Database Reference
In-Depth Information
this gives them experience with the interface. It's true that the Computer needs to understand how the
interface behaves in response to the user's inputs, but one can usually pick up the necessary
knowledge simply by watching someone else walk through the tasks a couple of times. Just as the
interface isn't expected to be perfect, neither is the person playing Computer—if the Computer makes a
mistake during a usability test (which is not uncommon for more complex interfaces), there's usually
another team member present who will notice and help get things back on track. (It can also take some
of the pressure off users to see that the Computer makes mistakes too.)
When practical, it's good to have more than one person who is prepared to be the Computer. You don't
want to cancel a usability test because your Computer is home with the flu. Also, it's fairly demanding to
be the Computer. In particular, it's hard for the Computer to also take notes, which is an important thing
for the lead designers to do. So try to spread out the effort a bit. Some teams have two or three people
who take turns playing this role, or they may have different Computers depending on the task. I've done
paper prototype tests where Person A kept all the pieces for tasks 1 and 2 , Person B was responsible
for tasks 3 and 4, and so on. (While the Computers are changing places, I joke with the users that
we're giving them a hardware upgrade!)
Some teams have a Co-processor work with the Computer. The Co-processor finds pieces, puts
pieces back when they're no longer needed, writes things on the removable tape, and otherwise helps
keep the prototype from becoming a disorganized mess. For example, when a user clicks "Add to Cart"
on an e-commerce site, the Co-processor prepares a piece of removable tape to represent how that
line item will appear in the shopping cart (see Figure 7.9 ).
Figure 7.9: The Co-processor can help out by doing things such as writing the line items for the
shopping cart based on what the user selects and recalculating the total.
When (and When Not) to Redesign
Sometimes even an internal walkthrough is enough to expose major problems in the interface. The
mere act of performing the steps as users are expected to do can reveal aspects of the interface that
are cumbersome or even technically impossible. When this happens, it's appropriate to come up with
an improved version of the design even before the first test. It makes sense to redesign the prototype if
theteam agrees that the issues found during walkthroughs are valid and serious. (As an example that
may seem extreme but that occasionally happens, sometimes even one of the lead designers can't do
a task.)
On the other hand, you should resist the temptation to redesign based solely on someone's opinion or
the desire to try a different approach without understanding the strengths and weaknesses of the
existing one. The problem with doing redesign before testing is that you don't yet know what you don't
know. Once you watch users work with the prototype, you'll better understand the problems you're
trying to solve. So if design ideas come up, jot them down and save them until you have some data
from testing—then you'll know which of your ideas you truly need.
Search WWH ::




Custom Search