Designing a new product is a messy process. It involves initial brainstorming, rough concepts, false starts, and extensive refinement. Good designs begin with an identified need or opportunity, and they’re based on a solid understanding of the product’s requirements. No matter how skilled the requirements analyst is or how informed and cooperative the customer participants are, the first set of requirements they develop will be only approximately correct. It takes a process of iterative refinement and validation to accurately understand the requirements for any nontrivial product.
Designs that sound good in theory often do not succeed in real life. Unless you’re an extraordinarily gifted—and lucky—designer, your first solution ideas won’t be the best. This reality leads to an important lesson for every designer to remember:
Design demands iteration.
Creating an optimal design involves multiple cycles of understanding the problem, identifying and understanding users, articulating requirements, devising solutions, evaluating those solutions, and then refining both the problem itself and the candidate solutions. Ultimately, the appropriate decision makers can select a solution that appears to solve the correct problem through the optimum balance of features, properties, cost, and constraints.
Prototypes: What and Why
You could wait until the final product is done to obtain user feedback, as through beta testing just prior to release, but at that point, it costs a lot to make changes. It is cheaper and faster to iterate at a high level of abstraction—concepts, requirements, sketches, and models—than on completed software code or a finished product. Prototyping is a cost-effective way to perform that iteration (Coleman and Goodwin, 2017).
A prototype is a partial, preliminary, or possible solution to the problem (Wiegers and Beatty, 2013). Compared to a set of abstract requirements statements written in natural language, prototypes bring requirements to life. A prototype can range from a simple sketch of a user interface screen to a realistic mockup of a final product, depending on where you are in the design process and what questions you’re trying to answer.
Watching people interact with a prototype helps you to judge how real customers might respond to the ultimate product. It’s best if your prototype evaluators weren’t involved in creating the design, so they can approach the product as a new user might. Prototype evaluations help you assess how easy a product is to learn and whether people consider it intuitive, obvious, and usable.
Assessing a prototype provides more confidence that you have the requirements right and that your solution ideas are on track—or not, thereby leading to important course corrections. A prototype can help you work through a particularly puzzling or complex feature to determine how it should function. The feedback from prototype evaluators can help a product-development team to:
- Correct requirement gaps, misunderstandings, and ambiguities
- Flesh out details
- Discard unnecessary requirementsAssess how acceptable a proposed solution would be to customers
- Explore alternative design approaches and user interface controls
- Optimize the product’s usability and refine its cosmetics
Iterative Improvement
Figure 1 illustrates a process flow for an iterative design process. Customer representatives work with an analyst to develop an initial set of requirements. These initial requirements likely will be on the right track, but incomplete and not entirely accurate. You need to accumulate enough information about functionality, quality attributes, and constraints so that a user experience (UX) designer can conceive one or more possible solutions. Then, the UX designer works with the development team to create one or more prototypes to further the conversation with the customers.
Figure 1: Prototyping is an important component of an iterative, usage-centered design process
After customers evaluate the prototype and provide feedback, all participants now have more information. They can refine their understanding of both the problem and the product requirements. That knowledge then feeds into another cycle of solution conception, creation, and assessment.
I’ve valued prototyping ever since I realized that I didn’t have to wait until the project was over to get feedback from users on my solution ideas. If some parts of the requirements were solid and the solution was clear, I could proceed with building those system components. For less certain portions, I needed a collaborative way to help my users think more carefully about what we were going to have when we were done. Sometimes I would mock up multiple approaches, so users could select the alternative that felt most sensible to them.
Prototyping is a collaborative endeavor. Analysts, customers, designers, and engineers or software developers pool their efforts to create prototypes. As you move further toward designing an excellent user experience, you’ll need to engage UX and technical designers who have the right skill sets. The UX domain is an extensive and specialized discipline, so don’t assume all product developers can create great user interfaces. As well as having users evaluate prototypes and proposed product designs, ask a usability or human factors expert to evaluate the designs for usability, accessibility, and all the other characteristics that feed into a rewarding user experience.
Tips for Successful Prototyping
Some prototypes are superficial, cosmetic, and nonfunctional; others implement a deep but narrow slice of functionality. The strategy depends on what you’re trying to learn. It’s important to tell your evaluators which aspects of the product you’re assessing by means of each prototype—and which you are not.
If you’re assessing functionality, it doesn’t matter if the prototype is unpainted and ugly. If you’re assessing design appearance, it doesn’t matter—at least to a first approximation—whether the prototype works. It’s a good idea to build some navigations into a software application’s user interface prototype so users can evaluate the flow of a task, even if the functions shown on the screens don’t do anything. Keep the evaluators’ attention focused on the goal of each prototype.
Don’t become too emotionally attached to a prototype. Be willing to throw it out it and try again if the users reject it. Nor should you expect prototyping to replace careful requirements exploration and insightful design. Consider the following tips for guiding your prototyping experiences, whether for software systems or for physical products.
- Treat each prototype as an experiment. Determine in advance the information you seek and then design the prototype and its evaluation activities to acquire that knowledge.
- Put the minimum amount of effort into building a prototype. The more effort you invest, the more reluctant you become to discard it and try another approach.
- Use simple prototyping tools. Rough screen sketches—paper prototypes—often suffice for early explorations of software user interfaces (Snyder, 2003). Electronic prototyping tools let you quickly build screens and connections between them. Cardboard and other simply-constructed mockups of physical objects sometimes are enough to show users what the designers have in mind.
- Don’t make the prototype look too polished. Evaluators might hesitate to critique what appears to be a nearly completed product. They can be distracted by high-resolution tweaks—fonts, colors, image choices, object positioning—and miss more important structural or functional issues. Get the broad strokes right before you fine-tune the details.
- Enlist real, representative users to evaluate prototypes. This is a good job for your product champions or a focus group. Have people of various ages, sizes, and other characteristics evaluate prototypes of physical products to look for usability and accessibility issues. Examine them not just for their visual appeal but also for workability, alignment with task flow, and conformance to standards and policies.
- Create scripts to guide users through activities or tasks. Insert questions at specific points to elicit exactly the information you want.
- Don’t coach the prototype evaluators through a task. A prototype evaluation is not a training session.
- Evaluate the prototype in various expected usage environments. Depending on the type of product, these might include different light conditions (daytime, dusk, night), noise levels, and the like. The different environments can reveal such problems as inaudible audio feedback and displays that are hard to read under certain lighting.
Beware the temptation—and customer or management pressure—to evolve a prototype into the product hastily just because it looks “almost done.” Iterative prototyping is a valid way to develop software, but only if the team builds the prototype with production-quality code from the beginning. Agile software development methods take a similar iterative approach, building not just prototypes but actual portions of a product in short increments, and then folding user feedback into subsequent development cycles. If you deliver an unripe product that looks good superficially but is flimsy underneath, you’ll pay for that decision with high maintenance and support costs.
Interpreting the results from a prototype evaluation can be tricky. Make sure your participants truly are representative of the target market so their feedback doesn’t lead you astray. Evaluators might struggle to use a prototype simply because it’s unfamiliar. Any new product or software system can be intimidating and requires some—maybe a lot—of learning. If you’re not careful, you can find yourself optimizing the design to be comfortable for beginners, even though beginners may not stay that way for long.
Prototyping should be in the tool box for every requirements analyst and designer. Here’s how I look at it. You’re going to get customer feedback on your product eventually. Wouldn’t you like to have some customer feedback before you’ve shipped the product? I would.
Author: Karl Wiegers
This article is adapted from The Thoughtless Design of Everyday Things by Karl Wiegers. Karl is the author of numerous books on software development, design, project management, consulting, and other topics. During the past 50 years, he has designed chemistry experiments, software applications and user interfaces, software development processes, books, games, songs, and training courses.
References
- Coleman, Ben, and Dan Goodwin. 2017. Designing UX: Prototyping. Collingwood, VIC, Australia: SitePoint Pty. Ltd.
- Snyder, Carolyn. 2003. Paper Prototyping: The Fast and Easy Way to Design and Refine User Interfaces. San Francisco: Morgan Kaufman Publishers.
- Wiegers, Karl, and Joy Beatty. 2013. Software Requirements, 3rd ed. Redmond, WA: Microsoft Press.