Sign-off is not a vote on whether a design looks good. It is when the design becomes the plan developers will build, so approve it like a plan: check structure, put real content in it, view the phone version, walk the enquiry path as a stranger would, and confirm trust and readability basics. Run those five checks before signing, and most changes businesses pay for later never become changes at all.
The short answer: sign-off approves structure, content fit and the enquiry path — not just the look (checklist summary)
- Structure: page list complete, navigation names match how customers think, one job per page.
- Real content: your actual headlines, service lists and longest page — and the Arabic version, if you will have one.
- Mobile: the phone layout approved, not only the desktop screen.
- Enquiry path: call, WhatsApp, form or booking reachable in one or two taps from every key design.
- Trust and accessibility: proof present, contrast readable, tap targets comfortable, headings in sensible order.
- Process: one named approver, one consolidated feedback response, revision rounds agreed.
If any line fails, do not reject the design — fix it now, while fixing means moving boxes, not rebuilding finished pages. This gate sits inside the wider website development process.
The problem: approving a picture, then paying to change a website
Most approvals happen in a meeting, on a large screen, homepage enlarged, everyone reacting to colours and photography. The design looks polished because it is a picture of a website, not yet a website. Placeholder headlines are short, the service list shows three tidy items, and nobody opens the phone version or asks where the enquiry button sits.
The misses surface in development, when the real headline is twice as long, the twelfth service breaks the grid, and the mobile menu buries the phone number. Each returns as a change — slower in code than in mock-up.
What sign-off actually commits you to — and what it does not
Approving a design commits you to its structure, layouts, content placement and visual direction: this page list, this navigation, this arrangement, this style. Development proceeds on it.
It does not approve what a mock-up cannot show: working forms, integrations or performance. Those are proven at build and testing — the post-build counterpart is the website visual QA checklist, and launch ownership sits in the website handover ownership checklist. Do not treat design approval as acceptance of the whole website, or withhold it for proof a picture cannot give.
Check 1 — Structure: page list, navigation and one job per page (link to the navigation guide)
Start with the page list, not the homepage. Every designed page should match the agreed scope; every scoped page should appear — a missing design now becomes a negotiation later. Then read navigation labels as a customer: would a stranger know which label holds pricing, booking or your main service? Labels named after internal departments fail this test.
Give each key page one job. A homepage that must introduce the company, sell six services, recruit staff and collect enquiries does none clearly. If a page's job cannot be said in one sentence, settle it before sign-off. Menu structure in depth belongs to our guide to website navigation for service businesses.
Check 2 — Real content in the mock-up: your headlines, your service lists, your longest page — and the Arabic version if you will have one
Ask for your real words in the design, homepage and one inner page at least. Real headlines run longer, service lists are uneven, and a real testimonial has a name, a company and three lines. A layout that only works with tidy dummy content will break on contact with yours — better now than later.
Check the extremes: longest headline, longest page, fullest list. If the design absorbs those, ordinary pages fit. If the site will have an Arabic version, see one key page in Arabic, right to left, before approving the English one — a design approved in one direction can need real rework in the other.
Check 3 — Mobile first: approve the phone version, not only the desktop one
Ask for the phone designs, on an actual phone — not shrunk on a meeting-room screen. Most visitors will meet this version, yet clients rarely see it first. Check content order still works in one column and nothing essential was dropped to fit.
If mobile layouts do not exist yet, that is the strongest reason to pause: approving desktop alone means the version most customers use is designed later, without your input.
Check 4 — The enquiry path: can a stranger reach call, WhatsApp, form or booking in one or two taps from every design?
Play a stranger: from each key design, count taps to enquire. Call, WhatsApp, form or booking should be reachable in one or two, visible without hunting, on mobile as well as desktop. A page that hides its contact route is a brochure, not a sales tool.
Also check the wording beside the button, what the form asks, and the thank-you state after submitting — approving pages without it leaves the most reassuring screen undesigned.
Check 5 — Trust and accessibility basics you can see: proof, readable contrast, tap sizes, heading order
You are not running an accessibility audit — you are checking what is visible. Trust first: does the design carry real proof — named testimonials, credentials, genuine contact details, an address where relevant — where a cautious visitor looks, or generic claims? This is the standard our UI/UX design team in Dubai designs to, and any agency welcomes it.
Then readability, using the published WCAG criteria at client level. Contrast: WCAG Level AA requires text contrast of at least 4.5 to 1, and at least 3 to 1 for large text — pale grey body copy on white is the failure you will actually see, so ask the designer to confirm main text and button colours meet those ratios. Meaning-carrying buttons, icons and form outlines should also stand out clearly. Tap sizes: WCAG 2.2 sets a minimum target of 24 by 24 CSS pixels at Level AA, and comfortable design sits well above it — treat anything fiddly as a question. Heading order: headings should descend logically: that order becomes the structure screen readers and search engines read.
Who approves, and how: one named approver, consolidated feedback, agreed revision rounds
Name one approver — a person, not a department. Others comment, but feedback reaches the agency as one consolidated response, disagreements settled on your side. Five people sending separate, conflicting comments means nobody can later say what was approved.
Agree revision rounds in writing before you sign: how many, what a round means, how feedback is delivered. There is no universal number — what matters is that both exist in the agreement. Record the approval: version, date, approver.
After you sign: what counts as a change request (and where that process lives)
After sign-off, the approved design is the baseline. Requests that move away from it — a restructured page, a new section, a different direction — are change requests, not revisions, handled through the project's change process, cost and schedule effects assessed first. That process, and how small changes accumulate, is owned by our guide to scope creep and change requests; this gate ensures you sign knowing the baseline is real.
Common mistakes (approving from a screenshot; approving placeholder text; five approvers, no tiebreaker)
Approving from a single screenshot. Approving placeholder text. Approving desktop while mobile is undesigned. Several approvers, no tiebreaker. Signing in the meeting, then reviewing afterwards, when every finding costs more. A slower signature, after the five checks, is the fastest route through the project — and the discipline a good web design company in Dubai expects too.
FAQ
What does design sign-off actually commit me to?
It commits you to the approved structure, layouts, content placement and visual direction — what developers build from. It does not accept what a mock-up cannot show, such as working forms, integrations or performance; those are proven later.
Should I approve the mobile design or just the desktop one?
Both — mobile deserves at least as much attention, because most visitors will use it. Review phone layouts on an actual phone. If mobile designs do not exist yet, pause: approving desktop alone means the most-used version is decided later without you.
How many revision rounds are normal before sign-off?
There is no universal number. Your agreement should state how many rounds are included, what counts as a round, and how feedback is delivered — with one named approver consolidating comments into a single response. Agree it before you sign.
Can I change the design after I have signed it off?
Yes, but a post-sign-off change to structure, layout or direction is normally a change request: its cost and schedule effect is assessed and agreed before work begins. Settle cosmetic preferences in the revision rounds — that is what they are for.
What if the mock-up still has placeholder text?
Ask for real content first — real headlines, service lists and your longest page, plus one Arabic page if the site will have an Arabic version. Layouts built around short dummy text often break with real wording, and the design stage is the cheap place to discover it.
Design in front of you and not sure it is ready? Get a second opinion before you sign
If your five checks raise questions your agency cannot resolve — no mobile version, a structure nobody can explain, a rushed approval — get it reviewed independently before the signature makes it a baseline. WebStackRank's web development consulting service covers exactly this: bring the mock-ups, page list and agreement, and we will tell you plainly whether the design is ready to build.
