This is the final installment in our series delineating the user-centered design process. We’ve talked about Why Usable Isn’t Enough, and we’ve walked through Phases 1 Discover, 2 Define, and 3 Ideate. Now it’s time to Implement.
It’s in this stage that you bring your concepts to life via prototyping and testing. Implement is another evaluative phase, and each prototype-test iteration adds details to your solution, resolves uncertainties, and compels you to think about how your solution will (or won’t) work in the real world.
But before you can bring your concepts to life, you have to decide which of the concepts from Ideate you want to pursue. That’s a difficult decision, but there are four key questions that you should be asking yourself about each concept that will help you to decide.
Selecting Concepts for Prototyping
1) Does the concept embody your design criteria?
At the end of Define, you will have developed several design criteria based on the results of the research you conducted in Discover. The concepts that you choose to pursue should embody as many of those criteria as possible, otherwise, your solution will not meet all of the needs of your target users.
2) Is the concept desirable?
If you’ve done due diligence in Discover and Define, you can be confident at this stage that you are solving the right problem for your users. But now you have to ask, will users want this particular solution? Does this solution fill a need and will it fit into people’s lives?
The Edsel is a classic example of a commercial flop that failed the desirability test. Among other issues, it was introduced in late summer of 1957, just before the economy entered a (predicted) recession. By 1958, buyers wanted economy-sized cars, and the Edsel, a rather large car, was seen as too expensive to own and maintain.
3) Is the concept feasible?
Ask yourself: can we do this? Can we as a company (or in the case of Daedalus, our client) actually build this thing? Do we (or they) have the right operational capabilities? Is the technology that this solution requires already available or is it at least within reach? What are the risks of developing this particular solution?
Failing the feasibility test is another classic example — the Apple Newton. The Newton was an early personal digital assistant that was introduced in 1993. The Newton could store your contacts and notes, manage calendars, send faxes, and supposedly translate handwriting into text-based notes. Unfortunately, the handwriting recognition was terrible—it misread characters so often and to such an extent that it was lampooned in the media, including in an episode of The Simpsons.
4) Is the concept viable?
Should we build this particular solution? What is the size of the target market, and what will be the return on investment for this particular solution? Does the cost of developing it outweigh its benefits? And does this product align with our (or our client’s) business goals?
As an example of a product that failed the viability test, consider Colgate Frozen Entrees. Introduced in 1982, these entrees asked customers to completely shift their view of the Colgate brand too far afield from oral hygiene to delish dinners. It was a leap that people just couldn’t make. Had Colgate launched these entrees under a different brand name, maybe we’d be eating them today.
Fail early. Fail inexpensively.
Once you’ve answered those questions and have selected the concept or concepts that you want to move forward with, it’s time to start prototyping. A lot of people think of “prototypes” as nearly completed versions of a product that will be used for usability testing or taken to a trade show to entice potential buyers. And while those are examples of prototypes, prototyping should start much simpler and much earlier in order to build toward those more polished late-stage prototypes. A prototype is any early conceptualization of an idea—including those simple sketches that you ended with in the Ideate phase.
Prototyping is also as much an internal learning mechanism as it is a testing method and should be applied at multiple stages of concept development. What you are trying to learn determines what type of prototype you should use. The point of prototyping is that it allows you to quickly determine what won’t work and to do so early enough in your design process that it won’t cost a lot of time and resources to fix the issues that you will inevitably find. Good prototyping addresses key uncertainties — those that help you to decide how a concept needs to change to continue to move forward as a solution.
In the early stages, you’ll use low-fidelity prototypes. These prototypes require low levels of effort, and might simply involve sketches that illustrate the concept as a whole or may focus on touch points or interactions in a user’s journey. At Daedalus, we regularly use paper prototypes with internal teams and clients to walk through how the user might interact with a product and to ideate system configurations. We even take low-fidelity prototypes to users and other stakeholders that we’ve talked with in the earlier phases for formative feedback. We will also on occasion use low-fidelity prototypes in participatory design activities.
As your process continues, you’ll move on to medium-fidelity prototypes, such as looks-like and feels-like prototypes. The effort involved in creating these prototypes is still comparatively low, which allows you to easily incorporate feedback. These types of prototypes are best used for testing the flow, navigation, and information architecture in a UI. For physical products, they allow designers to explore the basic size, look, and feel of a product. They can help to access ergonomic factors and provide insight into the product’s final form. But even with medium-fidelity prototypes, the idea is to use the minimum level of realism that helps you to answer your questions. Remember, you should still be planning for changes at this point as you gather additional feedback.
Finally, as your design process draws to a close, you’ll start to create high-fidelity prototypes. These prototypes require a much higher level of effort. They are often realistic models that are used for summative usability testing and final reviews, before going into production. They can be used for final fit testing, for component parts. To the greatest extent practical, they attempt to simulate the final design, aesthetics, materials, and functionality of the intended design. This is typically what people think of as prototypes but remember—this is the LAST stage of prototyping.
Though we’ve walked through the phases of user-centered design in a nice orderly fashion from Discovery to Define to Ideate to Implement, the process can be highly iterative, not just within each phase, but across the phases as well. It is always possible that you will learn something in a later stage that sends you back to an earlier stage. That’s not a bad thing—it means that your final solution will be more likely to succeed at solving the problems that you set out to solve and will be more likely to be accepted by your users.
Best of luck with your future design projects. Should you need extra guidance through any of the phases of user-centered research and design, Daedalus is here to help. We’ve navigated companies through the entire process, but also regularly assist through specific steps, from planning research and training companies to use the research protocol or helping to affinity sort research findings to ensure companies understand what they’ve learned, to facilitating ideation sessions and evaluating concepts with end users.