Intranet projects are challenging at the best of times. Sites are large and content rich. Project teams are often thrown into the deep end, with many constraints and expectations.

Intranet projects may confront challenges such as:

• unclear intranet ownership and governance
• tight timeframes
• limited (and often insufficient) budgets
• varied (and sometimes competing) stakeholder opinions
• large number of end users (staff), with widely varying needs
• technology considerations and constraints
• limited team experience and skills relating to intranets
• poor access to best practices and other intranets

Is it any wonder that intranet projects go off the rails? Even the most experienced and well-resourced teams can struggle under these circumstances.

It is useful to explore common mistakes made on intranet projects. These have been distilled from observations across many organisations, in both the public and private sectors.

The purpose of outlining these problems is to help teams avoid them, and to highlight good practices.

Even experienced teams can fall into design traps

Eight mistakes

This article outlines eight common mistakes encountered when designing or redesigning intranets:

1. Not testing with staff
2. Designing by opinion
3. Designing only half of the intranet
4. Taking a publisher’s perspective
5. Allowing technology to rule the design
6. Copying intranet designs
7. Designing in a hurry
8. Not designing for the long term

These are explored in the following sections.

Mistake 1: Not testing with staff

A lot of hard work is put into designing the new intranet. A number of options are considered and compared. Designs are carefully refined, tweaked and tuned. A home is found for every page, each in its logical place. The new intranet is easy, intuitive, and makes perfect sense.

Makes sense, that is, to the designer of the site. Which is completely to be expected, as they are the designer. They have lived every aspect of the project for months, and know every corner of the site. The real question is: does the new intranet make sense to staff?

This is the most common mistake made by project teams when delivering a new intranet. Designers are not users. The way they think is very different to that of ‘normal’ staff, and their expectations and practices also differ.

It is a tragedy when a huge amount of effort is put into delivering a new intranet, and it proves not to be any easier for staff. Yet we have heard this many times.

The key omission is testing with actual end users: staff. There are a range of practical, hands-on techniques which can be used to evaluate designs and navigation, and to refine designs accordingly. These include card sorting, tree testing (card-based classification evaluation) and usability testing.

Taking designs or mockups, putting them in front of users and asking “what do you think” does not count as testing. This gathers opinions, what people think about the design, but does not ensure that the design is actually easy to use when it comes to completing common tasks.

People’s opinions about what they would do, or want to do, often diverge from what they actually do in practice. (This is why many people talk about eating healthily, and yet McDonald’s is the biggest restaurant chain in the world.) Hands-on testing goes beyond this to assess more realistically whether the intranet is easy or hard to use.

Teams who make use of these techniques ensure that all the effort involved in an intranet redesign leads to the desired outcome: an intranet that really does work well for staff.

Remember that stakeholders are not users

Mistake 2: Designing by opinion

There is no shortage of opinions on what should go in the intranet, and how it should be designed. These come from stakeholders, senior managers, staff and peers. One of the most difficult aspects of designing an intranet is to cut through these often competing opinions to produce an intranet that works well for staff.

Stakeholders are clearly an important group when designing an intranet, and projects can tend to rely on workshops and sessions with these managers when determining intranet strategies.

There are, however, considerable risks with this ‘design by stakeholder’ approach. First and foremost, they are not the actual users of the site. It can also lead to a publisher-centric approach to site design, driven by the needs of those who write the content, rather than those who use it.

Often, an initial design or prototype is developed from stakeholder preferences, and taken to staff, who are asked ‘what do you think of this?’ A wide range of staff are involved, each expressing their personal opinion about the relative merits of different options, and making suggestions on potential improvements.

Staff know an awful lot about the work that they do, but they don’t know a lot about intranets (nor do they need to!). Their input is also coloured by their experiences with the current site.

Intranet projects can therefore spend considerable effort delivering a site that meets the expectations of stakeholders and staff, without producing a site that is actually easy to use in practice. Staff complaints continue, and the intranet continues to struggle.

This doesn’t mean that stakeholders should be shunned and staff ignored, quite the opposite. What is needed, however, is a structured way of engaging with the organisation that obtains the necessary involvement (and engagement) to produce a site that works.

