The ultimate guide to design prototyping

Sharing Adobe’s internal Design Prototyping wiki with the world

Two years ago, I wrote an article called Building to learn: the role of prototyping in Design as a way of sharing what I’ve learned from running a 20+ Design Prototyping team at Adobe. It’s a solid introduction to using code as a way to better understand new products and features at the design phase, and it explains how design prototyping is different from product engineering.

I’ve been thinking of ways to follow it up, and I’ve decided the most valuable information I can provide outside Adobe is exactly the same information I provide inside. What follows is a recreation of the home page from the Adobe Design Prototyping team’s internal wiki which I share with new hires and stakeholders we haven’t yet partnered with. It covers our:

• Mission
• Philosophy
• Engagement models
• Prioritization criteria

Unlike the vast majority of internal enterprise wiki pages, ours get updated on a regular basis, so this is better thought of as a snapshot. I’ve been prototyping in one form or another for well over a decade, but my team and I are still learning new tricks.

If you have any questions or would like further clarification, feel free to hit me up on Twitter. You’ll find that I love to talk shop.

“Design until you think you understand the problem. Write code until you realize that you don’t. Repeat.”

- NATO Software Engineering Conference (1968)

Mission (short version)

• Bring design to life.
• Pick up where static design leaves off.
• Build to learn before building to ship.

Mission –v (verbose version)

ADP’s mission is to:

• Transform designs and requirements into high-fidelity, interactive experiences which capture, test, and convey intent.
• Increase confidence in design through rapid build-measure-learn feedback loops, and by integrating real-world data.
• Learn as much as possible about user experiences before we invest in building and shipping them.

Philosophy

• Working software over comprehensive documentation. (Credit: The Agile Manifesto.) High-fidelity, interactive experiences are the currency in which we trade. We exist to show, not tell.
• A prototype is worth 1,000 meetings. (Credit: IDEO.) Meetings are usually about building consensus. The more you talk about your idea (as opposed to showing it), the more your audience must fill in gaps using their imaginations. Everyone’s imagination is different which means even when you think you’re building consensus, you probably aren’t. The more you show rather than tell, the less room you are leaving for interpretation, and the more consensus you are really building (requiring fewer meetings in the future).
• Prototyping isn’t a question of if, but when. The day will come when users interact with your software for the very first time. That can be after days or weeks of investment in a controlled and private environment, or it can be after months or years of investment and take place in a very public forum. Either way, you’re prototyping. Since future releases should be about innovating rather than backpedaling, I highly recommend the former.
• Build to learn before building to ship. Core to our philosophy is the idea that the hardest part of product development usually isn’t implementation. We believe that in most circumstances, the bigger challenge lies in knowing what your customers really want. For the majority of consumer and enterprise products, if we knew exactly what would resonate with our customers every time, implementation would rarely be what ultimately stood in the way of success.

Engagement Models

ADP has three primary engagement models:

• Quick Hits. If you want to know how navigation, gestures, tools, or other types of interactions will feel once they’re in users’ hands, and/or if you want to run some user tests, we can quickly build you a high-fidelity, interactive prototype — usually using technologies native to the target platform.
• Embedded. Our prototypers can become temporary members of your team, working side-by-side with designers, product managers, researchers, and/or engineers for rapid and highly productive experimental iteration.
• Exploratory. In collaboration with just about anyone who has a compelling idea, we can support explorations and longitudinal studies with secure, robust, and highly functional prototypes.

Prioritization Criteria

There is more prototyping demand than there are prototyping resources, so we use the following criteria to help prioritize our engagements:

1. Timing

This used to be a much longer section which attempted to analyze the value of prototyping at all stages in the product-development lifecycle. But I have since learned that the timing of a prototype — while still one of the biggest predictors of its ability to deliver value — can be condensed into an extremely simple formula:

• It is too early to prototype if there are faster or cheaper ways to answer the questions you have about your product or design.
• It is too late to prototype if you can’t make changes to your design or product roadmap based on what you learn.

2. Impact

Projects that are well aligned with the business receive highest priority, but that doesn’t mean we won’t prototype moonshots. Because the natural law of resourcing says that, given enough time, 100% of your energy will eventually go toward the most immediate deliverables, we specifically set aside resources for more forward-looking and experimental explorations.

3. Product Relevance

ADP looks for projects that either map to existing high-priority products, or that have a high likelihood of being productized. While we love forward-looking and highly experimental technologies, we look for areas where innovation and product opportunity intersect.

4. Time Horizon

One of the things that differentiates ADP from a more traditional “Labs” team is that we work on a time scale somewhere between “the next release” and two to three years out. Once you get into the five to ten year time horizon, you’re more in research territory than design prototyping. Once that research is ready to find product-market fit, let’s talk!

5. Clear Objectives

Before we begin a new prototyping engagement, it’s important that everyone involved agrees on:

1. The goals and the specific role of the prototype.
2. A clear definition of success.

(Note that the success of a prototype is not necessarily related to the viability of the concept being prototyped. A prototype that proves a negative — e.g. what not to do; a product not to pursue; a change that could decrease conversion or retention — is still a success if it leads to sound decision making and sharpening our collective intuition.)

6. Quant vs. Qual

We prefer to be involved in projects with researchers or other stakeholders who regularly conduct user testing. We respect everyone’s opinions, but we want most of the decisions made as a result of our work to be data-driven. In fact, a great way to scope a prototype is to build it to specs defined by a test plan. That said, we do sometimes build “qualitative” prototypes for designers who have reached the limit of what a static design tool can express and simply need a higher level of interactivity or fidelity to either understand a problem or better communicate a solution.

Epilogue

That’s the thing I found, that you have to prove things to people. Very few people you can run into and tell them an idea and get them to go along with you. They can’t see the potential in things, you know? So, I felt all along, all through my career, instead of talking to somebody about something, if I could, I’d go ahead and make something and then show it to them.

- Walt Disney