How to make prototyping a scalable, team-based process

Prototyping is one of the most important steps in the evolution of a digital product. The prototype allows us to simulate our product’s experience and gain insights to validate design solutions. They communicate how the product actually feels.

In digital product design, prototyping has now become a required step. When I was designing websites or applications eight years ago, very rarely did I take time to prototype my designs. Everything went from static mockups straight into production.

Now, due to the a more scientific approach to product design and the massive number of prototyping tools that have hit the market, prototyping is necessary phase in the design process.

Invision. Marvel. Flinto. Principle. Pixate. Form. Origami. Proto.io. Framer. The list of prototyping tools goes on and on.

Low-fidelity prototyping

After surveying different product designers and product design teams, I found that currently the most widespread design-to-prototype workflow involves Sketch and Invision. In fact, these are the tools I’ve used for the past few years. In the most simple sense, the prototyping workflow involves three steps:

  1. Design static UI in Sketch
  2. Export the artboards into Invision
  3. Build out the prototype in Invision

Now this workflow is repeated over and over again with every design iteration. And, for every new feature that we design for our product, we create more and more prototypes.

Once we begin start to consider how this workflow scales within the context of a design team, we don’t fare so well.

As the design team scales, more and more prototypes are created leading to workflow inefficiencies.

As a design team grows in number, so do the number of prototypes they must build. For every new product feature or features, new prototypes must be designed and hacked together. As more and more prototypes are produced by different designers, we begin to see an overlap in work being done (as illustrated in the animated graph above).

This overlap represents the repeated work that inevitably ends up being done as each designer designs and constructs their prototypes. One specific example is that all shared UI components and views that are incorporated throughout multiple features will need to be prototyped over and over again.

Also, every design iteration requires you to update all the artboards within your Sketch, Illustrator, or Photoshop file. It’s an endless cycle of repitition.

A high-fidelity, code-driven, master prototype

So, how do we improve this process?

Well, let’s look to how our engineering teams operate! It’s a fact that engineers have adapted to efficient process around scaling their teams and managing development workflow. Particularly, using tools like Git/GitHub.

Product design teams can mimic that exact same process in the context of prototyping. We can do this by developing one code-based, master prototype for our product. Whether this prototype is built using Framer.js, React, or even plain ol’ HTML/CSS–it does not matter.

The key is that your master prototype meets the following criteria:

  • The prototype contains all the features and functionality of the production version of your product
  • The prototype is version-controlled and lives within a Git repository

We can manage the adding new features to our prototype just like engineers do through their engineering development cycle.

After designing a new feature and the designer is ready to begin the high-fidelity prototyping phase, they would create a feature branch and code their prototype on top of the existing master prototype. Now, all experiments and user tests can be conducted directly from this branch.

Clear Wins

There are various benefits from implementing this prototyping process. For one, you are now user testing with a prototype accurately representative of the final product. Not just a static, low-fidelity representation (like with Invision or Marvel).

Design does not stop at the visuals. Animations and transitions help to convey concepts and communicate ideas. These concepts are often lost with low fidelity prototypes.

The most authentic and valuable insights are gained when you have the least variation between your prototype and final product.

Another major benefit, in the context of product iteration cycles, the master prototype would float one or two iteration cycles ahead of the actual implementation.

This is very powerful position to be in. The product design team can conduct multiple rounds of user testing and design iteration before the feature is pushed to the engineering team.

No process is perfect

Now, I’m not saying that low-fidelity prototyping does not have its rightful place in the overall design process. It sure does. Particularly, early on in the discovery phase when you are value-testing different design solutions. But, high-fidelity prototypes should take over once you are rigerously battle-testing your designs.

One of the major problems in implementing this process is the overhead in the amount of time it would take to build out the master prototype based on their current product offering/s. This is fair, but there are various ways to speed up this process.

One example would be to share share stylesheets and possibly even components between your production code and your master prototype. I will be writing a follow-up post on other ways to optimize for re-usability.

Another challenge with this process is that is assumes all or most of the designers on your team know how to code. I won’t go into that debate, but it’s a fair concern. You can read my thoughts on that question in an older blog post.

Thinking to the future

I’m a firm believer that the gap between designers and developers is gradually closing in. I’m also convinced that code-driven prototypes are future of digital product design. While this process may not be perfect, I do believe it’s the first step in evolving the prototyping from a siloed, one-person process into a collaborative, team-driven effort.

As a larger percentage of designers become more and more comfortable working within code, it will be intriguing to see the affects it has on the evolution of the design process and the tools that we use.

Thanks so much for reading! Please make sure to or this post if you found the ideas interesting.

Atif Azam is software designer and developer based in New York City. Currently, he is a product designer at MongoDB. He's made it a personal goal to write about design on a regular basis. Follow me to keep up to date.