By Brian Still| Member
This column examines the ways technical communicators contribute to the development of more usable products, especially those used in complex, dynamic environments. Novel usability evaluation methods and design techniques, as well as those rediscovered or repurposed, will be the focus. Please send your comments, questions, and suggestions for future articles to me at brian.still@ttu.edu.
For this column, I'd like to look at an under-used but valuable method for gathering feedback from users: low-fidelity (often called “paper”) prototyping. I think we look past low-fidelity prototyping for many different reasons, placing most of our efforts into learning what people think about more developed, maybe even already operational or “live,” versions of our products. Usability, however, doesn't just mean problem-finding. There is a place for discovering difficulties that effect user interaction, and certainly there is an assortment of methodologies available to us for identifying the severity and scope of those errors. But we need to remember that usability also works really well, and some, such as Lane Becker, argue that it works even better when it is integrated as early as possible into the design of a product.
This doesn't mean that users are designers. A lot of times users have crazy ideas, and usability isn't about preference, it's about use. We want to find a way to let users do what they do with our products, and if we can make that happen before we've spent a lot of money on finalizing the product or selling and marketing it, then in all likelihood we'll ultimately be able to iterate a website, software, a manual—really any product that people use—that is truly user-centered.
This is why low-fidelity prototyping should be part of every technical communicator's toolkit. It can be a great entry point for controlling user involvement in product design. It can even be used inventively in meetings where a lot of people might be involved and you need some method to organize collaboration and keep groupthink in check. Let me walk you through a brief overview of low-fidelity prototyping and offer some examples of how you might be able to make it work for you.
In every usability testing course I teach, traditional undergraduate and graduate courses as well as a three-day, hands-on corporate user-experience certification course, I require students to carry out low-fidelity prototyping almost right away. In the corporate course, because so much emphasis is placed upon making usability methods work for design, I assign paper prototyping on the first day of the class. That's because low fidelity isn't especially intimidating to the student. No special recording instruments or adherence to particular facilitation protocols are required. Low fidelity is also more comfortable for the user, who can be intimidated by the clinical setting of a usability lab or the high fidelity of a more refined product they are evaluating. In fact, studies show that users are often more willing to be critically constructive of a low-fidelity prototype because it doesn't feel too expensive or finished.
So how can it work? For starters, low fidelity can be defined differently. If you really want to get a sense for how users think about, for example, what makes a good design for a magazine, you might provide them with a scenario that contextualizes the situation they're working in, and then you offer literally a blank canvas (maybe as many sheets of blank paper as they want) for them to fill out, talking aloud as they sketch what they think is the ideal layout for the design. You and your team can ask questions as they design, and what the users create can be considered afterward along with other ideas you have.
Some might say this isn't any different from a focus group or interview, but I would argue this point. For one, focus groups often involve more than one user, and users are responding to (not using) questions and each other. Interviews, even open-ended, are responsive as well. With low-fidelity prototyping, users are doing something as they respond to questions or verbalize their thoughts, and they are performing within a scenario you construct. This scenario can be further organized by having the users carry out typical use tasks for the product under construction. In other words, low-fidelity prototyping still allows you to triangulate what users are saying and doing along with what you are observing, and this, unlike other feedback methods, provides you with a chance to gather early user contributions, but also to control them. Let users be users and incorporate their feedback not just on what they say, but on what they do and say. After all, users don't just talk about products, they use them.
Lower fidelity testing can also take on other forms. Let's say you know generally how your product needs to be constructed and you might already have a couple of design models. Ask users to evaluate your designs by engaging them with both models through comparative low-fidelity prototyping. Require users to perform tasks that are the same for each design. On paper, since there aren't any buttons that work yet, ask them to push on images of buttons and you or a colleague will make them work by pulling up another printed page. If a button or another kind of feature is missing, provide users with post-it notes so they can make and add what they like. Allow them to re-organize the layout if you want that sort of feedback.
A few years ago, students in my lab were working on discovering the interface problems of a radio alarm clock. It seemed that users were having problems making it work and were still calling down to the hotel front desk to ask for a wakeup call. Students inventively mocked up a tissue box with white paper and then created post-it buttons. They then asked users to design the interface of the alarm clock. After testing, they determined that users conceptualized a much simpler interface for the alarm clock than what the hotel provided, which included both “nap” and “snooze” buttons.
The point of low-fidelity prototyping is that there are few constraints other than those you create, based on your goals. You can make the prototype blank; you can print off just the home page of a website and evaluate navigation past it; you can cut up a brochure into chunks and ask users to arrange in a way they think is intuitive; or you can focus on particular elements of a page, say an advanced search feature, and ask users to carry out tasks using it, reacting to what's there and giving them a chance to add what they don't see but want. There are reasons aplenty for bringing in users as early as possible, and the fact that you don't have a working prototype should never be a legitimate excuse. You just need some imagination, paper, markers, crayons, post-its, tape, and scissors. You can even do whiteboard prototyping and forego all these supplies, encouraging the user to interact with the prototype using dry erase markers.
This whiteboard low-fidelity prototyping is especially useful for meetings. Plan ahead a little and you can use it for organizing what might be a normally disorganized free-for-all discussion. If you want to channel thoughts more productively of all involved and have something more concrete when you're finished beyond a whiteboard full of brainstorming notes, create a scenario for the process, come up with a task or two for the group to perform, and then challenge them to use/create the prototype within the constraints of the tasks and scenario.
If you design anything for anyone to use—and I mean anything—find a way to get users involved, as users, not designers, early on. Provide focus for all this by having a specific purpose or objective for what you're after. You just don't want the users to draw or talk about design. They should be doing something that helps you understand how the users they represent will think about and ultimately use a final version of this early prototype. Finally, if you want to know more about low-fidelity prototyping, read Carolyn Snyder's great book, Paper Prototyping, and feel free to drop me a line to help you with ways to think about how you can effectively integrate it into your TC toolkit.
