Advice on the design approval process fixes who approves, in what order, and by when. The failure it does not prevent arrives weeks later, on the staging site, when the client remembers approving one header and the producer built another, and nobody can produce the version the yes was given against. An approval that names no version approves nothing.
The email chain holds everything except the artefact
An agency’s approvals arrive in pieces. A PDF export goes out in one email. A reply says the header needs work. A screenshot comes back from a phone with an arrow drawn on it. The change is agreed on a call. A one-line reply says approved, go ahead. Every piece is genuine, and the last one quotes none of the others, so the word approved points at whatever the person reading it later imagines it points at.
Lay the chain against the questions a producer has to answer when the dispute arrives, and the shape is plain.
| What the producer has to answer later | Where the answer lives in the chain | What survives |
|---|---|---|
| Which version the client was looking at | The attachment on an email several replies up | A filename, if the version was in it |
| Which state of the file the live link showed them | The design tool’s history, if anybody checks it | Whatever the file shows today |
| Where the arrow on the screenshot pointed | A crop taken on a phone | The arrow, cut away from the rest of the page |
| Whether the change went in before the yes | The call | Nothing in writing |
| What the header meant in that reply | Nobody’s memory in particular | A guess |
The fourth row is the one a dispute turns on. A yes given on a call, after a change was agreed on the same call, is an approval of a design nobody has yet seen. The producer heard it as approval of the revised design; the client remembers approving the one on screen, with the change promised. Both are right, and there is no artefact either of them can hold up.
A live link approves a moving target
The fix most teams reach for is to stop sending exports and send a link to the design file instead, so that everybody looks at the same thing. That solves the wrong problem. A link to a design tool resolves to the current state of the file at the moment it is opened. An approval given against it on Tuesday attaches to whatever the file shows on Friday, after a designer has started the next round in the same file. The client approved a thing that has since been edited, and the link does not say which state they saw, because the link was the record.
An approval is a pointer, and it has to point at something that will not move. In practice that means the artefact that goes out for sign-off is frozen: an export with a version identifier in its name, or a named version inside the tool, and nothing in that version changes after it is sent. Working sessions can run on the live file all week. Sign-off happens against the frozen copy, and the frozen copy is what the build is made from.
The rule is short enough to put in a contract. Nothing is approved that can still change without acquiring a new version identifier, and the version identifier is what the written yes quotes.
Who can say yes, and who can only comment
A round of review collects comments from more people than are entitled to approve. That is normal, and it is also the source of the approval that turns out to have come from the wrong person. A marketing manager who writes looks great in the thread is offering an opinion. If the producer files it as the approval, the client’s director has grounds to reopen everything later, and will.
| Role on the client side | What they may do in a round | What their reply counts as |
|---|---|---|
| The named approver | Approve, reject, or approve with listed changes | The approval, once written against a version |
| A stakeholder invited to comment | Comment before the round closes | Input the approver weighs, never the yes |
| A stakeholder who replies after the close | Comment on the next round | A request, priced as the next round |
| Somebody copied in for visibility | Read | Nothing |
The first row asks the agency to do something before any design goes out: get the client to name one person, in writing, whose yes closes a round. Where the client cannot name one, the process has no approver, and the producer should say so before the first round rather than find out at the third.
The yes belongs on the thing itself
A screenshot with an arrow on it is a comment that has lost its address. The producer cannot tell which page it came from, at which viewport, or against which version, and a client asked those questions a week later cannot answer them either. The same comment made on the page, pinned to the element it is about, carries its address with it.
That is what visual feedback tooling exists for. In Notarus, a client walking the staging build in a review session files each comment against the element they are looking at, and the note keeps that element, the page path and the viewport with it, so the arrow never has to be re-found on a cropped screenshot. The note then sits on the team’s board as a ticket, and the client portal shows the client how far each one has moved.
Pinned comments also settle the version question. Once every comment in a round is filed against a version and an element, the next version is defined by them: it is the frozen copy with those notes applied and nothing else changed, and the yes at the end of the round quotes its identifier rather than describing it.
A mockup approval expires at the build
A mockup and a built page are two different artefacts, and the client’s yes covers only the first. The build is rendered by a browser, at viewports the mockup never had, with real content in place of the content the designer chose. Type wraps differently. An image that filled a fixed frame is cropped by a responsive one. A button that was a rectangle in the file becomes whatever the front-end framework’s button is. None of that is a deviation anybody decided on, and all of it is visible to the client on launch day.
So there are two approvals, and the second cannot be delegated to the client. Design QA is the check that the build matches the frozen version the client approved, and it has to be done by somebody with both in front of them. The client sees only the build, and a client shown the build without that check will approve it, or dispute it, against their memory of the mockup. Neither outcome is the record the producer needs.
The design approval closes a round; it does not close the job, and the schedule has to hold the difference. Between that yes and the client’s first look at the staging site there is a check the agency owns, against a version the agency froze, and a launch date that leaves no room for it leaves the dispute for afterwards.
