This week I demoed some flows I’d been redesigning to a room full of product managers and stakeholders.

The programme I’m on is huge. We’re redesigning a highly complex, enterprise-grade, case-working system.

There are many feature teams, each with their own product manager. I’ve been on the programme for 6 months now but it’s so big I’ve not met many of them.

The meeting was meant to present the before/after of the redesigns to show what it looks like to just use the simple and accessible patterns from the GOV.UK Design System and a few of my own, encouraging other feature teams to reuse them.

It did that.

But it also did something else, something I didn’t really expect:

Toward the end of the meeting, the conversation veered off.

There were comments and questions about the tool I'd used to create and demo the designs:

“I love the way this demos new concepts.”

“The prototype really helps you to understand the user journey”

“It’s been so helpful for our developers to show them how something actually works”

Most designers use Figma, but I had created an HTML prototype using the GOV.UK Prototype Kit.

Don’t get me wrong, Figma has its place but at the end of the day:

Figma can only produce pictures of software.

Not actual software.

Actual software is alive.

• It moves
• It adapts
• It errors
• It loads
• It responds

Figma might be useful to design in.

But it’s not good to design “out”.

By that I mean:

When you present your designs with Figma, you’re not interacting with the product you’re designing.

You’re interacting with the software you used to design.

As a result:

1. It’s slow and jarring. Your audience has to watch you stop, scroll, pan and zoom around Figma between each step.
2. It may not do your design justice. Your audience is focused on you navigating Figma rather than experiencing your design.
3. It may hide problems. You’ll probably jump between screens and miss important details - realistic data, micro interactions, transitions, loading states, error states and edge cases.

Designing in code and demoing in the browser forces you - or at least encourages you - to confront these things.

For my demo, instead of just sharing screens:

1. I opened the browser and typed in the URL
2. I signed into the case-working system
3. I landed on the overview page which showed me my priority tasks
4. I made the screen smaller to show two instances of the app side by side
5. I clicked “Cases” in the primary menu to go to the case list
6. I searched, filtered and sorted the list to find a particular case
7. I filled out a complex multi-step form flow with conditional logic

In other words, I went through the entire end-to-end journey and interacted with the prototype just like real users would.

This allowed my audience of product managers to free up their mental energy and instead focus on understanding the design intention and potential gaps.

That’s 100x harder to do with Figma.

After the meeting, I received a lot of positive feedback which is great because I love praise.

One product manager actually suggested I help train some of the other designers on the programme who are less familiar with the Prototype Kit.

But she also pointed out that it would probably take up too much of my time.

Luckily, I’ve been preparing for this moment for 2 years. I told her:

I have a course that teaches designers how to use the GOV.UK Prototype Kit to unlock the many benefits of prototyping in code.

If you’d like to learn how to use the Prototype Kit and unlock those benefits — including a little unexpected praise when you present at your next show and tell:

​https://prototypekitcourse.com​

Cheers,
Adam