{"id":3740,"date":"2022-02-07T09:50:45","date_gmt":"2022-02-07T14:50:45","guid":{"rendered":"http:\/\/blog.daed.com\/?p=3740"},"modified":"2024-07-11T10:59:12","modified_gmt":"2024-07-11T14:59:12","slug":"user-centered-design-phase-4-implement","status":"publish","type":"post","link":"https:\/\/blog.daed.com\/?p=3740","title":{"rendered":"User-Centered Design: Phase 4 Implement"},"content":{"rendered":"

This is the final installment in our series delineating the user-centered design process. We\u2019ve talked about<\/span> <\/span>Why Usable Isn’t Enough<\/span><\/a>, and we\u2019ve walked through Phases 1 <\/span>Discover<\/span><\/i><\/a>, 2<\/span> <\/span>Define<\/span><\/i><\/a>, and 3<\/span> <\/span>Ideate<\/span><\/i><\/a>. Now it\u2019s time to <\/span>Implement<\/span><\/i>.\u00a0<\/span><\/span><\/span><\/p>\n

\"The<\/p>\n

It\u2019s in this stage that you bring your concepts to life via prototyping and testing. <\/span><\/span>Implement<\/span><\/i> 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\u2019t) work in the real world.\u00a0<\/span><\/span><\/span><\/p>\n

But before you can bring your concepts to life, you have to decide which of the concepts from <\/span>Ideate<\/span><\/i> you want to pursue. That\u2019s a difficult decision, but there are four key questions that you should be asking yourself about each concept that will help you to decide.\u00a0<\/span><\/span><\/p>\n

Selecting Concepts for Prototyping<\/b><\/span><\/h2>\n

1) Does the concept embody your design criteria?\u00a0<\/span><\/i><\/span><\/p>\n

At the end of <\/span>Define<\/span><\/i>, you will have developed several design criteria based on the results of the research you conducted in <\/span>Discover<\/span><\/i>. 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.\u00a0<\/span><\/span><\/p>\n

2) Is the concept desirable?\u00a0<\/span><\/i><\/span><\/p>\n

If you\u2019ve done due diligence in <\/span>Discover<\/span><\/i> and <\/span>Define<\/span><\/i>, 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 <\/span>this<\/span> particular solution? Does this solution fill a need and will it fit into people\u2019s lives?\u00a0<\/span><\/span><\/p>\n

The<\/span> Edsel<\/a> 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.\u00a0<\/span><\/span><\/p>\n

3) Is the concept feasible?\u00a0<\/span><\/i><\/span><\/p>\n

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 <\/span>this<\/span> particular solution?\u00a0<\/span><\/span><\/p>\n

Failing the feasibility test is another classic example \u2014<\/span> the Apple Newton<\/a>. 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\u2014it misread characters so often and to such an extent that it was lampooned in the media, including in an episode of <\/span><\/span>The Simpsons<\/span><\/a>.<\/span><\/span><\/p>\n

4) Is the concept viable?\u00a0<\/span><\/i><\/span><\/p>\n

Should we build <\/span>this<\/span> 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\u2019s) business goals?\u00a0<\/span><\/span><\/p>\n

As an example of a product that failed the viability test, consider<\/span> Colgate Frozen Entrees<\/a>. 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<\/span><\/span>. It was a leap that people just couldn’t make. Had Colgate launched these entrees under a different brand name, maybe we\u2019d be eating them today.\u00a0<\/span><\/span><\/p>\n

Fail early. Fail inexpensively.<\/b><\/span><\/h2>\n

Once you\u2019ve answered those questions and have selected the concept or concepts that you want to move forward with, it\u2019s time to start prototyping. A lot of people think of \u201cprototypes\u201d 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\u2014including those simple sketches that you ended with in the <\/span>Ideate <\/span><\/i>phase.\u00a0<\/span><\/span><\/p>\n

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\u2019t 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 \u2014 those that help you to decide how a concept needs to change to continue to move forward as a solution.\u00a0<\/span><\/p>\n

In the early stages, you\u2019ll use <\/span>low-fidelity<\/span><\/i> 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\u2019s 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\u2019ve talked with in the earlier phases for formative feedback. We will also on occasion use low-fidelity prototypes in participatory design activities.<\/span><\/span><\/p>\n