Here at Arcweb, we’ve been spending more time using analog methods of exploring and communicating our ideas and we’ve augmented our UI design process with Sketch.app. The next piece of the Arcweb design process that we’ll explore is prototyping.

What is Prototyping?

In our context, prototyping is the process of efficiently creating a representation of a digital product that reflects our current vision of it. Prototypes are meant for learning and communicating, not perfection. They can vary in fidelity from simple, ad-hoc paper prototypes to complex, clickable versions that are almost indistinguishable from real, working software. Efficiency is key here; we create the prototype to learn more about our assumptions and how a piece of software might work before actually building the software.

Why Prototype?

Prototyping helps us build customer value from the day we begin the Discovery process on a project. More specifically, it facilitates three types of communication that contribute to building the right product for the problem at hand:

The Designer’s Inner Monologue

The closer something is to “real,” the easier it is to evaluate. Consequently, that’s not the case for what’s in a designer’s head. What’s in a designer’s head is, in fact, the furthest thing from “real” there is. But a prototype changes all that. By prototyping, we are able to iterate quickly through ideas that won’t work without sending other departments (like development) on missions built to fail. Said differently, rapid, iterative prototyping allows the design team to fail fast which in turn will bolster confidence because everything’s been considered.

Designer-Developer Collaboration

Prototyping also facilitates more effective designer-developer collaboration. With prototypes, the design team is able to show the development team what’s to be built rather than simply telling them. (This is valuable for both practical and interpersonal reasons.) Some prototyping tools even allow developers to pull snippets of code that they can use to get started or in production.

By prototyping, we reduce the frustration and ambiguity that can occur when designer and dev terms don’t make sense to the other. For example, when the design team prototypes, devs don’t have to guess at what a phrase like “the sidebar dances in” means. Instead they see it. (By now it should be abundantly obvious that prototyping minimizes engineer grumpiness.) And when they see it, developers can provide rich, insightful feedback, assess technical feasibility and system design and cut excess scope earlier in the process.

Customer Dialogue

If a picture is worth a thousand words, a prototype is worth a thousand meetings. Prototyping allows us to build consensus with our customers earlier in the life of a project. As much as a customer can say they “get it” from reviewing flat comps, prototypes that look and feel like real software allow for deeper, richer understanding. Throughout the life of a project, that means fewer surprises and the less-than-comfortable conversations you have to have when they spring up.

Finally, customers tend to be more vocal when it comes to raising issues when they’re looking at a prototype versus live software. And this makes sense: no matter if it’s a small modification or a complete pivot, change requests after multiple dev sprints are expensive. They are far less so in the prototyping stage. (Think hours instead of weeks or months.)

So that’s why we prototype. It improves how designers communicate their visions. It aligns designer-developer relationships and workflows. And it helps customers better understand what will be built before it’s built.