1. Define the purpose and the next action
“We need a modern website” describes a preference, not a task. Write down who the website helps, what that person should understand and what action they should take. For example: “Help a small-team manager understand the service and send a description of their problem.”
Choose one primary action: an enquiry, quote request, booking or purchase. Secondary actions can exist, but they should not compete for attention. Also name the person who receives the enquiry and describe what happens next.
A useful check: can a colleague explain the purpose of the homepage from this description? If not, refine the task before choosing a visual style.
2. Describe the visitor through their questions
Instead of a broad “high-value audience”, describe the visitor’s situation. Are they choosing a provider for the first time, comparing offers or looking for help with a specific problem? That determines what to explain first.
- What problem brings this person to the website?
- What do they already know about the solution?
- What stops them from getting in touch: unclear scope, missing examples or unknown cost?
- Which details help them decide, and which can wait for a conversation?
Use anonymised questions from actual conversations when available. Keep assumptions separate from observations so they can be tested after launch.
3. Build a small page map
Every page needs a job. Start with a small table and add a section only when its content and purpose are clear. The following is an illustrative structure, not a requirement for every website.
| Page | Visitor’s question | Next action |
|---|---|---|
| Home | Is this offer relevant to me? | Open the relevant service |
| Service | What is included and how does it work? | Describe the task |
| Practical guide | How can I prepare or assess a solution? | Use the template; enquire if needed |
| Contact | Who can I speak to and how? | Choose a contact channel |
For a multilingual website, decide which pages will be translated and who will check their meaning. A translated menu is not a complete language version.
4. Review the content before the layout
List the copy, photographs, service descriptions and verified examples. Give each item an owner and a status: ready, needs updating or missing. This shows what can be designed now and what depends on content preparation.
Flag facts that require approval before publication: figures, deadlines, client names, testimonials and photographs of people. If evidence is unavailable, explain the working process rather than presenting an unsupported result.
When sharing design references, say what you like: the scale of headings, composition, imagery or transitions between sections. “Make it like this” does not explain which choices fit your content.
5. Define enquiry handling and constraints
List contact channels and their owners. For a form, define the necessary fields, where an enquiry is stored and what happens on failure. For a messaging link, check the recipient and the clarity of any suggested message.
If the website needs a CRM, payment or other integration, name the service and describe the intended workflow first. Connection options must be checked separately; an existing online account does not establish that a suitable integration is available.
- What must be preserved: the domain, important page addresses, content or existing tools?
- Which information must never appear on the public website?
- Who approves the copy and accepts the finished work?
- Who updates the website after handover?
Do not include passwords, tokens or private conversations in the initial brief.
6. Agree on what “finished” means
Check the visitor’s journey, not just the appearance of the first screen. Useful criteria include approved content, readable mobile pages, correct contact links, language switching to the corresponding page and enquiries following the agreed workflow.
For publication, separately agree on a backup, the replacement sequence and a way to restore the previous version. For handover, list access requirements, owners and instructions without putting secrets in a shared document.
Short brief: we offer …; our visitor is …; they should understand …; the primary action is …; the required pages are …; content is prepared by …; enquiries are handled by …; completion is checked against … .
A completed paragraph and a page map are enough for a useful first discussion. Details can be refined as constraints are checked.