Design Deliverable

Inside one person's head, design is a single thing. The moment it has to be handed to someone else it splits into several, and if those several don't have separate names, the same request means a different object every time it's made.

Pagedeck ran into this early. When Mia, the product manager, asked when the design would be ready, Noa couldn't answer. That week Noa had forty screenshots of comparable products pinned up and was deciding which overall impression to chase. What Mia had in mind was a finished screen she could click through. What Theo, the engineer, had in mind was a number telling him how much space sat above a button. Three people used one word and pictured three different objects, so the conversation was never going to land on a date.

The mismatch charged its fee in the same two places. Noa would be mid-exploration, Mia would read the exploration as a settled direction and report it upward, and two weeks later a completely different screen would appear along with a question about why the plan changed. The reverse also happened: Theo would receive a fully colored screen, start building, find no measurements written anywhere, estimate them by eye, and learn in review that twelve places were off. Neither case was caused by bad work. Both were caused by the handoff being unclear about what had just been handed over.

So each stage's output got its own name. A name settles three things at once — the question this object answers, who receives it, and what the receiver is allowed to do with it. A board of reference images answers a question about direction, so the right response is an opinion. A file with measurements on it exists for implementation, so the right response is to build it. React to the first as if it were the second, or to the second as if it were the first, and the handoff goes wrong.

On the larger design map, this branch belongs to how a team works rather than to what a team designs. If design process is the order in which a problem becomes a solution, deliverables are the objects that actually leave the room at each step of that order. An order with no objects gives nobody a way to check progress. Objects with no order leave you unable to tell which stage the thing in your hands came from.

What changed once the names existed wasn't the designer's workload. It was everyone else's waiting. Before, nobody could ask anything useful until the screens were finished, and the answer to any question was some version of "still working on it." Now a single stage name carries what has been decided and what is still open. Knowing these terms tends to be worth more to the people working with a designer than to the designer.

Four branches sit under this term. They're ordered by when the work happens, and what separates them isn't polish but the question each object answers. Getting more refined toward the end is a side effect; each branch exists because there's a question the earlier stage genuinely cannot answer.

Lining up the four questions first shows where the six terms attach.

1. What impression are we going for — the exploration stage
2. What goes where — the structure stage
3. How does it actually look — the visual stage
4. How does this get handed over and checked — the delivery stage

The first three branches hold one term each. The last holds three. Handing work over goes wrong often enough that the stage got subdivided.

The exploration stage holds the moodboard, a single board of reference images collected to settle on a direction. Color, the texture of photography, how heavy the type is, how much white space gets left — those add up to an impression. It's the kind of decision that drifts when it's discussed in words, so it gets made into an object instead. When Grace, the CEO, says she wants something that feels more trustworthy, the screen she's picturing and the screen Noa is picturing are almost never the same one. Put twelve images up and ask which side of the room it is, and the question closes in a few minutes. Nothing from the actual product gets drawn at this stage. It decides what to draw; it doesn't draw it.

The structure stage holds the wireframe, a plan drawn in gray boxes with color, imagery, and typography stripped out, showing only what sits where. The styling is removed on purpose, because it hijacks the conversation. Show people a colored screen and the first comment is about the blue being too heavy, while nobody touches the question of whether the document list belongs on the left or across the top. With only gray boxes on screen, layout is the only thing left to talk about. Pagedeck's document sharing screen flipped three times at this stage. Whether the share control lived inside the document or in the list got settled here, and had that flip come after the color was applied, the same decision would have cost three extra days.

The visual stage holds the mockup, a design with real color, type, and imagery applied on top of a settled structure so it reads as a finished screen. Hierarchy only becomes visible here. Given identical layouts, making just the save button a strong color gets people reading that first, while four buttons in the same color means all four get read. Wiring several screens together so someone can tap through them produces a prototype, which sits on the product branch of the map rather than this one. A mockup shows the state of one screen; a prototype shows the movement between screens.

The delivery stage holds three terms with different jobs. In order, they write the values down, hand them over, and check the result.

1. Redline — a design marked up with the spacing, size, and color values written out as numbers. Space above the button 24, corner radius 8, type size 14, all labeled on the screen. Designers used to draw these annotations by hand; now tools like Figma read the values straight out of the file. The drawing disappeared, but the need to agree on the numbers didn't.
2. Design handoff — the whole act of passing design to engineering. It isn't sending a file. It's communicating which parts are settled and which aren't, plus what the screen does in the situations nobody drew. Empty lists, very long text, failed requests — when those go missing here, the engineer ends up making those calls alone.
3. Design QA — the review that checks whether what got built matches what was designed. The two versions go side by side and the differences get listed. However well the first two steps go, without this one a four-pixel gap ships as it is. A single screen being four off is invisible; twenty such screens make a product that quietly no longer matches its own design, and by then tracing where the drift started is hard.

The four branches form a chain, but no team runs all four every time. Questions that already have answers get skipped. If the impression has been settled into a design system, there's no reason to build another moodboard, and adding one button to an existing screen doesn't need the structure stage either. A brand-new product's first screen, on the other hand, goes through all four. What decides the skipping is which answer the team is actually missing.

Skipped stages sometimes send a bill later. Skip the structure stage, build a fully colored screen, then have the layout flip, and what needs redrawing isn't only the layout — it's all the color, type, and imagery sitting on top of it. So the trade to weigh is the time saved against the odds of a flip. On top of something settled, skipping pays. On top of something still moving, skipping is debt.

"This is a moodboard, so please don't read it as the final screen. Just react to the direction."

Drawing a line so the receiver doesn't treat the object as settled. Without that sentence, a different screen two weeks later reads as someone changing their story.

"Let's hold the color conversation for now and decide whether this list goes on the left."

The question this particular deliverable exists to answer is layout, not color. It's a request to keep the stages intact, not to suppress opinions.

"Before handoff, can I get two more screens — the empty state and the error state?"

The normal case alone isn't enough to start building. Without those two, the engineer picks something, and review sends it back.

At Pagedeck these sentences turn up in the weekly screen-by-screen check. Mia puts up the list of screens shipping this cycle and Noa marks how far each one has come. The marking uses stage names rather than percentages. Seventy percent tells nobody what to do next; "at the structure stage" tells Theo not to start yet and tells Mia she needs a color decision this week.

Theo only pulls screens that have reached the delivery stage. He doesn't look at a visual-stage screen, infer the structure, and start early. Running ahead means that one revision to the design wipes out everything built against it. What he does instead is ask why, in a week where few screens reached delivery. Whether the holdup is an undecided question or a missing pair of hands changes who moves next.

The most common mistake is reading deliverables as a checklist that must be filled in at every stage. Four stages lined up in order look like a procedure, and skipping one looks like breaking it. But each object exists to answer an open question, so when the answer is already there, the reason to build it disappears too. Starting from a moodboard to add one item to a settings screen burns two days producing a board nobody will open. Once this misreading sets in, a team starts treating the production of deliverables as progress, and ends up with more files and no more decisions than it had before.

The opposite mistake is just as common: reading a fully rendered mockup as a finished design. Nothing looks missing, so the assumption is a fair one. But a mockup shows one moment in which everything went well. The user with a twenty-character name, the brand-new account with no documents in it, the instant a save fails — none of those are in that image. Hand it over as is and the engineer fills those gaps alone, and the filling gets overturned in review. Pagedeck built one list screen twice, and what had been missing was not design sense but a single decision about what to show when there are no documents. Picturing each screen as a stand-in for five or six states keeps this in check. A polished image means one of those states is done, not that all of them are.