What to prepare before commissioning a website

You do not need every answer before commissioning a website. You do need to distinguish what is known from what still needs a decision. A useful brief makes that boundary visible before a misunderstanding reaches the handoff. ## Start with the task the site must support Choose the main action: understanding a service, sending an enquiry, booking or buying. Then explain what the visitor needs to know before taking it. Different audiences may need different routes; a new customer looking for services and an existing customer seeking support do not necessarily need the same opening message. For a hypothetical architecture studio, the site might help visitors understand project types, the working process and how to enquire. That gives the team something more specific to discuss than a request for a modern-looking website.

## Build the page list around real content List the necessary services, projects, company information and contact pages. Include one realistic example of the text, images and information for each page type. Assign an owner and delivery date to missing material. For a multilingual site, agree which pages need translations and who approves them. Decide how incomplete editions will behave. English text inside a Persian page does not complete the translation. Reading direction and different text lengths need to be tested in the layout. ## Record important journeys and error states Describe how a visitor reaches the main action. For forms, specify essential fields, validation, success feedback and where the request goes. A polished form without reliable receipt and follow-up is not a complete enquiry route. Include loading, empty, no-result and connection-failure states in the scope. The [W3C forms tutorial](https://www.w3.org/WAI/tutorials/forms/) is a practical reference for labels, instructions and feedback.

## Include accessibility in the brief [WebAIM's February 2026 evaluation](https://webaim.org/projects/million/) examined one million popular home pages with WAVE. The chart shows three commonly detected failures. It supports making accessibility a testable requirement; it does not establish a reason to make a site unnecessarily complex. A means low contrast, B means missing alternative text, and C means missing form labels. Categories overlap. Automated checks cannot find every barrier and do not establish full WCAG conformance. This sample is not an assessment of your website.

## Separate design, development and content responsibilities The proposal should describe the design deliverables and who implements them. Do not assume copywriting, translation, licensed images, payment integrations and content migration are included in design. If implementation is included, define its scope and the owner of ongoing maintenance. List necessary access, but keep passwords out of the brief. Use an appropriate secure handoff and account permissions. A designer does not always need full administrative access to understand the problem. ## Name the deadline and decision-maker Separate the launch date from the design handoff. Allow time for implementation, content entry and verification. Late material or approvals can change the schedule; record those dependencies early. Ask one person to consolidate feedback. Conflicting comments without a clear decision use time without resolving the design. Tie approval to the site’s purpose and the visitor's task. ## Your one-page brief Record the main goal, audience, required page types, a realistic content sample, contact or purchase flow, languages, technical constraints, scope, dates and approval owner. Mark unresolved items as decisions to make. This information makes a [website design](/services/website-design) estimate more useful. For one offer and one action, a [landing page](/services/landing-page-design) may be a better starting point. Choose the scope from the need, rather than the number of pages available to build.

• website design brief
• website planning
• website content