The Power of Prototyping

The artifacts we create as digital designers rarely reflect the full and final product experience. We’re building complex, interactive products—the usefulness of our pictures and slideshows is fleeting, and often limited.

Photo by Jo Szczepanska on Unsplash

Static mockups, still images and clickable slideshows are very useful early on in the design process. They allow us to quickly communicate our ideas in a tangible way, get quick feedback on the broad direction of a design, and validate concepts early. It’s also one of the cheapest and easiest ways to perform usability testing.

In order to test an experience, someone needs have the experience.

That said, while static mockups can be useful to validate initial ideas, these artifacts are limited in their ability to validate experiences. In order to validate a designed experience, someone needs to actually have that experience. Static pictures and clickable slideshows often fail to capture the nuance and complexity involved in digital experiences. By building a prototype, you can ensure your design is complete.

A Complete Experience

Creating a prototype that looks & feels like the final experience is important when determining if your design truly solves the problem—down to every detail.

While some hypotheses can no doubt be answered with click-through prototypes, there’s a time and a place for static testing. Complex questions require complex tests.

If we ask someone to describe how they would perform a complex task given a series of pictures we run the risk of testing not our product, but the limits of their imagination (and how similar their imagination is to our own). Key elements that influence user behaviour—like animation, input states, and interaction—are lost in static pictures and can make testing a challenge. This is particularly true when the interaction itself is the thing you’re testing.

We tested at least a dozen iterations of the stacked line graph before finding a usable solution.

When we’re evaluating whether an experience solves a problem, we want the user to feel like they’re in control. Instead we’ll often give a tester a limited, static experience, and watch while they play Where’s Waldo. Then we declare our tests failed when they can’t find the Waldo-button fast enough; meanwhile the full experience might have no usability issues at all. Perhaps our tester would have been able to articulate their action plan if they could explore and interact with the interface, and form a fuller mental model.

Designing a complete experience will not only benefit you and your users. When you prototype a full experience, you’re forced to account for things that you may have overlooked otherwise. Edge cases and logical gaps that you may have glossed over can come to the surface when you’re building the full experience. These issues will have to be solved eventually, so why not solve them when you’re still deep in the process?

Completely documented

As a designer, when you handoff a series of pictures to a developer, you often leave it up to them to decipher your intentions. With this workflow, details can get lost in translation: “How did the designer envision this interaction?” they ask, “How does this element work?”. There will also inevitably be cases that have not been explicitly accounted for in mockups.

There might also be elements of the interface that influence how a feature will be built—some interactions might influence the data flow, or inform the overall architecture of the software. These problems are solvable, but an interactive prototype is an effective way to clarify and communicate all the nuance in a design. As the creative’s mantra goes: show, don’t tell.

By referencing the prototype, the developer was able understand where the data flowed, and how the elements interacted.

When you explicitly design for every edge case, and call out every subtle interaction, you ensure that nothing is left to the imagination. And because nothing is left to the imagination, it’s easier for developers to get a better understanding of how feasible the design might be.

Completely doable

When creating digital experiences, the medium we use to create our artifacts doesn’t always reflect the strengths and limitations of the final medium. It’s entirely possible for a designer to create something in Sketch or Figma that’s impossible to build. Even when a designer knows how to code, it’s one thing to know the limitations of the final medium, it’s another to be subject to them.

If you’re on the web, it can be incredibly useful to finalize many aspects of a design in the browser. As Jen Simmons said at Artifact Conf, “The design will always be finished when the CSS is written.”

While we had a Sketch file for the dashboard, the majority of the design was finalized in the browser.

By designing in the same medium as the final product, you get a better sense of the possibilities and limitations earlier on in the process. Nobody wants to spend days refining a design in Sketch, only to be told that it can’t be done.

Once you know what is doable and what isn’t, you’re able to make appropriate design tradeoffs and modifications. Subtle changes in the design can often be the difference in whether something is easy to implement, or impossible. Understanding and being aware of these implementation details can speed up the design process, and allow you to design more efficiently.

Prototyping in Practice

The medium we use to create our artifacts doesn’t always reflect the strengths and limitations of the final medium — Me, three paragraphs ago

The most efficient way to prototype is to skip comprehensive design artifacts altogether. With a design system in place, all you need is a whiteboard, and a conversation with a front-end developer to get started building something. Then design is a collaborative, truly agile effort. The designer can make “spot-mocks” of small pieces of the feature while the developer refines the feature. Throughout this process you’ll always have the most up-to-date experience with which to do usability testing. This is something Brad Frost and Dan Mall call the “hot-potato” method.

You can also get similar speedy prototyping with tools like Framer X, UXPin or Modulz. If you’re using React, Framer X will let you import your production components and place them on a canvas like Sketch. SwiftUI is another great prototyping tool for iOS development.

Another option is a hybrid, or parallel-environment approach. Our team uses Angular as our development framework, which isn’t necessarily the easiest to use for all designers. So instead we’ve set up a prototyping environment in Vue.js with shared styles between production and prototype. While this isn’t necessarily the most efficient way to prototype, it enables the design team to quickly create close-to-full experiences in the browser. These prototypes can then serve as scaffolding for building the final experience.

A Prototype is not the Product

Building and testing on a prototype that looks and feels like the final experience can help speed up product development. However, it’s important to communicate the limitations of a prototype. A prototype is not production. Nor is it a public demo app. By making it clear that a prototype is an internal validation and communication tool only, you’ll save days not maintaining something that was never meant to be maintained in the first place.

I’m a product designer & developer based in New York. I design and build features and maintain the design system at New Visions for Public Schools.

I’m online, and will occasionally tweet things.

Tom Johnson has written an article about design tools, which goes more in depth on the limitations of current design tools.