What does it mean to proof a design?

Proofing a design means checking the work for errors — copy accuracy, colour values, image resolution, layout consistency — before sharing it with a client for approval. A proof is the version you send for review; proofing is the process of checking it yourself first. The goal is that the client's feedback is about the design direction, not about typos and broken links you should have caught.

What should I check when proofing a graphic design?

Work through four areas: text accuracy (read every word, including phone numbers, URLs, and legal lines), colour correctness (check hex or CMYK values against the brand spec, not by eye), resolution and format (photos at correct DPI for the output, black text as 100K for print), and mobile or output render (view the file at the actual display size your client will use). Checking in this order catches the most common revision triggers before the client sees the work.

How do I get a client to approve a design proof?

Share the proof as a link the client annotates directly, not a flat file. Ask two specific questions alongside it — 'Does this headline clearly communicate the offer?' and 'Are the brand colours correct here?' — because specific questions get specific answers. Ask for an explicit written approval comment, not just a thumbs-up emoji. Vague approval leads to 'I thought I was approving a different version' disputes after delivery.

How many rounds of proof should a design take?

One or two rounds is realistic when you run your own proof pass before the client sees the work, and when the client annotates directly on the design rather than describing feedback in email. Email-based feedback typically takes three or four rounds — one round locating what they meant, one making the change, one confirming it. Proofing thoroughly yourself and sharing an annotatable link eliminates the first round almost entirely.

What is the difference between a design proof and a final file?

A proof is a review version — usually a PDF, PNG, or preview link — shared for feedback and approval. A final file is the production-ready source that goes to the printer, developer, or client for use. The proof might be a lower-resolution export or a live preview; the final file is the full-quality, print-ready or export-ready source. Never send the final editable source file as the proof — clients sometimes use it before you've made their requested changes.

How do I avoid vague design feedback like 'it just needs something'?

Vague feedback comes from clients who can't point at what they mean. When the channel is email, they describe — and descriptions are imprecise. Two things help: share the proof as a link they can annotate (clicking the exact element produces pinned, specific notes instead of a paragraph about 'the top area'), and ask two or three direct questions with the proof ('Does the headline match what you told me the audience needs to hear?'). The combination of a specific question and a way to answer by pointing rather than describing cuts vague feedback significantly.

drafty

How to proof a design before sending it to a client

Quick answer

To proof a design, run a quick self-check first — spot colours, copy accuracy, mobile render at 390px — then share a link the client can annotate in their browser rather than emailing a flat file. Giving them a way to click the exact element and pin a note removes the 'which bit near the top?' round before it starts, and keeps every revision in one place.

Step 1

Check the copy and numbers yourself first

Most designers proof the visual — and miss the text. Before the client sees the file, read every word as if it's new to you: headlines, body copy, call-to-action labels, legal lines, phone numbers, URLs, and QR codes. Read each word out loud or cover it with your finger and uncover one word at a time — your brain autocorrects familiar text when you skim. Check numbers twice: a price with a missing zero or a date formatted wrong will come back as a revision, and that's a credibility hit. If the brief had a specific tagline or legal disclaimer, compare your file against the original brief word-for-word, not from memory.

Step 2

Verify colours against the brand spec

Open the brand guide or colour spec and check each swatch against what's in your file — not by eye, but by hex or CMYK value. A common failure mode: you duplicate a previous project's template, the old client's brand blue is still on one element, and neither you nor the client notices until the file is at the printer. In Figma, right-click a fill → Inspect to see the exact hex. In Illustrator, open the Swatches panel and select 'Show Find Field' to search by name. For print work, also confirm that any RGB-mode images have been converted to CMYK, and that black text is 100K (not rich black), otherwise fine body copy bleeds on press. This is the step most client revision rounds are actually about — catching it yourself first removes an entire loop.

Step 3

Render it at mobile size before they do

Your client will look at the proof on their phone — usually within the first minute of receiving it. If it's a web or app design, open the export or live preview in Chrome DevTools and set the viewport to 390px (iPhone 16). If it's a printed piece, open the PDF on your phone and check readability. The failures that show up most reliably at this step: hero text that wraps to four lines, a CTA button too small to tap, and imagery that crops unexpectedly at the aspect ratio the export uses. For social media designs, preview at actual pixel dimensions (1080×1080 for square, 1080×1920 for story) — Figma's canvas doesn't always match the platform's compression. Running the phone check yourself typically removes one client feedback round.

