Clickable Dummy

Some things stay invisible until someone tries to use the screens, even when every screen has already been drawn. Whether the order makes sense, and where a person stops partway through. Pictures alone don't surface either one.

That is what happened at Pagedeck on the sharing settings work. Noa put twelve screens on the meeting room display and walked through them — press this button here and you land over there — and everyone agreed it looked fine. Two weeks later Theo built it and there was no route back for anyone who picked the wrong permission. The gap had been invisible because Noa was joining the screens together out loud.

With users in the room the problem gets worse. Put a still image in front of a participant and fill in the rest by saying "imagine pressing this opens the next screen," and they are now watching the screen while being guided through it. The whole point of the session was to see where they get lost on their own, and someone is narrating the route the entire time.

A clickable dummy exists to remove that narration. Attach the press-and-advance behavior and nobody has to explain anything, and the holes in the flow show up on their own at whatever point the walk stops. That is exactly where it parts ways with a wireframe, which is a still drawing of layout and nothing more.

The minimum is enough screens to walk one scenario end to end, plus the links that connect them. In practice there are six things to get right.

1. The screens. Build only what the one task under test needs. A flow for changing sharing settings runs from the document list to the settings panel, the permission picker, a confirmation and a done state — somewhere between eight and fifteen screens. If that count keeps growing, the question being tested hasn't been settled.
2. The links. Specify which region of a screen leads to which other screen. Leave three or four pressable spots per screen and let everything else sit dead.
3. A starting point and a task sentence. Write down which screen the session opens on and what the participant is asked to do, in one line. "Share this document with someone outside your company, view only" gives the goal without giving the route.
4. Dummy data. Fix the names and numbers that appear on screen, and make them plausible. If every document in the list is called "Untitled," the participant can't tell what the picker is even asking them to choose between.
5. Dead ends. Pressing anything outside the mapped route does nothing, which reads as a broken product and stops people cold. Put a note in those spots saying the screen is only built this far, or agree on a signal the facilitator uses to move things along.
6. A list of what doesn't work. Text typed in is never saved, search does nothing, the counts in the list never change. Tell the viewer this before they start rather than after they trip on it.

Fidelity is a separate decision. Add links to a low-fidelity prototype made of boxes and lines and you have a clickable dummy; add them to a high-fidelity prototype with final color and copy and you also have a clickable dummy. The term draws a line around behavior, not around how finished something looks.

Product designers usually build them, since whoever drew the screens can wire them up fastest. Design tools carry screen-linking built in, so when the screens already exist an hour or two covers the wiring. When a flow is only a few screens long, product managers often do it themselves.

Three audiences read it, and the audience changes how much you build.

1. Usability test participants. This is the artifact behind a usability test, where people are given a real task and watched for where they get stuck. Five participants running the same task without any explanation will surface most of the serious problems. For this audience nothing outside the task needs to be pressable.
2. The team building it. Attach the link to the PRD and engineers stop having to picture screens from prose. This audience cares more about exceptions, though, so expect requests for the empty state and the no-permission state on top of the main path.
3. People outside the company. Investor meetings and customer demos. Viewers readily take what they see as a finished product, so say up front that it is a design that doesn't work yet.

"Send me a clickable dummy instead of screenshots. I want to press through it."

A request for something walkable rather than a set of stills.

"This one only opens the invite flow. Nothing else responds."

A heads-up that a single path was built, so dead spots elsewhere aren't bugs.

"Three people stopped at the same place in the clickable dummy."

Three of five participants couldn't find the next action on one screen, which is evidence for fixing that screen.

At Pagedeck, Noa builds these and Mia writes the task sentences. For the sharing settings work they built an eleven-screen version and ran five participants through it, and three of them stopped at the permission picker. All three sat staring at the screen because they couldn't tell view-only apart from comment access.

What got changed was two lines of copy, not the structure of the screens. No engineering had started yet, and what Theo received was the corrected dummy with the new wording already in it. In a design sprint — the five-day workshop that runs from framing a problem to testing a solution — building one on day four and showing it on day five is written into the schedule.

The most common reading is that it means a well-made prototype. Pressing through something that advances feels close to a finished product, so the association is easy to form. But the word draws its line around behavior rather than appearance, and screens no better than a paper sketch qualify. Teams that treat it as the minimum bar for real validation end up spending two days on a check that a few sheets of paper would have settled in thirty minutes.

Reading it as a way to save engineering time is the other one. It costs so much less than the real thing that the saving sounds obvious. But this isn't a head start on what gets built — it is how the team decides what to build. None of the screen wiring turns into a single line of code. What shrinks isn't build time but the odds of building the wrong thing and rebuilding it two weeks later.