Mockup

The drawing a team makes before building a screen is a wireframe: gray boxes showing what goes where, with color and imagery deliberately left out. It suits the conversation about layout. Once layout is settled, though, one question remains that gray boxes cannot answer — what will this actually look like.

Teams kept nodding at the gray drawing and then reopening the whole conversation in front of the built screen. Grace says the screen isn't what she pictured, Noa says it matches the drawing, and both are right. The layout does match. The impression comes from everything the drawing left out.

With the same layout, making only the save button a deep color means people read that first; making four buttons the same color means they read all four. Raising body text from 14 to 16 turns an eight-row list into a six-row list. None of this makes any difference on the drawing, and all of it shows up the first time the real screen exists.

A mockup is the step that moves that discovery earlier. After the structure is fixed, color, type, and images go on, and the team agrees on a finished-looking screen before anyone starts building it.

One mockup contains everything that will be visible in the final screen. Six things.

1. The settled layout — it arrives from the previous stage unchanged. Reopening layout here means reapplying every color and every piece of type that was placed on top of it, so layout is finished before this point.
2. Color — values for background, text, emphasis, and warning. The goal isn't attractiveness, it's hierarchy. The strongest color on a screen belongs to the single action you most want the user to take.
3. Type — typeface, sizes, weights, line spacing. This is where you decide how many steps to keep, such as 20 for headings, 14 for body, 12 for supporting text. Too many steps and nothing reads as more important than anything else.
4. Images and icons — the gray rectangles that held space now hold actual photos and icons.
5. Real content — the placeholder "Title goes here" gives way to the sentences and data that will really appear. Put in a two-character name and a twelve-character one, and a document title of 40 characters, and you can see what the screen does with them.
6. States — a screen is not one picture. The empty list, the loading state, and the failed request each get drawn. Leave those out and a developer decides them alone during the build, which usually produces a blank area with no explanation. The empty state is the one that matters most, because it's the first thing a new user sees and the only screen that can tell them what to do next.

One product designer makes it, and four groups read it. They look at the same image for different reasons.

1. Product manager — checks that every part of the planned feature is on screen and that no case is missing. A state that isn't in the mockup won't be in the build either.
2. Developers — read what has to be built. Appearance alone isn't enough, so a redline carrying spacing and size as numbers follows, along with a design handoff that passes on the edge cases. Tools like Figma read the values out of the file automatically, but what's settled and what isn't still has to be said by a person.
3. The founder and the team — check the impression. It's the kind of decision that drifts when it's discussed in words, so it gets decided in front of an image.
4. Sales and marketing — use it to show customers a feature that doesn't exist yet. That use needs a caveat attached, since what ships may differ from the picture, and a customer who signed expecting the picture is a problem that lands back on the product team.

Later, holding the built screen next to the mockup and hunting for differences is design QA. The mockup stays the reference until then.

"We have the mockup now — can we treat the colors as final?"

Asking whether passing this stage means the visual decisions stop moving.

"This mockup only has ideal data. Can I get one with a title longer than 40 characters?"

A screen built from short samples will break on real content.

"Could I get something clickable instead of a mockup? I want to see the flow."

The request is about movement between screens, not the appearance of one.

When Pagedeck built its document sharing screen, Noa delivered five mockups: the default screen, one where nobody has been given access yet, one while a link is being generated, one where the request failed for lack of permission, and one where more than thirty people have access. The original request was for the default screen only, but Theo asked for the other four, and drawing them then was faster than asking mid-build.

Mia found a gap in her own spec by reading those five. Looking at the screen with thirty-plus people on it, she noticed there was nowhere to remove someone who already had access. Drawing a thing exposes holes that a written spec hides.

Many people treat the mockup as the end of design. What's visible looks finished, so the assumption is reasonable. But handoff still comes after it: writing the values down as numbers, passing along the edge cases, and confirming that the built screen matches. Skip that and a margin meant to be 24 ships as 20. A single screen four pixels off is invisible, but twenty such screens make the product quietly different from its designs everywhere, and by then nobody can say where the drift started.

The other frequent error is reading a good-looking mockup as an easy-to-use one. A well-made mockup contains ideal conditions, which makes this even easier to believe: data is a convenient length, lists hold a reasonable number of items, and nothing fails. Real users live outside those conditions. Whether something is usable gets answered by clicking through it rather than by looking at one picture, which is why a prototype follows the mockup. A screen that looks obvious on a laptop can still leave someone stuck on step three.