Usability Engineering by Jakob Nielsen

Posted: January 15, 2008 in Review, Usability, writing
Tags: , ,

The new semester has begun, and I am back to work. I’ve set a goal for myself of reading 500 pages a week, one that I imagine will take me a little while to get up to. But more importantly, I’ve decided that I will not write for my thesis at least until March, thus giving me a solid month and a half of just reading. I likely will continue reading into March in order to refine whatever I’ve figured out in this first run of reading, but for now, I’m just trying to broaden my knowledge base, so that I can approach problems from a place of better understanding.

To that end, today I finished reading Jakob Nielsen’s Usability Engineering, which I had started before the break. This book was somewhat revolutionary for me, as Nielsen has tended to be in recent experiences. What follows is a somewhat unorthodox review of the book. As with everything else here, this review is slanted towards my own research, and so not all of the book was relevant to me.

Yet, a surprising amount of it was relevant. Within the first ten pages of the book, I was finding things that I could apply to peer response. When Nielsen wrote “It is no shame to have to revise a user interface design as a result of user testing [. . .] it might be a true measure of usability maturity that one is willing to acknowledge the need to modify initial design choices to accommodate the users” (11), I immediately thought of how true that was about peer response. There is nothing wrong with having to revise even the entire structure of a paper as a result of peer response. In fact, the willingness to do so shows that someone is most able to benefit from peer response.

There were other usability slogans in the beginning of the book that seemed easily adaptable to peer response. “Designers Are Not Users” (13) could just as easily read “Authors are not Audiences” and still make as much if not more sense. Students need to understand that the people who read their papers will not know everything they know, and will not necessarily read with the same tone that the author used while writing. Some of the slogans were just good advice: “Less Is More” and “Details Matter” (15) all sounded like things that I tell my students every semester. Details are important, but sometimes less is more: it matters which details are included and which ones are left out. Finally there was the obvious conversion of “Usability Engineering Is Process” (16) to “Writing is Process.”

Next, as Nielsen began talking about Discount Usability Engineering, I began thinking about discount peer response, my own idea and the reason I came to this book in the first place. Naturally, a large portion of this segment interested me. When Nielsen wrote “more careful methods [of testing] are also more expensive—often in terms of money and always in terms of required expertise” (17), I thought of the articles I’ve read about how difficult peer response is, and how it takes so long to learn how to do it properly (Simmons). Spending time really going through and offering the best response is both expensive in terms of time (the coin of the realm in a classroom) and required expertise of the responder.

The parts of Nielsen’s discount testing paralleled a lot of the best ways to consider peer response. His scenarios mapped on to students focusing on one particular thing (introductions, conclusions, outlining, tangents, etc) for responders to consider. Simplified thinking out loud might map on to the idea of reading a paper out loud—something I always suggest my students do to make sure the language flows clearly, or it might just map on to the idea of a responder giving thoughts and opinions as they go through the paper.

Most important in this section, though, was where Nielsen wrote “In discount usability engineering we don’t aim at perfection; we just want to find most of the usability problems” (19). I think that often times the most difficult thing for students to really understand is that their papers don’t have to be perfect, and likely never will be. What matters is that they make papers as good as possible. Too many students get paralyzed by the belief that perfection is required, and end up losing heart. Telling them that they don’t have to be perfect might free them to give response a sincere effort. Of course, it might also convince them that they don’t need to bother with it, since it won’t be perfect anyway. But hopefully, that won’t happen.

What follows that section is a long period of interesting but not relevant to my research information about the history of usability interfaces and what usability engineering really is. I didn’t find much else to adapt from there until chapter 4, which starts off with this:

Usability engineering is not a one-shot affair where the user interface is fixed up before the release of the product. Rather, usability engineering is a set of activities that ideally take place throughout the lifecycle of the product, with significant activities happening at the early stages before the user interface has even been designed. (71)

