When the users may not know best

Today I was asked for my advice by a colleague in another NHS organisation, who is just starting the process of researching and building a intranet. She has held some initial consultation sessions but feels disappointed that they haven't provided a comprehensive picture of the organisation's requirements.

I'm a fan of user involvement in websites, whether structured or spontaneous. My team and I have just re-launched our own intranet and we've found certain elements of feedback and interaction absolutely invaluable. But I've learned that sometimes the users don't know best; sometimes they need someone to step in and suggest what they need. Perhaps one of the skills of the web manager is to know where to draw the line.

In my own organisation - a large hospital with thousands of staff ranging from porters to professors - one of the first things I took away from our user involvement sessions was the very poor levels of computer and web literacy. Many staff didn't know the difference between our public website and our intranet (some didn't know the former existed; some thought the public could access the intranet).

Large numbers of my colleagues, especially those in clinical roles, had spent the vast majority of their working life in the NHS and had therefore been exposed to a very limited number of intranets of very limited quality and functionality.

So while consultation sessions are great for getting buy-in and getting a feel for factors such as these that may determine the broad strokes of your project, and may throw up a few gems, remember that some users may not really understand (or care) what you are trying to achieve or what is possible; they are focussed on their own problems. Take advantage of this and mine this source of really important information. You have to understand their requirements and then it's you, the web professional, who has to translate these into the form and frame of the website.


Some examples from our intranet project

• Staff said they couldn't find the documents they wanted. We knew this meant we had to be strict about version control, perhaps through restricting who can upload certain types of documents such as policies. It also meant clearing out the archives of old versions that are already saved to the site, and implementing a search engine that indexed the full text of our documents, not just titles and keywords.
• Staff claimed to be confused by the IT pages. On close inspection we could see that although the information was correct, we needed to implement a simpler information architecture and help the IT authors follow plain English guidelines, especially getting them to drop or explain all their acronyms. Some people we talked to didn't even know what FAQ stood for; I found this a bit shocking but it was a great example to share with IT!
• Staff told us they didn't know the difference between the public website and the staff intranet. We realised we needed to give clear visual signals to help them differentiate, so chose a colour scheme in startling contrast to both the old intranet and the public website. We gave our new site a new name that would scream "this is for staff and staff only". We are ruthless about ensuring that all content is written with an internal audience in mind.

User involvement is clearly still vital. Surveys, statistics, user testing such as card sorts and wireframing, and round-table discussion groups will make sure you base your analysis in the facts of working life in your specific organisation and ensure your solutions are successful for those who are actually going to be using them once the site is launched.

The sympathy vote

More cynically, involving a representative cross-section of your organisation also helps you get the support and sympathy of a broader base - not just your boss or the management.

During my own project, one of my key methods of engagement was to held monthly meetings with a working group of about 20 staff staff. I invited each of the major support services (such as IT, training and HR) and each staff group (medics, nurses, scientists and administrators) to send a representative. I deliberately didn't hand pick people I already knew, to try to get a fresh perspective.


The group didn't have any final decision-making power but they championed the project outside the team, as well as acting as a sounding board for ideas, a source of inspiration and a human face to the organisational monoliths - my living, breathing 'personas'. They also carried out practical roles such as proofreading and checking for broken links on the new site just before the launch. 


It wasn't perfect; sometimes I struggled to put together an agenda that would be useful and educational for them and of practical value to me. Sometimes their ideas made me want to weep - when they wanted to call our new site 'The Intranet' I had to remind them that half of our users don't know the difference between an intranet and the internet. But like all the user involvement, it helped me make decisions, sometimes supporting and sometimes challenging my thinking.

My increased closeness to the users, understanding their frustrations and their needs, also helped me keep believing in my ideals even when internal politics started to make things difficult. It's immensely tempting to give in when you are under pressure of time, money, or powerful people wanting their own way. You do have to interpret and cajole to get the best out of your users; but that pernicious senior manager will have no choice but to capitulate if you can prove your arguments are based on evidence garnered from your own organisation, as well as theoretical best practice.