Conference Notes

Notes on "Intranet content: Accessible, Usable and Useful", Aug 24

The two final sessions of the day started at 3pm, with Nick Besseling from The University of Auckland speaking on Intranet content: Accessible, Usable and Useful. In terms of Web 2.0, check out Why I Hate Web 2.0. Nick is very passionate about what he believes, and his passion for clear content came through.

Nick started by saying that we’ve talked a lot about applications that create content, but we haven’t yet spoken about making truly great content. He’s going to correct this. Two key questions: (1) who are your users?, and (2) what are you trying to achieve? In terms of the latter, it’s most about taking an action or making a decision.

Users need to be involved in Intranet design, and their feedback is good. Consider them as your customers, listen and respond to their concerns, meet their information / decision needs, and be visible and accessible. Don’t hide behind an email address or feedback form, but rather get out and visit people.

Intranets are not websites. They are business tools to support users get their jobs done. It should help with productivity, and align with business goals. Stickability is bad for intranets … help them make their decision quickly. Don’t use the intranet for ego marketing … fight against the egos and internal politics.

Good intranet content is:

  • Accessible … users can find and see it. Follow consistent styles, and a use a good contrast of colour, eg, black text on white pages! It’s fairly simple. Does it sit logically within the navigation structure? Architecture is based on users’ point of view. And ensure that it is indexed by search engines … but get something that works! The quality of search results would work better if we took away the crappy content.
  • Usable … can users follow and use it? Put key points first. Use small chunks of content. Headings and bullet points consistently used show a clear structure. Scrolling is okay, but in-page navigation is essential.
  • Useful … does it help users work? Is the information really useful for your users? Is it what they need to help decisions or actions? Is it up-to-date and still relevant?
  • Use Plain English … avoid group and department specific language and colloquialisms. This will work for some things, eg, HR policies. Realize that the reading ability of users may differ, and provide a glossary of terms.
  • Don’t crowd the page with irrelevant promotion … just say what needs to be said.

In terms of writing for screen vs. print, there are some things to note. Users skim and scan rather than read, so you need to cull some of the content. Users read 20-25% slower online. Two ways of helping users: (1) keep paragraphs to 3-4 sentences expressing a single idea, and (2) make sentences focused and short (15-20 words maximum). Online is more dynamic, so we should revise content more regularly. Think about linkages between content items in the larger site. And finally, titles, headings and meta data is very helpful for search engines.

With blogs, wikis and forums, you can not impose the same style controls on people. They won’t like it, and they won’t use it. You can’t force usage, it has to be emergent.

Offer an “How Do I?” section, putting content into natural language questions for users. This should provide information on key tasks and processes, it should support other site information, and it should group common verbs.

Links should be contextual to the text, not “Click Here”. Links help users scan through the content. Whether you underline links or not, you should be consistent across the whole site. Links should be easily recognized. If links are underlined, don’t use underlining for other headings as it will confuse people.

Images should provide context and support to content … they should be relevant. Avoid open slather for content owners to ‘design’ pages. Content owners are generally not good designers.

Provide guidelines and training. Guidelines are essential, and should be pretty firm. Some flexibility in a large organization is necessary. Advocacy is the best approach, but policy can help when people won’t take the hints or arguments. The policy can help avoid battles on styles and approach, and it should be developed in collaboration with stakeholders. This will get you so far, but you may still have to make the final decisions.

Training on software is important, and training requires good documentation. Formal training for CMS or other software is essential. However note that teaching everything is harmful. Let people find out some things. Train also on the content; train with existing content where possible. Break people up into small groups, with an emphasis on discussion. You don’t need external consultants to train people how to write … work it out internally as a peer development approach.

Categories: Conference Notes