ASTC-NSW 2010 day 1: Delivering an intranet that works for staff

This week I’m attending the ASTC-NSW 2010 conference in Sydney. These are the notes that I took during a session by James Robertson. All the credit for the content and ideas goes to James. Any mistakes are mine.

James Robertson gave a presentation titled “five ways to deliver an intranet that works for staff”. He covered these topics:

  • Understand what the staff needs
  • Make the site design useful
  • Focus on key content
  • Separate “back office” content
  • Test your design with the staff

Understanding what the staff needs

People will use the intranet if it’s useful. You need to talk to the people. James’s tip is this: Don’t ask people what they want! There’s a difference between what people say they want and what they actually do.

Instead, we need to understand what people are actually trying to do. Find out what works well for them, and where they are having difficulties. In an interview, don’t even ask people about the intranet. Instead, ask them about their job. Ask what information they need to do their job and where they get it from.

James discussed a number of needs analysis techniques, and gave us a link to his website where there’s more detail.

Making the site design useful

James discussed the fact that typical intranets give you no information at all on the home pages. Instead, they’re full of boilerplate text, a welcome message or a photo of the director. Instead, use the body of the home page as a navigation page, in plain language and linking to the information that’s useful, categorised into chunks. This is where, as content people, we have a lot to say about the navigation.

Ensure that the links are task-focused. For example, add a block of “how do I” topics such as “apply for leave”, “access my email from home”, and so on. Using task-focused design is something all technical writers know, and this is how we can help in the intranet design.

One of the categories on James’s slide was “How, what where”. Someone from the audience commented that this can quickly get out of hand. James agreed: FAQs are evil! The same applies to “quick links”. They can quickly expand to an amorphous mess. We need to design for tasks that are useful to staff, and we need to design for sustainability. Some designs and information architectures will make it much easier for the site to be manageable.

Focusing on key content

We all know what good content looks like. The challenge is, how to we get this content onto the intranet. One problem is that we have amateur authors adding content to the intranet. They weren’t selected for their ability to write, but they’re doing their best.

James suggests that we need to recognise this fact: Not all content needs to be of equal quality. Some documents do, such as HR policy. But communications from IT, for example, don’t. Currency is more important than quality.

We need a graduated governance model. We have limited resources. We will target them at high value content.

Separating “back office” content

By “back office” content, James means those large amounts of information specific to one area of the organisation, such as finance modelling spreadsheets and engineering documents. This content is often the content that people need to do their job. We can take it off the intranet and put it somewhere else. These are the collaboration sites for specialised bulk content. The governance of these is critical, to ensure that they can be managed and that people can find the information.

Testing your design with the staff

We need to apply use-centred design. James was running out of time here, so he talked fast through the techniques such as card sorting, tree testing to test navigation on bits of paper, usability testing.

These are the techniques that we can use to combine information architecture, content and strategy into a site that actually works for staff.

My conclusion

James is hilarious and informative. I thoroughly enjoyed his talk. Thanks James!


About Sarah Maddox

Technical writer, author and blogger in Sydney

Posted on 30 October 2010, in technical writing and tagged . Bookmark the permalink. 2 Comments.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: