Website design brief: agree the business task before mockups
The owner expects the new website to present the company convincingly, marketing wants more qualified enquiries, and the head of sales asks not to increase the flow of enquiries with no budget. If you start by styling the homepage, these expectations will clash during approval. A website design brief helps define a shared task before mockups: who the site helps, which action it supports and which promises the business can actually deliver.
The outcome of briefing is an agreed basis for decisions. Here is a way to build it together, separate facts from assumptions and check readiness for design.
A website design brief starts with the problem, not the style
“We need a modern website” does not explain what will change for the customer. Instead, describe an observable obstacle: visitors do not understand which projects the company handles, send incomplete enquiries or expect a service that is not offered. Add the source: enquiries to sales, search logs, analytics or interviews. If there is no evidence yet, explicitly label the problem as a hypothesis.
Write down the desired outcome for the person and the company separately. For example, visitors can determine whether the service fits their task, while the sales representative receives enough context for a substantive response. This avoids replacing a business goal with a button colour. Enquiry numbers only make sense alongside a definition of quality and a method of tracking it.
In its Double Diamond model, the Design Council distinguishes understanding the problem, defining it and finding solutions. The useful principle for a brief is to agree on the problem first, then discuss the approach. This is neither a requirement to adopt a methodology nor a promise of improved sales.
Separate responsibilities and final decision-making authority
The owner sets the business priority and acceptable compromises. Marketing explains the audiences, acquisition channels and messages. Sales and operations check the promises: which enquiries they can handle, what information they need and who will update the content. A technical representative identifies limitations of the existing website and systems. One person may fill several roles, but no important function should be left without an accountable person.
One coordinator does not mean one source of truth
Appoint a coordinator to collect answers in one document rather than forward conflicting messages to the designer. Next to a disputed point, note the decision owner, the rationale and the response date. The final approver should know about the disagreement, not receive a version for signature from which it has quietly disappeared. “I like it” is no substitute for checking whether it addresses the task.
Agree in advance how feedback is collected and what approval means. Changing a priority requires recording the reason and its impact on scope, timing and costs. A brief does not prevent a change of mind: it makes the change visible. It is better not to treat a participant’s silence as consent unless the team has explicitly agreed otherwise.
Gather evidence about the audience and its primary action
“Our customer is a business” is too broad for design. It is more useful to describe the situation: a manager is looking for a supplier for a specific task, comparing capabilities, short of time and required to explain the choice to colleagues. Record what they already know, what they are uncertain about and which answer they must get before making contact. Do not invent precise profiles or motivations without research.
For each audience, identify the primary action and the information needed before it. For an estimate request, this might include service boundaries, examples of work and an explanation of the follow-up. Do not mix support for existing customers with new sales. Prioritising one action does not require removing every other route.
Keep facts, assumptions and unknowns separate
Business requirements for a website become clearer when each has an evidence status. “Sales staff regularly ask customers to clarify the type of task” is an observation to substantiate with enquiries. “A mandatory field will solve the problem” is already a solution hypothesis. “The customer will agree to state a budget immediately” is an assumption worth testing. This gives the designer room to explore rather than an instruction to implement an untested idea.
GOV.UK guidance on learning about user needs recommends analysing existing data, talking to people and observing them. It concerns government services: adapt the methods to your business rather than treating other organisations’ results as a forecast.
Turn wishes into boundaries for the first version
After discussing the problems, create a short map of decisions. Distinguish launch essentials, desirable items and deferred work. For each item, note the reason and dependency: writing copy, agreeing the offer, obtaining photographs or verifying data. Do not describe future capabilities as though they are already included in the agreed budget.
| Vague wish | What to clarify in the business brief | Evidence of readiness |
|---|---|---|
| More enquiries | Which enquiries are needed and who receives them | An agreed definition of a qualified enquiry |
| Demonstrate reliability | Which claims can be substantiated publicly | Approved materials and a person responsible for verification |
| Make choosing easier | Which differences between services the customer needs to understand | Agreed boundaries and descriptions of the offers |
| Launch sooner | What can be postponed without losing the primary action | Separate lists for the first version and the next stage |
Explain visual references: clear hierarchy, a restrained tone, an effective product presentation. Also name what does not fit. “Make it like theirs” is not permission to copy a design. Provide brand materials and the rights to use them separately.
Do not confuse this document with a detailed description of element behaviour. Once the task is agreed, you will need an interface-state specification before development, but that is the next level of detail. If you need to organise procurement, the request format is discussed in the article on RFI, RFP and RFQ for choosing a contractor. Neither replaces internal agreement on the task.
Hypothetical example: a company receives office furnishing enquiries
This is a hypothetical situation, not a GL.ua case study. A furniture supplier furnishes offices. The owner wants to present the full service, marketing wants to showcase the range, and sales staff lack information about the premises. Instead of immediately “adding a large form”, they first agree which request the business is ready to handle.
In the agreed version, the priority is enquiries about full office furnishing. The audience is the person responsible for setting up an office who does not yet have a finished specification. The primary action is to send a description of the task and contact details for clarification. Before that, the site explains what the service includes, which materials will help the discussion and what happens after the enquiry. The retail catalogue remains a separate route rather than disappearing because of the new priority.
Resolve a disagreement without voting on a mockup
Operations confirms that a sales representative can start a conversation without a complete furniture list. An existing floor plan is therefore invited if available, rather than made a prerequisite for contact. Marketing prepares the service explanation, the owner approves its boundaries and sales agrees the response process. Automatic cost calculation is postponed until rules are agreed. This is a decision about business capabilities, not a specification of fields or technical integration.
The example’s verification is hypothetical too: show the service description to members of the intended audience and ask them to explain what the company will do and what they can contact it about. Separately, give a sales representative a sample enquiry. If the visitor expects a complete project free of charge and the representative cannot understand what the conversation is about, clarify the offer and the context needed, not just the presentation.
Check agreement before mockups and before launch
Design brief approval should conclude with a check for shared understanding. Do not only ask whether everyone has read the document. Ask participants to explain the main task, priority audience and first-version boundaries in their own words. Different answers reveal where approval is still only formal.
- Match the problem statement to evidence; assign verification and an owner for anything unconfirmed.
- Walk through the primary scenario verbally: what the person should understand, do and receive from the company.
- Check the promises with sales and operations, including follow-up contact and support.
- Check content readiness, rights to materials and the list of open questions blocking design.
- Record the agreed version, decisions on deferred work and conditions for another review before launch.
Use the prototype to check whether the offer and route are understandable; before launch, check whether the actual site and the team’s work match the brief. This does not replace functional testing, accessibility checks or analytics. Compare business outcomes after launch using the agreed definition of a qualified enquiry, accounting for channels and seasonality; design alone does not guarantee growth.
What affects timing, cost and risks
Preparation time depends not on the number of questions but on the availability of people and evidence. Unagreed services, conflicting priorities, missing copy and slow feedback delay the start of design. Plan stages for collecting data, discussing it together, testing hypotheses and recording decisions. Tie the move to mockups to resolving critical questions, not to a promise to fill in a template in an evening.
Separate work on the brief from subsequent website production when considering costs. Preparation may include interviews, enquiry analysis, agreeing the offer and reviewing content. Research, prototyping, visual design, copy, photographs, development, integrations and testing are then estimated separately. Clarify licence fees for third-party materials or services, and support and updates for the launched site. Quoting an amount or a percentage saving without agreed scope would be speculation.
The main risks are substituting the manager’s opinion for customer needs, hiding disagreements or freezing a weak hypothesis as an immutable requirement. A short brief does not compensate for missing strategy, and a detailed one does not remove the need for research. A small update only needs a concise record of the change and its boundaries; a new business line with an unknown audience requires demand validation first. Not every enquiry problem is solved by a redesign.
When the task is ready for design
Move to mockups after agreeing on the problem, audience, primary action, version boundaries and responsible people. For unknowns, define a verification method and the decisions that depend on them. Design discussions can then rely on shared criteria rather than competing tastes.
If you are preparing a new website, share this agreed context with GL.ua (Glyanec) to discuss website planning and development for your business task. The practical next step is to identify which questions need resolving before a prototype and which first-version scope can be estimated on a sound basis.
Just one step to your perfect website
