A useful brief reduces uncertainty—not creativity.
A website brief should not prescribe every layout before the project begins. It should make the business problem, audience, evidence, constraints and definition of success clear enough that a capable team can propose the right system.
Without that shared baseline, one proposal may include positioning, copy, analytics and migration while another prices only visual design and page assembly. The totals look comparable, but the products are not.
Copy this one-page website redesign brief.
- Business: What do you sell, to whom, in which markets, and what makes the business commercially different?
- Reason for redesign: What is failing now—positioning, trust, lead quality, mobile experience, editing, speed, search visibility or technical reliability?
- Primary audience: Who must immediately recognize that the site is relevant? Include location, company type, urgency and purchase context.
- Primary conversion: What is the single most valuable next step—qualified form, booked call, estimate request, purchase, application or account creation?
- Qualification: What information is truly required before the team can respond usefully? What should disqualify an inquiry?
- Evidence: Which reviews, case studies, credentials, guarantees, customer data and first-party examples can be verified and published?
- Required pages: List only the routes already known to be necessary. Let the proposed information architecture solve the rest.
- Required functionality: Forms, booking, CRM, payments, accounts, search, multilingual content, calculators, uploads or internal workflows.
- Content ownership: Who researches, writes, approves, translates and migrates the copy, images, video and downloadable material?
- Brand inputs: Which identity assets exist, what must remain, and where is a new direction allowed?
- Technical constraints: Domain, hosting, CMS, analytics, consent, accessibility, security, integrations and internal maintenance requirements.
- Measurement: Name the events and commercial outcomes that must be observable after launch.
- Timeline: State the real deadline, why it matters, who approves work and how quickly feedback can be returned.
- Budget context: Give a planning range or ask for clearly separated scope options instead of forcing teams to guess.
Add the numbers that shape the conversion system.
The design team does not need confidential financial statements, but it does need enough commercial context to avoid optimizing for the wrong action. A company selling a $250 service has a different qualification threshold and follow-up path from one selling a $25,000 engagement.
| Input | Why it changes the website | Planning question |
|---|---|---|
| Average first sale | Sets an appropriate level of friction and sales involvement | What is a new customer initially worth? |
| Gross margin | Helps pressure-test acquisition and redesign payback | What contribution remains after delivery cost? |
| Qualified lead rate | Reveals whether volume or filtering is the bigger problem | What percentage of inquiries can the business serve? |
| Close rate | Connects page performance to sales capacity | How many qualified opportunities become customers? |
| Response time | Determines booking, automation and handoff requirements | How quickly does a real person respond today? |
| Service capacity | Prevents campaigns and pages from selling unavailable work | How many new customers can be handled each month? |
Define launch acceptance before design begins.
Acceptance criteria prevent the final week from becoming a debate about whether the project is finished. They should describe observable behavior, ownership and testing—not subjective promises such as “modern,” “premium” or “high converting.”
- Every agreed route renders correctly on current mobile and desktop browsers.
- Primary forms are submitted end to end and received in the correct inbox or CRM.
- Required analytics events appear in the live measurement property.
- Page titles, descriptions, canonical URLs, robots rules and sitemap entries are present.
- Old URLs have an approved redirect or removal decision.
- Content owners have approved the final claims, legal text, images and credentials.
- Keyboard navigation, labels, contrast and motion preferences have been reviewed.
- Domain, hosting, source files, analytics and third-party accounts are owned by the business.
- The team receives a launch record covering known limitations and post-launch responsibilities.
Keep launch scope separate from the growth backlog.
Not every useful idea belongs in version one. Mark each requirement as launch-critical, post-launch experiment or future capability. This protects the deadline without silently deleting valuable work.
A launch-critical item is necessary for the offer to be understood, trusted, submitted, delivered or measured. A growth experiment needs live traffic or sales feedback before it can be judged. A future capability depends on a later operational decision, data source or budget.
| Bucket | Example | Decision rule |
|---|---|---|
| Launch-critical | Primary service pages, form delivery, analytics and redirects | The site cannot responsibly launch without it |
| Growth experiment | Alternative landing-page message or shorter qualification path | Requires real visitor or sales evidence |
| Future capability | Customer portal, advanced calculator or multilingual expansion | Depends on a later business decision |
Compare proposals with the same five questions.
The strongest proposal is not necessarily the one with the most pages or the lowest total. It is the one that demonstrates a credible route from the documented business problem to a usable, measurable launch—and makes its assumptions visible before work begins.
- What assumptions does this proposal make about strategy, copy, content and approvals?
- Which deliverables and integrations are explicitly included?
- What is excluded or billed separately?
- Who owns implementation, launch QA and post-launch defects?
- How will the business verify that forms, analytics and search foundations work?