How to Review Design Work as a Client: What to Check in Wireframes, Visual Mockups, and Clickable Prototypes

The design files arrive, the client opens them, and the first comment is often “Can this blue be a bit brighter?” A few rounds later the color has changed five times, and only in development does anyone notice that member registration is missing a step and the order lookup page has nowhere to put filters. The real difficulty in reviewing design work is not taste. It is looking at the right things at the right stage.

Software and website design usually passes through three stages: wireframes, visual mockups, and clickable prototypes. Each stage answers a different question, and the cost of changing things differs at each. The earlier a flow problem surfaces, the cheaper it is to fix; the later a structural change is raised, the more likely it is to disturb work that is already done.

What follows goes through the three stages in order: what to look at in each, what not to dwell on at that stage, how to write feedback a designer can act on, and how to agree in advance on sign-off and the number of revision rounds.

Why design review needs stages

Splitting design into stages is not a way to bill more often. It is a way to make different kinds of decisions separately.

Wireframes deal with where information goes and how the flow runs. Visual mockups deal with whether it looks like the brand and whether it reads comfortably. Prototypes deal with whether it actually feels smooth to use. Review all three at once and the discussion loses focus: one person is talking about button color, another about whether a field should be required, and the meeting ends without a single conclusion anyone can act on.

Stages have another benefit: when a stage ends, the decisions from it are locked in. Visual mockups are built on top of approved wireframes. Asking to rearrange a whole page’s structure at the mockup stage means going back and overturning the previous stage, and the designer has to redo far more than one image.

So the first rule of review is this: ask yourself which stage you are in and what question that stage is meant to answer before you start looking at the work.

Stage one: what to check in wireframes

Wireframes are usually gray boxes and text. They deliberately leave out color and images so that you focus only on structure.

What to look at in this stage:

• Is the list of pages complete? Are all the pages you need there? Screens like forgot password, no search results, and what happens after an order is canceled are often missed.
• The priority of information on each page. What does a user most want to know when they open this page? Is that information in the most prominent spot?
• Does the flow work end to end? From the entry point to finishing the task, is there always a next step to tap? Is there anywhere a user gets stuck halfway with no way back?
• Are the fields and data correct? Which fields does the form ask for, and which columns does the list show? Do they match how the business actually works?
• Differences between roles. Do administrators, regular members, and visitors see appropriately different screens?

What not to dwell on at this stage: color, fonts, images, icon style, and button corner radius. The size of the boxes in a wireframe is only indicative, not the final proportions. Spending time on aesthetics here is like critiquing the brushwork on a sketch.

Wireframes are best reviewed alongside the requirements document. If the requirements are unclear, the wireframes will reflect that vagueness, and the fix is to go back and fill in the requirements rather than guess on screen. For how to structure requirements, see How to Write Software Requirements.

Stage two: what to check in visual mockups

Once the wireframes are approved, the designer adds brand colors, typography, images, and component styles, producing screens that look close to the finished product.

What to look at in this stage:

• Brand consistency. Do the colors, tone, and image style fit the brand? Would they look out of place next to your website, social accounts, or business cards?
• Readability. Is body text legible on a phone? Is there enough contrast between text and background? Do long paragraphs have enough line spacing?
• Clear hierarchy. Can you tell primary buttons from secondary ones? Are headings, body text, and helper text distinguishable at a glance?
• Complete states. Are pressed and disabled button states, form error messages, empty states, and loading states all designed?
• Responsive versions. Are there both desktop and mobile versions? A mobile layout is not the desktop shrunk down; priorities need to be rearranged.

What not to dwell on at this stage: reopening the flow and page structure. If you genuinely find a structural problem, flag it explicitly as a change at the wireframe level so the designer can assess the impact, rather than mixing it in with ordinary comments. And if placeholder copy and images are not final, there is no need to edit them word by word; just confirm the layout can hold real content at its real length.

Readability and contrast also relate to accessibility. If your site serves older people or users who rely on assistive tools, check it against the Web Accessibility Guide at the same time.

Stage three: what to check in clickable prototypes

A clickable prototype links the mockups into a simulation you can tap through and switch between. It is not real code yet, but it lets you use the thing once.

What to look at in this stage:

• Walk through the key tasks. Pick the three to five most important scenarios, such as signing up, placing an order, looking something up, or submitting an application, and go through each from start to finish.
• Test with real users. Ask a colleague who was not involved in the project, or a customer, to try it. Give no hints and just watch. Where they pause and where they tap the wrong thing is what needs to change.
• Transitions and feedback. Is there a clear response after a button is pressed? After a successful submission, does the user know what happens next?
• Exception paths. When input is wrong, the connection drops, or permission is lacking, does the screen guide the user to a next step?

What not to dwell on at this stage: how smooth the animations are, the content of placeholder data, and the limitations of the prototyping tool itself. Transitions in a prototype are not necessarily what will be built, and dummy data is only a placeholder. The question is whether the interaction logic is right, not how polished the prototype is.

