How to write a small business website brief

Give the website one primary job

Describe the business problem in observable terms. “Our inquiries arrive without enough project detail” is more useful than “Our website feels old.” The first statement suggests questions, examples and a better inquiry form. The second can be part of the design discussion, but it does not explain what success looks like.

Name a primary visitor and the situation that brought them to the site. A business buying its first website needs different explanations from a team replacing a complex customer portal. Choose a primary next step, such as preparing a brief or requesting a conversation. Secondary actions should help someone who is not ready for that step.

Plan pages around buying questions

List the questions a visitor needs answered: what you offer, who it suits, how the work happens, what information you need and what happens after an inquiry. Group questions that belong together. Separate genuinely different services when each needs its own explanation. Avoid creating several nearly identical pages just to repeat different search phrases.

For every planned page, record its purpose, main answer, available evidence and next action. Evidence can be an original demonstration or a transparent explanation of your process when you do not have permission to publish client work. Label demonstrations clearly. Google’s guidance on helpful content emphasizes useful, original information for people; it does not prescribe a preferred word count.

Use this website brief template

Copy these prompts into a shared document. An honest “not decided” with an owner is more useful than a confident guess. Keep reference websites alongside notes about the particular navigation, writing or interaction you want to learn from.

• Business goal: What problem should this website help solve, and how will we recognize progress?
• Audience: Who is visiting, what do they already know, and what question brings them here?
• Primary journey: Which page do they enter, what do they need to understand, and what should they do next?
• Content: Which pages, photographs, brand assets and examples exist? Who writes, approves and maintains each item?
• Functionality: Which forms, downloads, editing tools or integrations are essential? Which can wait?
• Constraints: What must work with existing tools? What launch dependency, accessibility need or operating limit matters?
• Acceptance and ownership: Who approves the release, checks inquiries, owns accounts and handles updates after launch?

A hypothetical brief for a service business

Consider a hypothetical small interior styling studio. Its team receives vague messages asking for “more information.” The brief names homeowners preparing a room refresh as the primary audience. The desired action is an inquiry that includes the room, location and intended timing. The site needs a clear service explanation, a preparation checklist and a short form.

The first version can explain the process and show a labelled room concept. A booking calendar remains optional because the studio wants to review fit before scheduling. The acceptance check is concrete: a mobile visitor can identify the service, understand the next step and submit an inquiry that the team can retrieve. This is a planning example, not a Kinetivy client result.

Choose a scope your team can maintain

A single landing page can suit one offer with a short explanation. Separate service pages help when visitors have materially different questions. A content management system becomes useful when someone will publish or edit regularly; it also adds editing permissions, training and maintenance to the brief. Ask who will use it and for which tasks.

Evaluate features against the primary journey. A useful calculator may help someone prepare, while a decorative interaction may simply support the identity. Both need time to build and test. Decide what happens on a small screen and with reduced motion. Put essential information in readable content so understanding the offer does not depend on an animation.

Agree the checks before approving the design

Walk through the journey using realistic sample information. Check keyboard navigation, visible form labels, error messages, mobile layouts, working downloads and the actual destination of an inquiry. W3C’s forms guidance explains why labels need to identify their controls and be associated with them. Treat this as part of the functionality, not a final cosmetic adjustment.

Record who supplies metadata, redirects from an older site and measurement requirements. Define a useful completion, such as a durably saved inquiry, rather than counting every button click as success. Ask for a handover that identifies domain, hosting and account ownership. The brief is ready when another person can explain what will be delivered and how it will be accepted.