Low-fidelity Prototype

Showing something before building it is not a new idea. The cost of making the something was the problem. Drawing a screen properly meant choosing colors, settling on typefaces, and hunting down icons, and after three or four days of that the person who made it is in no position to throw it away. Nobody volunteers to start over on work they just spent the week on.

The same thing happened on the viewing side. Put a finished-looking screen in front of a room and the comments are predictable. Noa once brought five fully colored screens to a review of the signup flow, and the hour went entirely to button colors and the tone of the copy. What she wanted to ask was whether verification could move to after signup, and that question never came up.

A low-fidelity prototype, usually shortened to lo-fi, solves both problems the same way: by deliberately building less. Strip out the color and turn text into gray bars and the thing takes an hour to make, costs nothing to discard, and leaves the room nothing to say about styling — so the room talks about structure instead. The low finish is the feature, not a side effect.

Five things belong in the file, and once you go past them you are making something else.

1. Screen frames — one rectangle per screen, holding only the lines and boxes that divide it into regions. A single flow usually runs three to eight screens.
2. Placeholders — gray bars for text, a rectangle with a diagonal through it for images. Real copy stays out because the moment people can read it, they start editing it. Button labels and screen titles are the exception and use real words. They are the minimum needed to tell what a screen does, and blanking them makes the flow unreadable.
3. Hierarchy — what is large and what comes first, expressed through size and order. This is close to the only design decision made at this stage. Whether the search field sits above or below the list gets settled here.
4. Links between screens — a line from a box to the screen it opens. This is what separates the file from a wireframe. A wireframe is a drawing you pin to a wall; this one you tap to move forward.
5. The question being asked — one line at the top of the file, such as "do people reach verification without dropping out of signup?" Without it the review drifts and the screen count keeps growing while you build.

What stays out is just as fixed: color, typefaces, logos, real photography, error messages, and edge states like an empty list. What to show when a list has no data in it is a real decision, but it isn't the one this artifact answers. Fill all of that in and you've spent three days, and by then you have a high-fidelity prototype.

A designer usually makes it, but at this fidelity anyone can. Boxes and lines don't reward tool skill. At Pagedeck, Noa makes most of them, and when things are moving fast Mia draws the boxes herself in Figma. Figma is a design tool several people edit at once in the browser, so one link puts everyone on the same screen.

Readers split into three groups, and each looks at something different.

1. Teammates — Mia checks whether a step is missing; Theo checks what the server has to return for the flow to work at all. When Theo says the value screen 3 needs isn't in the API today, the design changes on the spot. Hearing that after the screens are finished costs three days of work.
2. Users — this is the artifact used in a usability test, where five people get the same task and you watch where they stall. The lack of polish helps here. People say a rough drawing looks wrong without hesitating.
3. Decision-makers — this rarely goes to someone like Grace, and it doesn't go to investors or prospects either. It works only among people who know it is unfinished.

"Let's look at the flow in lo-fi first. Color comes later."

Drawing a line in advance around what the meeting decides: order and placement, not appearance.

"This is lo-fi — why did it take so long?"

Two days went into something that should have taken an hour.

"Let's run it past five people in lo-fi before we decide."

A proposal to check with a usability test before moving to the next stage.

When Pagedeck starts on a new feature, this file is the first thing Noa opens. She reads the path Mia mapped in the user flow, draws five screens as boxes, and writes the question for this round on the first line. A user flow is the screens and branches someone passes through on the way to a goal, drawn as a connected path, and it's where the rough screen count comes from.

The next day the three of them open the link and step through it one screen at a time. What comes up is almost always sequence: move verification later, merge screens 3 and 4. A merge decided in that room takes ten minutes to redraw, which is the whole reason the conversation can stay this loose: nothing on the screen is expensive enough to defend.

The most common misreading is that low fidelity licenses low care. "Less finished" sounds a lot like "less effort," so the slide is easy. But only the surface is lowered; the structure has to be sharper than usual. If the screen order is tangled or a button has no label, each viewer fills the gap differently, and three people leave the meeting holding three different products in their heads. That gap surfaces halfway through the build.

The opposite mistake is trying to settle everything at this stage. Staring at boxes until every question is answered stretches the review and grows the screen count. What this artifact can answer is order, placement, and hierarchy. Which of three labels reads most clearly is not something boxes decide, and if that question is still open, the next fidelity is where it gets answered.