The overall goal of the E-government Strategy is for New Zealand to "be a world leader in using IT to realise its economic, social, environmental, and cultural goals, to the benefit of all its people."
Optimal Usability › Edit — WordPress
We certainly spend taxpayer money pursuing this goal. Last year 64% of public sector agencies expected to spend money on a new/upgraded website in 2008/09, and 53% expected to spend money on new/upgraded online services.

However, despite spending all this money New Zealand is falling behind in public sector innovation.
 
A 2008 UN report (PDF, 1.5MB) ranked New Zealand 25th in the world in terms of e-government readiness. That’s a drop from 18th place in 2005. 

Despite promises of dramatic change and innovation, the public sector today looks much as it did when the Internet started. Instead of transforming government, innovation has tended to be small-scale and gradual.
 
I believe that there are four steps to reversing this trend and creating government websites that rock.
 

Step 1. Create a citizen-centred culture
 

A. Ditch the shared accountability model
 
Currently many government departments have a shared accountability model. Someone creates content based on what their team is working on, gets it approved by the comms department and a techie tucked away in a corner somewhere publishes it to the web. 
 
Things like optimizing content for search engines, rewriting pages to make them easier to read and cross-promoting other departments are mostly lost in the busyness of day-to-day operations.
 
The trouble is that when something is owned by everybody, it is owned by nobody.
 
For example, one government department we know of doesn’t have an online strategy for their public facing websites or their four intranets. They’ve got no governance group and they’ve got hundreds of authors. The result can’t help but be mediocre.
 
B. Hire a Chief Citizen Officer
 
To create a superlative citizen experience public sector agencies need to get away from this shared accountability model and hire someone who can call the shots at the highest level. I believe that every public sector agency should have a Chief Citizen Officer (CCO), whose role it is to manage the customer experience across all the channels.
 
Hiring a CCO takes guts. But it takes this kind of commitment to run a great website. Real money and real people.

 
Step 2. Create an actionable, citizen-centric online strategy

 
A. Stop trying to design for all citizens
 
Government departments often try and design their websites to suit the needs of "all New Zealanders".
 
I understand that most public sector agencies have a vast mandate, to which they are held publicly accountable. But I believe that public sector agencies are mistaken to try and design for all citizens.
 
The trouble is that when you try to design for everyone, you design for no-one. All you get is a mediocre website.
 
One great way to stop designing for all citizens is to use personas. Personas are pretend users of a website, based on research, with details to make them "real". They are a tool that is used to help make design decisions. Suddenly you aren’t designing for everyone, you a designing for a specific someone.
 
One tip though - personas must be based on data, and there are few shortcuts. Don’t believe anyone who says they can create personas in a day.
 
B. Create a coherent, lightweight online strategy
 
Once you know what your users’ goals are, you can combine them with your own organisational goals to create an online strategy.
 
I believe that you can actually use a fairly simple process to do this. The approach we generally take is to do upfront research into users and their goals, interview stakeholders, and run workshops grounded with real-world examples of other websites. The strategy tends to come together quickly because most of the work is in the preparation.
 
Finally, don’t develop the online strategy in isolation. The role of the CCO should be to ensure that all services offered across all channels are taken into account as part of a broader cross-channel strategy.

 
Step 3. Improve findability
 

A. Create an intuitive information architecture with the help of users
 
There are currently 10,000,000 webpages spread across 900 .govt domains.
 
The number of pages are only going to grow. For example, parliament.govt.nz might add 200 documents in a single day when parliament is sitting.
 
That’s why the information architecture of public sector websites has to be carefully created and validated based on feedback from real users. The structure and labels of a website cannot be made up out of thin air.
 
B. Remove redundant content, and consolidate sites to make stuff easier to find
 
Governments in general are broken up into competing agencies and jurisdictions.
 
This causes government websites to spring up like mushrooms. Agencies care about their individual "web sites" rather than trying to understand the broader goals of their visitors. Websites should be based around key tasks, not agencies, and should ideally hide of the mechanics of government.
 
Government silos also mean that taxpayers end up paying for the same content in multiple places. I found four different websites that dealt specifically with fuel economy. I would like to calculate how much energy it takes to run all the sustainability websites!
 
