Website design scope Dubai: ten pages, different jobs
Two Dubai website proposals can both say ten pages and still describe materially different jobs. One may include a proper sitemap, responsive templates, content migration and launch testing. The other may mean ten desktop visuals sent over as PDFs, with the awkward bits left for somebody else to sort.
That makes page count a poor way to compare website design services. It is useful for estimating scale, but it does not tell you what decisions have been made, what will be built, or who owns the work between approved design and a live website.
A useful website design scope in Dubai should identify the discovery work, page structure, reusable templates, mobile behaviour, content responsibilities, development handoff, quality assurance and launch activities. Development, hosting, migration and ongoing support may be included or separate, but the proposal should state this plainly. A page count alone is not enough to compare two website projects fairly.
Start by asking what ten pages actually means
Take a typical service business. It needs a homepage, several service pages, an about page, contact page, case studies and perhaps a resources area. Both suppliers may call that ten pages.
One supplier might design every page as a separate one-off layout. Another might create three reusable templates: a service template, an insight template and a standard information page. The second approach can be more useful because it gives the business a consistent system for future pages, rather than ten isolated designs that only work while nobody touches them.
There is also a difference between a designed page and a built page. If you need a working WordPress site, forms, editable content modules and a sensible editor setup, the proposal needs to show where website development in Dubai begins. Otherwise, the build may appear later as an extra line item, usually after the design has been approved and the budget has already developed a limp.
The website design scope checklist
Use this table when comparing proposals. It separates design decisions from build and launch work, which is where apparently similar quotes often stop being similar.
| Scope area | What a useful proposal should clarify | Common gap to spot |
|---|---|---|
| Discovery | Business goals, audiences, priority services, enquiry routes, competitor context and existing website issues. | A visual direction is chosen before anyone has agreed what the website needs to explain. |
| Structure | Sitemap, page priorities, navigation, calls to action and the relationship between services, proof and contact routes. | Ten pages are listed without explaining what each page is for. |
| Templates | Which layouts are reusable and which pages need a genuinely bespoke treatment. | Every page is treated as a separate design, making later additions inconsistent or costly. |
| Responsive states | How key templates behave on mobile and tablet, including menus, forms, grids, buttons and image crops. | Desktop-only mock-ups are assumed to cover mobile. |
| Content | Who writes, edits, approves, uploads and checks copy, images, case studies, FAQs and legal pages. | Content migration is quietly assumed to be somebody else’s job. |
| Development handoff | Files, components, interaction notes, image guidance and what the developer is expected to build. | A polished visual is supplied with no instructions for the parts that move, collapse or change. |
| Migration | Whether existing pages, media, redirects, forms, SEO fields and document downloads are moved across. | Old URLs and files are left behind until search traffic or a referral finds a dead page. |
| QA and launch | Browser checks, device checks, form testing, redirects, analytics, backups and launch ownership. | A site goes live because it looks right on one office screen. |
1. Put discovery in the scope before visual work
Discovery does not need to become a month of workshops and Post-it theatre. It does need to establish what the business sells, who needs convincing, what evidence matters and what action a visitor should take.
For a Dubai property consultancy, that may mean separating investor services from landlord services, making licensing and local knowledge easy to find, and deciding whether the primary enquiry route is a form, phone call or WhatsApp. Without those decisions, a designer can make something tidy but still place the wrong message in front of the wrong visitor.
A broader website design service for Dubai businesses should make this relationship between structure, messaging and enquiries clear. The visual layer matters, obviously. It just cannot carry the whole job on its own.
2. Check the templates, not only the page list
Ask which page types are being designed. A service page usually needs a different hierarchy from an about page, a case study or a contact page. If the proposal says ten pages, ask whether it includes ten unique page designs, a set of templates, or a mix of both.
This affects consistency, future editing and development time. It also affects content. A reusable service template can make it easier for an internal team to add a new service without inventing the page structure from scratch every time.
3. Make mobile behaviour a named deliverable
Mobile is not desktop with less room. Navigation changes, side-by-side blocks stack, oversized headings wrap badly, image crops become unhelpful and a neat two-column contact section can turn into a long scroll with the phone number buried at the bottom.
Ask to see responsive states for the important templates. At minimum, that should cover the homepage, service page, contact route, navigation and forms. A mobile layout does not need a separate design file for every screen size, but the intended behaviour should not be left to guesswork.
4. Get content responsibility written down
Content is one of the most frequent scope gaps. A proposal may include content population, content migration, copy editing, copywriting, image sourcing, image optimisation, or none of them. Those are different jobs.
There is a dull but important operational detail here: moving old copy is not simply pasting words into new boxes. Old sites often contain PDFs linked from forgotten pages, images with unhelpful filenames, contact forms sending to a departed employee’s inbox, and service pages with no current owner. If migration is included, clarify what material is being moved and who signs it off.
5. Separate design approval from development handoff
Design approval should not mean a developer receives a nice-looking file and is expected to infer every practical decision. The handoff needs to cover components, states, spacing rules, form behaviour, interactions, image treatment and editable areas.
For example, a testimonial carousel may look straightforward in a desktop concept. The build still needs decisions about how many slides appear on a phone, whether it auto-rotates, whether it can be edited in WordPress, and what happens when a client supplies a very long testimonial. That is not design fussiness. It is the difference between a component that survives normal business use and one that becomes a small nuisance every time somebody updates it.
6. Treat migration, QA and launch as their own workstream
A new website can look finished on a staging address while the launch work remains undone. Redirects, DNS changes, forms, analytics, cookie settings, old URLs, downloadable files and backups all need an owner.
QA should include practical checks on key browsers and devices, but also real journeys. Submit a contact form and confirm the email arrives in the right inbox. Check the success message, but do not mistake it for proof of delivery. Test phone links, WhatsApp links, maps, downloads and key enquiry routes before launch.
If a proposal says launch support is excluded, that is not automatically a problem. It simply needs a named person and a proper handover plan. Comparing website costs beyond the number of pages can help when the cheaper quote has pushed these items outside the first figure.
A cleaner way to compare the proposals
Put both proposals against the checklist and mark each item as included, excluded, assumed, or requiring a separate quote. Do this before choosing based on page count, visual style or the first number at the bottom.
- Ask for the sitemap and template list.
- Ask which responsive views will be reviewed.
- Ask who owns copy, images and migration.
- Ask what the developer receives after design approval.
- Ask what is tested before launch and who fixes issues found in QA.
- Ask what happens after launch if a form, redirect or layout needs attention.
The best proposal is not necessarily the longest one. It is the one where you can see the boundaries without needing a follow-up call to decode them.
Does website design normally include development?
Sometimes, but not always. A design-and-build project may include strategy, design, WordPress development, content population, testing and launch under one scope. A design-only engagement may provide layouts and handoff material for an internal developer or another supplier. Either route can work, provided the handoff, build responsibility and launch tasks are explicit before design begins.