Beware of using opinions to design an intranet
Categorised under: Intranets, Usability & user-centered design
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?
James Robertson is the Managing Director of 
5 Comments:
It’s an interesting topic James…I guess in a way you asking how do you balance keeping the stakeholders happy with delivering a valuable intranet (both important goals).
In my experience when it comes to intranet redesigns almost every stakeholder has an opinion about what is should look like (stakeholders usually include the project sponsor, senior managers representing the business, IT, internal comms, marketing and of course, the end users). This is a good thing because it means they are engaged. However, quite often these groups have their own agenda and sometimes it’s a case of the wheel that squeaks the loudest getting the most grease. Sometimes to the detriment of other less vocal groups.
The big challenge I have found is how to keep the stakeholders happy (very important since they are paying for the project) while at the same time providing a solution that provides a real benefit to the whole organisation. Don’t get me wrong, these goals are not necessarily at odds – just sometimes the focus of the redesign can be influenced in a way that does not necessarily provide the biggest benefit.
The approaches you have suggested – needs analysis, usability and information architecture – are very helpful for providing a structure around implementing the redesign.
I have also found the following to be very useful in building focussed teams that deliver valuable solutions:
* Set clear, measurable, and agreed objectives at the beginning of the project. All redesign efforts are then aimed at acheiving these goals. Some examples include, reduce the number of calls to the internal help centre, reduce the time it takes to process a customer enquiry, increase the level of employee enagagement (can be measured using Hewitt survey), increase the number of people who use the intranet
* obtain intranet case studies from other organisations to support your objectives – Jakob Nielson’s 10 best intranet reports provide some good examples as does your innovation awards
* prototype asap- it’s not until people see something that they become truly engaged (I was once involved in a project where it was 5 months before we even had a home page to discuss – way too long!).
I’m very taken with the work of Ellen Di Resta & Sean Howard in the related area of understanding consumer needs: http://www.craphammer.ca/2009/02/the-latent-truths.html
Intranet needs could be split into explicit, tacit & latent.
The unreliability of self-reported opinions in market research & product development is well-known and a lot of the same issues apply to intranets…
James, Thought-provoking post. We are currently in the middle of a redesign of our intranet using a Usability company to deliver a research based approach to the redesign. Our internet redesign is due to be released in about 6 weeks and that process seemed pretty smooth. It has been more challenging to deliver a good IA for the intranet, as opinions are more strongly held. So far, we have done an open card sort and a closed card sort exercise and we are about to create a wireframe to test. It is interesting to see what a variety of views there can be about where things belong.
@Andrew, all great suggestions! I think the initial step of identifying project objectives is particularly important. Without this, intranet projects can become “rudderless”, shifting at the whim of stakeholder and user opinions.
@Moria, all sounds great! This is exactly the sort of processes intranet teams should be using. As you indicate, while these projects do take some effort, they can go more smoothly due to the strong underpinning methodologies and frameworks. Good luck with the relaunch, I’ll look forward to hearing how it goes!
One Trackback
[...] Beware of using opinions to design an intranet (tags: intranets guidelines intranet) [...]