In our product development business we refer to the concept of "killing puppies". Sometimes hard calls need to be made to discontinue a product. It can feel like putting down your own cute, adorable puppies. But sometimes, that’s what’s needed.
 
The UK government shutdown 425 sites when it implemented the directgov portal. 425 dead puppies. Maybe it’s time our government did the same.
 

Step 4. Follow a user-centred design process
 

A. Use ISO 13407
 
The New Zealand government spent $1.9B on ICT last year. There is an opportunity to realize immense return on investment from projects that follow a user-centred design (UCD) process simply because government operates on such a large scale.
 
ISO 13407 is probably the most well known usability standard, and documents the characteristics of UCD. It’s a simple, high-level framework with requirements that include the following:

• Project planning shall allocate time and resources for the human-centred activities. This shall include time for iteration and the incorporation of user feedback, and for evaluating whether the design solution satisfies the user requirements.
• Relevant user and stakeholder groups shall be identified and their relationship with the proposed development described in terms of key goals and constraints.
• There are four linked human-centred design activities that shall take place during the design of any interactive system
  • Understand and specify the context of use;
  • Specify the user requirements;
  • Produce design solutions;
  • Evaluate.

(From International Standards for Usability Should Be More Widely Used)

If you follow this standard you will end up with a more effective, easier to use website. Government RFPs should require vendors to comply with ISO 13407.
 

Government websites that rock

We still have a long way to go, but there are many examples of successful government websites.
 
Practice.co.nz is a risky, non-traditional website, targeted at young drivers. The user testing we did showed us that people in the target demographic loved it. (Design by Aim Proximity)

The Retirement Commission used to be three people and a part-time commissioner. They still managed to create the Sorted website that attracted over 1,000,000 visitors/year when they were that small. They succeeded because of their relentless focus on the website - it was and remains their number one channel. (Design by Sparks Interactive)

ACC recently followed ISO13407 to redesign their site, without even realising it! Their emphasis on the user experience and following a robust research programme has resulted in a 25% increase in page views. (Design by DNA)
 
 
With examples like these it’s possible to see how the Internet can transform government. I’m looking forward to the day when public sector websites become so useful and intuitive that we drop the term "e-Government" and just call it government.
 

If you’d like to hear more on this topic come along to a free breakfast on the 22nd of September in Wellington. Those who can’t make might want to check out the slides.
 

By Dave O’Brien
 
Suppose you’re designing (or redesigning) the overall structure of a website. You’ve come up with a new structure - depending on the coffee, you may have come up with two or three. But are they good? Which one is best? And are they better than the old structure? Until recently, there wasn’t a quick way to find out, short of building the site and testing it after the fact.
 
We weren’t the only ones looking into how to test the organisation of websites. Some years ago, Donna Spencer pioneered a simple technique with a complicated name: Card-Based Classification Evaluation. Donna did her testing on paper, but it struck us that an online tool would make the technique much quicker and easier.
 
So we built Treejack. Its purpose was to make this "tree testing" automated and easy, while answering several key questions:

• Can users successfully find items in the site?
• Can they find those items directly, without having to backtrack?
• Can they choose between topics quickly, without having to think too much?
• Overall, which parts of the site structure work well, and which fall down?
   

Treejack - a tree-testing tool

Tree testing is a simple technique, so we made Treejack a simple, focused tool. Its sole purpose is to improve site organisation through quick, iterative testing. In a typical tree test, about 50 participants click a web link to start a Treejack session:

• Each participant is shown a website task (e.g. "Sign up for the company newsletter.")
• They see a list of the site’s top-level topics.
• They click a topic, and see the subtopics under it.
• They continue clicking down until they find the answer. They can also back up and try a different path, or give up and move on to the next task.
• After about 10 tasks, they’re done. Elapsed time: 10-15 minutes.
   

Interpreting the results

After those 50 people have tried 10 tasks each, clicking through your site structure, Treejack can show you how well the structure performed, and more importantly, show you which parts failed with users. It summarises the results into three values:
 

• Success - The % of users who found the correct answer.
• Speed - how fast users clicked through the tree. Quick choices suggest high confidence, while hesitation suggests that topics are not clear enough.
• Directness - how directly users reached an answer. Ideally, users reach their destination without having to backtrack and try a different path.

