Planning the Useful Intranet

Know Your Audience...

The key point of usability is having an understanding of your users so that you can create to match their requirements and create an intranet with your audience in mind. The users of the intranet are more important than the developers or the designers; and your role as a creator of the intranet is to support them in their day-to-day tasks.

"The users of the intranet are more important than the developers"

You cannot assume that you know what is appropriate for your users. You probably have significantly more experience with computers than they do, and you will use the intranet for different day-to-day tasks than they will. Nor can a book like this one tell you what is right for your set of users; the only ways of telling what is appropriate for your individual audience is to employ user-centered techniques, such as the ones described in this chapter.

If you already have an intranet, then you need to identify how well your audiences are currently supported by intranet content. If there is an information void in a valuable area, then you need to identify it and target content to fill it. You cannot do this by using server statistics to identify the most and least used areas of the intranet, because the required information may not be on the intranet! Instead, you must use techniques such as user interviews and analyzing the words used in intranet searches to find out where information is missing.

... But You Have Lots of Audiences!

The problem when designing an intranet is that you have a number of different audiences, all of whom need to be supported. For example, possible audiences for your intranet might include:

• A new employee looking for site maps, HR information, and an address book with photos to help him put names to faces.

• An experienced employee who fills in timesheets and searches the company address book several times a day.

• A member of a Customer Service team, who needs fast access to customer information and support databases while on the phone to customers.

• A press officer, who needs to ensure that internal staff are aware of company-related news.

• A salesman out on the road, who needs fast access to his client information over a modem or from a PDA.

• A department manager who wants to keep the company informed about what her department is doing, to help her team work together well, and to assess the company's performance.

• A member of the web development team, who needs to maintain and update the intranet effectively, and view logs to see how the intranet is being used.

Each poses different usability challenges.

For example, new employees won't understand the company jargon. For them, the layout of the intranet must be easy to understand, and the intranet applications should be simple to learn. They will also need specific content, for example a glossary of company-specific terms.

The experienced employees value efficiency more than ease of learning. The intranet is a tool for them, and they want to use it as quickly as possible to get the results they want. Although a step-by-step "Timesheet wizard" might be useful for the newcomer, it will just frustrate an experienced employee because they know what they want to do and just want to do it quickly.

We'll talk more about the problems the salesman faces, and their solutions, in Chapter 13.

You shouldn't assume that these categories are fixed. For example, the experienced employee who knows the timesheet system inside out, and all its shortcuts, may still be flummoxed when she tries to enter an expense report over the intranet, or needs to visit an area of the intranet that she hasn't seen before.

However, despite the problem of multiple audiences, in some ways it is easier to improve the usability of an intranet rather than an Internet site. Although an intranet may have more distinct audiences than an Internet site, the intranet users are also easier to reach for tasks such as usability testing than Internet users are (they are probably all listed in your company address book). They also have a vested interest in increasing the usability of the intranet, as doing so will allow them to do their jobs more efficiently. In addition, you know what the business goals of your organization are, so you can build the intranet to effectively support these goals, whereas if you're working on an Internet site, you're unlikely to know the goals of your users.

So, what can we conclude? Designing a usable intranet is difficult? Yes, it is, as demonstrated by the many company intranets that are not usable, but by listening to (all) your users and having their needs in mind you can make your intranet usable. The rest of this chapter will be about methods to do just that.

Peoplewatching

In Chapter 3, we described the process of "stakeholder interviews" to find out what your users believe should be available on the intranet. This process should be repeated to find out how your users believe the intranet should be organized and how it should work in terms of usability.

You can carry out formal user interviews, but this is often unnecessary. Just chatting to people at their desks for quarter of an hour about the intranet can be very informative. Ask about their problems with the current intranet, what they like, the parts of their daily routine that could be made more productive by it, and whatever else they want to talk about. Make sure you have a notebook to jot down their ideas. However, in a large organization it may not be possible for you to visit representatives of each of your audiences - be careful that you don't skew the intranet design to reflect the needs of those people that you are close to at the expense of other staff such as those in branch offices.