The intranet homepage is just the start of a good design

Mistake 3: Designing only half of the intranet

The intranet homepage is by far the most visible page on the site, and it gains the greatest traffic. It is not surprising that most design attention is focused on this one page on the site.

The design process works down from there, typically concentrating on the top layer or two of the intranet. Below that, pages are left to business units and content owners to manage as they see fit. Unfortunately this is doing only half the job.

Staff come to an intranet to find a specific piece of information, or to complete a task. This is successful when they have obtained what they need.
Having a well-designed intranet for the first few clicks means little if the staff member is then dumped in a poorly managed intranet section or site.

For example, it is not hard to work out that the leave form will be found in the HR section, making the first click easy to choose. If the HR section is very poorly designed, staff will still struggle greatly, just a single click into their search for the leave form.

Key sections of the intranet need to be designed all the way to the bottom of the site. This means applying good design principles and methodologies to content owned by decentralised business units, beyond just the top levels of the site.

Content must be structured according to staff needs

Mistake 4: Taking a publisher’s perspective

Intranet content is owned by someone, such as HR, finance, IT, customer service or product development. These content owners are responsible for maintaining ‘their’ content on the intranet, whether it’s one section or a whole ‘site’.

It is human nature that content owners will create and publish content in a way that makes sense to them. They use terminology and jargon that is familiar to their business unit, and will structure content in a way that is logical to them.

This ‘publisher-centric’ approach to intranets is widespread and corrosive. It means that staff have to know who owns the content before they can find it, one of the most common frustrations for users, particularly in large and complex organisations.

It leads to intranets that are dense in jargon, where whole sections of the intranet are named in surprising ways. For example, staff all understand who ‘HR’ are, and what they do. These areas, however, have a tendency to rename themselves and then use that as the navigation on the intranet (‘People & Performance’ anyone?).

At the worst extreme, this produces intranets which are little more than a collection of independent sites, islands of content in a common ocean. This is commonly the case for very large organisations, where business units operate independently and may be the size of a medium-sized firms in their own right.

The challenge for intranet designers is to move the site towards a ‘user-centric’ approach, where content and functionality is delivered in a way that will be easily understood by staff. This requires a clear vision, excellent training and support for content owners, and ongoing change management.

Make sure the redesign doesn’t become a technology project

Mistake 5: Allowing technology to rule the design

Intranet technology is constantly evolving and improving, as evidenced by the current spread of SharePoint and wiki-based intranets. New tools offer greater capabilities and new approaches that can benefit organisations and staff.

While technology improvements are always appreciated, they also lead intranet and project teams into common traps.

The first is to assume that more functionality is better than less. With any new tool, the temptation is to enable most (or perhaps all) of its features. This can, however, quickly overwhelm the readiness of authors, content owners and staff (end users). With greater functionality also comes more complexity, with the requirement for additional training and support.

There can also be an assumption that if a capability is offered in a product, particularly a widely-used solution, then it must work in all situations. This overlooks the importance of understanding staff needs, matching the organisational culture, and setting a manageable pace of change.

It takes a lot of time and effort to ‘digest’ a new technology solution, understanding how it works, and becoming proficient in its use. For this reason, intranet redesign projects can all too easily become technology projects, with the IT aspects overwhelming the more important goals of improving the site itself.

Changing technologies can force a complete migration of content from the old site to the new platform. In turn, this triggers a ‘big-bang’ redesign, with all the effort that entails. This eliminates the possibility of incremental improvements, or step-wise changes.

Of course, if the current technology platform for the intranet is completely broken, then a new product will be very welcome, and likely a necessity. Technology enhancements also help to drive the steady pace of intranet evolution. Care must be taken, however, to ensure that the benefits of the new tools are maximised, while the impact is reduced or mitigated.

How well do common designs work for staff?

Mistake 6: Copying intranet designs

Jakob Nielsen of Nielsen Norman Group (www.useit.com) once compared the homepages of a number of intranets, overlaying them to show that they all have a very similar design. This is useful to know, but it is more important to ask: are these designs any good? Or are the intranets all the same, and equally wrong?

