Seven design bloopers
This month we provide some useful information on web site usability from one of our managed affiliates, The Hiser Group.
The Hiser Group has been specialising in the design of interactive systems since 1991, so we’ve seen many changes take place in the IT industry. Our tried-and-true methodology has been used on a range of interfaces, from character based systems to the latest web technologies. The proof of our success lies in more than 1,500 projects we’ve been involved with since we started.
In this article Alinta Thornton, a Senior Consultant at The Hiser Group gives you an insight into designing a web site or application and avoid usability problems …
Web teams around the world have come up with many ways to get user input. Here are seven methods people use to design their web site or application that are usually unsuccessful in avoiding major usability problems – and the design rules that show you how to avoid them.
Blooper 1: “We’ll just build a good site…” (without users)
Many people think good design is just a matter of carefully building a structure that makes sense to them, getting a good graphic designer to create a beautiful interface, and writing snappy content.
“After all”, they reason, “we’re good at what we do. We win awards”.
“No need to involve users, that takes far too much time and effort. We’ll just build something that works, right?
“Anyway, what if we find out users don’t like some of it? Does that mean we’re not good designers?”
Involving users to find out their needs is good design. No matter how good a designer you are, you’re going to produce something better if you fully understand what users want (and more importantly), what they need.
You’ll get the credit if the site does what it’s supposed to do.
Rule 1: “Don’t design in a vacuum”.
Blooper 2: “We know what our users think”
Many companies think they know their users very well. “We deal with them every day, we have a lot of information about them from market research and sales figures and call centre records.”
We’ve found many times that beliefs companies hold about their own customers are at odds with how the customers really think and behave.
The problem is that you aren’t your user. Your skills, knowledge and reactions are very likely to be different from theirs. However hard you try to imagine you’re the user, you can’t be them.
After all, they do different jobs, probably don’t work at your company, come from different backgrounds, are different ages, aren’t steeped in the company’s terminology, and probably aren’t web site experts.
Even if you know them very well and deal with them daily, and even if you use the same site you’re designing or upgrading, you still aren’t a user.
Why is this a problem?
Things that seem natural and normal to you may not seem so to customers. For example, it might seem obvious to an aluminium production company which of its products are made in the Extrusion Division and which are made in the Foil Division. Customers, however, may not be at all sure.
In this case, having two buttons on their site labelled “Extrusion” and “Foil” is likely to be a poor choice, even though it may please the managers of each of these divisions.
Rule 2: Don’t work without involving real users
Blooper 3: “We know what users think – we surveyed them”
Another way to approach the problem is to create an initial design, show it to users, then ask them to complete a questionnaire.
Unfortunately, even the best questionnaire will rarely get accurate results. Usually people will rate the system much higher than it ought to be rated. We often see people struggle with a site, unable to do any of the tasks they wanted to perform, and then rate it 4 out of 5 on every aspect.
Why surveys are inaccurate
People don’t accurately reflect all their difficulties in surveys for a number of reasons. For example, they:
-
don’t want to upset the person who’s reading the result
-
are unwilling to commit criticism to paper
-
are unwilling to criticise more than one thing, because they don’t want to be mean
-
are influenced by the site’s appearance. If they like the way it looks, they will often rate it highly even when they can’t do anything
-
tend to believe their problems using the site were their own fault for not using the site properly or not being skilled enough.
Cost to the business
Placing too much store in survey results can be risky. If, for example, a shopping site’s customers can’t locate items in a catalogue, or a banking site’s customers can’t work out how to apply for a mortgage, they will take their business to a competitor.
Rule 3: Don’t rely solely on questionnaire results for your user data
Blooper 4: Ask internal staff instead of end users
Another approach is to develop a design and show it to people inside the company. After all, they aren’t close to the design the way you are; won’t their opinions be useful?
Their opinions are useful to you – as stakeholders at your company, but not as your users. They are too steeped in the company’s structure, organisation, naming conventions and attitudes.
Staff don’t have the same point of view as customers. Unless you’re building a product your company’s staff will use, such as an internal software system or intranet, staff opinions are interesting but they are not going to help you much.
They know why customer service takes three days to answer a query, whereas a customer doesn’t care. Customers just want an answer, now.
Your friends and family don’t usually fall into the category of your users either. (Unless your site is for, say, librarians and your friend happens to be a librarian).
Rule 4: Staff, family and friends are not normally your users.
Blooper 5: Justify or defend the design when you’re testing it
Some design teams will gather together a focus group before the project starts. This can be very helpful, if you’re asking about things like what they’d expect from such a site, what they’d want to find there, what they’d want to be able to do, etc.
If on the other hand, you’re showing users a finished design and asking for opinions, it’s unlikely to pull out anything useful.
When the design is finished, you may be somewhat defensive. If a user says, for example, “I don’t like the way the navigation works”, you may find yourself jumping to explain why it’s like that – it’s only natural.
Unfortunately, you’d miss out on the useful feedback, and the user gets the message not to criticise.
If you use a collaborative design method, though, this can work well. It’s all in the way you approach it.
Rule 5: Don’t justify or explain faults: let the design stand or fall on its merits
Blooper 6: “It’s a training issue”
Where training is used as an alternative to user-centred design, it tends to happen on internal applications, such as intranets or software systems or web sites for use by clients and staff.
The system will be difficult to use, but staff are captive, so the development team can say to themselves, “it’s hard to use because it’s new; we can train everyone to use this and it will be fine”.
That’s true; people can be trained to use anything. You’ve probably done so yourself.
Cost to the business
But what’s the cost of this training – an ongoing cost – as opposed to the cost of getting it right upfront?
You can calculate the cost like this:
(No. staff turnover/year x hours required to learn the system x median hourly income) + (x hours training x median income trainers) + (cost of training materials and equipment) = total training cost.
Acme’s training costs
Using a sample company, Acme Pty Ltd, here’s a worked example:
120 staff x 35 hours’ formal training x $62/hr = $260,400
45 hours trainer’s time (including preparation) x $76/hr x 40 groups = $136,800
$15 per handout x 120 staff = $1800
10 hours informal training x 120 staff x $62/hr = $74,400
10 hours informal training x 120 staff x $76/hr = $91,200
Total training costs = $564,600
If Acme can reduce training requirements by even 25%, this represents a saving of $141,150 per year. Over the life of the site this could really add up.
A well designed, usable system could reduce training time by considerably more than 25%.
Rule 6: Don’t use training to substitute for good design
Blooper 7: Doing only acceptance testing or prototype testing
Sometimes a web site team will do user acceptance testing, or even usability testing once a prototype is built. This in itself can be useful.
But what often happens is that serious design problems will be uncovered at this point. After you’ve done the design, graphics work, coding and structural work, it can be expensive and time consuming to fix the design at this point in the development process.
By now you’re near the launch deadline. Realistically, you only have a few options:
-
Most teams will fix whatever is easy to fix and launch the site, complete with problems
-
Delay the launch to fix the worst problems
-
Add resources to help you fix them.
Launch anyway with the problems intact
Launching a site with usability problems can mean you lose customers, since research shows if people have a bad experience on your site they won’t return. You just lose the business.
Fix the worst problems
Fixing serious problems late in the development cycle usually means you’ll miss the production deadline. Since the deadline often relates to meeting current market needs and beating competitors into the market, this can be serious.
Data shows that companies generally:
-
lose 33% of after-tax profit when they ship products six months late, compared with
-
3.5% loss when they exceed product development budgets by 50%.
House and Price (1991)
Add resources
So it’s better to spend a little more on hiring a specialist user interface designer (either in-house or consultant) to get the design right up front.
Cost to the business
The rule of thumb is that it costs:
$1 to fix usability problems during the initial design phase
$10 to fix once the code has been written
$100 to fix after it’s been released.