This gave me a major revelation about peer response. One of the things that students seem to have the most trouble with is that peer response comes at a point in the process when they feel like they’re already done. They’ve written the paper, and now we (the teachers) are asking them to keep working on it, but without giving them a grade. They tend to resent that. But if peer response came earlier on, if it were something to be considered throughout the process, then the students might start seeing it as part of writing the paper, rather than as something they do when the paper is already finished.

The chapter continues with advice that can be adapted to writing. We (the writers) need to know the user (audience) and we need to perform a task analysis so we know what we need help on. Task analysis is something I already incorporated into DPR, but this is where it comes from. Students do all know what they need help on, as Diana George suggests, but sometimes it helps to have them really look at their work and decide how best to ask for that help. Nielsen also talks about keeping an eye on what the competition is doing, both for inspiration and to avoid cliché. This seems pretty similar to the maxim that “A Writer Reads.”

Another interesting thing that Nielsen suggests is parallel design. By starting off the design looking at a number of potential ways to proceed, the programmer is less likely to get locked into a structure that doesn’t work for them. I see that in my students all the time. If they were willing to just organize their papers a different way, everything would come more easily to them. But it’s hard to convince them of that, because they’ve already put so much work into it that the prospect of ‘starting from scratch’ terrifies them. So maybe, if they wrote more than one structure from the beginning, they could at some point decide which structure is best and avoid the problem from the beginning.

Much of the rest of the book is relating to methods of usability engineering, which is to be expected, given that it’s the topic of the book. But there were still a few gems for my own thinking that I managed to mine out of it. When Nielsen talks about reliability, he writes “For usability engineering purposes, one often needs to make decisions on the basis of fairly unreliable data, and one should certainly do so since some date is better than no data” (166). Students don’t always trust one another and the responses they get. Sometimes, advice isn’t as good from a peer as it could be from someone with more experience. Even still, it’s important for them to consider that advice, because the advice is there, and even very little advice, or unreliable advice, is better than no advice at all; the author can always abandon what won’t work for them.

Nielsen presents stages of a test that sound like the process of writing. He suggests that a usability test has four basic stages: Preparation, Introduction, the Test, and Debriefing (187). Similarly, the process of writing (most particularly of rewriting) can be broken down into those same stages. First the writer prepares by writing the paper, performing a self analysis, and producing peer response questions. Next comes the introduction, where they find a potential responder, explain what help they are looking for, and provide those questions. Third is the actual test, where the responder looks at the paper and tries to provide helpful feedback. Finally we have debriefing, where the responder and the writer talk, and the comments that need explaining are explained.

Nielsen’s advice to the experimenter (the person running the test) is also very useful. He mentions that they “should normally refrain from interacting with the user, and should certainly not express any personal opinions [. . .]” (190). Similarly, writers need to not defend themselves and their papers, but rather just listen and understand that the advice is meant to help. After all, the tester (responder) is there to provide outside input, and since they essentially are the audience, they can provide good information about how the audience reacts to the paper.

The rest of the book wasn’t relevant to my research, but there were some interesting bits. Apparently, thinking out loud proves to be generally more efficient. Users are almost 10% faster and make only about 20% of the mistakes if they think out loud (196). Beta testing might be adapted to writing studies, but I’m not sure having students grade one another’s papers would be the same as when “a forthcoming product is released to a small number of selected customers for their comments” (222).

All in all, it’s a fascinating book, and a surprising amount of it was relevant to my research. Maybe that’s a point in favor of the similarities between programming and writing studies, or rather the contention that programming is the same thing as writing.

  1. […] is beginning to really simplify his definition of usability. It isn’t as complex as it was in Usability Engineering, and it looks like he’s making a move towards equating usability with ease of use. Some (such […]

  2. Praveen says:

    I liked your application or parallels on usability engineering to writing. I am looking forward to buy this book. Came across your blog. It has inspired me further to read. Thanks for sharing!.
    Praveen Uchil

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s