By Jakob Nielsen, Ph.D.
If you’re a one- or two-person development shop, can you do usability? Emphatically, yes. In fact, you’ll have an easier time with usability than many big organisations.
The two biggest barriers to quality user experiences are:
- Internal focus, instead of a focus on customers’ needs.
- Not believing the user research or not acting on it because the project is bogged down in bureaucracy.
These two problems are common in big companies, where employees spend most of their time navigating the internal system, because the internal system is so big. In contrast, small companies have fewer internal issues, so they are free to focus on customers’ needs. You don’t have to worry about the career implications of crossing the ‘vice president of important meetings’, if you don’t have any VPs.
A big company, it’s hoped, has the luxury of a dedicated usability group that performs a lot of studies. Ask any of the usability engineers, and they’ll know why customers don’t like a product and the main problems that need to be resolved. Unfortunately, these research findings frequently are put aside and not given top priority in the development process.
When a project manager or the vice president of system development hears a usability specialist report, for example, that ‘Almost no customers can use the foo feature in our new product release’, they will mentally dismiss the data. After all, they didn’t personally watch 10 people struggle with the product and fail to use foo correctly. In their minds, the empirical data becomes something like ‘Well, maybe foo isn’t as great as we thought it was.’
When it’s time to work on the next release, the project manager may remember to take a second look at the foo feature, instead of spending the entire budget on new features. But the radical revamping that was indicated by the data usually won’t happen.
Contrast this story with the situation in a small operation.
You, yourself, the main (and maybe only) developer spend a day running a usability study with four users. You cringe as all of them have a miserable experience with your beloved foo feature that you spend many a late hour creating.
When preparing for the next release, you’re sure to remember this experience. Also, you’ll definitely believe the usability data. After all, you ran the test yourself, so you can’t dismiss the findings by telling yourself that the researchers didn’t know what they were looking for.
Four users you observed yourself can affect the product more than a ten-user study documented in a report that’s lying on a shelf somewhere but isn’t acted upon.
All of this raises the question: Can and should developers conduct their own usability studies?
They can and they should.
I’ll be the first to admit that there are methodological benefits from employing usability professionals who specialise in this field and spend years polishing their skills. But it’s a false dilemma to posit a choice between advanced and thorough usability research on the one hand and zero usability studies on the other hand. Usability isn’t an all-or-nothing situation.
There’s another way: to do a cheap and simple usability study, often in the form of scaled-back testing with a handful of users. You can do it in a day. I call this ‘usability at a discount’. Fast methods such as this also have the advantage of playing well with Agile development projects.
For simplified user testing, follow these guidelines:
- Get hold of three to five representative customers, and test them one at a time.
- Ask each user to perform some typical tasks with your product.
- Shut up and let the user do the talking.
These rules sound easy enough, and they are. Yet most people violate them and thus don’t get the full benefits from their investments in user testing.
First: whom to test. You need outside test participants. You can’t test with your own staff or even with your friends or family, because they will have heard you talk about the product. Thus, they know too much before they start using the UI and it will be much too easy for them to figure it out, compared with regular customers, who know nothing in advance.
Also, you should test one user at a time. Interaction design research requires one-on-one studies as opposed to the focus groups that are good for marketing studies. You want to see each user interact with the system on his or her own, rather than have a group of people sit and chat about what they might do.
Second: what to do during the test session. The classic mistake is to ask people what they think of your wonderful features. Don’t do it. Users aren’t designers. They’re users, and so they should use. In other words, spend the test time observing how people interact with your user interface, what works well, and where they have trouble and need a redesign. Don’t ask them what other design they would prefer, because they won’t know, and anything they’d say would be pure speculation.
Third: what to say to the users during the test. Most developers make the mistake of saying too much and helping users to operate their design. Remember, this is a test, not a demonstration. Unless you plan to personally visit all new customers and help them get started with your product, don’t give any assistance to your test users. Watch, and see whether they can figure it out on their own.
Follow these simple rules, and you too can do user testing. The first time you try, you’ll be amazed at the weird and unexpected ways real humans use your design. But your product will be the better for your efforts. And it only takes a day. So do it.
About the author
Jakob Nielsen, Ph.D. is a principal of Nielsen Norman Group. He is the founder of the “discount usability engineering" movement, which emphasizes fast and efficient methods for improving the quality of user interfaces. Nielsen, noted as "the world's leading expert on Web usability" by U.S. News and World Report and the next best thing to a true time machine" by USA Today, is the author of the best-selling book Designing Web Usability: The Practice of Simplicity, which has sold more than a quarter of a million copies in 22 languages. His other books include Usability Engineering, Usability Inspection Methods, International User Interfaces, Homepage Usability: 50 Websites Deconstructed, and Prioritizing Web Usability. Nielsen’s Alertbox column on Web usability has been published on the Internet since 1995 and currently has about 200,000 readers. From 1994 to 1998, Nielsen was a Sun Microsystems Distinguished Engineer. His previous affiliations include Bell Communications Research, the Technical University of Denmark, and the IBM User Interface Institute. He holds 79 United States patents, mainly on ways of making the Internet easier to use.
