The build is done and the screens are not what we pictured: how to run the prototype phase

When a client says "this is not what we had in mind" on delivery day, the cause is rarely a bad designer. It is usually a design phase that never happened. The order that works is this: decide how a person will get the job done from start to finish, turn that flow into a clickable prototype, put the prototype in front of a few people who actually do the work, make the changes in the design file, and only then write code. Changing a screen in a prototype takes half an hour. Changing the same screen after launch means touching the data model, the tests, the documentation and usually the records already in the database.

The design phase is not the decoration phase

Many buyers hear "design" and think colours and fonts, which is why they say they need function, not design. But most of the decisions made in this phase are functional, not visual. Is the customer field mandatory when you create an order? Is the discount applied per line or on the total? Can a record waiting for approval still be edited? Can a user delete something they created themselves?

These questions usually get one sentence in a requirements document. On a screen they have to land somewhere specific. That is the real value of the phase: it makes the unanswered questions visible before they reach the code. We covered how to write a software requirements document separately, but even a good one stays abstract until someone draws the screen.

Map the flow before you list the screens

Starting with a screen list is a common mistake. A screen list tells you how many pages get built. It tells you nothing about whether a user can finish their job.

A more useful starting point is one sentence per task. "The warehouse clerk opens the incoming delivery note, counts the items, flags what is missing, closes the record, and accounting picks it up." Write that down and the open questions surface immediately. Can the record be closed with items missing? If accounting rejects it, who gets it back? What happens if the count is interrupted halfway through?

While you are at it, write the three states that sit next to the happy path: what the screen shows when there is no data at all, what the user sees when the action fails, and what happens when someone without permission lands on that page. Skip these in design and they enter the code as "we will deal with it later," which in practice becomes a screen that says "Something went wrong." How error handling is designed is a subject of its own.

How much fidelity do you actually need?

People treat prototype fidelity as a single dial, but it is not. Kara Pernice at Nielsen Norman Group separates it into three dimensions: interactivity (do the links and menus really work), visuals (do layout, hierarchy and spacing match the real product), and content (is it real copy and data or placeholders). A prototype can be high on one dimension and low on another, and often should be.

What you pick depends on what you want to learn. If the argument is about the logic of a flow, boxes on paper are enough and they change fast. If you want to know whether a dense form or a layered menu is actually usable, you need something clickable with real text in it, because people do not read placeholder copy the way they read the real thing.

The same article names the two risks of going high fidelity too early. A polished prototype makes stakeholders feel the product is ready and creates pressure to launch, and designers who have invested heavily in a screen get attached to it and resist changing it. Writing "draft" on the file does not fully solve either problem, but it helps.

A prototype also firms up the quote and the date

A clickable prototype is not only for users. It settles contracts. The main reason quotes for the same job differ by a factor of three is that each vendor reads a different scope into the same sentence. With twenty prototype screens on the table, everyone is looking at the same thing.

It changes what an estimate rests on, too. A number attached to "inventory module" is a guess. A number attached to "these six screens, these four states, these two integrations" is arithmetic. The uncertainty range described in software estimation and delivery dates narrows noticeably once a prototype exists. If you are considering a fixed-price arrangement, a prototype is close to mandatory, because in a fixed-price contract the party carrying the risk needs the scope pinned down.

If time is tight, prototype the riskiest flow rather than the whole product. The design sprint that Jake Knapp developed at Google Ventures does exactly this: five days to map the problem, sketch solutions, pick one, build just enough prototype to survive Friday, and test it with users the same week. Not every project needs one, but when a team cannot decide between two approaches, it turns a three-month argument into a week.

Five users is enough, but not in one sitting

Usability testing sounds like an expensive research programme. It is not. Jakob Nielsen's 2000 article, still the most cited piece on the subject, gives the distribution: one user surfaces about 31 percent of usability problems on average, five users surface 85 percent, and you need at least 15 to find all of them.

The recommendation in that article matters more than the numbers. If you have the budget for 15 participants, do not spend it in one go. Run three rounds of five. Each round fixes what the previous one exposed and tests the new version, and once the obvious problems are out of the way, the deeper ones underneath become visible.

