How to review a mockup before it reaches the client
To review a mockup, work through it in four passes: visual hierarchy (does the eye know where to go first?), consistency (same fonts, colours, spacing throughout), interactive states (buttons, inputs, and links all documented), and mobile render at 390px. Do your own pass first, then share a link the client can annotate directly — so feedback lands on the exact element, not in a vague email thread.
Run the five-second hierarchy test
Cover the mockup with your hand, remove it, and count to five. What did your eye land on first? A mockup passes this test when the primary action or message is obvious within that window — a visitor who has never seen the product shouldn't need to scan the whole screen to understand what it's for. The most common failure: the hero image is large and decorative, but the headline is the same visual weight as the body copy below it. Adjusting scale, contrast, or spacing between the headline and the next element usually fixes it in one pass. Run the test again after the change — your eye adapts to what you built, so a second opinion (a colleague who hasn't seen it) is worth more than your own second look.
Check consistency: colours, typography, and spacing
Designers who work in Figma often catch this before export — but in a handoff or a live preview, inconsistencies reappear. Go through the mockup and check three things: first, that every button colour matches the defined primary or secondary (one rogue hex is enough to look unfinished); second, that heading levels are visually distinct (if H2 and H3 read at the same weight, clients will call the whole page 'confusing' without being able to say why); third, that margin and padding follow a consistent scale. A 24px gap between sections and a 20px gap elsewhere is the kind of thing that reads as sloppy to a trained eye. Run a quick spot-check on at least three sections before you share — one consistent page is worth more than three 'mostly consistent' ones.
Document every interactive state
A mockup that shows only the default state is half a design. Before sharing for feedback, check that buttons have a documented hover and disabled state, that form inputs have a focus ring and an error variant, and that any link has a clear affordance (underline, colour shift, or both). Clients won't notice missing states until development — then they become revision requests that feel like scope creep but are actually documentation gaps. A quick note beside each interactive element ('hover: brand-tinted background, 200ms') takes two minutes per component and saves an entire revision round. If you're working in Figma, the component variants panel is the right place; if you're sharing a live preview, add a sticky note layer or a comment before the client sees it.
Share a link for annotated client feedback
Once you've done the self-review, the worst thing you can do is email the mockup as an attachment and ask 'what do you think?' Clients sent a flat image respond with 15 emails in separate threads, or a voice note that says 'the bit near the logo, I think it needs more space?' Share a link they can annotate directly. They click the element they mean — the headline, the button, the hero image — and pin a note to the exact spot. You see the feedback in a thread, anchored to what they meant, not transcribed from a call you had to take because the email was too vague to action. The difference in revision rounds is real: element-anchored feedback typically cuts the back-and-forth in half, because 'the headline feels too small on mobile' and 'I mean this element, here' are the same note — one just skips a round of clarification.
If you're sharing a Figma export, a live staging URL, or an image of your mockup — paste it into Drafty and send the client the link. They click the element they want to comment on and pin a note right there. No account, no screenshot, no email thread. Every note lands in one place, anchored to the spot they meant. When you push a revised version, the same link shows the update — you don't send a new file.
Open a live demoQuestions
- What should I look for when reviewing a mockup?
- Work through it in four passes: visual hierarchy (does the primary action register in five seconds?), consistency (same colour tokens, type scale, and spacing increments throughout), interactive states (every button, input, and link documented with hover and error variants), and mobile render at 390px. Doing your own pass before the client sees it removes the most predictable revision requests.
- How do I give useful feedback on a design mockup?
- Point at the exact element you mean and describe what you'd like it to do differently — not how you feel about it. 'The headline doesn't tell me what this product is for' is actionable. 'This doesn't pop' isn't. Annotating directly on the mockup (rather than writing a feedback email) forces specificity, because you have to click the thing you mean before you can leave a note.
- How do I share a mockup for client feedback?
- Share a link rather than a file. A file gets re-saved, renamed, and emailed back with handwritten arrows on a screenshot. A link the client can annotate directly — clicking the element and typing a note — keeps every comment attached to the exact spot they meant. It also means you're both looking at the same version, not a downloaded copy from three days ago.
- How many rounds of feedback should a mockup take?
- One or two rounds is normal when feedback is element-anchored and specific. Three or more usually means one of two things: the client is seeing the design for the first time without any self-review pass from the designer, or feedback is scattered (email + Slack + call notes) and things are getting lost between rounds. A single annotated link per round fixes the second problem. A designer self-review before the first share reduces the first.
- What's the difference between a wireframe and a mockup review?
- A wireframe review focuses on structure and flow — is the right content in the right place, does the navigation make sense? A mockup review adds visual execution to that: are the colours and type consistent, does the hierarchy read correctly, do the interactive states look intentional? The questions shift from 'what goes here?' to 'does this communicate what we meant?'
- Should the designer review the mockup before sending it to the client?
- Yes — and it saves time. A five-minute self-review catches the consistency issues (rogue hex, wrong font weight, missing hover state) that clients notice but can't name precisely, which generates vague feedback that takes two rounds to resolve. Sending a cleaner first pass means the client's feedback lands on real design decisions, not fixable oversights.
Keep exploring
Stop emailing files back and forth.
Share one link. They comment on the exact spot — no account, always the current version.