These are measured for each task, with an overall score for the whole test.
In a way, it’s like analytics for a website you haven’t built yet.

Lessons learned

We’ve run several tree tests now for large clients, and along the way, we’ve learned a few things:
 

• Test a few different alternatives. Because tree tests are quick to do, we can take several proposed structures and test them against each other. This is a quick way of resolving opinion-based debates over which is better. In a recent government project, one proposed structure showed much lower success rates than the others, so we were able to discard it without regrets or doubts.
• Test new against old. You don’t just want your new site structure to be different, you want it to be better. Tree testing is a great way to determine this. In the same government project, the original structure only had a 31% success rate. Using the same tasks, the new structure scored 67% - a solid quantitative improvement.
• Lather, rinse, repeat. Everyone talks about being agile and iterative, but schedules and budgets often quash that ideal. Tree testing, however, has proved quick enough that we’re able to do two or three revision cycles for a given tree, using each set of results to progressively tweak and improve it.
   

Summary
Tree testing has become an important part of our information architecture work with clients. And Treejack has given us the automation we were after - a quick, simple-to-use tool that generates clear results quickly.

Like user testing, tree testing shows us (and our clients) where we need to focus our efforts, and injects some user-based data into the site-design process. Its simplicity means that we can do variations and iterations until we get what we came for - a tested, effective site structure.
 

A common lament of designers and usability consultants is "if only you’d come to us earlier". In establishing Optimal Experience this year, we saw the opportunity to work further upstream, before the client closed off options or used up resources that would have made for a better result.
 
So, we’re excited to be working with a major Australian government department as it prepares for a ground-breaking new web initiative. Last week, we held a three-hour scoping workshop with 30 stakeholders to help crystallise a shared vision - a fistful of ideas that will grow as planning, design, writing and development follow in the next few months.
 
This project is challenging. It is a national initiative calling for cooperation within and across Australia’s three layers of government as well as its commercial and community sectors. But the biggest challenge of all is a commitment to deliver ‘easy’, ‘user-friendly’, ‘central’ public access to a broad range of government programs. Those simple words tie the project’s success to the quality of the user experience - to results, not gestures or promises. That’s why we’re excited, and why the workshop was abuzz.
 
Some of those 30 stakeholders represented other programs with their own funding, plans, schedules, and their own websites. One of the big issues is to unravel all the interdependencies. That calls for lots of discussion, and we need consensus and cooperation despite the differing perceptions, assumptions and priorities. Yet at this early stage there’s nothing to use as a common reference point. A few words, but no detailed requirements and certainly no design to point to and pore over.  
 
We knew that this workshop needed to provide a mechanism for stakeholders and the project team to develop a common vision for the site and a common understanding of the issues and factors influencing decision-making.  This is essential for creating the conditions for confident, effective project planning and decision-making; in particular for the strategic technology and content issues that will govern the project schedule.
 
So to facilitate the discussion, we prepared a range of site concepts beforehand to focus the workshop discussions at a practical, concrete level as much as possible. This minimised the need for participants to digest unfamiliar, complex, abstract information at short notice; helped ‘ground’ the discussion in reality rather than through hypothetical situations; and enhanced the group’s ability to make confident decisions.  Participants left the workshop with a shared view of the end goal (and at least an inkling of the tasks that lie in front of them).  We are now revising the site concept to create a common reference for project stakeholders and a starting-point for requirements and user-centred design activities. 
 
The site concept captures only the essentials for purposeful communication as the project takes shape, without encroaching on the freedom necessary for innovation.  This concept is really just a place-holder - it’s not there to restrict the ongoing development of promising options by imposing unnecessary detail too early.
 
The value of this approach is allows us to scope the project in a much more meaningful way, focusing on the ‘when’, ‘how’ and ‘who’, not just the ‘what’.  We can consider the editorial function, the breadth and depth of content, the means of access, the technical effort and the overall governance.  It allows us to look traditional software development approaches, and ensure that the relationships, guidelines and processes are in place to support the project in delivering on its promises.

