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 article 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: 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 need, and you really want to get those insights before development is in full swing. The ideas that come from nontechnical people aren't always useful or workable, but the paper prototype will sort the wheat from the chaff. Be open to prototyping something even if you're not sure how to make it work—maybe you'll be able to use the idea in another form if it works well for users.

• If you're not technical, remember that interface design is a skill as well as an art. You have a lot to contribute, but not all of your ideas will be practical within the constraints of your development process. Sometimes you'll have to defer to the techie types when they say, "The architecture doesn't support it" or "That goes against our style guide." But don't be afraid to pick up a pen and scribble a screen if inspiration strikes.

It's important to have at least one person on the core team who has the technical perspective—knows the system architecture, the limits of the technology, what is easy, and what is hard. This will prevent the team from developing a prototype that is impossible to implement. This person(s) should have the final word on whether and how something is included in the prototype.

The Rest of the Team

Paper prototyping is a multidisciplinary activity and should include people in addition to those who are directly responsible for the interface design/development. In particular, seek out those who have direct contact with users: sales, marketing, tech support, trainers. These people often have valuable insights about what users want and what confuses them. So do writers and QA/QE/test engineers because they are often among the first people to use the interface, albeit in a lab setting.

A Note about the Graphic Designer

If there's a graphic/visual designer assigned to the project, it's great to have that person involved, possibly as part of the core team. But the rest of the team shouldn't be intimidated by the presence of someone whose doodles could be framed and sold as art. When a team member has artistic ability, others may be tempted to let that person do all the prototyping work "because it will look nicer." Remind everyone that it's fine if the prototype looks like it was drawn by a 10-year-old because the point is not to spend time making things look pretty when you'll want to change them tomorrow anyway. The graphic designer shouldn't have to do more of the work than anyone else.