How to brief a web designer or developer

Why this matters

A clear brief helps designers and developers understand what you need, why you need it, and what success looks like. Good briefs lead to better outcomes, fewer revisions, and smoother projects.

This guide covers what to include in a brief and how to structure it for clarity.

1) Your goals and context

Start with why you need the project and what you want to achieve.

What to include

• Primary goal: What is the main thing you want to achieve? More enquiries, better performance, accessibility compliance, rebranding?
• Business context: What does your business do? Who are your customers? What makes you different?
• Current situation: What do you have now? What problems are you trying to solve?
• Success metrics: How will you know the project succeeded? More enquiries, faster pages, better rankings?

What to avoid

• Vague goals: "Make it better" or "Improve the site".
• Too many competing goals: Pick one primary goal, then list supporting goals.
• Assuming the designer/developer knows your business: Explain context clearly.

2) Target audience and users

Help the designer/developer understand who will use the site.

• Primary audience: Who is the main user? Small businesses, consumers, charities, professionals?
• User needs: What are visitors trying to do? Get a quote, buy a product, find information, contact you?
• User context: How do people find you? Search, social media, direct? What devices do they use?
• Accessibility needs: Do you serve people with disabilities? What accessibility standards matter? See what accessibility means.

3) Content and pages

Describe what content you have and what pages you need.

• Existing content: What content do you have? Can it be reused, or does it need rewriting?
• Page list: What pages do you need? Home, about, services, contact, blog, shop?
• Content types: What types of content? Text, images, videos, products, events, testimonials?
• Content workflow: Who creates content? How often does it change? Do you need a CMS?

For more on content, see writing for the web: content that converts.

4) Functionality and features

List what the site needs to do, not how it should be built.

• Essential features: Contact forms, booking systems, e-commerce, search, user accounts?
• Integration needs: Analytics, email marketing, payment processing, CRM?
• Third-party tools: Chat widgets, booking systems, social media feeds?
• Future needs: What might you need later? Mention it, but do not make it a requirement now.

5) Design and branding

Share your brand guidelines and design preferences.

• Brand guidelines: Logo, colours, fonts, tone of voice, style preferences.
• Design references: Sites you like (and why), sites you do not like (and why).
• Must-haves: Specific design elements, layouts, or styles you need.
• Flexibility: What can the designer change? What must stay the same?

6) Technical requirements

Specify technical needs and constraints.

• Performance: Fast load times, good Core Web Vitals [2]Source 2 . See fast websites: what fast means.
• Accessibility: WCAG 2.2 AA standard [1]Source 1 . See what accessibility means.
• Browser support: Which browsers and devices matter most?
• Hosting preferences: Do you have hosting already, or do you need recommendations?
• CMS requirements: Do you need a CMS? Who will edit content? How often?

7) Timeline and budget

Be clear about constraints and expectations.

• Timeline: When do you need it? Is there a hard deadline? What is flexible?
• Budget range: What is your budget? Be realistic and transparent.
• Phases: Can the project be done in phases? What is essential vs nice-to-have?
• Ongoing costs: What ongoing costs can you handle? Hosting, maintenance, updates?

For more on timelines, see website project timelines: what to expect. For more on budgeting, see budgeting for website projects.

8) Success criteria

Define how you will measure success.

• Conversion goals: More enquiries, more sales, more sign-ups?
• Performance targets: Page load times, Core Web Vitals scores?
• Accessibility targets: WCAG compliance, accessibility audit results?
• User feedback: How will you test with real users? See user testing basics.

What makes a brief effective

• Clear and specific: Avoid vague language. Be specific about what you need.
• Focused: One primary goal, with supporting goals clearly listed.
• Realistic: Budget and timeline match the scope of work.
• Complete: Include all relevant information, but do not overwhelm with unnecessary detail.
• Open to questions: Be available to answer questions and clarify requirements.

Common brief mistakes

• Too vague: "Make it better" or "Improve the design" does not help.
• Too many goals: Trying to achieve everything at once dilutes focus.
• Unrealistic expectations: Expecting a £2,000 site to do everything a £15,000 site does.
• Missing context: Not explaining your business, audience, or goals.
• Too prescriptive: Telling the designer/developer exactly how to build it, not what you need it to do.

After the brief

Once you send the brief:

• Be available: Answer questions quickly and clearly.
• Review proposals: Compare quotes, timelines, and approaches.
• Ask questions: If something is unclear, ask. Better to clarify early.
• Set expectations: Agree on communication, updates, and review process.

For more on working with developers, see working with web developers: what to expect. For help choosing between designer and developer, see choosing a web designer vs developer.

Summary

A good brief includes: your goals and context, target audience and users, content and pages, functionality and features, design and branding, technical requirements, timeline and budget, and success criteria.

Keep it clear, specific, focused, realistic, and complete. Be available to answer questions and clarify requirements.

If you need help creating a brief or finding the right designer/developer, see website build services or get in touch to discuss your project.