Step 4

Share a link they annotate directly — not a flat file

Once you're satisfied, how you share the proof determines how useful the feedback is. Email a PNG and the client will reply 'can you adjust the header area' — you'll spend the next message establishing which element they meant. Ask them to comment in Figma and they'll hit a login wall and often fall back to email anyway. The workflow that keeps revision rounds to one: share a link the client opens in their browser, clicks the exact element they want to flag, and leaves a threaded note pinned right there. 'Hero headline — too long for this audience' anchored to the headline is actionable on the first read. 'The bit near the top' costs you at least one round of clarification before you can make a change.

Step 5

Get explicit sign-off before you close the round

A 'looks good' reply in an email thread is not sign-off — you've probably re-experienced that when a client comes back after delivery saying they missed something. Document approval on the same link the proof lives on: ask the client to leave a comment confirming approval (something specific like 'approved to proceed'), or use a dedicated approved/rejected status if your review tool supports it. This creates a timestamped record. For print work especially, a written approval on the final proof protects you if the client later disputes that they signed off. It also creates a natural stopping point in the revision cycle — 'this round is approved' is clearer than a trail of increasingly positive emoji in an email thread.

The faster way

If your client is reviewing the proof — not just you — the fastest path is a link they can open in their browser and annotate without installing anything. Drop the design export (PNG, PDF, or live preview URL) into Drafty, share the link, and your client clicks the exact element and pins a threaded note right there. No Figma account, no downloaded file emailed back. Every note lands in one thread, you push the revised version to the same URL, and the client's approval comment stays on record.

Open a live demo

Questions

What does it mean to proof a design?: Proofing a design means checking the work for errors — copy accuracy, colour values, image resolution, layout consistency — before sharing it with a client for approval. A proof is the version you send for review; proofing is the process of checking it yourself first. The goal is that the client's feedback is about the design direction, not about typos and broken links you should have caught.
What should I check when proofing a graphic design?: Work through four areas: text accuracy (read every word, including phone numbers, URLs, and legal lines), colour correctness (check hex or CMYK values against the brand spec, not by eye), resolution and format (photos at correct DPI for the output, black text as 100K for print), and mobile or output render (view the file at the actual display size your client will use). Checking in this order catches the most common revision triggers before the client sees the work.
How do I get a client to approve a design proof?: Share the proof as a link the client annotates directly, not a flat file. Ask two specific questions alongside it — 'Does this headline clearly communicate the offer?' and 'Are the brand colours correct here?' — because specific questions get specific answers. Ask for an explicit written approval comment, not just a thumbs-up emoji. Vague approval leads to 'I thought I was approving a different version' disputes after delivery.
How many rounds of proof should a design take?: One or two rounds is realistic when you run your own proof pass before the client sees the work, and when the client annotates directly on the design rather than describing feedback in email. Email-based feedback typically takes three or four rounds — one round locating what they meant, one making the change, one confirming it. Proofing thoroughly yourself and sharing an annotatable link eliminates the first round almost entirely.
What is the difference between a design proof and a final file?: A proof is a review version — usually a PDF, PNG, or preview link — shared for feedback and approval. A final file is the production-ready source that goes to the printer, developer, or client for use. The proof might be a lower-resolution export or a live preview; the final file is the full-quality, print-ready or export-ready source. Never send the final editable source file as the proof — clients sometimes use it before you've made their requested changes.
How do I avoid vague design feedback like 'it just needs something'?: Vague feedback comes from clients who can't point at what they mean. When the channel is email, they describe — and descriptions are imprecise. Two things help: share the proof as a link they can annotate (clicking the exact element produces pinned, specific notes instead of a paragraph about 'the top area'), and ask two or three direct questions with the proof ('Does the headline match what you told me the audience needs to hear?'). The combination of a specific question and a way to answer by pointing rather than describing cuts vague feedback significantly.

Keep exploring

How to review a design Design feedback tool How to annotate a design

Stop emailing files back and forth.

Share one link. They comment on the exact spot — no account, always the current version.

Open a live demo