Another useful approach is not to ask people what they need, but to watch them doing their everyday work instead. Sometimes, you will find more information this way than by an interview, perhaps because they are reluctant to tell you their problems for fear of appearing stupid, or perhaps because they are so used to a problem that they work around it without even noticing. This approach can be time consuming; an alternative that can have some of the same benefits is to ask a user to log their intranet usage for a day on a sheet of paper. As they perform a task on the intranet (or perform a task that could have been done via the intranet), they should jot it down, and note what worked well and what didn't. This will often stir their memories as they look critically at the tasks they perform.

It's important to make people feel that the intranet is being created around their needs, rather than purely for the imparting of corporate news. User interviews are an important step towards that, as long as results are seen to be acted upon.

You can also find out a lot about how an existing intranet is being used by checking its server logs - you should be able to see which parts of it are frequently used, and which intranet applications are being totally ignored. You may also be able to use a tool to analyze user data by individual or by group to see what pages and applications are being used by which intranet audiences. Never take this as the final word; after all, there's no way of telling from the logs whether an intranet application is not used because it's hard to use, or because it's not useful, or because users don't know it's there, or because there's a better alternative used in practice. Instead, use it as a basis to steer your conversations with users.

Note

Lots of companies nowadays have intranets so users, particularly new employees at your company, may have experience of several other company intranets. Pick their brains about the best and worst aspects of the previous intranets they've used - there may be ideas you can use, or pitfalls to avoid.

For more information on effective ways of using of server logs to improve usability see Practical Web Traffic Analysis (Fletcher, et al., glasshaus ISBN 1-904151-18-3).

When speaking to users, there are some techniques you should bear in mind:

• Avoid leading questions - you want to find out what the user thinks. By asking leading questions, you give them clues as to what you think the "right" answer is, and they may simply agree with you. This can provide reassurance to you, but it's not useful in improving usability.

• Ask open-ended questions that elicit further responses. Avoid simple yes/no questions; very few questions regarding usability are so clear-cut that these are useful.

• Be enthusiastic and interested - this will encourage the user to talk to you, and help convince them that you are going to act on the results of your talk.

• At the end, you may find it helpful to ask for feedback on your own user-interviewing technique, to help you improve your user interviews in future.

• Make sure the user knows how to contact you if they have further thoughts.

