Wireframe

Meetings about layout kept ending without a layout decision. The cause turned out to be the artefact on the screen.

The day Noa brought in a version with colour and type applied, the first comment was that the blue was too heavy, the second was that the icons looked dated, and the third was about the corner radius. In an hour, nobody raised whether the document list belonged on the left or across the top. A decorated screen makes people talk about what their eye lands on first, and layout is never what the eye lands on first.

So the decoration gets removed on purpose, in a separate artefact. With nothing but grey boxes and lines, layout is the only thing left to discuss. Pagedeck's document sharing screen was reversed three times at this stage. Whether the share button lived inside the document or on the list got settled here, and reversing that same decision after colour was applied would have cost three more days.

Seven things belong on the page, and one of the seven is the list of what stays off it.

1. The screen name and a one-line purpose: what the user does here. "Screen for sharing a document with a colleague" gives the rest of the discussion something to hang on.
2. Region blocks. Header, left list, main body, right panel, drawn as boxes. What's being decided is the number of regions and where they sit; sizes only need to be approximately right — whether a box takes half the screen or a quarter is precise enough.
3. Element types and hierarchy. Headings, body text, buttons and inputs only need to be distinguishable from each other. Use two or three text sizes and don't lean on colour.
4. The actual copy that will ship. Filler text hides length. "3 documents selected" and "There are 3 documents currently selected" occupy different widths, and that difference moves the button. Error messages are the worst offenders, since the real ones run two lines and the placeholder ran one.
5. The exception states. Draw the list empty, the list with 200 rows, and the list failing to load. Leave them out and three developers invent three different versions during the build, and each of those versions becomes a separate bug report later.
6. Movement between screens. Note with arrows or annotations which control leads where, including what happens on cancel, which is the transition most often left undefined.
7. What stays out: colour, imagery, typefaces, shadows and exact spacing values. Those five belong to the mockup that comes next, and settling them here drags the layout conversation back into decoration.

A designer usually draws it, and on teams without a designer yet the product manager starts it by hand. A sheet of paper counts as this artefact too, as does a shared document with boxes typed into it. What matters is not the tool but the condition: the decoration is absent.

There are three readers.

1. The people deciding the layout together — the product manager, an engineer, sometimes whoever knows the customers. This drawing isn't a document announcing a result; it's an object you put on the table in a meeting.
2. Engineers, who read it to size the work rather than to build from it. That an extra right panel appeared is enough to judge whether two more days are involved, and whether anything on the server side has to change.
3. The author. Drawing it regularly reveals that what was meant to fit on one screen is two screens' worth of content. It fits in your head and stops fitting once it's in boxes.

There's also an audience it should not reach. Show this to a customer or an investor and the first question back is why it looks so unfinished. Those rooms get a moodboard, which carries the intended impression, or a mockup that's close to final.

Its life is short. Once the mockup exists, the wireframe gets thrown away rather than archived somewhere it can be found and trusted. Maintaining two documents that describe the same screen guarantees they diverge, and after they diverge nobody knows which one is right. The exception states from item five are the one thing to carry forward, because that list is requirements rather than layout.

"Ignore the colours — it's a wireframe, so just look at the arrangement."

Fencing the discussion around layout, before anyone spends the meeting on shades of blue.

"There's no empty state here. Could you draw that one too?"

Flagging a missing exception state before three people invent three versions of it.

"Let's skip the wireframe and go straight to the mockup. It's one button on an existing screen."

The layout decision is already made, so the structure stage adds nothing.

Noa's first pass at the document sharing screen took fifteen minutes; the next three days went to exception states. Sharing with someone outside the company, re-selecting a person who already has access, and a person without permission opening the link were three different screens. Looking at that list, Theo revised his estimate from three days to eight — and having that revision arrive during the layout stage was far cheaper than having it arrive mid-build.

The most common reading is that this is a roughly drawn mockup. It's grey and coarse, so it looks unfinished. But the drawing isn't a low-quality version of the visual design, it answers a different question. It answers what goes where, and says nothing about how the result will look. Read it as unfinished and applying colour starts to feel like progress, which means decoration arrives before the layout is settled and the review that mattered never happens.

The other position is that tools have improved enough to start at the mockup. Colour and type cost far less time than they used to, which sounds like a fair argument. What changed is the cost of production; the kind of feedback you get back did not. Put a coloured screen in a meeting and layout comments largely don't arrive. Settle the layout in that state and the bill comes later, as twelve mockups that all need editing. Faster production feels like cheaper reversal, but the cost of reversing scales with the number of screens.