This month, we welcome back Larry Marine, to respond to last month’s newsletter about link-rich home pages. He writes about when lots of links might not be the right answer, and what to do about it. Larry is a founder and principal of Intuitive Design & Research, and holds a degree in Cognitive Science. He is an expert in user research and user-experience, and has worked with companies of all sizes, from start-ups to Fortune 500.
 
 
After last month’s article, you would be forgiven for thinking that link-rich homepages are the answer to every web design problem.  Unfortunately, however, it’s not that simple. Link-rich homepages are a good solution for information-oriented domains, but a task-oriented environment may be better served by a different approach.
 
Usability testing shows that information-oriented designs are not very successful in task-oriented environments. An information-oriented website, such as a standard business or corporate site, tends to offer plenty of content, from varying types and sources. A task-oriented site intends to help customers solve problems, such as determining the right health insurance options for a couple expecting their first child.
 
Information-oriented sites organize and categorize information by the content type and relationship. This approach relies on the users’ ability to find, assimilate, and use the right information, and most importantly, to know what information to ignore. Such sites work well when users know what they are looking for and how it is organized, but this approach rarely works well when the users need more guidance.
 
In a task-oriented environment, the users barely know the extent of their problem, much less what to look for or how it is organized on the site.   They can get lost and frustrated very quickly, and chances are, they won’t come back.  A much more successful, though more difficult, design approach helps the user define their problem and then suggests the best solution.
 
As you might guess, the design approach is very different for these two domains, and just as an information-oriented approach is not very successful in a task-oriented environment, the reverse is also true. If you know what you are looking for (as in an information-oriented environment), a task-oriented approach seems quite cumbersome.
 
But what does a task-oriented problem domain look like? To begin with, content doesn’t have to be information artifacts. It can be anything.  Take buying flowers, for an example. In an on-line flower shop, an information-oriented approach would have users find different flowers by flower type or name and put them together in a bouquet. A typical florist would have little trouble performing that task with such an information-oriented tool, but the average on-line flower purchaser is not a florist. Actually the average flower consumer is on the opposite end of that scale - men.
 
The typical male doesn’t know or care much about flowers.  All they want is to get a nice bunch for their sweetheart, in as short a time as possible. If it wasn’t for the last minute, the typical man would get nothing done, especially when it comes to anniversary and birthday gifts. I’m a man, so I know! When it comes to flowers I need them fast, and I don’t want to spend half a day figuring out which flowers I need. I just want the right bouquet for the occasion. After years of marriage, I have learned one thing about flowers, with the exception of Valentine’s Day, nothing cries insincerity more than a simple, dozen red roses. Roses are supposed to be a surprise, not an easy way out.
 
OK, so now we have the root of a task-oriented problem. I need just the right flowers grouped together in a bouquet that is appropriate for the occasion. A task-oriented approach should begin by asking me for the occasion, and then show me a set of bouquets perfect for that occasion. This is a big difference between an information-oriented approach and a task-oriented approach. An information-oriented design will typically provide an information artifact, such as an article, in one and only one location. A task-oriented design may very likely duplicate artifacts, such as putting the same bouquet in many different appropriate occasions.
 
Take a look at ProFlowers.com, an on-line florist that employs a task-oriented user-experience approach. The Nielsen ratings of on-line commerce for May, 2008 show that Proflowers is number 1 in conversion rates, almost 36%. There are a number of reasons for this, not the least of which is their task-oriented design. I know, because I designed it and the CEO still publicly acknowledges that the UI design is one of their key success factors. Interestingly, the other on-line florists, at the time, used an information-oriented design that required users to build bouquets. What was the hot seller on those sties? You guessed it, a dozen red roses.
 
But as I said, task-oriented designs only work in task-oriented domains. Focusing on making sure you understand the problem domain correctly before defining a solution will help you find the right design approach.
 
Now go buy your sweetheart some flowers.

This month we’d like to welcome back Donna (Maurer) Spencer.  We last interviewed her nearly a year ago, on card sorting. Today she is talking about link-rich home pages, a subject that is near and dear to my heart.
 
I recently had a conversation with a manager of a large government website. He boasted about the recent changes to the department home page.  He was particularly proud of one of his developments. "I reduced the number of links from 67 to 17", he told me.
 
My eyebrows shot up and I just managed to stop myself gasping in surprise.  Regaining my composure, I calmly asked him, "Oh, really. How did that work out?"
 
