Intranets and usability

It’s now been a little over a decade since I designed and built my first Intranet. I had been building websites for a university for some years, but my first Intranet was my first public service job, and my first experience of how government handles internal communications and knowledge sharing.

Back then, in the 1990s, we lived in a Web 1.0 world where websites had simply replaced previous electronic distribution methods like FTP, News Groups and electronic Bulletin Boards. I remember very clearly creating pages with early WYSIWYG editors like Hot Dog and the first version of Microsoft FrontPage.

For me, the early days were a mixture of creativity, graphic design and HTML coding skills. Building corporate Intranets, though, saw other dimensions added, like the battle for real estate on the front page. I found myself surrounded by people who felt that unless their area appeared there, then no one would find their information. What usually resulted was an Intranet designed by committee – little more than a laundry list of links of business areas with no context and lots of downloadable PDFs and Word documents behind them.

And of course, the IT department would then train staff how to use this ‘tool’ because, realistically, the navigation was far from usable – it only served the “Powers That Be” and wasn’t designed in such a way so as to make it usable by the people who would need it to find information.

I remember staff then trying to rely on ‘search’, but, again, people don’t generally write for others in mind. They write for themselves. This meant the terms they used in search just didn’t match the words in the documents and so the search engine was then blamed for not being good enough.

The behaviour that typically follows is simple – print out the corporate directory to phone someone and ask them to email them a copy of a document directly. It’s a behaviour I’ve seen plenty of times now. It’s usually the first symptom that your Intranet just doesn’t work as well as it could.

I quickly learned, though my first years in government, that the best and easiest means for building an Intranet so it would actually be usable was to involve those people who were actually going to use it – not their bosses, and not through committees ^[1]. Fortunately, not many managers have time to come to a 2-3 hour workshop. Rather than sit in a room, though, and just ask people to talk about what they wanted, I learned instead to apply collaborative design techniques.

The first tools I learnt as an Information Architect remain my favourites today.

They are:

• Personas
• Card sorting
• Collaborative web page design
• Prototyping the solution

Personas

Starting with Personas is an awesome means of setting the scene for workshop participants.

Card sorting workshop. Photo Credit: Jorge Barahona

It gets everyone thinking about who is going to use the Intranet, from newbies to veteran staff members.

I ask the group to come up with a name, contribute to the person’s background, and to the picture by drawing from workforce statistics from the agency’s own HR area to make it a real representation of a staff member. I also encourage people to have fun with it. Whether they like or dislike the persona they create, though, this person is the one they will need to keep front of mind when going through their other activities.

Card sorting

I then follow personas with card sorting. I put a list of all the content into a spreadsheet and get it to produce a list of 100 random items and print them out onto small cards. I then put people into groups of 3-4 and ask them to sort the cards into themes –  like with like –  and label the theme. Printing each card set in a different colour means I can differentiate each of the groups’ preferred ways of collating the content once they’re done.

As each group sorts cards into themes I usually walk around and challenge the way they’re doing things (usually just by asking questions). People’s first reaction is to simply reproduce what they know and use the same terms, acronyms and labels. Of course, most of these conventions will result in an Intranet that is unusable by a new employee, so I ask whether the labels they’re using will be understood by the personas we created earlier in the workshop. In my experience, this approach has an instant affect. Given people contributed to creating the persona in the first place, they find it difficult to disagree when you point this out.

Having each group present their themes and card categories to other groups is the next step. It will quickly become obvious to everyone that people think about information in different ways. Having a few managers in the room to witness this is also worth its weight in gold.

Collaborative web page design

The final task is to have each group design a home page for the Intranet and to put their categories onto the page as the site’s navigation. I then ask each group to present their ideas to everyone else.

It’s these tasks that will give you your information requirements for your Intranet, one that will align with how the site’s users think about their information. Putting together that navigation, though, isn’t always straightforward because I rarely find that everyone comes up with the same categories, themes or designs.

Firstly, people take the cards whose content labels have the most meaning to them. That is, the first cards people pick up either represent the most important content, or the content used most frequently, or both. These cards will be placed in a pile to the left with subsequent piles moving toward the right. This order of sorting and collating cards left to right will give you the navigation order preference.

The next step, though, is to record the sort order of all cards across all groups in an Excel spreadsheet. Collapse similarly labelled categories and assess whether or not a piece of content appears more prevalent in one category or another. What you end up with, after analysing the results, importantly, is a navigation structure that will match the way people think about their information.

Prototyping the solution

The last task is to prototype the solution. This involves creating a mock-up of your overall design and findings and asking people to comment and test whether your solution will work for them. There are lots of different types of prototypes, from sketches on paper through to clickable HTML, the later of which can be easily done through software like Adobe Fireworks or my personal favourite Axure RP. These tools allow you to create a graphic representation of your solution.

Paper prototype. Photo Credit: Samuel Mann

I normally use Axure to create a high fidelity HTML representation of my solution. I even include the banner and icon graphics from the graphic designer so that it looks as real as possible, make the navigation clickable, and put in existing content so that it feels real. Once this is done I give people a task to try and find that content and record the time if takes to find it to assess whether the new solution is better than the existing Intranet. Of course, if you’ve put everything together properly, and you’ve incorporated all these user-centred design elements, then all will be fine.

I use these techniques every time I design, build and project manage my Intranets. If you adopt these simple tools yourself you’ll definitely see an improvement in your Intranet.

Back to top

Name: Matthew

Web Site: http://magia3e.wordpress.com

Bio: Matthew Hodgson is an experienced social media and web strategist with 15 years experience in information architecture, information management and knowledge management, working with the government and commercial sector to deliver innovative solutions to difficult web problems. He has published papers in the areas of social psychology, has lectured at the University of Canberra on social computing, and is regarded as one of the most engaging speakers on information architecture, agile business analysis, user-centred design, and social media in Australia.