A good source of interviewing techniques is How to Get Beneath the Surface in Focus Groups (George Silverman, available on the web at http://www.mnav.com/bensurf.htm.) Although it's aimed specifically at organizing focus group discussions, it's got a lot of useful advice for user interviews in general.

Note

The goal of interviews and field observations is to determine how people are actually using the intranet, rather than how you think they should be using the intranet.

One company decided that they could cut costs and increase efficiency by putting their company address book on the intranet. They did so, but several months afterwards found that very few people were using it. They investigated, and found that everyone was still using the old-fashioned paper address books, because it allowed them to scrawl useful notes in the margin - not possible with the online version.

In this case, there was an obvious solution to increasing the usefulness of the online address book, simply allow users to add personal annotations online as they did in the printed version. If the company had asked the users what they found most useful about the paper address book, then the intranet address book could have been useful from the start.

In fact, this example could be taken one stage further. With the intranet address book, it would be possible for each user to share their annotations with their colleagues, and to search them - converting the initial usability problem into an advantage!

Heuristic Evaluation

For a usability technique, "heuristic evaluation" doesn't have a very usable name. A heuristic is a rule of thumb; a common-sense rule that is usually right.

So, a heuristic evaluation is an inspection of an interface, in this case an intranet, to find areas where it doesn't conform to usability principles; these are the heuristics. You could call it a "usability checklist" instead if "heuristic evaluation" puts people off.

It generally involves one or more people looking through a list of intranet pages. As each finds problems, they mark them down, saying what the problem is and whether it is major or minor. Afterwards, all the results are brought together, and the combined list of problems can be used as a basis for a redesign.

Some Example Heuristics and Questions

This isn't intended as a definite list of questions - instead, it should be thought of as a set of rules of thumb which are appropriate for intranet design, and some example questions that illustrate those rules. Not all of the specific questions will be appropriate for your intranet; it will depend on the size of your company, the aims of the intranet, and the expectations of your users. However, the broad areas should be appropriate for all company Intranets.

There are any number of heuristics that could be used; although they're not specifically intended for intranets, there are some more example usability heuristics listed at http://www.asktog.com/basics/firstPrinciples.html, and at http://www.useit.com/papers/heuristic/heuristic_list.html.

"There's no point having useful information on the site if there's no way of finding it"

Easy to Find Your Way Around

There's no point having useful information on the site if there's no way of finding it - so useful navigation is very important to usability. Navigation elements should be consistent and logical.

• Is the layout of the navigation logical? Having read the top-level headings, would you be able to work out what type of content is under each one?

• Are the most frequently used tasks emphasized? This can be difficult on an intranet, because different users will use different areas of the site. Implicit or explicit personalization can help by allowing different users to have different tasks emphasized to them. Implicit personalization is automatic personalization based on the user's profile and browsing habits, such as Amazon's "People who bought this book also bought...". Explicit personalization is allowing users to customize the information they see, for example by selecting the items that appear on their intranet homepage.

• Is there a site map that helps you visualize the entire structure of the site?

• Is there easy access to a site search? Ideally, there should be a search box on every page, rather than a link to a separate search page.

• Is the site layout consistent?

• Are names of links meaningful and unambiguous? For example: 'Company phone book' rather than 'extensions'.

• Is it possible to find similar pages to the one that you're currently looking at? One approach to doing this is using an automatic "People who bookmarked this page also bookmarked..." similar to the Amazon implicit personalization described above. However, there are problems doing this on an intranet; unless you are careful, you are likely to simply find the most popular intranet applications referenced from every page. An alternative approach is to have authors provide links to related pages when they create a page.

Obvious Where You are in the Site

It's an important usability principle to make the system status visible to the user at all times. For an intranet, part of this corresponds to making it obvious where the user is in the site.

• Is there a "breadcrumb trail" visible on every page? (A "breadcrumb trail" is a hierarchical list of the section that the page is in - for example "Company Offices -> Europe -> UK -> London").

• Is the navigation entry for the current page highlighted?

• Is it easy to find your way back to the homepage?

Easy to Find Information Again

It's not enough to be able to find content easily once. It should be easy to find the same information quickly when you look for it a week later, without having to go through a lengthy search process again.

• Are there different link colors for visited and unvisited links, so you can see where you've been in a site, and easily retrace your steps?

• Are there distinctive colors and images for different areas of the intranet? For many people, these act as memory cues - it's easier to remember that a document was in the "blue" section with a picture of a dandelion near it, than it is to remember the exact route to it.

• Are there accurate page titles that make it easy to organize your browser bookmarks?

• Are the URLs easy to quote over the phone? For example, "http://intranet/humanresources/firstaid.html" is memorable and can be read over the phone, "http://jar-jar-binks:9811/Web-APPL/Generator.cgi/01326923746,4392946,3329282209.html" is not.

• Are frames avoided? Pages within frames are harder to bookmark, and often have misleading titles.

Easy to Tell if Information is Relevant and Valid

Ideally all pages are kept up-to-date and irrelevant or unimportant information is removed from the intranet, but often the best you can do is make it clear what the source of the information is, and how old it is.

• Is the "Last updated" date obvious on each page? Obviously, some pages date faster than others - a company stock ticker changes hourly, but the head office address may never change.

• Is the page author obvious on each page, with a link to their contact details? This lets you get more up-to-date or specific information directly from the author, and can let you know the validity of the information.

• Is there an obvious mechanism for a user to report inaccurate content? For example, some intranets allow users to annotate content, or even to edit it directly without going via the page author.

Does Your Intranet Speak the Users' Language?

The intranet shouldn't be seen as a "separate world" from the normal day-to-day business of the company - it should use the same language as the business, and be linked in to business processes. A major purpose of many intranets is to put different people into contact with each other, and this should be simple for the user.

• Are appropriate specialist terms used in the intranet navigation and content, rather than computer jargon or general terms that are less precise?

• Is it easy to get information about the author of a page, so you can understand where they are coming from? For example, if you read an item in a technical company knowledgebase, it's useful to know how much experience the author has with the technology being discussed.

• Is it easy to find the experts on a subject within the company?

Is Site Behavior Consistent?

This doesn't necessarily mean that the whole site should look exactly the same - but it does mean that it should behave the same in every area.

• Is navigation in the same place on every page? This also includes keeping the search box or link in the same place.

• If there are keyboard shortcuts defined for pages or forms, do they behave the same everywhere in the site?

• Are there separate systems (that work together), that can speed up the work for an expert user, and at the same time guide the way for a new one?

Responsiveness

This doesn't just mean that pages are fast to download (although that's good), but also that there's feedback to the user on tasks in progress.

