There are two kinds of prototypes in this world:

Low-fidelity prototypes like sketches, paper prototypes, and wireframes. These are great for quickly communicating and validating ideas. But outside of the design studio, out in the real world, where concepts need to prove their worth, they often fall short.

High-fidelity prototypes like clickable mock-ups, coded experiences, or even a complete MVP. Combined with realistic mock data, these prototypes can validate successful business concepts. But in practice, they take a lot of time to create and risk increasing time-to-market.

What if we could get to high-fidelity prototypes faster?

Building a design system

Design systems are basically like lego blocks, allowing you to play and build quickly. At Metrixlab, where I work, a design system was initially needed to make things more consistent: The eco-system looked horribly inconsistent before I created the design system that is now used across applications.

Very often design systems are created in a pre-mature phase. This results in inconsistent UI and static documentation that needs to be updated manually. The key to success is to automate as much as possible so the workload is reduced, adoption is increased and focus will shift to design system government. I learned this the hard way myself, but John Gully and Marcello Summers created a excellent maturity model to showcase this.

So instead of focusing on getting from design to code, I decided to put my initial focus on distributing code. I created Angular components with automated documentation in Storybook and distributed the components with NPM so applications could be updated automatically. (The components live in Figma as well, but separately.) Surprisingly, this taught me how to prototype faster as well.

Of course, you don’t need to build your own design system for prototyping. You can use any existing design system like Bootstrap, Material Design, or Tailwind CSS. At Metrixlab, we chose to build our own design system so we could tailor it to our specific needs and brand. If you choose to use any existing design system, just make sure that it supports advanced interactions based on mock data that feels real.

Query builder

For example, I collaborated on designing a query-builder interface in Figma. It needed advanced functionality like if-else conditions, logical operators, and nested groups. After countless iterations on the most arbitrary details, I was noticing that the designer and product owner I worked with were mostly telling how things should work, rather than showing how they could work. That didn’t help, of course. We ended up going in circles, being misaligned, and not being able to validate with real users.

So I made the decision to leave behind Figma for this particular feature, and start prototyping in Angular. Besides a small challenge on the drag and drop, prototyping in code was almost as fast as prototyping Figma with our Angular design system. The major difference between Figma and code was the lack of limitations in prototyping.

We succeeded in implementing drag and drop, which made us experience things like we couldn’t before in Figma. We also mocked up some realistic data, which helped the product owner experience the prototype in a more realistic way. She could now feel like she was really building an advanced query that hadn’t been possible before in Figma. Soon, we found ourselves trying out the prototype with real users and got much better user feedback than ever before.

Survey builder

Besides the query builder, I also worked on a design for a new survey builder together with the same designer and product owner. The new survey builder had to be much more intuitive compared to its predecessor, so betting on a new design was hard.

When we started, I hosted a sketching session with the product team. Everyone contributed and we were able to get a consensus. The designer on the team then created mockups, which the product team implemented.

But after implementation, we found a problem. One group of users complained that there was no space to see the questions and answers together on smaller screens. This was partly because the mockups did not consider small screens, and partly because of how the product team interpreted the intended scrolling behaviour.

At first, the product team did not prioritize this feedback. They were focused on other, more pressing issues, and told the users to just ‘zoom out in the browser’. But when a second user group complained about the same issue, the launch of the tool became dependent on a solution. The product team then requested a design for some space optimizations.

I had been bothered for a while by the issue, and the decision not to prioritize the user feedback. So when the request finally came in, I was very eager to help with a redesign.

But I also knew that it was very important to get the implementation right this time. We couldn’t afford any more flawed interpretations of the design. Because the product team had been holding off on a real solution before, time was pressing now.

So instead of making more mockups, I opted for creating a front-end prototype as well. This front-end prototype could present the intended scrolling behaviour more realistically. And I also added some other improvements to interactions that had been disturbing me, without leaving room for false interpretation.

After the redesign, the questions and answers were visible together on smaller screens, and users loved it.

Take-away

These were just a few examples of how a design system can boost your prototyping. But the possibilities are endless as you can leverage native technology and create your own components. Of course, as a designer, you don’t always need to create these prototypes by yourself. You can team up with engineers to create the prototype with you and learn together. I’m also not advocating to ditch Figma or similar design tools. I find myself switching between Figma and Angular code a lot to quickly explore the look & feel before creating any hi-fi prototyping.

My next goal is to learn how to scale this approach across organizations. Many organisations, like Metrixlab, use a Scrum, lean or agile approach and release code to gain insights. But hi-fi prototypes that use realistic data can validate concepts without risking negative user impact. I think there is much to be gained from this design thinking approach combined with design systems and hi-fi prototyping.

What I learned from this:

• Hi-fi prototypes to test and handover design can be created quicker with design systems.
• Designers can do more if they know how to build prototypes in front-end code.
• By prototyping teams will learn that user feedback should be addressed early on.

Further reading

How design systems can help build and prototype better digital products | by Luis | UX Collective (uxdesign.cc)

A Maturity Model for Design Systems | by Marcelo Somers | Slalom Build | Medium

Prototyping with Angular. Since joining Google a year ago, I’ve… | by Edwin Lee | Angular Blog