Why usability reports never get read (11 May 2004)
Most usability reports seem to be written to validate the study, and prove that the data found is reliable. Unless this is the first usability study for a team or corporation, scientific validation isn’t very important. They trust you. They pay your salary and give you an office (and probably shiny computers, and fancy equipment for the labs). The most important thing about a usability study is how what was observed should impact future decisions. Should some features get cut? Added? Changed? If so, how? If the study can’t answer these questions directly, or contribute to conversations of this nature, how else can it be of use? All of these things are what programmers and managers want to know. Statistical validation or details for how many people were able to do what, in what amount of time are all secondary. They are only helpful in determining answers to the questions I just listed.
The best usability engineers I’ve known tended to see the actual reports as a formality. Instead they focused on email, in person discussions, and post study (akin to post-game) breakdowns of what was observed. By focusing on the relationship between the usability engineer and the team (or client), the usability engineer can replace the report as the primary conduit for information. They make themselves available for discussions, for brainstorming sessions, and for less formal debriefing presentations to the team. In the infrequent cases where deeper analysis was required (say, a benchmark study) enough trust was built with the team that they would wait for the full report when necessary, and understand enough about the process to see why that time was necessary.
Article URL: http://www.uiweb.com/issues/issue32.htm
Read 36 more articles from UI Web sorted by
date,
popularity, or
title.
Next Article: Combining Place, Time, and Topic
|