Business Website Design Brief: 12 Requirements to Define Before Pricing

A brief is not the sentence ‘make us a beautiful website’

A website design brief gives the business and its delivery partner a shared understanding of who the site serves, what it must enable and which evidence will be used to judge the outcome. It does not need to be dozens of pages long. It needs enough clarity for a supplier to define scope, expose missing assumptions and identify decisions that must be made before pricing.

Vietnamese customer-experience reporting in 2025 points to the same priority: people value experiences that are fast, accurate and transparent, while organisations can over-invest in channels and personalisation before fixing basic needs. For a website, the brief should therefore state what visitors need to find, verify and complete before it discusses visual effects.

Nominate one project owner before requesting proposals. When every department sends a separate wish list, suppliers have to guess the order of importance and often add contingency to cover the uncertainty.

• ✓Project name, final decision maker and required reviewers.
• ✓Why the website is being commissioned now and what the current site fails to do.
• ✓The three most important business outcomes for the first 6–12 months.
• ✓Explicit exclusions so later requests are not assumed to be included.

A price is meaningful only when both sides are describing the same outcome. The brief turns an ambiguous wish into a scope that can be verified.

The first four requirements: outcomes, buyers, journeys and evidence

Write goals as observable customer behaviour: a qualified enquiry, a capability document download, a distributor lookup, a usable mobile catalogue or a successful language switch. Avoid a goal such as ‘increase awareness’ unless the brief explains which signals will demonstrate that awareness changed. In B2B work, enquiry volume alone is weak; measure qualified enquiries, response time and progression to a commercial conversation.

A buyer definition should go beyond age and job title. Capture the decision context, recurring sales questions, proof requirements, usual devices and other people involved in approval. A technical director, a procurement executive and an overseas partner may use the same website but require different routes through it.

List the evidence the company is allowed to publish: projects, certifications, production capability, process, original photography, verified data and approved client references. A visually polished site without verifiable evidence often makes due diligence slower rather than easier.

• ✓Requirement 1 — Outcomes: business results and measurement.
• ✓Requirement 2 — Buyers: context, questions and barriers before contact.
• ✓Requirement 3 — Journeys: entry points, priority tasks and next steps.
• ✓Requirement 4 — Evidence: case studies, data, certifications and approved material.

The next four requirements: sitemap, content, functionality and integrations

Do not build the sitemap from the organisation chart. Group pages around buyer questions and decisions. The first sitemap may change after discovery, but the brief should identify essential page types, launch languages and existing content that must be protected because it earns search traffic, links or supports sales conversations.

For content, name who supplies raw material, writes, translates, approves and clears image rights. This work is frequently absent from headline quotations. If a company provides a few old brochures but expects 30 polished bilingual pages, editorial research, verification and translation are a major project workstream.

Describe functions and integrations as operating scenarios rather than technology labels. ‘Connect the CRM’ is incomplete: which fields move, when they move, who can see them, how failures are reported and which system is authoritative? Scenario-based requirements allow suppliers to estimate more accurately and reveal operational risk earlier.

• ✓Requirement 5 — Sitemap: page types, languages, protected URLs and content access.
• ✓Requirement 6 — Content: writing, data sources, approval, translation and image rights.
• ✓Requirement 7 — Functions: forms, search, filters, accounts, downloads and booking.
• ✓Requirement 8 — Integrations: CRM, ERP, email, analytics, payments and failure handling.

Turn SEO, performance and accessibility into acceptance criteria

SEO should not appear at the end as an optional add-on. The brief should identify URLs that must be preserved, pages already earning impressions, language architecture, canonicals, sitemaps, structured data and redirect rules. Google recommends useful people-first content and the words readers use in prominent places such as titles, headings, image alt text and link text; each page should serve a distinct intent instead of repeating the same keyword across several URLs.

Performance should not be accepted because a page ‘feels fast on my laptop’. Core Web Vitals assess real experience through main-content loading, interaction latency and visual stability. Current good thresholds at the 75th percentile are LCP at or below 2.5 seconds, INP at or below 200 milliseconds and CLS at or below 0.1. Laboratory tools help diagnose problems, but field data remains the outcome to monitor.

Accessibility belongs in testing as well: keyboard navigation, heading hierarchy, form labels, contrast, error states, image alternatives and information that does not depend on colour alone. Agreeing these checks in advance replaces subjective acceptance arguments with evidence.

• ✓Requirement 9 — SEO: URLs, metadata, internal links, redirects, canonicals, hreflang, schema and sitemap.
• ✓Requirement 10 — Quality: supported devices, browsers, Core Web Vitals, accessibility, security and backup.
• ✓For every criterion, define the method, environment, approver and remedy when the result misses the target.

The final requirements: ownership, handover, schedule and budget

Domain registration, hosting, source code, databases, analytics, Search Console, original design files, fonts and image libraries need an explicit owner. Core accounts should belong to the business, with the supplier receiving suitable access instead of holding sole control. The brief should also define what happens when the relationship ends: export formats, handover time and transition support costs.

A schedule must depend on inputs and decisions. ‘Complete in eight weeks’ is not meaningful when content is unavailable or five people can block approval. Break the project into information architecture, design direction, content, integration, testing, data entry and launch. Name the approver and maximum response time at every gate.

A budget should communicate an investment range and priorities, not invite a supplier to spend the maximum. Ask proposals to separate the minimum launch scope, later improvements that need evidence and annual operating costs. This shows whether a partner can make decisions rather than simply add features.

• ✓Requirement 11 — Ownership and handover: accounts, source, data, design files, instructions and warranty.
• ✓Requirement 12 — Commercial plan: budget, approval gates, payment, operating costs and change control.
• ✓Require every proposal to identify assumptions, exclusions and rates for additional work.

A short brief template to send to every shortlisted company

Use the checklist below as the first page of a brief and attach the detailed content, data and technical requirements behind it. Send the same version to every shortlisted supplier and give each one equal time for questions. When an answer changes scope, share the clarification with all participants so the comparison remains fair.

Do not compare only the total prices. Compare content responsibility, decision rounds, quality criteria, ownership, post-launch support and assumptions that transfer risk back to the client. A higher proposal with clear accountability can have a lower total cost of ownership than a cheaper quote that leaves content, integration and handover undefined.

Keep the final brief as the project baseline. Record every later change with its reason, schedule impact, cost impact and revised acceptance criterion. That discipline turns a subjective design request into a business asset that can be operated and improved.

• ✓Context and three business outcomes.
• ✓Buyer groups, priority tasks and available evidence.
• ✓Draft sitemap, languages, content and existing data.
• ✓Functions, integrations and URLs that must be preserved.
• ✓SEO, performance, accessibility, security and acceptance criteria.
• ✓Ownership, handover deliverables, launch schedule, budget and exclusions.