Why we show clients running prototypes, not slides
What static mockups and decks hide, what a CEO decides better with a working app in hand, what prototypes cost, and how we keep them cheap enough to throw away.
We rarely ask a client to approve a design from a slide deck any more. We send a link. They open it on their own phone, it fills the screen, and they use it: tap the tabs, scroll the feed, type in the search field, hit the back gesture. Then they tell us what they think.
This isn't a stance against Figma or against slides. We use both every week. It's a view about what a decision-maker needs in their hands at the moment they say yes, and what goes wrong when that thing is a picture.
What a static mockup hides
A mockup is a design at its best moment: the right photo, the right name length, perfect data, no keyboard, no waiting. Real use is mostly the other moments. Here is what we've learned to expect when a flat frame becomes code.
| What the mockup shows | What the running app reveals |
|---|---|
| A finished screen | The 300 ms before it's finished: spinners, skeletons, content jumping into place |
| One state of a button | Pressed, disabled, loading, and what happens if you tap twice |
| A tidy list of five items | Zero items, one item, and 400 items with real scrolling |
| "Anna Berg" | "Maximiliane Oppenheimer-Schulz" wrapping onto three lines |
| A neat transition arrow | Whether the screen slides, fades or just cuts, and whether that feels right |
| A search screen | The keyboard covering half of it, and where the results go |
| A big primary button | Whether a thumb can reach it on a 6.7-inch phone held in one hand |
| A happy path | Offline, permission denied, payment failed, session expired |
None of these is exotic. They are the normal life of an app, and each one is a design decision. A deck can describe them in a bullet. Only a running prototype makes someone feel them.
Timing is a design property
Response time is the clearest example. Nielsen Norman Group's long-standing response-time limits put it simply: around 0.1 seconds feels instant, around 1 second keeps the flow of thought, and around 10 seconds is where people lose attention. You can write those numbers on a slide. You can't feel the difference between a screen that appears and a screen that arrives.
Motion is the same. A bottom sheet that springs up and a sheet that appears in one frame look identical in a mockup. In the hand, one feels like a native app and the other feels like a web page. Clients notice this before they can name it, and they will say "it feels cheap" about a design whose visuals they approved a week earlier.
Hands, not eyes
Desktop review hides the physical side of a phone. On a large monitor every target looks easy to hit. On a phone held in one hand, a tab in the top-left corner is a stretch, and a 32-point icon button next to another one is a mis-tap waiting to happen.
The platform minimums exist for this reason: 44 by 44 points in Apple's guidelines, 48 by 48 dp on Android, and at least 24 by 24 CSS pixels in WCAG 2.2's target size criterion. A prototype on the client's own phone tests these without a lecture. They try to tap the thing and miss.
What a CEO decides better with something in hand
The people we design for are usually CEOs and founders. They aren't designers and they shouldn't have to be. What they are good at is judging whether something is right for their customers. That judgement works much better on an experience than on a description of one.
- Scope. "Do we need the filters in v1?" is easy to answer after trying to find something without them.
- Priority. A home screen that looked balanced in a frame can feel crowded after three scrolls. The CEO sees which block they never look at.
- Tone. Copy, empty states and error messages read differently in context. "No results" on a slide is fine. On the phone, after a real search, it reads as a dead end.
- Readiness. "Is this ready to build?" turns into "I used it for ten minutes on the train and I didn't get stuck." That's a better signal than a nod in a meeting.
There's also a social effect. In a slide review the designer presents and the client reacts. With a prototype the client explores, and the designer watches. The feedback that comes back is about what they tried to do, not about what we chose to show.
A deck asks for approval of an idea. A prototype asks whether the thing works.
What it costs, honestly
Running prototypes are not free, and we'd be misleading you if we said otherwise.
- Time. A clickable flow in code takes longer than the same flow in Figma, especially the first time. Setting up data, navigation and states is real work.
- False finish. A prototype that looks and moves like the real app can make a client think the product is almost done. It isn't. Most of the back end is fake, and we have to say so clearly.
- Polish creep. Because it's code, there's a pull to keep fixing small things that don't matter for the decision at hand.
- Narrow feedback. High-fidelity work invites comments on details. Nielsen Norman Group's piece on prototype fidelity notes that people give more open criticism to rough work because it looks unfinished. A polished prototype can get you comments on a shade of grey when you wanted a view on the whole flow.
The rule we use is simple. If the question is "which idea?", stay static. If the question is "does this work?", build it.
How we keep prototypes cheap
The cost problem is mostly solved by not starting from zero. Our prototypes are built in the same stack as the client's app, usually React Native with Expo, so we can reuse real components and export a web build that runs inside a native shell on the phone.
- Real components, fake data. We use the product's actual buttons, cards and type styles, and feed them a JSON file instead of an API. The design system does most of the visual work.
- Realistic fake data. Long names, empty lists, missing photos and one item with a broken image. The awkward cases go into the fixture on day one, because that's where the design decisions are.
- Throwaway branches. Every prototype lives on its own branch and is allowed to be messy underneath. If an idea wins, we rebuild it properly. If it loses, we delete the branch without regret.
- Only the path that matters. We build the flow under review and stub the rest. A tab that isn't part of the question shows a placeholder, and the test tasks say so.
- Fake latency on purpose. Where waiting is part of the experience, we add a realistic delay so the loading state gets reviewed too.
Done this way, the second prototype for a product costs much less than the first. By the third, the effort comes close to a detailed Figma flow, and it answers more questions.
What to take from this
- Use static work to choose a direction, and running prototypes to approve one
- Put the prototype on the decision-maker's own phoneTheir device, their hand, their network. Not a laptop in a meeting room.
- Design the awkward states before the happy path is polishedLoading, empty, error, long text, keyboard open.
- Say clearly what is fakeData, back end and anything outside the flow under review.
- Keep prototypes on throwaway branches with real componentsCheap to build, cheap to delete.
A slide is a promise about an app. A prototype is a small piece of the app. When the question is whether to spend months building something, we'd rather our clients answer it holding the thing.
Sources
- Response Time Limits · Nielsen Norman Group
- UX Prototypes: Low Fidelity vs. High Fidelity · Nielsen Norman Group
- Understanding Success Criterion 2.5.8: Target Size (Minimum) · W3C WAI
- Accessibility · Apple Human Interface Guidelines
- Make apps more accessible · Android Developers
- Publish websites · Expo Documentation
