I’ve just settled back in from my most recent conference tour, and I’ve spent a lot of time talking with intranet teams from a wide variety of organisations, across three continents. Based on the types of approaches I’ve seen to intranet designs, I’m going to state:

Beware of using opinions to design an intranet

There are two sets of opinions that too often shape the design or redesign of an intranet:

Stakeholder opinions

A common approach to working out what should go on an intranet is to talk with stakeholders from across the organisation, either one-on-one, or in a workshop format. These stakeholders represent common business areas, including communications, HR, IT, finance, policy and product.

These discussions usually focus on topics such as:

• What are the strengths of the current site?
• What are the weaknesses?
• How should the site be improved?
• What additional functionality should be implemented?
• What content should be published?

This approach has a number of strengths:

• comparatively quick and easy
• gains engagement from key stakeholder groups
• addresses internal politics
• the right stakeholders will have valuable input

There are, however, a number of huge problems with this “design by stakeholder” approach. First and foremost, these are not the actual users. While they may claim to speak on behalf of staff, our experience is that this is not necessarily the case.

This is also a very “publisher-centric” approach, driven by the needs of those who write the content, rather than those who use it. This can lead the intranet back to a range of ineffective approaches, such as filling the site with hundreds of linked documents (such as policies), or packing the homepage with nothing but news.

Stakeholder groups may also not know a lot about intranets, beyond what they’ve experienced on the current site. Alternatively, they may get caught up in the latest trends and fads, based on what they’ve heard at conferences, or what “experts” have said. This makes it harder for these groups to move beyond the current site, or to deliver a substantially improved design.

What is the alternative?

Conduct structured needs analysis, spending time with the staff who do the actual work to identify gaps, issues and opportunities. This will generate a very clear picture of the current site’s strengths and weaknesses, as well as providing a solid foundation for the design process.

This is not to say that stakeholders shouldn’t be involved, quite the opposite. What it does mean, however, is that these groups should provide input on business issues, rather than acting as a design committee. A great design then finds the intersection between business and user needs.

User opinions

Once an initial design or prototype has been developed, we often hear of teams taking this out to staff to ask: 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. Some teams even call this “usability testing”.

This is not usability testing, it is the gathering of user opinion. In many ways, this is even more dangerous than designing based on stakeholder input.

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!). Time and time again, it has been shown that user opinions about what they need don’t match what they actually do in practice.

This would be like IT going out to staff chosen at random, and asking them how the standard PC environment should be configured, and what server settings to use.

What is the alternative?

There are two disciplines that provide very concrete techniques for designing sites that are easy to use: usability and information architecture. Both provide a toolbox of approaches that structures the design process, and conducts realistic tests to ensure that the new intranet really is easy to use.

This still involves a wide range of staff, and so delivers the same engagement and change management benefits. It also doesn’t need to be some huge project with hundreds of tests, or piles of theory. Instead, lightweight processes can be used even in projects with tight budget or time constraints.

Delivering intranets that really are better

By managing the role of opinion in the design of intranets, we can greatly improve what is delivered by our redesign projects. Using structured techniques will help to directly align the intranet to the needs of staff, while supporting business objects. These techniques will also help to cut through the often confusing sea of opinions and ideas that surrounds every intranet project.

What are your thoughts?