Problems found at the prototype stage are usually the cheapest changes in the entire project: the experience is close to real use, but no production code has been written yet. That is also why many teams building a minimum viable product (MVP) validate the flow with a prototype before developing it.

How to write feedback a designer can act on

The same issue written as “this page feels off” and as “first-time members can’t tell they need to fill in their profile first; suggest moving the step indicator to the top” gets handled at completely different speeds.

Useful feedback has four elements:

1. Location: which page and which section, ideally with an annotated screenshot.
2. Observation: what you saw, or what difficulty a user ran into.
3. Reason: why this is a problem, and which business goal or usage scenario it affects.
4. Desired outcome: the effect you want, not necessarily a specific solution.

The fourth point matters most. Describing what you want to achieve works better than dictating “make the button red,” because the designer may have a better approach. Of course, if it is a hard requirement from brand guidelines or regulation, state it plainly.

A feedback template (copy it as is):

• Page / section:
• What I see:
• The problem this causes:
• The outcome I want:
• Priority: must fix / suggestion / can wait for the next phase
• Raised by:

Marking priority stops the designer from treating every item as equally urgent. Keep all comments in one document or one tool, ordered by page, rather than scattered across chat groups and email. Scattered feedback is the easiest to miss and the most likely to contradict itself.

Feedback habits to avoid:

• Feelings with no reason: “I don’t like it,” “not premium enough,” “it doesn’t do anything for me.”
• A competitor’s screenshot in place of an explanation: “make it like theirs,” without saying which part.
• Contradictions within one round: item one asks for something leaner, item five asks for more information.
• Adding comments privately after the fact: after sign-off, “actually the owner has some thoughts too.”

How to agree on sign-off and revision rounds

The most common reason design review drags on is that nobody has said clearly when something counts as signed off.

Sign-off should be an explicit act: the designated decision-maker confirms a specific version of a stage’s work in writing, by email or a comment in the project tool, and any change after that is a change request. It looks like a formality, but it prevents someone from producing an old version halfway through development and saying “I remember it being like this.”

Agree on the number of revision rounds in the contract or at project kickoff. A common arrangement is a fixed number of rounds per stage, with each round’s feedback submitted all at once. A “round” means one complete feedback document, not every individual comment raised piecemeal. Going beyond the agreed rounds, or overturning a stage already signed off, goes through the change process to assess schedule and scope. For what to agree at kickoff, see the Client Checklist Before a Software Project Kicks Off.

Why limit rounds? Not to stop the client from making changes, but to force decisions. What happens in practice is that without a limit, people fall into the habit of giving some feedback now and thinking about the rest later. Each round only settles part of the problem, and the total number of rounds ends up higher than if everyone had thought it through once.

A self-check before sign-off:

• Are all pages and all roles’ screens in the files?
• Are empty, error, and loading states designed?
• Have both the mobile and desktop versions been checked?
• Has everyone who needs to approve seen it? Is anyone’s input still missing?
• Has every item from the last round been addressed or explicitly declined?
• Does the layout fit the final copy and images at their real length?

Five common mistakes clients make in design review

1. Reviewing out of stage. Looking at color during wireframes and discovering flow problems during visual mockups. The result is that sign-off on the earlier stage loses its meaning.

2. Looking at single pages, not the flow. Each page looks good on its own, but strung together the flow breaks. Every review should walk through at least one complete task.

3. Substituting your own preferences for the user’s. The color scheme or layout a decision-maker likes is not necessarily the easiest for the target audience to use. When in doubt, have a few real users try it; that settles more than a debate in the meeting room.

4. The decision-maker is absent. The intermediate contact approves three rounds, then the owner takes one look at the end and throws it all out. The person with real decision-making authority needs to take part at least at the wireframe stage and at final sign-off.

5. Treating the design as the functional specification. Design shows screens, but a lot of behavior cannot be drawn: sorting rules, permission logic, when notifications go out. Those have to be written into the specification in words, otherwise both sides interpret them their own way and the dispute only appears at acceptance.

When design review is done well, development, testing, and acceptance all go more smoothly. When it is done carelessly, the cost travels all the way to the days before launch. If you have a set of designs and are not sure where to start, or you want to plan review checkpoints and sign-off at the start of a project, talk to NETVANA. All of our software services are quoted after a consultation, and we first set wireframe, visual mockup, and prototype review checkpoints according to the size of the project. You can see the scope and deliverables of each service in the software services overview.

Further reading: Requirements need to be clear before design starts, so see How to Write Software Requirements. For what to agree with a vendor before work begins, see the Client Checklist Before a Software Project Kicks Off. For how a redesign should connect with the old site, read the Website Redesign Project Guide. To validate an idea with a prototype first, see the MVP Development Guide. And for how to accept the finished work, see How Software Acceptance Works. If it is unclear who should receive your design feedback, see Software Project Team Roles Explained.