"It’s much better," he said.  "Now people only have to choose from the 8 main categories on the home page" (the other 9 links were footer links and site utilities).
 
I walked away knowing that this manager had no real idea whether the changes worked and with a strong feeling that they probably hadn’t.
 
Believe it or not, link-rich home pages (ones where you have a lot of links) are OK.  They might even be a really good option, especially for large websites with a wide variety of content.  Let me explain why.
 
Whenever we combine content into groups and decide on a label, we are creating a category. On large websites with varied content, creating a small number of categories that represent all the content is extremely difficult.  That’s because as we create fewer and fewer categories, the labels get more and more abstract. The labels chosen may mean something to the developers, or the staff of that organisation, but will the customers understand?  How will the customers know how to find the information they want?
 
That’s where link-rich homepages can help. Instead of using just broad categories as the entry point to a site - we can use broad categories plus detailed links. Take a look at the MAF website in New Zealand for an example.
 
An example I’ve worked on recently was for a big government department in Australia. The old home page navigation had a left-hand navigation bar with 8 main categories. The new approach still uses the left-hand navigation bar, but the body of the page has the category name plus links to sub-topics and relevant external websites. The addition of key links helps explain what the each category is about, and allows people to jump directly to a topic of interest (and they do - when the new version was released, traffic to the topics pages increased).
 
A word of caution is necessary, however.  Effective link-rich home pages don’t just happen.  Too many links can be confusing and hard to navigate.  There is a lot on the page, so you need to take special care to:
 

• Cluster links into groups that make sense to the reader - or people will still not know where to start.
• Place a lot of attention on good visual design - use plenty of whitespace, good alignment and good line height. Otherwise the groups of links will not be readable.
• Avoid using other attention-grabbing devices such as banner ads and anything that moves - the visual load will be too high.

The final challenge with link-rich pages is that everyone will tell you that you are wrong - the common perception is that less is better. The best way to overcome this is to undertake usability testing. But don’t just test the link-rich page. Test an alternative version with a more traditional small set of categories. That way you’ll know that your link-rich version works, and you’ll be able to show that it is better than the alternative.
 
Want to know more? Hear Donna rave about the advantages of link-rich home pages and much more IA goodness at our workshop on the 21st of August in Wellington.

This month we are very pleased to have Sarah Bloomer from the US in New Zealand. She has 20 years of design experience under her belt and was one of the founders of The Hiser Group that pioneered User-Centered Design (UCD) in Australia. Our Auckland-based director, Shailesh Manga, took the opportunity to ask her a few questions while she was in the country.

Shailesh:
Sarah, while you have been in New Zealand I have heard you talk about Design Thinking. What is that and how is that different from typical design?

Sarah:
Design is problem solving, it’s not simply about styling and look. Designers, broadly speaking, explore a design "problem" by looking at many possibilities, while engineers look immediately for a solution. At the consulting company I started in Australia, The Hiser Group, we taught our consultants to explore and validate different designs. We taught our engineers not to jump to solution mode, but to let the design evolve. "That’s good, but we don’t want an answer yet," we’d tell our clients when they’d say "I know how we can do it!"

We didn’t realize it then, but we were engaged in "Design Thinking."  When Design Thinking is applied, the problem is reexamined and often reframed. That is, the problem originating the need for design may be discovered to be the wrong "problem". When NASA needed a pen that could write in outer space, they had an enterprising individual spend millions of dollars and thousands of hours designing a pen, the ink flows without the aid of gravity. The actual problem was to provide a tool for writing in outer space. The Soviets solved it by using a pencil. No gravity required.

Shailesh:
In increasingly competitive markets, organisations are looking to innovate to differentiate themselves. What does design thinking have to offer here?

Sarah:
Innovation comes from seeing things differently. Design Thinking welcomes all ideas without judging them good or bad, feasible or crazy. At its broadest definition, it is the ability to put many ideas together to create something new. Design mash-ups. It’s seeing opportunity in a crowd of issues, problems and goals. It’s allowing ideas to evolve and bubble up without jumping to solutions, as engineers have been trained to do. New ideas come from research, analysis and synthesis. Innovative ideas do not generally emerge Athena-like from the head of a few great designers. All designers can innovate. In fact the role of design in organisations needs to grow.

