High-fidelity Prototype

A screen drawn as boxes and lines is cheap and fast, but there are questions it can't answer. Which of three button labels confuses people least. Whether someone faced with two buttons presses the one they meant to. Nobody can answer those looking at a gray rectangle with the word "button" on it.

Pagedeck got caught by exactly that. Noa brought a permissions screen drawn in boxes and lines, the review went around, everyone said it looked fine. Once it was built, "Share" and "Invite" sat side by side at the same size, and half the users trying to hand a document to their team pressed Invite. In the review those two had been a pair of gray rectangles, and the people looking at them filled in a screen where the difference was obvious.

Gray rectangles cause a second problem: people defer judgment. Shown something visibly unfinished, they think it'll be fine once it's done and move on. Build it close to the real screen and that grace period disappears, so people say on the spot what will happen if it ships as it stands.

This is the top rung of the fidelity ladder that starts at the paper prototype. Flow gets settled on paper, structure gets settled after that, and when copy and color are the things left to decide, the work moves here.

Six things have to be filled in.

1. The copy you actually intend to ship. Filler text erases the very thing you were trying to check. Nobody can judge whether an explanation reads clearly when the spot says "description here."
2. Data close to the real thing. Don't only put a short name in the name field — include the case where the department name runs twenty characters, and the case where a list has zero rows. Fill it with short, tidy values and you won't see the line wrap that real data causes.
3. Visual rules. Pull color, typeface, and spacing from the design system, the single set of reusable rules and parts. Taking them from there means engineering can build it as drawn, and no two mockups drift into different colors.
4. The screens for when things don't go well: the empty state with nothing to show yet, the waiting screen, the screen for invalid input. Build only the happy path and you've checked only half of it.
5. Transitions and responses. Pressing moves to the next screen, entering a value makes the screen respond. This overlaps with the clickable dummy, where only the screen transitions work for real; at high fidelity even the way screens move resembles the finished product.
6. A path that runs one task end to end. It has to connect from the first screen to the last without a gap to be usable in front of anyone.

Decide what not to include, too. Values that really persist, results that change with the search term, every branch the permission model can take — those usually go unbuilt. Skip that list and the screen count keeps growing until building takes longer than the moment you were building for.

A product designer usually builds it. At Pagedeck, Noa builds and Mia writes the question and the task sentence alongside. The same screen needs a different number of states depending on whether you're asking "how does this look" or telling someone "make this document visible to the whole team," so the question has to be settled before the scope is.

There are three audiences.

The first is users. Give five of them the same task and watch where they stop. That session is why the copy and data have to be close to real — otherwise participants spend their time decoding the screen and the hour ends before anyone reaches the part you wanted to ask about.

The second is the team. Theo reads spacing and state screens off it and builds from there. "Show a message on error," written in a requirements document, produces a different picture in every head; put that screen in the prototype and the interpretations converge.

The third is outside the company: Grace showing investors, Sofia running a customer demo. That audience takes the most care. It's indistinguishable from a real screen, so viewers easily receive it as a feature that already exists, and when a contract date gets set on top of that misunderstanding, someone has to walk it back later. So it gets introduced as a screen that hasn't been built yet.

"Make it high-fidelity — there's a customer demo next week."

It's going in front of outsiders, so it needs to look like the real screen.

"Put the real copy in. With filler text there's nothing to ask about in the test."

Fidelity is about the content, not the polish.

"Are the empty and error states in there? We need those before we can start building."

The request from the people using the prototype as the basis for implementation.

Pagedeck reversed the order when it rebuilt the permissions screen. Noa made three high-fidelity versions differing only in the labels and sizes of the Share and Invite buttons, and gave five users the same task: make the document visible to the entire team.

Four of five pressed Invite on the first version; on the second, only one did. The only difference was changing the label to "Share with team" and making the invite button less prominent. Gray rectangles can neither produce that difference nor ask about it.

It's easy to assume higher fidelity always means a better prototype. More went in, so it must be further along. But the right fidelity depends on what you're checking. Bring a fully colored screen to a session meant to test whether the order makes sense, and people talk about preferring blue instead of telling you the order is strange. If the order was the question, that meeting spent itself on nothing.

The other common mistake is reading it as nearly finished. It clicks through, so the remaining work looks small. In practice it's a shell that does nothing off the prepared path. Values don't persist, nothing shows up on anyone else's screen, and permissions and error handling are usually absent altogether. Leave that impression standing and whoever saw the demo starts expecting a launch next week, while the team inherits a deadline that never existed.