You do not need a lab for this. Open the prototype, ask five people to do a specific task, and watch without talking. The hard part is the watching without talking. The moment you say "no, click the other button," you have lost whatever that session was going to teach you.

In internal software, who is the user?

When a company commissions an internal system, the design meetings fill up with managers. The person who will spend eight hours a day in the thing is usually not in the room.

That gap decides the outcome. A manager uses summaries and reports; an operator opens the same screen hundreds of times a day. Their needs are not the same. One of them cares about a clean dashboard, the other cares about creating a record without leaving the keyboard. Test the prototype with both groups separately, and do not put the operators second. They are usually the ones who determine whether the system gets adopted after go-live.

A prototype is not a product, even when it looks like one

AI tools can now turn a written description into screens that look and behave like working software. This genuinely speeds up the phase: a flow that took two days to draw is clickable in an afternoon.

The risk is that what comes out gets mistaken for a nearly finished product. Generated screens promise nothing about permissions, concurrent users, failure states, performance, accessibility or data integrity, and that is not what a prototype is for anyway. Saying this out loud to whoever signs off prevents the later conversation that starts with "but the screens were done."

If you do intend to keep some of that code, do not exempt it from normal review. The rules in reviewing AI-generated code apply here as well.

A design system starts at the second screen, not the first

One screen does not need a design system. By screen twenty you have three different greens for the same button, four row heights for the same table, and every new screen reopens a settled argument.

The fix is to decide colour, spacing, typography and component behaviour once, then reuse those decisions. There is now a shared machine-readable format for storing them: the Design Tokens Community Group published the Design Tokens Format Module as version 2025.10 on 28 October 2025, its first stable release. It is a community group report rather than a W3C standard, but most design tools support it for moving colour and sizing values between the design file and the codebase.

Do not overdo this on a small project. Building a component library for a ten-screen internal tool is time stolen from the actual work. A reasonable trigger: when you copy and paste the same component for the third time, define it.

Accessibility and edge cases are design decisions

Most of accessibility is decided in design, not in code. Contrast between text and background (4.5:1 for normal-size text at WCAG 2.2 level AA), the size of touch targets (at least 24 by 24 CSS pixels under SC 2.5.8, or enough spacing around them), not carrying meaning by colour alone: all of it can be settled in the design file, and all of it is expensive to retrofit. We went through WCAG 2.2 compliance in a separate post.

Edge cases work the same way. What does the table do when a product name runs to 90 characters? How does pagination behave with 50,000 rows? What happens when a user navigates away from a half-filled form? Drawing these takes minutes. Discovering them in production delays the next release.

What actually reaches the code is not a pretty screen

The output of the design phase is more than a prototype file. What a developer needs is this: the empty, loaded, loading, error and unauthorised state of every screen; which fields are required and what the validation rules are; default sort order and pagination behaviour; how the layout changes on a narrow screen; and a shared definition of the components in use.

That list doubles as the skeleton of your acceptance criteria. Criteria written against a prototype largely end the "that is not what we agreed" discussion during acceptance testing and go-live, because both sides signed off while looking at the same screen.

When to skip the prototype

Not every piece of work needs one, and an unnecessary design phase slows a project down. Adding a column to an existing screen, implementing a familiar pattern such as a login or password reset, or building a simple internal tool for three people rarely justifies a clickable prototype. A rough sketch does the job.

Prototyping pays for itself when the flow is new and nobody is sure how it should work, when there are competing solutions to the same problem, when the people paying for the software are not the people who will use it, or when a fixed price is about to be agreed on scope.

What you can do on your current project

• Write a one-paragraph flow for every main task the software supports, and add the empty, error and unauthorised state to the end of each.
• Pick the two riskiest flows and make them clickable; leave the rest at sketch level.
• Test the prototype with five people who actually do the work, starting with operators rather than managers, and resist helping while you watch.
• Fix what you found and run a second round of five; two short rounds reveal more than one large test.
• Turn the prototype screens into an acceptance criteria list and attach it to the quote or the contract.
• Check contrast ratios, touch target sizes and colour-independent meaning in the design file, before anything is built.
• Define a shared component the third time you copy one, and do not build a design system before that.