Planning a Usability Study with a Paper Prototype - Paper Prototyping: The Fast and Easy Way to Define and Refine User Interfaces - page 80

People to Involve
Paper prototyping and usability testing should involve all members of the product team, not just those
who have "designer" or "usability" in their title. Every day of a project, dozens if not hundreds of
decisions are made that affect some aspect of the user experience. Even under-the-surface technical
factors such as database design can have an impact on the user interface (and vice versa). Practically
speaking, the number of decisions that affect the user is too large for one person or even one
department to handle. If only one or two people in the company are responsible for the entire user
experience, their limited ability to collect and disseminate usability data will quickly become a
bottleneck. Instead, it's usually better to have many people participate in usability activities and get the
data firsthand. This section explains who should be involved and to what extent.
Terminology: Designer and Developer
As I start tossing around words such as designer and developer, I'm going to run afoul of differences in
how people define these terms. At some companies, the same person who designs the interface also
codes it, tests it, and maybe even helps document and support it. Other companies distinguish
between designers and developers. Furthermore, there are graphic designers and interaction designers
and software designers and instructional designers—see the problem? I'm going to adopt some role-
based conventions:
A designer figures out what it should do or be. (The "it" depends on the context—usually I'm talking
about an interface, but these terms also work for documentation, training, and so on).
A developer makes it happen.
Technical means "understands the constraints of the technology and tools used to implement the
interface."
Using these conventions, someone from Marketing might be considered a designer, and a trainer
wears the developer hat in the context of creating a course. People from a variety of departments might
be considered technical depending on what they know—for example, some writers are very savvy
about technology. I am deliberately using broader definitions than many people are used to because it
underscores my philosophy that creating a product is a multidisciplinary process. You know who you
are—if it sounds like I'm talking about you, assume that I am, even if I'm not using the title you're
accustomed to.
The "Core Team"
If you have a large development team, it's a good idea to designate two to five people as the "core
team" for the activities in a usability study. When it comes to scheduling, it's unlikely—and probably not
even desirable—that the entire development team can be involved in every aspect of the prototype
preparation and testing. Plan the activities around the availability of the core team and invite others to
participate in whatever they're able to.
The core team consists of those people whose involvement is crucial to preparing and testing the
prototype. Typically, the core team includes the designer/developer(s) responsible for the interface and
a usability specialist if the team has one. One of these people takes the leadership role in planning and
conducting the activities. The development manager or product manager may be part of the core team,
although if this manager oversees several projects he or she may delegate the responsibility to one of
the people mentioned earlier. It's also quite common to have a tech writer, marketer, and/or graphic
designer on the core team.
Technical Expertise
For a moment, I'm going to divide the world into two types of people: [ 1 ] those who are technical as I've
defined it and those who are not:
If you're the technical type, realize that other people have good insights about what users want and