• Do lengthy processes (over 10 seconds, or thereabouts) have some sort of progress meter (as a minimum to show that they are still working, and preferably to estimate time remaining)?

• Is there feedback as to how far through a process you are? For example, in an intranet application that requires you to fill in a multi-page form, are there indicators that you are currently on "Page 3 of 7"?

• If image buttons are used, is there an "onClick" graphic that gives an immediate indication that the button has been clicked?

Accessibility

This is particularly an issue for publicly funded organizations, but it needs to be considered by most large companies. Accessibility doesn't just mean making your intranet accessible to users who are blind - it's also about making it accessible to your visually impaired 65-year-old managing director, the 10% of people who are colorblind, and those employees with poor motor skills.

Intranet accessibility may be covered by laws such as Section 508 in the US and the Disability Discrimination Act in the UK. These essentially state that companies must take "reasonable steps" to avoid discrimination against disabled employees - quite what this means for intranets is as yet ambiguous, since very few cases have been brought under them. In any case, increasing the effectiveness of disabled employees by enabling them to use the intranet efficiently is going to benefit your company, regardless of the law.

There is more information on accessibility available from Accessible Web Sites (Thatcher, et al., glasshaus ISBN: 1-904151-00-0). On the web, the W3C's Web Accessibility Initiative is an excellent source of information, and their list of Web Content Accessibility Guidelines is at http://www.w3.org/TR/WAI-WEBCONTENT/. Another good source of information is Dive Into Accessibility at http://diveintoaccessibility.orgl/.

Read the W3C's recommendations for a full list of checkpoints. A few that are particularly relevant to intranets are:

• Is text resizable?

• Are site colors high-contrast? Can they be altered? In the HTML 4 standard, it is possible to provide alternative stylesheets for web pages, but switching to an alternative server-supplied stylesheet is not supported in Internet Explorer. There is an article at http://www.alistapart.com/stories/alternate/ that describes how to provide alternative stylesheets in Internet Explorer as well as Mozilla/Netscape 6+.

• Is the intranet usable without JavaScript? For example, forms that provide client-side JavaScript input validation also require server-side validation if JavaScript is disabled, and JavaScript intranet navigation needs to degrade gracefully such that it is still usable without JavaScript.

• Are there keyboard shortcuts defined for the intranet? This not only speeds up access for frequent users, but it also helps employees with poor motor control. There is more information on this later in the chapter.

• Is there alternative text available for all images? One common mistake is to use spacer images for layout, and use the alternative text "Spacer image" for each one - it is permissible (and in this case recommended) to have the image alt attribute defined but set to a blank string.

Is it Possible to Undo Bad Decisions?

