Database Reference
In-Depth Information
Type quietly.
Some keyboards are noisier than others, and fingernails can make additional noise.
The quieter the typing is, the less distracting it is.
Type continuously.
If the room is quiet and suddenly I start banging on the keyboard, that could
alert the users that they've just done something interesting (which they will probably assume is a
mistake). But if I keep up a fairly constant stream of typing, it becomes part of the background
noise and thus is less salient.
I've found it useful to learn to type without looking at my screen—not too hard once you accept that
you'll make a liberal number of typos; that way you can keep your eyes on the action. (As a note-taking
facilitator, I have learned to type one thing while saying another, which is much more difficult and takes
practice.) Whether your notes are handwritten or typed, if you follow my suggestion to leave at least 2
hours between usability tests, you should have time to go through your notes. Fill in details and repair
any especially unintelligible passages while the events are still fresh in your mind.
Although it is uncommon (it's never happened to me), if a user ever asks to see your notes you should
allow this because users have a right to know what data you've collected about them. The implication is
that you should never put anything in your notes that you'd be uncomfortable letting users read.
Capturing User Quotes
I tell myself that the user's voice speaks 100 times louder than my own. One or two user quotes are
usually worth whole paragraphs of my own opinions about something—it's hard to argue with a good
user quote. But even though I type fairly fast, I can't keep up with speech, so sometimes my quotes
turn into paraphrases. (For those who don't type fast or want to be certain they've gotten a quote right,
a tape recorder might be a useful backup.)
As with observations and inferences, you want to be able to distinguish after the fact which is which, so
my convention is to use quotation marks to set off wording that I'm certain I've captured verbatim.
When I fall behind and have to start paraphrasing, I'll end the quote but continue with the gist of what
the user said. Or, sometimes I use ellipsis (...) to leave out the words I didn't capture exactly, then pick
up the quote farther on. One of the risks of paraphrasing is that it can be hard to tell afterward how
accurate you were. One trick I've learned is to use "says" in my notes when the user is talking and I'm
fairly certain I'm capturing the meaning but not the exact words—in other words, I believe a videotape
would confirm what I'm writing but I wouldn't bet a year's salary on it. If I'm less certain (or am certain
that I missed something), I use "Something about..." which is a reminder for me later to ask the other
observers if they can fill in what I missed.
The user's voice speaks 100 times louder than my own.
Including Context
This has happened to me more times than I care to admit: I'll have some awesome quote in my notes
such as, "Oh, wow, it's like they read my mind" and 2 days later, I have no idea what the user was
talking about. In the heat of the moment, between asking questions and listening to answers and all
that, I forgot to include enough contextual cues in my notes to reconstruct what happened. In particular,
context means keeping track of what screen the users are looking it and what data they enter. You may
also want to write down what the facilitator says, to help you distinguish between a spontaneous
comment and one that was prompted by a question—the former usually carry more weight.
Search WWH ::
Custom Search