How to write a useful website brief when you are not technical

Writing a website brief can feel difficult when you are not a designer, developer or digital project manager. You may know that the current website is not helping enough, but not know how to describe the replacement in technical terms. The good news is that technical vocabulary is not the most useful starting point. A strong brief explains the business, the customer and the decisions the website must support.

Your brief does not need to predict every screen or feature. It needs to create shared understanding before work begins. When it explains what matters and what must happen first, a designer or builder can turn it into a practical structure.

Begin with the reason for the project

Write down why the website needs attention now. Perhaps visitors do not understand the offer, existing customers cannot find important information, enquiries are poorly qualified or the organisation has changed. A clear reason is more helpful than a general statement such as “we need a modern website”.

Describe the current situation with examples. Mention questions customers repeatedly ask, pages people cannot find, outdated services, confusing routes or actions that happen outside the website. If you have evidence such as enquiry messages, analytics observations or feedback from staff, include it without trying to turn it into a technical report.

Then describe what should be different after launch. You might want more relevant enquiries, a clearer explanation of your services, more confidence before a first contact or fewer routine questions. Choose the outcomes that matter most. They will help you decide whether a proposed page or feature belongs in the first version.

Describe the people you want to help

Avoid describing your audience only with age, industry or location. Explain why someone visits the website, what they already know and what may make them hesitate. A new customer may need a simple explanation, while a returning customer may need opening information, prices or a quick route to a specific service.

Include the situations that bring people to the site. Are they comparing providers, checking whether you serve their area, looking for an urgent answer or preparing to contact you? Mention the words they use when describing their problem. Real phrases are useful for navigation, headings and content because they show how visitors think about the need.

Identify important differences between audiences. If one group needs a different service, language level or action, explain that early. You do not need to prescribe a separate website for every group. You do need to show where their questions and priorities diverge so the structure can remain understandable.

Define the actions the website should support

List the most important things a visitor should be able to do. These might include comparing services, requesting a quote, booking a call, finding a location, reading preparation information or contacting the right person. Put the actions in priority order rather than treating every link as equally important.

Explain what a successful action looks like. If someone submits an enquiry, should they receive a confirmation, choose a time, upload information or wait for a personal response? If someone reads a service page, what should they understand before deciding to contact you? This detail connects the website to the real process behind it.

Also list actions that should not be forced. A visitor may want to read before making contact, return later or use a different channel. A useful brief makes room for trust-building and independent research instead of measuring every visit only by an immediate form submission.

Gather the content and knowledge you already have

Make an inventory of useful material before asking for everything to be written again. Existing service descriptions, customer questions, photographs, testimonials, instructions, policies and internal explanations can reveal what the new site needs. Mark each item as keep, rewrite, combine, verify or remove.

Do not assume that more content automatically creates a better website. A short explanation in the right place can be more useful than several long pages. Note where information is missing, where the current wording is too technical and where different pages contradict one another.

Include people who work directly with customers. They know which promises need explanation and which questions appear before a purchase or enquiry. Their input can also prevent the brief from reflecting only the internal view of the organisation.

Give direction for brand and presentation

You do not need to specify fonts, spacing or a complete colour system. Instead, describe the impression the website should create and the one it should avoid. It may need to feel calm, practical, warm, precise, premium or accessible. Explain why that impression suits the customers and the service.

Collect examples of websites, publications or visual references that show something useful. Say what you like about each example: the clarity, pace, photography, tone, navigation or amount of detail. Also say what should not be copied. A reference is most helpful when it communicates a principle rather than a demand to reproduce another company’s design.

List existing brand assets, restrictions and preferences. Mention a logo, colours, photography style, language requirements or accessibility expectations. If these are uncertain, label them as questions to resolve rather than hiding them inside an assumed requirement.

Separate launch priorities from future ideas

Create three groups: essential for launch, valuable soon after launch and possible later. Essential items should be those required for a visitor to understand the offer, trust the business and take the right next step. Future ideas can include advanced integrations, extra content areas or experiments that need more evidence.

For each requirement, explain the problem it solves. “Add a customer portal” is less useful than “returning customers need to access their documents without calling”. The second description leaves room to find the simplest suitable solution. It also makes it easier to question a feature that does not address a meaningful need.

Record open questions, decisions still needed and people responsible for answering them. A brief is a working document that makes uncertainty visible so it can be resolved at the right time.

Review the brief with someone who knows the business and someone who does not. The first person can correct missing operational details; the second can reveal assumptions and unexplained language. Keep the final version short enough to use during planning, but detailed enough to explain priorities.

ChatBuild can help turn this kind of practical direction into a clear website foundation. Bring the brief into the first conversation and use it to judge pages, content and calls to action. For related planning, read how to choose a website structure.

Sources

• Creating helpful, reliable, people-first content · Google Search Central

Frequently asked

Does a website brief need technical requirements?

Include technical constraints that are already known, such as required systems, languages, accessibility needs or content ownership. You do not need to choose the implementation yourself. Describe the business need and let the technical solution follow from it.

How long should a website brief be?

It should be long enough to explain the reason, audience, priorities, content and open questions, but short enough to use in a planning conversation. A focused document of a few pages is often more useful than a large collection of unprioritised ideas.

What is the most important part of a website brief?

The most important part is a clear explanation of the customer and business outcome. When everyone understands who the website serves and what should improve, page structure and feature decisions become easier to evaluate.