In order to learn any interface, including an intranet, users must be able to make mistakes without their experimentation causing serious problems (for example, losing half an hour's worth of form-filling by one careless click). This builds user's confidence in their actions.

• Can you return to the homepage of the current section of the site easily if you get lost?

• Do multi-page forms allow you to return to the previous page? Can you step back several pages, change an item and step forward again without having to re-enter data? Is a summary of the data presented back to you before any final Submit buttons?

• Can you easily repeat tasks with slightly different information? For example, is there a search again box on the search results page that is initialized with the text of the last search?

• Does the site store previous versions of documents?

• Are links that create new windows used carefully? In a newly created pop-up window, the browser's "Back" button will not work.

When Should You Use a Heuristic Evaluation?

This technique is cheap and fast. It's best carried out with a small number of people (four or five), but you can still get useful results by using it on your own if you have to. You don't even need a finished design to use this technique - you can use it very early in the design process to assess the merits of mock-up designs on paper.

In the next section, we'll talk about another technique for assessing usability - user testing. It's best to use a heuristic evaluation to identify and remove the most obvious usability problems before beginning user testing. This stops you from wasting your users' time by having them identify problems that you already know about. Then, the user testing can efficiently find the problems that the heuristic evaluation has missed.

User Testing

User testing is perceived as expensive and difficult - and this impression is reinforced when you read about usability labs with video equipment, one-way mirrors, teams of usability specialists, and even user heart-rate monitors! But, fortunately, all you really need to do very effective user tests is a user and a notebook.

"All you really need to do very effective user tests is a user and a notebook"

User testing is something that should be done early on in the design process, and then repeated before the intranet site is put live. If you already have an intranet that you're working to improve, then of course you can test with the existing site. If not, then you need a skeleton of an intranet and some working intranet applications, or at the very least a paper mock-up of the site.

If you've already carried out usability testing for an Internet web site, then you'll be familiar with the process. The differences are that it's easier to get hold of users (you have a captive audience) and there should be more of a focus on using intranet applications (such as an address book) than on site navigation.

First, Catch Your User...

Four or five people is a good number for user tests (although you should test with each person individually) - it's enough people to get several perspectives on the site, but still keeps the tests short. If you've carried out a survey, as we suggested earlier, then you should have a list of people willing to take part - otherwise, your HR department might be able to help. You should try to get a mix of users from the different audiences that will be using the intranet - it may be worthwhile to try and randomize the users you test. If you can't get enough people, don't worry - even one user can provide very valuable information.

"Remember that you're testing the intranet, not the user."

You can carry out the tests at the user's desk, and doing so will give you useful information such as how often they are normally interrupted and what their work involves. On the other hand, you may be wasting time by just listening to the user deal with unrelated problems and find it more productive to use your own office or an empty office.

Don't have more than two people watching the test - it can be intimidating for the user. If you have to convey your results to a larger team, then you can use a video camera, but it's often more effective to rotate the position of "second observer" around the team (especially because in most companies persuading your managers that you need to buy a video camera for web site testing is likely to be an uphill struggle).

It's important to remember that you're testing the intranet, not the user. If they can't find things, or can't use applications, then it's the fault of the design, not them. Also, ask them a few questions to see how much experience they have with the Web in general (although you should avoid testing users who have no web experience at all since you don't want to waste time explaining basic concepts), and with the company intranet in particular (if there is one). Also find out how long they've been at the company - it will determine whether they understand your company's standard terminology or not.

During the Test

You should provide the user with a list of tasks that you'd like them to try and achieve. Run through this list yourself beforehand to find out how long it takes you - and if you can't perform the tasks, then sort these problems out before you involve any users! Good tasks for your intranet might be:

• Finding the phone number of someone who can fix the user's computer

• Finding a map and directions to the London office

• Filling in a timesheet or expense report

• Scheduling a meeting and booking a room for it

• Updating their personal information in the company address book

• Finding and using the intranet A–Z

In general, think about what kind of tasks the user will be performing on the intranet, and how frequently they will need to perform each task.

Ask the user to think aloud - and note down what they say. What's going through the user's mind is as important as what they actually do. Also notice if they spend a long time pondering where to find something or reading a page. You should also make it clear that the user can stop performing any task, or stop the whole test itself, anytime that they want to.

Watch out for problems in the site. Typical problems discovered by user testing include:

• Confusing titles - in the navigation (perhaps company jargon that doesn't mean anything to a newcomer?)

• Logical organization - is it always clear where to look for site pages?

• Unclear forms - is it obvious exactly what goes in each box? Are form elements being ignored when they should be mandatory? Or mandatory when they're not really that important?

• Unclear pages - is it easy to find the important information on pages? Maybe greater use of bullet points and highlighting could help?

• Headings and sidebars ignored - much like the phenomenon of "banner-blindness" on the Internet, "heading-blindness" is a problem on intranets. Users will often focus on what they consider to be the content of the page, and not bother reading areas they perceive as peripheral.

• Ineffective site search - is your site search easy to find and is it easy to scan the list of results to find the relevant ones? If users have to open ten different web pages from the search to find the one page that they're interested in, then maybe you should rethink the way you display search results.

Note

I've always found the hardest challenge in usability testing to be keeping quiet while the user misses the "obvious" links and does entirely the wrong thing! Make sure that any other observers that are with you understand the importance of this.

The chances are that user testing will show up problems that you never expected - which is why it's so useful.

After the Test

Take the opportunity to ask the user for their general impressions of the intranet, and what they'd like to see on it. Also listen to their suggestions for improvements - after all, the users know what their everyday tasks involve better than you do.

Usability testing should be an enjoyable experience - after the first batch of tests, you might find other users queuing up to demand their turn! This is especially true if users can feel that they are having an impact on the intranet as the problems they identify are fixed.

Note

Keep a record of how long each task took, and record it where you can reference it later. This can be very useful if you make changes after the user testing, and then test again. By comparing the times taken, you can see how much employee time you've saved by the redesign - which is very helpful when justifying your user-testing costs!

Dealing with the Results

The hardest part of user testing can be trying to convince the web site designers that there actually is a problem with the current design; it's far easier to blame "stupid users" than it is to consider that your own design may be flawed. This is one of the reasons that it's good to make sure that the members of your development team sit in on at least one user test session each (or that you video the tests if your team is too large for each person to observe a session). After seeing one user make a mistake, it's easy to dismiss it as user error - when you've seen five in a row make the same mistake, then it's more convincing.

You need to analyze the data that you have obtained from the tests. The big problems should be obvious - for example, if every user has encountered a problem with one specific form, then that form needs to be redesigned. Other data, such as the time required to complete each task, and the percentage of task completions, need to be evaluated statistically. I've found it simplest to do this with a spreadsheet program such as MS Excel. You can generate means and standard deviations automatically, and it may be helpful to generate graphs to spot trends in the data.

User testing isn't a complete solution of course, any more than any of the approaches in this chapter are. Just because you've identified a problem, doesn't mean that you know how to solve it. You need to make judgment calls about what should change and how, based on the results of the tests. Still, it can give very valuable information, and is one of the best techniques for increasing site usability.

After completing one round of user testing, it's usually worthwhile to spend time fixing the problems that were shown up, and then conduct another user test. The more testing you do, the greater chance you have of your intranet meeting your users' requirements - which means happier, more productive intranet users.

Note

Stay in touch with your users! An intranet will change over time, and so will the way that people use it. Don't treat user testing as just something to be done in the initial design process - instead, every 6 months or so spend a day or two performing another test and re-evaluating your intranet usability.

Finding More Information About User Testing

An excellent source of user testing information on the Web is the "Usability Methods Toolbox" at http://jthom.best.vwh.net/usability/. This site has lots of in-depth information on usability testing techniques

A good book about user testing is the Handbook of Usability Testing (Jeffrey Rubin Wiley; ISBN 0-471594-03-2), This is not intranet (or even web)-specific, but it has a lot of practical advice and is a good all-round reference. To find out how some major web sites such as eBay, the BBC, evolt, and others carry out their user testing see Usability: The Site Speaks for Itself (Adrian Roselli, Don Synstelien, et al., glasshaus ISBN 1-904151-03-5). Another good book that is web-specific, but only touches lightly on user testing is Don't Make Me Think (Steve Krug, Que, ISBN 0-789723-10-7).

Other Ways to Keep In-Touch with Users

One big advantage that you have when trying to create a usable intranet, rather than an Internet site, is that you are one of your own target audiences. If you're not using the intranet on a regular basis, then why not? What would make you do so? How could you improve it to benefit yourself?

This "scratch your own itch" motivation can be very useful. If you find it inconvenient to use the intranet's timesheets application, then you can be sure that many other people in the organization are inconvenienced by it too. If you can increase its usability, then you can make your life easier as well as everyone else's.

However, do always remember that you're not the only audience. It's likely that you're more technically adept than the majority of users, and what seems easy to use for you may be baffling for other users. It's always worth, at the very least, calling in someone from the next office to have a look over every user interface change that you'd like to make to see whether it makes any sense to them.

Note

I've found it helpful to keep a notebook handy at all times (or better still, a lightweight CMS system), If I have trouble using or finding something on the intranet, then I jot the problem down. Later, I can chat to other people and see if they've encountered the same problem. If they have, then it's probably affecting other people too - if not, then maybe I just had a temporary mental block.

Seminars

As well as being useful for promoting the intranet, seminars can be useful for increasing its usefulness. A seminar is a good opportunity for finding out what people want from the intranet, and allows informal user training. It's also a good way for users to share information with each other - you may not know what is in an obscure section of a large intranet, but the chances are that someone will. Information can then be disseminated from the seminar attendees.

Have an Intranet "Suggestion Box"

Earlier we mentioned an important principle of intranet design, that on every page it should be easy to see who the authors of that page are and how to get in contact with them. This principle applies to the intranet homepage just as much as it does to all the others. It's a good idea to have a way of contacting the intranet team on the homepage itself, so suggestions for improvement can be gathered.

Another way of keeping in touch is to use Instant Messaging. If you have an internal IM server, such as Jabber, then intranet users can talk to you immediately, to ask questions, raise a problem, or make comments. The best source of information is always a knowledgeable human, rather than an intranet. However, this is only really practical in a very small intranet, or in a larger intranet with dedicated full-time intranet-user support staff. There's more information on Instant Messaging in Chapter 9.

The most important challenge here is to make sure that all suggestions are responded to, and that at least some of them are acted upon - otherwise users can feel that they are being ignored.

Iterative Development

So, user-centered design is no problem? Just find out what the users want and then do it?

Sadly, users usually don't know exactly what they want, or they want conflicting features, or they want technically infeasible features. And it's a lot easier to see what's wrong with an existing design, than it is to work out what would be a successful design.

The solution is to use iterative development. Create a simple prototype, test it, fix the problems, test again, and repeat as necessary. You won't find all the problems the first time, but as long as you involve users in the design process and they can see they impact on the design, you'll be removing problems each time.

Iterative development is cheaper than other forms of development. In general, if you can catch a usability problem early on, then it's easier and cheaper to fix than if it's identified after the intranet has been rolled out to everyone.

Justifying Usability

Although investing in usability can return significant benefits, there is usually a need to quantify those benefits to demonstrate that the time and money spent on usability is worthwhile. We have already looked, in Chapter 2, at the ROI of the intranet as a whole. Here we'll look specifically at the ROI of usability.

It's easy to work out the costs of usability - it's the cost of employing the intranet developers (and the users they work with) for the time taken to carry out the users tests, the evaluations, and the subsequent reworkings of the intranet site. It's much harder to quantify exactly what benefits it gives.

Estimating Usability Benefits

A simple, if na ve, formula for estimating savings from intranet usability is:

• Find the time taken to perform tasks on the original intranet site. This is information that you should be recording as part of the user testing process. If you are designing an intranet from scratch, then this can be the results of the first user testing of the early intranet designs.

• Compare it to the time taken to perform tasks on the final version of the intranet site, after you have identified and fixed the problems. Hopefully, the second figure is lower!

• Multiply the time difference between the two figures by the number of users that will perform the task.

• Multiply again by the number of times that users will perform the task per day.

• Multiply again by the average wage of the users.

• Multiply again by the number of days worked per year, to obtain the total savings per year.

For example, imagine an intranet application that is used on average twice a day, by a thousand people within your company. If your usability improvements speed up their use of it by one minute each, then that's 2000 minutes (about 30 hours) saved per day. If the average hourly wage is 10 per hour, then that's 300 saved per day. If users work for about 250 days per year, that comes to a saving of 75,000 - certainly enough to justify a few days of usability testing.

There are several criticisms that could be made of this approach:

• It assumes that users will use the time saved for useful productive work.

• A user's salary is not their actual cost to the company - the actual cost includes such things as equipment, support staff, electricity bills, rent on facilities, and so on, and is generally estimated at about twice the salary.

• It assumes that all usability savings are made in terms of timesavings. Other advantages can be increased use of the intranet reducing the cost of other business functions, increased accuracy of information available to the business, and reduced errors in data entry.

• It takes no account of reduced training costs and reduced support costs.

Still, it provides a workable estimate that will tend to err on the low side. If you need to make a case for usability to your managers, it's best to be conservative with the estimates of savings; an over-optimistic estimate is too easy to discredit.

Even though this formula will give a conservative estimate, it is still likely to show that investing in usability pays for itself many times over, simply because every improvement in intranet usability is multiplied hugely by the number of people that it benefits and the number of times it benefits them. In one usability study, by Clare-Marie Karat of IBM, savings of $6.8 million were estimated from an investment of $60,000 in usability - a hundred-fold return on investment.

Further Information

There are helpful real-world examples of money saved by usability at the Usability Professionals' Association web site (http://www.upassoc.org/outreach/real.world.ex.html). It includes reports of major savings attributable directly to usability research made by companies including Ford, Microsoft, and the USAA. Their site has a number of references to studies that have shown significant savings from usability (http://www.upassoc.org/outreach/benefits.html). There is also useful information in the article "A Business Case for Usability" from the WebWord usability newsletter at http://webword.com/moving/businesscase.html.