A brief should explain who the site serves, what visitors need to know and what action they should take. It turns an abstract design request into a deliverable. Write: We help independent cafés with bookkeeping; visitors should understand three services and request an introductory conversation. References should explain the qualities you like, not instruct a designer to copy another company’s site.
Add a small section titled decisions still open. List only genuine unknowns, such as whether two services need separate pages or whether an existing booking provider should be linked. Distinguish these from fixed requirements. This helps a provider investigate the uncertain parts without reopening everything already decided.
Attach examples of real content when available. One complete service paragraph and a genuine image can communicate more than a long list of abstract preferences. Include the longest business or service names the design must accommodate. For multilingual work, provide approved terminology or identify who will review it. Keep the brief current as decisions are made so it does not become a historical document that conflicts with the offer. At the point of approval, the remaining open questions should either be resolved or explicitly separated from the accepted release. This gives the project a clear boundary without preventing later improvements.
Describe the business in language a visitor would use
A useful brief begins with a plain explanation of what the business does and whom it serves. Avoid starting with desired colors or an instruction to make the site modern. Those preferences can be discussed later; the first task is to identify the information a prospective customer needs. Write the main offer, the audience and the intended next action in three short statements.
For an illustrative consultancy, the brief might say: we help independent cafés organize bookkeeping; visitors need to understand three service options; the desired action is a request for an introductory conversation. This is more actionable than saying that the business needs a premium digital presence. It gives both the content and the design a purpose.
List the most common questions someone asks before becoming a customer. Which services are available? What preparation is required? Where does the business operate? What happens after an enquiry? Use these questions to build the first page list. Distinguish information that deserves a dedicated page from details that can be a section within another page.
Assemble a practical brief document
Use a simple structure: business description, primary audience, main site goal, page inventory, required languages, features, content materials, visual references, approval process and timing constraints. Under features, describe actions rather than labels. Write that a visitor submits an enquiry and receives a truthful confirmation, not merely that the site needs a contact section.
For each page, add a sentence explaining its purpose and a named content owner. Mark which copy is approved, which photographs have permission and which translations remain to be prepared. Keep real customer information and account credentials out of a public brief. You can identify that an account exists without including passwords or secrets in a shared planning document.
For visual references, explain the relevant quality. A reference might demonstrate a readable service hierarchy, a calm typographic system or useful project captions. It should not instruct the provider to copy another company’s branding, claims or photographs. Also note any existing brand files that genuinely belong to your business.
Include one approval owner who can consolidate feedback. If several people need to review the work, decide how their comments will become a single list. This is especially helpful when revisions are organized into grouped rounds. Contradictory requests are easier to resolve before they reach the developer.
Turn constraints into decisions
State the intended launch occasion if there is one, but distinguish a desired date from a confirmed delivery promise. The schedule depends on the final scope and on receiving the required materials. If the content is incomplete, identify what can be prepared now and what must be resolved before implementation. Do not create an artificial deadline by assuming every missing asset can be produced during final review.
Set out what is not required in the initial release. A brochure website may not need payments, customer accounts, a reservation engine or a content management panel. Excluding an unnecessary function can keep the first project focused. If a function is genuinely needed, describe it clearly rather than hiding it until after a package has been selected.
Finish with acceptance questions. Can the visitor identify the service? Are language versions complete? Does the form produce a real stored or delivered enquiry? Are accounts and source files handed over as agreed? These questions make the brief useful at delivery as well as at quotation.
A brief does not have to be long or written in technical language. It needs enough concrete information for both sides to understand the same project. Once the provider responds, update it into the agreed scope and keep the written offer alongside it so that new ideas can be evaluated as revisions or separate changes.
Practical checklist
- State the primary goal
- Draft the page list
- Assign content and approval owners
A concrete example: Write: We help independent cafés with bookkeeping; visitors should understand three services and request an introductory conversation.
A boundary to keep clear: References should explain the qualities you like, not instruct a designer to copy another company’s site.
Your next step
Tell Orvunweb about your project