The widespread nature of staff complaints about intranets suggests that we have some way to go before we consistently deliver sites that work well. With many organisations falling into the traps outlined in this article, the danger is that copying another site may simply copy their mistakes.

It is useful to see other intranets, and to take from them ideas and design elements. Care must be taken, however, not to simply replicate the ‘way things are done’ without checking that it will work well for your staff (see mistake 1).

Intranets work best when they reflect the organisations they serve. Every organisation is different, based on its purpose, size, history, culture, geographic spread and a hundred other factors. For this reason, there is no single ‘best’ intranet design, only the design that best meets the needs of staff in your organisation.

Project teams also need to be wary of common ‘rules’ and ‘principles’ which turn out to be myths. The ‘three clicks rule’ is the most widespread example of this (see the earlier article The three clicks myth). Just because something is done widely, doesn’t mean it’s right.

Mistake 7: Designing in a hurry

Intranet projects can be hard to get off the ground, and significant time is spent building support, gathering resources and obtaining budgets. Once final approval is gained there is significant pressure to deliver a solution quickly. If the intranet team has been talking about the project for over a year, there is little patience for a drawn-out redesign.

This forces too many teams into a rapid redesign, completed in a small number of months, or even weeks. Once trapped into ‘designing in a hurry’, intranet teams are forced to make the project activities fit the overriding time constraints.

This compromises several key aspects of the project. Firstly, it limits the time and resources that can be spent on understanding the current intranet, and exploring staff needs. The design process itself needs to be cut short, potentially preventing any meaningful testing with staff. Lastly, there is no time to review and correct content, leading to a straight migration to the new site (‘garbage in, garbage out’).

These short-cut projects can also come about when a change in technology platform is driving the redesign. As the technology deployment slips, it eats into the time that was allocated to the redesign itself.

There is little value in relaunching an intranet if it’s not better. Even short projects take a lot of effort, and will undoubtedly generate a lot of stress on the project team. If the new site is not clearly better, the value of the redesign will certainly be questioned.

A full-scale intranet redesign will not take less than 9 months, and 18 months is common. (Any longer than that, and the project has lost its way or has attempted to do too much.) Expectations around these timeframes need to be set at the outset, and constantly communicated to stakeholders.

This is not to say that all redesign projects need to be this large, and there are many benefits to taking an incremental approach to the redesign, which are discussed in the article Intranet change: evolution or big bang?

Intranet redesigns will take more than a few months

Mistake 8: Not designing for the long term

Assuming the design or redesign project went well, the intranet looks great on the day it is launched. The layout is elegant and attractive, navigation is intuitive, and every piece of content has its place on the site.

Now the challenges really start. From the day the site is launched (or relaunched), requests start rolling from the business. This includes new content to be added, entirely new sections, content updates and additional functionality.

Everyone also wants their content, news or project on the homepage. Requests travel up the chain of command, until a senior manager requires the item to be added to the homepage.

Very quickly, the clean design and intuitive structure can start to slide. Unless managed well, the intranet will quickly become a mess. This is like cleaning up the attic: it’s perfect one day, but fast forward two years and it’s filled again with junk.

Intranet teams can overlook the longer-term sustainability and manageability of the site when developing a design. Insufficient space is left for additional items. Page elements have unclear purposes, and new items don’t have a clear home.

These sustainability considerations sit alongside the ease of use for staff, and they are equally important. A well-considered design will greatly help the intranet team to manage the ongoing updates and changes to the site, as well as somewhat mitigating the impact of internal politics and opinions.

Conclusion

Intranet projects are often challenging, and hidden away within organisations, it is not surprising that teams fall into common traps.

Failing to test with users, or designing by stakeholder opinion, can impact heavily on the ease of use of the final site. Limited time and a focus on just the top levels of the site also reduce the benefits that are delivered.

Many of these issues can be easily addressed when a robust methodology is followed. Even within tight time and resource constraints, a simplified approach can be taken that delivers many of the same benefits.

For a starting point on an effective intranet design methodology, see the following articles:

• What is usability?
• What is information architecture?
• Intranet (re)design wrap-up