Database Reference
In-Depth Information
Example 1: The MathWorks
By Mary Beth Rettger
I'm Director of the Usability Group at The MathWorks, a developer of technical computing software. At
The MathWorks, we use several user-centered design techniques to help us understand what our
users need and to ensure that what we build actually meets those needs. Here's how we applied
contextual interviewing, paper prototyping, and usability testing to the development of MATLAB 6.
Contextual Interviewing
It's important to watch and/or interview customers in their own work environment, where they can easily
show us examples of what they are trying to accomplish. This process is called contextual interviewing.
Rather than just getting a laundry list of new features users want, they show us how they hope to use a
new feature or explain what problems they are trying to solve with the current product. Armed with a
thorough understanding of the problem, our software designers can come up with targeted solutions
that address the users' needs.
During MATLAB 6 development we undertook a research project with the assistance of undergraduate
students enrolled in an Engineering Psychology class at Tufts University. The project was a win-win
situation—we obtained a lot of data with relatively little effort from within the company, and the students
received course credit for their work. After some training in contextual interviewing techniques by our
usability team, the students interviewed about 20 MATLAB users. The students wrote formal reports
summarizing the "top 10" issues observed during the interviews. They also provided us with detailed
interview results, including artifacts such as samples of users' work, outputs, and photos of the users'
work environments. Finally, the students created several "Meet Our Users" posters that graphically
illustrated several typical users and their work. (This is similar to the technique of creating
personas,
although personas are usually made-up examples of typical users instead of actual people.)
All this information was valuable to the development team. Developers who were eager to get a fresh
perspective on the problems our users faced appreciated the top 10 lists and the user posters. The
individual interview transcripts were even more important—developers pored through this information to
get specific data with which to prioritize their efforts. Several key themes came out during these
interviews, including requests that we improve MATLAB's Printing, Plot Editing, and help system. That's
where the work artifacts came in handy: Seeing examples of real work that users were trying to do (or
had difficulty doing) helped the developers gain a better understanding of where to focus their efforts.
Because the students were not MATLAB experts, we were still left with the task of determining which
changes to make to MATLAB. Several development team members (including tech writers and quality
engineers) went out on a handful of follow-up interviews with users, getting answers to questions that
had arisen from the student interviews. This combination of efforts helped us come up with an excellent
list of priorities for MATLAB 6.
Usability Testing of Paper Prototypes
Once they understood what users wanted, developers were eager to begin coding new solutions, so
we moved on to paper prototypes. Most often, the basic design was hand-sketched, and other user
interface elements such as drop-down menus, dialog boxes, and error messages were created using
sticky notes, tape, and glue.
Thanks to the contextual interviews, we had a good idea of what "realistic tasks" were for our users.
Team members worked with one task at a time and walked through the process of completing it with
the prototype. Because the developers were focused on the users' tasks, they had to think hard about
the purpose and value of each feature. This ensured that only the essential parts of the interface were
created—no need to add extra features if they weren't relevant to the users' work.
The MATLAB 6 release contained several tools, so it was practical to test each tool with only a small
number of users. We selected customers who would typically use the feature we were testing. One or
more developers acted as the Computer, responding nonverbally to the user's interactions with the
Search WWH ::
Custom Search