Shailesh:
You have also mentioned that the idea of Design Thinking is not actually new and that it is closely aligned with what user experience practitioners call User-Centred Design. Can you elaborate on this connection?

Sarah:
Roger Martin wrote:

"Great designers seek deep understanding of the user and the context, which entails consideration of many variables.

They don’t limit their considerations to aspects that can be thoroughly quantified. They worry less about whether they can replicate a particular process — and more about producing a valid solution to the problem before them."

There are many ways to gain "deep understanding of the user and the context". One of the most effective is, of course, UCD, our area of expertise. Like Design Thinking, user-centred design is an approach, a way of finding design solutions. More importantly, UCD is also a set of techniques. User-Centred Design may have come out of the field of interaction design, software design and web design, but today UCD is being appropriated by all sorts practices: process design, industrial design, service design even business design.

Design isn’t a free-for-all-it requires a process or set of stages to enable design to happen, repeatable process and a set of tools and techniques. Adopting User-Centred Design is a good place to start, regardless of what is being designed.

Self reporting techniques, such as surveys, interviews, and focus groups have long been used by marketing reps for collecting customer data, for good reason. They provide excellent information on demographics and user reaction to a new technology. But this information is not necessarily helpful in all circumstances. For example, they are often misused when undertaking User-Centred Design (UCD).

Good design should empower users to succeed at their key tasks. A designer’s job, therefore, is to predict the future use of the product, which should include some kind of user research to be successful. Unfortunately, many UCD practitioners mistakenly apply self-reporting techniques without realising that surveys are an ineffective design tool. They can lead to excellent systems that do entirely the wrong thing. Instead, user observations are the key for designers. They are as effective at identifying design data as surveys are at collecting demographic data.

Recently, a company asked us to design them a Knowledge Management (KM) system. Its purpose was to facilitate information sharing across departments, and improve the consistency of reporting procedures. But ethnographic observations quickly determined that a KM system would have been doomed to failure, as it would not have met the essential needs of the users. They were already busy, and typically stored data in several repositories. For example, all users had important documents stored in their inboxes. It was generally agreed that these documents should be saved to their hard drives and/or the shared network drive, but only one had actually done so. Moreover, each repository had a different organisational structure, and all had stored incomplete or minor artifacts, as well as complete reports.

There were two major problems for a KM system here. Firstly, it would have required users to move all the items out of their individual repositories, and then to categorise and meta-tag each data object. All this would have taken time and behavioural changes on the part of the users, which decreases the likelihood of acceptance.

Secondly, a KM system depends on a general understanding of the organisation and categorisation of the data and few KM systems contain incomplete or minor artifacts.

Therefore, what the organisation actually needed was a better search mechanism. This system did not depend on any additional user effort, worked across all data repositories, considered both minor and incomplete artifacts as well as major and complete ones, and actually provided the users with better suggestions of information sources.

Here is a clear example where self-reporting techniques would have provided an entirely inappropriate solution. It might have been very good, but it would not have fixed the problem. This is because users are much better at recognising or reacting to a design solution, than they are at describing the problem. Added to this, they typically know less about the potential technologies than the designer, so their input is limited. As Henry Ford once said, "if I had asked my customers what they wanted, they would have said a faster horse."

Users also tend to describe their tasks differently from how they actually perform them. Often this is because they blame themselves for any mistakes they make, rather than the technology. In one observation, a hospital lab manager told us that her organisation’s current tool was a good system, but then committed eight errors within a 30 second task. Fortunately, because the consequences could have been life-threatening, she recovered from all of them. Later, when asked about the errors, she mentioned that it was her fault that she made the mistakes and that she just wasn’t smart enough to use the tool correctly. Was this a case of a ’stupid’ employee, or was the system unnecessarily complicated?

Too many products force the users to change their tasks to fit their perception of how to use the product. Your objective is to optimize the users’ tasks and design a product that fits the optimized tasks, not to improve how users use the product. The product should be transparent to the task. Users want to write a letter, not operate a word processor. By observing users using your product you will likely end up merely automating their current frustrations.

