Nobody buys a car without a test drive. Why are we shipping static mockups?

How I build interactive demos with fixture panels, role switching, and real states, without being a developer.

Most product design demos are not really demos. They are screenshots. Beautiful, polished, carefully arranged screenshots.

Any beginner designer can recreate a screen they saw on Dribbble or Behance. The sweet spot, the thing that separates a design concept from a design decision, is showing how it should work. Interactively. The key difference between screens and a demo is response and feedback.

Think about it this way. Nobody buys a car from a website without test driving it first. If you do, you are unreal. People go to the dealership, sit in the seat, grip the wheel, and feel how it responds. Even people who buy online have usually tested that car somewhere before.

Yet in product design, we routinely ask stakeholders, clients, and engineers to commit to building something they have never actually touched. We hand them static frames and expect them to imagine the interactions, the states, the feel. Then we act surprised when what gets built does not match what we intended.

I stopped doing that. This article is about what I do instead: building demos that behave like the actual product, complete with role-based access, switchable data states, and a fixture panel that lets anyone explore every scenario without touching a line of code.

And no, I am not a developer. That is kind of the point.

The project that forced me to figure this out

A while ago, I worked on a revenue collection platform for a local government institution here in Nigeria. Bills, levies, taxes. I was designing the admin side, and it came with a challenge that would have been miserable to handle in Figma: four different user roles, each with its own permissions, screens, and actions.

A super admin who sees everything and can take every action. A finance officer with access to transactions and invoices. An enumeration officer with a narrower operational view. And a read-only director role that can observe but touch nothing.

The system automatically purges out whatever a user is not allowed to see or do based on their access level. Which means the same dashboard is a genuinely different experience depending on who is logged in.

Now imagine communicating that in Figma. You would be duplicating entire flows four times, maintaining every change across four parallel universes of screens, and praying nobody asks “wait, what does the finance officer see on this page again?” I have done that kind of duplication before. It is tough, exhausting, and boring. And thinking up demo data for every state was honestly the hardest part.

So instead, I built it as a working demo. Real navigation, real interactions, real role-based rendering. You could log in with test credentials for any of the four roles. Or better: once inside, you could switch between users seamlessly from a floating panel without logging out. Same page, different role, instantly different reality.

That floating panel changed everything about how I present design work. Let me explain what it is.

The fixture panel: a demo’s control room

A fixture panel is a small floating bubble that stays present on every page of the demo. Open it and you can switch users, change data states, and trigger scenarios on whatever page you are looking at.

The idea came from a YouTube video where a designer at Ramp showed how he used MagicPatterns for prototypes. He used it mainly for switching data values. When I saw it, I thought: this could do so much more. So I started asking my coding agent to build fixture panels based on the full context of each project.

Here is what mine typically control:

User roles. Switch from super admin to finance officer to read-only director in one click. The interface reshapes itself instantly. Stakeholders can see exactly what each user type experiences without the friction of logging in and out.

Data states. A page with 5 entries looks and behaves very differently from one with hundreds of entries and pagination. An empty state is its own design problem. I ask the coding agent to build interactive mock data with switchable variants: empty, sparse, full, overflowing.

The states designers usually forget. What happens when there is no internet connection? What happens when an action stops midway? Error states, loading states, interrupted flows. These are the moments where products actually earn user trust, and they are the exact things static mockups never show. In my demos, you flip a switch in the fixture panel and watch the failure happen.

A built-in testing guide. This one evolved naturally. I started using the panel itself as a todo list for whoever is reviewing the prototype. The panel tells you what to look at on this page, which states to try, which roles see what. It turns a passive viewer into an active tester.

On the government project, the panel listed the test credentials for all four roles right on the login screen, along with error states to try: invalid credentials, a deactivated account, even an account lock after five wrong password attempts. Reviewers did not need me hovering over their shoulder. The demo taught them how to test it.

How I actually set this up (without understanding data structures)

Let me be honest about my technical level. I am not an engineer. I do not know how data structures work. My coding knowledge stops at HTML, CSS, and basic JavaScript.

What I do know is context. And that turns out to be the skill that matters.

I front-load the instructions. In every project, I add fixture requirements to the project’s CLAUDE.md file (the instruction file that coding agents read for context). It forces the AI to always create multiple states and add fixture controls for every page and feature it builds. I do not ask for fixtures after the fact. They are part of the definition of done from day one.

I write user flows with states included. My user flow markdown files do not just describe the happy path. They describe the empty state, the error state, the overloaded state, the different role perspectives. When the coding agent has that context upfront, it builds the variations naturally instead of me retrofitting them later.

I give context, not specifications. I cannot tell Claude how to structure a mock database. What I can do is describe the feature, the users, the scenarios, and ask it to build interactive mock data with switchable variants. The agent figures out the technical shape. I judge whether the result behaves correctly.

I start from an existing component library. This is the speed unlock. Most SaaS frontends out there are built on Tailwind anyway. I use libraries like Untitled UI (which matches our Figma design system) or shadcn, then configure the tokens to my taste: typography, colors, radius, paddings, spacings. You can even point your coding agent at a reference style. I sometimes use styles.refero.design to pull a visual direction I want for a project. Building components from scratch is where demos go to die. Composition and theming is where they ship in days.

I sync with engineers on data shape. Before I build fixtures for a feature, I sit with the engineers to understand what data and values actually come from the backend. That way my mock data mirrors their architecture. Nothing in the demo looks funny or sets a false expectation, and the demo stays useful as a reference when they build the real thing.

What changes when people can actually touch the thing

The first thing you notice is the energy in review sessions. People who were bored of stale prototypes suddenly lean in. They click around on their own. They find edge cases themselves. The conversation shifts from “how would this work?” to “what happens if I do this?” That second question is where real design feedback lives.

I still walk stakeholders and clients through the demo first, so they know how to explore it on their own. And after building a feature, I ask my coding agent to generate a “How to test” document: a simple guide explaining what to check and how to use the fixture panel for that feature. Reviewers test asynchronously, on their own time, without me in the room.

There was one client project where we needed to present a working demo, but engineering was not done with the build and integrations. The design demo carried the entire presentation while engineering caught up. It looked and behaved so much like the real product that the client left the session excited and reassured. Not a habit I recommend building a process around, but it saved the team that day.

And the reaction that stuck with me most came from a developer I worked with. After going through one of my demos with the fixture panel, the role switching, and the state variants, he said: “You’ve done most of my work for me.”

That is the real value. The demo is not just a presentation artifact. It is a specification that engineers can open in a browser. Every role, every state, every edge case, already visible and behaving. Instead of interpreting annotations, they reference working behavior. The fixture panel guides them through use cases and contexts they might otherwise miss.

Start smaller than this

You do not need a four-role government platform to try this approach. Start with one feature you have already designed.

Ask your coding agent to build it with mock data. Then ask for one fixture control: a toggle between the empty state and the populated state. That is it. One page, two states, one floating panel.

Once you feel how different a review conversation becomes when people can flip that switch themselves, you will not want to go back to static screens.

Screenshots show what a product looks like. Demos show what a product is. And in a world where anyone can generate beautiful screens in seconds, showing how it works is what makes your design work impossible to ignore.

Let people test drive the car. That is how you sell it.

Nobody buys a car without a test drive. Why are we shipping static mockups? was originally published in Bootcamp on Medium, where people are continuing the conversation by highlighting and responding to this story.