Building to learn: the role of prototyping in Design
Comprehensive design doesn’t just happen through wireframing and workflow diagramming. Sometimes it also means writing code.
I run a team of prototypers inside the Adobe Design organization, and the most succinct way to express our mission is that we bring design to life. Sometimes screen design tools or paper prototypes are all you need to validate a hypothesis and hand off to engineering with confidence. But sometimes you have to incorporate real-world data into your design to make sure it still holds up, interact with gestures and new kinds of drawing tools directly on a device, or experience comprehensive workflows first-hand.
Whether you’re shooting a movie, designing a rocket, or building software, the earlier you realize you need to make changes, the cheaper, easier, and faster they are. While it’s tempting to try to make perceived progress early on in a project’s lifecycle by skipping the prototyping phase, you’re taking out a loan that you will probably have to pay back with exorbitant interest. Embracing prototyping at the design phase of any endeavor — especially when combined with research — is like an inexpensive insurance policy that covers you against market indifference, customer backlash, and overwhelming support costs.
When Adobe designers and researchers need a higher level of fidelity than they can achieve with standard design tools, they partner with us. We are a diverse, international, multidisciplinary team with a passion for design, development, user experience, and most of all, learning.
Prototype Taxonomy
The types of prototypes my team builds usually fall into one of three categories:
- Validation (short term). A validation prototype is an exploration of a product or feature that we know we are going to ship, and that we understand fairly well, but that we believe will benefit from a few rounds of design, prototyping, and user testing to help really dial in the user experience. Good examples are new features being added to existing applications, workflows between products, and new types of user interface controls.
- Exploratory (medium length). When we know that we are going to ship something in a given space, but we don’t necessarily know what that something is, we often do exploratory prototyping. For example, long before announcing Project Aero, we had a team prototyping immersive authoring experiences, and before showing off Photoshop on the iPad, we spent months reinterpreting desktop interactions for multitouch surfaces.
- Moonshot (long term). Sometimes it’s impossible to assess the value in a risky or disruptive idea until you can see it, touch it, interact with it, and maybe even integrate it into your daily life. Moonshot prototypes are open-ended studies of concepts that may or may not ever end up productized but that we believe are worth exploring. For example, my team has been prototyping Project Lincoln, a new data visualization tool, for over a year, and we are currently supporting a series of long-term research studies around creative collaboration.
Prototyping != Engineering
Although most of our prototypers are engineers, prototyping and engineering are not the same discipline. Typically, the job of a product engineer is to deliver rigorously tested, secure, scalable, production-level code. In order to hit (often extremely aggressive) deadlines, product engineers need to focus on requirements, reduce iterations, and reuse as much code as possible. While modern engineering teams are far more agile than they used to be, product engineering resources are in such high demand that they frequently don’t have the bandwidth for in-depth user experience explorations.
Prototypers, on the other hand, optimize for rapid learning rather than things like scalability, security, and robustness. While most of us are experienced engineers, and therefore appreciate concepts like design patterns, abstraction, and code reuse, we’re also not ashamed of blatant hacks, or of spending days or even weeks on code that might never get used again.
(Note that I draw a distinction between “scalability” and “performance.” Prototypes rarely need to scale in that there are seldom more than a handful of people using them at the same time. However, performance is a critical aspect of any modern user experience and therefore needs to be taken into consideration in order to avoid negatively affecting user research.)
We’re not ashamed of blatant hacks, or of spending days or even weeks on code that might never get used again.
While some product teams do have their own prototyping resources, it is often difficult to keep those engineers focused on learning in the face of imminent deadlines. In contexts where products are design-led, it can also be more efficient to organizationally position prototyping alongside designers (and design researchers) so that the build-measure-learn feedback loop can happen as rapidly as possible.
Taking Time to Prototype
The prototyping phase of product development is often sacrificed because design or product teams don’t think they have time in their schedules. But the reality is that you probably don’t have time not to prototype.
One thing that over twenty years in the software industry has taught me is that everybody prototypes, but not everyone plans for it. In other words, no matter how experienced you are as a designer or a product owner, the chances that a new product or feature will resonate perfectly with customers exactly as it was originally conceived is pretty low — especially when you’re trying to deliver entirely new kinds of user experiences across new kinds of devices and platforms. If you skip the design prototyping phase, that means you are prototyping with your customers which is by far the least efficient and most costly way to learn.
The reality is that you probably don’t have time not to prototype.
The more learning you do before launching a new product or feature, the more confidence you can have that it will resonate with end users right away, and the better the chances are that you can devote the next release to innovating rather than addressing customer complaints — or worse, customer indifference. Although it may feel counterintuitive, sometimes the best way to move faster is to first slow down.
The global design company IDEO has a great saying about prototyping:
“If a picture is worth 1,000 words, a prototype is worth 1,000 meetings.”
If you’ve ever experienced how a high-fidelity, interactive prototype can facilitate decision making and drive alignment across organizational silos, it’s hard to imagine shipping anything without taking time to prototype it first.
Prototyping doesn’t just save time during short- and long-term product development lifecycles; it can also dramatically reduce friction around innovation. Throughout my career, I have seen countless good ideas — ideas that could have been significant revenue generators — collapse beneath the weight of debate or indecision only to be resurrected by future unsuspecting resident entrepreneurs. Prototyping can disrupt these cycles by giving stakeholders something concrete to evaluate. The faster you can bring an idea to life, the sooner you can make a deliberate and well-informed decision to either take it to market or put it to rest.
Everybody prototypes, but not everyone plans for it.
The last point I want to make around taking the time to prototype has to do with misconceptions around product schedules. Most people — even experienced product owners — assume that the most difficult aspect of building a successful product is the implementation. That hasn’t been my experience. While anything that adds value to customers’ lives certainly does take time to build, if you always knew exactly what customers wanted, and exactly the user experience they would ultimately find most intuitive and engaging, figuring out how to give it to them probably wouldn’t stop you from being successful. It is usually far more difficult to get users’ attention in the first place, hold that attention long enough that they begin developing habits around your product, and then consistently delight them. Until you are confident that you know what you should build, don’t waste time trying to build it. Prototype it instead. Stop building to ship until you’ve first built to learn.
The Three Pillars of a Prototype
There are three primary ways prototypes help save time throughout the product development lifecycle:
- Design validation. Think back to the last time you imagined a complex project, then consider the reality of the execution. No matter how vivid our imaginations or well-honed our intuition, expectations rarely match reality. Most modern design tools only allow designers to approximate their visions, but collaborating with a prototyper can allow designers to experience their work directly and therefore gain rapid and early insight.
- Research and user testing. After an interactive prototype has allowed designers and other stakeholders to gain early insight into a user experience, it can then be put in front of users for testing. We build prototypes that support everything from fast-paced user testing sessions to comprehensive longitudinal studies. Most of our prototypes can be configured to behave in multiple ways so that different hypotheses can be rapidly tested, and some can even be remotely controlled in real-time through a separate interface by researchers.
- Living spec. The last leg in a prototype’s journey is that of a living specification that can be handed off to an engineering team. While static designs, click-throughs, wireframes, and design guidelines are critical artifacts in the design-product handoff, we have discovered that engineers love working from functional prototypes. Not only can they easily access values like CSS or animation properties, but clearly communicating intent through a prototype reduces the need for time-consuming clarification. Given that engineers and designers are frequently in different time zones, even minor questions can quickly add up into measurable impacts on tight schedules.
No matter how vivid our imaginations or well-honed our intuition, expectations rarely match reality.
As we built out the Adobe Design Prototyping team, we discovered an additional, unanticipated service that we could provide. Early stage product development is stressful enough without having to manage communication challenges between organizations who often think very differently, have divergent goals and constraints, and may not even share a common lexicon. But since many design prototypers are both designers and engineers, we can sometimes serve as a kind of bridge between the two worlds. Not only do the prototypes themselves allow teams to communicate intent far more clearly than static mock-ups, but design-oriented prototypers can serve as a type of liaison between design and product engineering.
Rules of Engagement
Because the space in which we usually operate (very early in the lifecycle of a product or feature), we are often surrounded by a great deal of uncertainty. Therefore, we try to remain flexible and avoid overly prescriptive engagement models. But that said, we do have a few high-level guidelines.
No production code. Because we optimize for learning rather than security, scalability, and code readability, we do not recommend that product engineers incorporate our code directly into shipping products. Instead, we offer access to our repositories as a type of reference. In other words, our prototypes come with warranties, but our code does not.
Designs now are always better than designs later. Because the sooner we can bring a design to life the more we can learn before it gets baked into a shipping product, the most productive engagements are those in which designers and prototypers start working together very early — even before designs are “ready.” Good prototypers are intimately familiar with the technologies, devices, platforms, patterns, and design systems that they are prototyping, therefore we can often work from whiteboard sketches or other types of low-fidelity wireframes. Time spent perfecting a design that everyone already knows will have to change is time that could be spent iterating and learning.
Prototype before production. Sometimes designers and product teams don’t realize that they need a prototype until a new product or feature has already gone to engineering. That doesn’t mean it’s too late to prototype, but it significantly complicates the engagement. In addition to the designers, prototypers, and researchers having to coordinate, the product team needs to ensure that engineers aren’t implementing something that is being actively researched. The best way to simplify a prototyping engagement is to ensure that prototyping and research are part of the design process rather than acting as emergency services that are only called in when expectation and reality inevitably collide.
Order of Operations
As you probably remember from high school algebra, the order in which we go about solving problems matters. I’m only able to write a conclusion to this article because I’ve already gone through the process of organizing and articulating my thoughts. Scientists can submit papers to journals with confidence only after having conducted rigorous, peer-reviewed research. And no matter how experienced a doctor, or how seemingly straightforward the complaint, it would be irresponsible for any medical professional to make a diagnosis without a thorough examination. The disciplines of design and product development deserve no less.
High-stakes product launches should not be large-scale, risky experiments. They should reflect conclusions drawn from countless rapid, inexpensive, low-risk explorations. The work we release should represent confident declarations of our findings — hand-crafted treatment plans to cure specific customer afflictions.
We all know that no company or product gets an unlimited number of extra lives with users, so don’t take guesses and hope for the best. The last thing any product team should be doing is squandering future cycles on fixing unforced errors. You should be using new releases to innovate, to put daylight between you and the competition, and to not just satisfy you customers, but consistently delight them.
Update (5/11/2021): For a follow-up to this article, see The Ultimate Guide to Design Prototyping.