For instance, we were once asked to design a website for an on-line florist. Instead of watching how flowers were bought on-line, we went out and observed people buying flowers in a shop. Have you ever seen shopping carts in a florist shop? Of course not, so then why should the site have one? Eliminating the ubiquitous online shopping cart saved the client thousands of dollars, and they could still up sell associated items, such as vases and teddy bears. This and other key innovations derived from our user observations have made this one of the world’s most successful and profitable e-commerce sites.

Finally, self-reporting methods require lots of respondents, which takes time and effort, while you only need to observe half a dozen representative users to get a good insight into their needs. Surveys are good at getting user reactions to solutions, but observations are much better at defining the actual problem. So instead of relying on self-reporting methods in your user research, try to conduct user observations. You’ll get better insights and you’ll actually take less time.

Metaphors have a powerful role to play in helping us make sense of our world. According to Gerald Zaltman, "they help us see new connections, interpret our experiences, and draw meaning from those experiences." [1] He points out that we use almost six metaphors per minute of spoken language. Just as they permeate everyday life, so metaphors also permeate human-computer interfaces.

Metaphors are the representation of one thing in terms of another. Complex user interfaces can be more easily understood if they are depicted in terms of some commonplace system that users are familiar with. Like the humble desktop metaphor, which is the "single most important design decision of the last half century." [2]

The desktop concept was invented in 70s by a group of researchers at Xerox’s high-end computer science lab in Palo Alto. Originally multiple windows used to compete for space on a screen that wasn’t much bigger than a sheet of paper. The breakthrough came when a researcher named Alan Kay began thinking of the screen as a desktop. "People in offices got around the same problem of too much paper and not enough room by piling pages on top of one another." [3] Kay simply transferred this real world solution to the computer and overlapping windows were born. No-one looked back from there.

Part of the reason for the staying power of this particular interface metaphor was that it was extendible. It is not a huge mental leap to incorporate other familiar office concepts such as a trash can and files.

Of course, like with most things, the use of metaphors can go too far. It’s easy to imagine the desktop metaphor being taken too literally, with piles of unordered paper, scattered business cards and coffee mug stains. That’s the beauty of the metaphor, it can be used to help understanding without being tied down by the limitations of the real-world equivalent.

(For those interested in the history of the modern PC user interface, I would strongly recommend reading Dealers of Lightning, the story of the Xerox PARC lab. It’s a very interesting account of the invention of the first personal computer and graphical interface.)

[1] From How Customers Think by Gerald Zaltman
[2] Interface Culture by Steven Johnson
[3] From Dealers of Lightning by Michael A. Hiltzik

- Trent

Recently we were asked what we thought the most widespread web usability issues were. We have evaluated over 140 websites in the last 18 months, and repeatedly see the same website design mistakes, most of which are easily corrected. The Top Ten mistakes are:

1. Poor categorisation and labelling of information.
Problems with site structure and the names of the main categories are among the most damaging problems for a website. For example, the <a href="http://www.pumpkinpatch.co.nz">Pumpkin Patch website</a> has ‘Shopping’ and ‘Product Guide’ categories - neither of which actually show the range of kids clothing that they have for sale. Too often websites reflect the internal structure and labels used by the organisation, rather than those of their customers.

2. Poor navigation design.
Even if a site is well organised and information is in clearly labelled categories, the design of the navigation elements can undo all the good work.

3. Cluttered page layout.
Many pages are difficult for users to scan because the design is cluttered. Information isn’t aligned and there is too much unused space. The most important information on a page isn’t clear at a glance. Few pages make effective use of section headings and sub headings so that it is obvious how the information on a page is structured.

4. Inconsistencies with web design conventions.
People spend most of their time at other sites. That’s why it’s crucial that your site follows standard design conventions and behaves as visitors would expect. Inconsistencies will make your site harder to use and less intuitive.

5. Too little content.
It is amazing how little thought goes into understanding who website users are and why they are using a site. A luxury lodge website we worked on earlier this year, for example, did not tell visitors how many people could stay at the lodge at one time, or whether they could bring their own food.

6. Too much content.
While too little content can be a problem, we more often hear complaints about too much content. Users balk at the idea of reading long pages of text online. Overseas research has shown that people read up to 25% slower from a computer screen as opposed to paper. Our own experience supports this - at ACC, for example, people preferred pictures and diagrams over words to illustrate injury prevention principles.

