Dealing with requests for news features: Whose homepage is it, anyway?

Who's got top billing?
Image by Michael Comiskey
and used under creative commons

Webmistresses and intranet-meisters will quickly recognise a serial homepage news item requestor.

  

This person thinks their service, event or publication is the only topic that anyone in the world/organisation can possibly be interested in, and is so vital it must be featured prominently for at least a month.

  

You might think you can feature it for a day or two and then remove it and they won’t notice – wrong. The moment you give something else top billing, your phone rings, and they’re telling you that they’ve had loads of feedback that no one can find their information.

  

That’s not to say their anecdotes aren’t true. Those who have always been given homepage features for prolonged periods may not think it's important to put much thought into their permanent pages – if indeed they have them. They've probably not thought about making them easy to find, using search-optimised language. They have also trained their users to be lazy, so now they expect to be able to spoon-feed their audience with a direct link, rather than using the search or A to Z or navigation occasionally.

 

What to do

• Spend some time with this problem user. Understand what they need, and offer genuine solutions where you can.
• Explain that it’s not wrong to expect users to have to work a bit and look past the homepage, as long as you educate them of the need to do so, and make the search and navigation work.
• Recognise that the web team may partly be to blame – have you actually checked that their pages are in the right places in the navigation, cross-linked them from relevant related pages, and done what you can to boost the return of logical search results? Is it easy to find archives of older news items?
• Explain that after a while users will become blind to the same old content. Better to take the feature away and bring it back again later in the month, because the visual impact of the change (especially of a new image, but even of the changing shapes of the words on the page) will do more to draw attention than a clipart icon that's quickly becoming part of the furniture.
• Explain the dilemma you're facing. For example, you might say there are 2,500 pages on the intranet and, believe me, everyone wants a slot on the homepage. We can’t possibly do this so we try to be fair, and rotate in everything in a timely fashion. but we must also ensure that the structure, search and permanent content is top notch, so everyone can find what they need regardless of the current homepage content. (Then drawn them into your plan to improve their permanent pages.)
• You may also be able to offer some alternative channels or widgets for promoting their content. For example, send them to internal communications colleagues for possible inclusion in the next all-staff email, or see if they can turn their news item into a question for a poll, interview for your staff magazine or feature for the chief exec’s blog. You might be able to re-purpose web news for your intranet, or vice-versa. If your organisation still has a print budget you could even send them off to a designer for a poster campaign.

  

Rather than seeing this person as a periodic pain, try to fix their problem. It may not rid you of the requests completely, but at least you’ll understand their requirements better and, with luck, they will understand why you can’t always give them top billing and appreciate that you are doing your best to help them. You’ll also hopefully be better able to differentiate between times when they are ‘crying wolf’ and when there is a genuine need to pull out the stops for them.

Who we are: who cares?



Paper jam (courtesy of nanny snowflake
and used under creative commons)

One of my colleagues, Mrs P, is currently campaigning against the ‘Who we are and what we do’ paragraph that seems to start every department’s intranet page.

We’ve got something similar on the website. It’s a waste of space because basically, most users don’t care about the history of the department, who was appointed when, or your strategy for waste disposal. That’s not how your service users are going to get their job done. And all that descriptive padding and self-congratulation just gets in the way of people finding the useful information.

Intranet navigation shouldn’t be department-based because, for example, not everyone knows instinctively that it is IT who fix networking issues with the photocopiers, but if you have run out of toner cartridges, you have to log a call with Facilities instead.

People shouldn’t need to know who to ask to get a job done.

It’s even more important on a public website. How is a member of the public going to know that they’ll find information about their asthma clinic under the Specialist Medicine department’s page?

In theory, no matter how the navigation is structured, you’d hope that search would help. If you search ‘photocopier’ or ‘asthma’, you’d expect to find your answer.

But often departments are so busy describing themselves in important-sounding management jargon, that the simple keywords for their services are missing entirely. Or they are hidden on the fourteenth sheet of a gaudily-designed and poorly-constructed Excel document named ‘Useful Information v2.0’, where they are mentioned in a couple of FAQs.

So Mrs P and her team are re-focusing the intranet content around Services (things people can help you do) and Tools (things you can do for yourself), and keeping department information down to a minimum.

Please look for this ego-fluffing guff on your website or intranet, and consider whether it adds any real value for your users. If not, it’s most satisfying to hit delete... and wait to see if anyone actually notices.

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.