Don’t Make Me Think! A Common Sense Approach to Web Usability. – Steve Krug
Category : Designing for Usability
Steve Krug explains how we can create better Websites if we just stop wasting time on useless debates within teams and engage in ‘usability testing’ early on in the development process. His book provides the antidote.
He distinguishes between designers and developers in what they consider to be a ‘good’ website design. Designers prefer pleasant layouts, whereas developers enjoy a good amount of features. This is also compared to the duality between commercial culture and craft culture. Which is a question of aesthetics versus usability. Ideally, we would want to have both.
Krug notes that there is no such thing as an “average user”: every user behaves differently and the more you observe and test users the more it becomes clear that users are all different from one another. “All Web use is basically idiosyncratic. […] Good design […] takes this complexity into account.” (p.128) The recurrent mistake is to assume that users alike or even that users will think like you(!). To create a site that ‘works’ Web teams should test the usability of their interfaces by observing how people understand the concept and purpose behind the site and how easily they manage to complete specific tasks. This is why considering the context in which users experience a site is very important as well. Usability testing highlights what works and what doesn’t work with a site. Often it is through testing that the most obvious and important flaws are brought to designers and developers’ attentions, as it reveals user intentions, motivations, perceptions, and responses, which give insights into whether people can use the site.
Moreover, Krug emphasizes the need for ‘usability testing’ in the early stages of designing a site, as it will help teams get rid of underlying issues once and for all (and it saves time!). For him, ‘Testing is an iterative process. […] You make something, test it, fix it, and test it again.’ (p.135) In other words, KEEP TESTING until you are left with a site that users can actually make something of.
The author then prescribes a set of prescriptions for doing your own testing when on a low budget. He proposes that: testers should avoid divulging a site’s content to testees, make sure they think out loud, document both the screen-actions and the testees (using a camera and a screen recorder), ‘usability testings’ can be held once a month, in an office room or any room with a computer, 3 or 4 candidates who have basic knowledge of the Web are a good number for every test made during the development process of a site, offering stipends ($50 to $100 per user) shows that you care about their opinions, and that this procedure can be made in a morning and debriefed with the team during lunch hour. It’s not rocket science!
However, he points out that while ‘usability testing’ is important, there are problems users will encounter that will not be essential to focus on (such as ‘why doesn’t this site have “…” service?’) and other problems that will need immediate fixing. Also, it’s important to design for you audience and others, for experts and beginners, which is why clarity of information (i.e. clarity of the wording used throughout the site) becomes significant when ‘usability testing’ is made on virtually ‘any’ user. He names 2 types responses to focus on while testing: “Get it” testing (do users get it?) and Key task testing (were they able to perform a task? and how well did they do?) (p.144).
What often happens once a few determined problems have been fixed is that new (or hidden) problems come to the foreground, which explains why testing must be made often.
Although I found the text a bit redundant, I must concur that it will be difficult to forget his advice: “Recruit loosely and grade on a curve.” (p.139)