7. Poor use of links.
People move around on the web by clicking on things. That’s why it’s got to be obvious what a user can and can’t click. Sites should link useful pieces of information together. For example many university sites don’t link their subjects pages to useful pieces of information such as timetable details, or pre-requisite papers.

8. Poorly implemented forms.
Despite their popularity, most online forms still make basic mistakes. Compulsory fields aren’t highlighted and users aren’t given instructions on how to enter dates and phone numbers in the correct format. My personal favourite - entered information is not saved until the form is complete - forcing users to re-enter all information if they make a mistake.

9. Poorly written error messages.
An ideal website prevents people from making mistakes in the first place. At the very least a website should help users to diagnose and recover from errors. Instead most error messages are terse and impolite and use obscure jargon and vague phrases.

10. Poorly implemented search.
Many people browse for information on a website and use search engines only as a last resort. Your search engine needs to be bullet proof, or you risk irritating already exasperated users.

Note: Jakob Nielsen has also recently released his Top Ten Web Design Mistakes of 2005

The New Zealand Government Web Guidelines were created in August 2001 as a way to ensure that government websites provided equal access to all NZ citizens. One in five New Zealanders have some kind of disability and the government has a responsibility to ensure that they are not discriminated against. The 69-page Guidelines document is a good piece of leadership from the NZ government, building on similar efforts overseas.

We have audited over 130 government websites against the Guidelines in the last 18 months, so now seems like a good time to share some of our observations about the guidelines. In our opinion the following changes to the guidelines would be very helpful for agencies trying to comply:

1. Checkpoints should be uniquely numbered and provided in a checklist form. The Guidelines themselves are not very usable. There is no easy-to-use checklist included as part of the document. In fact, if you were to go through the document and try and create a checklist (as we’ve done) you’ll see that some checkpoints are repeated three times! The checkpoints aren’t uniquely numbered either, so it can be a tongue twister to describe exactly which checkpoint you’re referring to: “It’s checkpoint 5.4.1, the second bullet point in the second paragraph after the heading on page 25”.

2. Checkpoints should have a similar scope. There are checkpoints that a site will pass by including a single email address on just one page. Other checkpoints literally roll up 30 criteria into one, such as “you should satisfy WAI priority 2 checkpoints”.

3. Checkpoints should be less ambiguous. The Guidelines say no frames, so does that exclude IFRAME tags as well? Sites must be DOM compliant – sure, but to what level? Level-0 compliance means something a lot different to the current Level-1 standard.

4. Difficult to achieve checkpoints that offer little value should be culled. For example, writing HTML tags in the same order on every page requires a huge amount of discipline. Only the very smallest sites will pass this checkpoint, so why include it?

5. All checkpoints should be testable. It is well known in software engineering that requirements of software systems must be testable. If you are expected to comply with something, then you must be able to tell when you’ve succeeded and when you haven’t. How can you tell if your site is ECMAScript compliant for example? Some of the checkpoints also introduce an element of subjectivity. Different auditors might interpret “it is clear who to contact about a part of the site” in different ways.

6. Guidance should be given to help determine what is meant by a pass and a fail. It is difficult to interpret the meanings of “should” and “must”. What actually constitutes a pass and fail? If you pass 100% of the musts? Or is it like school, and 50% is a pass? If one page on a site fails, does the entire site fail?

Probably the biggest criticism of the entire Guidelines compliance exercise is that it is still possible to create a very unusable site and comply 100% with the guidelines. Compliance needs to be in someway about abiding with the spirit of the Guidelines. As UK-based consulting firm Nomensa put it: “Making a web site technically accessible is just the first step. For your online solution to be successful it must also be both useful and usable.” Local expert Zef Fugaz also warns that “too many Government websites (there are exceptions) seem to be taking the blandness pill – playing it safe, not offending anyone, keeping it neutral.”

In most cases, it’s not technically difficult to create an accessible website. Unfortunately though, in the same way that it’s hard to create a curb cut-out after the curb has been built, it’s very difficult to achieve compliance once a site already exists. That’s the challenge ahead for the 500+ government websites that need to be compliant by the 1st of January 2006.