Website design brief Dubai: stop comparing guesses

Three agencies receive the same request from a Dubai consultancy: ten-page website, modern look, a few competitor references attached. One prices a straightforward English brochure site. Another allows for bilingual templates and CRM-connected forms. The third assumes content migration, approval rounds and a launch deadline tied to a new office opening.

Abstract website briefing sheet with Dubai skyline and proposal folders

All three may be acting reasonably. They have simply been asked to price three different versions of the job.

A useful website design brief does not need to prescribe colours, layouts or the exact number of rounded corners. It needs to explain the commercial job, who the site is for, what those people must be able to do, and the operational limits around delivery. That is enough to make proposals more comparable without producing a forty-page specification.

If you are still deciding what the finished project could involve, our website design service for Dubai businesses gives useful context on the wider delivery route. The brief is what lets a supplier work out which parts of that route apply to you.

Start with the business decision, not the homepage

Write one or two plain sentences about why the website is being commissioned now. A consultancy may need better-qualified discovery calls. A clinic may need patients to understand treatments and make contact with the right branch. A real estate business may need a credible way to present developments and route enquiries to the correct team.

Be specific about the priority. More traffic is not a website brief. Neither is make it look premium. Both may be fair ambitions, but neither tells anyone what must change.

  • What should the website help the business do?
  • What is the main action a suitable visitor should take?
  • What currently makes that action harder than it ought to be?
  • What must remain true about the brand, offer or approval process?

Name the people and the routes that matter

A site for everybody tends to make its own life difficult. List the priority visitor groups and what each needs to establish before acting. This is particularly useful where a Dubai business serves local UAE clients, regional buyers and overseas decision-makers with different questions and expectations.

For each priority group, outline a simple route: how they arrive, what they need to understand, what proof they need, and the next action. A route might begin on a Google service page, move through a case study, then end at a CRM form. Another may start with a referral checking whether the business covers a particular sector.

Do not confuse a page list with a journey map. A page can exist without doing much useful work.

Put content and functionality on separate lines

Content responsibility is one of the quieter ways a project drifts. State whether copy, photography, case studies, team biographies, legal text and translated material already exist, will be supplied, or need creating. If old content is moving from another website, say roughly what is being migrated and who decides what gets left behind.

Functionality needs similar treatment. A contact form is not merely a box with a submit button. The supplier may need to know which inbox receives it, whether a CRM should create a lead, whether consent wording is approved, who owns the spam settings, and whether the success message confirms submission only or actual email delivery. An old shared inbox and a cached form can cause grief long after launch if nobody owns them.

For a clearer distinction between visual work and build responsibilities, read how website design and development responsibilities differ in Dubai. It is worth sorting before a design is approved and an integration appears late in the day.

The one-page website brief framework

Keep the required decisions separate from inspiration. References are useful for showing a preferred tone, structure or level of restraint. They are not requirements unless you explain what you want to borrow and why.

Brief area Required decision Optional inspiration
Commercial goal Business objective and primary enquiry action Examples of websites with a suitable level of polish
Priority users Main audiences, locations and decision stage Preferred tone or visual character
User journeys Routes from entry page to enquiry, booking or call Useful page patterns you have seen elsewhere
Content What exists, who writes it, what must migrate Photography, illustration or video references
Functionality CRM, forms, booking, payments, languages and analytics needs Examples of interactions you like
Constraints Launch date, legal review, hosting, access and approval limits Nice-to-have ideas for a later phase
Ownership Decision-makers, technical contacts and final approver Internal preferences that are not fixed requirements

Make launch constraints visible early

Projects do not usually become awkward because somebody forgot a decorative icon. They become awkward because a bilingual version was assumed rather than named, the CRM owner was not involved, or four directors each expected final approval.

Include the practical constraints: required languages, existing domain and hosting access, planned campaign dates, compliance review, internal sign-off, training needs and any dependency on another supplier. If the site must launch alongside a trade event, new service, office move or paid campaign, say so. It may affect content sequencing, testing and what belongs in the first release.

Use the brief to compare the proposals properly

Once the same concise brief goes to each supplier, compare what they have included against it. Look for assumptions around templates, content entry, mobile behaviour, form delivery, integrations, testing, migration, training and launch support. A lower proposal may still suit the job, but only if it is pricing the same job.

For a close look at why equal page counts can conceal different workloads, see what ten pages can actually mean in a Dubai website scope. It is a useful check before treating a neat-looking total as a like-for-like quote.

What should a website design brief include?

Include the business goal, priority audiences, required visitor actions, essential content, technical requirements, languages, integrations, known constraints, decision-makers and launch conditions. Add reference sites as supporting material, but explain what each reference demonstrates. A concise brief should define the problem and constraints without trying to design the answer in advance.

How detailed should the brief be before requesting a quote?

Detailed enough that every supplier can identify the same core deliverables and risks. You do not need final copy, finished photography or every page wireframed. You do need to state what is known, what remains undecided, who will make decisions and what cannot be missed. Unknowns can be priced as discovery work rather than quietly guessed at.

Write the brief before comparing prices so each proposal is answering the same job. If you have a rough version already, Standish Services can help turn it into a workable website delivery plan.