Website design brief: what to send for an accurate quote
You do not need a finished specification to ask for a website quote. Send the goal, main content, languages, integrations and deadline. This checklist helps you describe the work without choosing the technology first.
- Goal
- The visitor’s next action
- Scope
- Pages and materials
- Delivery
- Budget, date, acceptance
Describe the action a visitor should take
A website brief helps a business and its supplier agree on the result before discussing implementation. You do not need to know the technology in advance. Start with the visitor: who are they, what do they need to understand, and what should they do next? Requesting an estimate, booking a service and buying a product require different paths through the site.
Your offer and audience
Explain your offer in ordinary language. List the main services or products, the customers they suit and the questions people ask before contacting you. If there are several business areas, identify the priority for launch. This helps determine whether they need separate pages and what each page must explain. Search phrases can be considered later alongside those actual customer needs.
Where visitors come from
Describe where the first visitors will come from. Someone following a link after a sales call already knows more than someone arriving from search. Advertising may send a visitor directly to a particular service. These entry points affect the order of information. Name the main paths in the brief so the site can support them without relying on one ideal journey from the homepage.
List pages and who supplies the material
- Main offer and customer groups
- Pages or catalogue sections
- Existing text, photographs and identity files
- Launch languages and the person checking each translation
- Content your team needs to edit afterwards
- Page structure
- An initial structure might include the homepage, services, projects, company information and contact details. A store also needs categories, product pages and a checkout. Give each section a purpose. “Blog” alone does not define the work: say who will write it, how many articles are needed for launch and how the team will publish later material.
- Content readiness
- Mark the state of the content for each page: ready, needing editing or not yet available. Share examples of real text and images early. Their length and quality affect design decisions. A layout built around short placeholder headings may need revision when the actual service names and detailed project descriptions arrive.
- Verified project material
- For projects, provide the verified task, materials and information you are allowed to publish. If a client name or result cannot be disclosed, say so. For a catalogue, identify the source of prices, descriptions, specifications and photographs. A representative sample is usually more useful in an initial brief than a large unexplained export. It allows the supplier to assess preparation and import work.
Describe languages and differences between markets
Name the languages required for the first release and the person who will review each version. If another language is planned later, record that separately. Explain whether the offer is identical across markets. Different services, contact details or ways to order may require structural changes as well as translation.
Interface copy
Remember interface text: navigation, buttons, form messages, error states and metadata. These are part of the visitor's experience even when they are not included in the main copy document. Translations also change text length, which can affect cards and mobile layouts. Assign time for content and visual checks in every launch language.
Actual service area
Describe your actual service area and working method. A remote team can explain meetings, approvals and delivery without implying a local office. If customers need to visit a physical location, accurate access information becomes part of the site. These details help the supplier present a credible, useful offer rather than infer facts from a city name in the brief.
Describe integrations without sending passwords
Describe the event
List the systems the website must work with: CRM, calendar, catalogue, email or payment provider. Then describe one event from start to finish. For an enquiry, name the fields the visitor submits, where the record should be stored, who receives it and what confirmation the visitor sees. This is more informative than simply asking for a CRM integration.
Define fields and exceptions
Identify which fields are essential and whether the page or selected service should travel with the enquiry. Explain what should happen if a service is unavailable or the same event arrives twice. You can describe the expected behaviour in plain language. The technical method can be selected after the supplier checks the available operations and account permissions.
Arrange access separately
Do not include passwords, API keys or a customer database in the initial brief. Service names and anonymised examples are enough for the first assessment. Access can be arranged separately for agreed operations. If an existing integration must be preserved, explain where it runs, what it currently does and who maintains it.
Explain what you like about each reference
Name the quality you like
Choose a small set of relevant examples and explain the specific quality you like. One may have readable typography, another a helpful project structure, and a third a clear explanation of a process. Without that explanation, the designer might focus on a colour or animation that was not your reason for sharing it.
Share existing brand rules
Include your logo, colours, fonts and existing brand guidelines. Distinguish fixed requirements from elements that may change. If the website is meant to establish a new visual identity, that should be treated as part of the scope. Applying a finished identity and developing one from scratch require different decisions and deliverables.
Explain practical constraints
Constraints are useful too. Explain which treatments would make the site difficult for your customers: overly small text, distracting movement or an inconvenient mobile menu, for example. Connect feedback to the task. “Visitors need to compare specifications quickly on a phone” gives the team something concrete to test while developing the visual direction.
Name the constraints and the decision-maker
State a budget range and any fixed date, along with the event behind it. A site for an exhibition may need to be ready before the advertising campaign begins. Identify external dependencies such as photography, final product information or account setup. A useful schedule shows what is needed from both sides.
Appoint someone to collect and approve feedback. Other colleagues can review their areas, but the development team needs a coordinated decision. Keep optional future features separate from launch requirements. A customer portal or additional catalogue may influence the initial architecture without being included in the first delivery.
Agree how completion is checked
Describe how completion will be checked. The agreed pages should be populated, navigation should work, and the main enquiry or purchase path should be tested on a phone. A successful form message is only one part of the check: confirm that the intended person or system actually received the submission.
Include editing and handover in the brief
Say what your team expects to update independently: articles, projects, prices, contact details or catalogue items. At handover, try one of these tasks using the supplied instructions. If the process requires technical knowledge the team does not have, that needs to be addressed before launch rather than discovered during the next urgent update.
List the accounts and access you expect to control, including the domain, platform, hosting and analytics where applicable. Ask for the recurring costs and renewal responsibilities. Clarify how support works after delivery and how new features will be estimated. This separates a completed first release from the ongoing work of running a business website.
A short brief you can copy
Your first message
Use this structure for the first message: “We offer [product or service] to [customers]. Visitors should be able to [action]. Launch requires [sections and languages]. We have [materials] and still need [missing content]. We use [systems], and enquiries go to [role]. These references appeal to us because [reasons]. Our target date is [date and event], with a budget of [range].”
It is fine to mark an item as undecided. The brief should capture reliable information and open questions, not create a false impression that every choice has been made. After discussion, it becomes an agreed scope: what will be delivered, who provides each input and how the working site will be accepted.
How we can help
Our part
We turn the agreed brief into a fixed scope and price. These published projects show the work behind the offer.
Questions
Questions from readers
Can I request an estimate before the copy is finished?
Yes. Send a rough page list and mark which materials are missing. Preparing content can then be included in the proposal instead of silently delaying the project.
Do I need to choose Webflow or WordPress before writing a brief?
No. Explain what you need to edit, sell or connect. The platform can be selected after those requirements are clear.
What should I leave out of the first brief?
Passwords, payment credentials and personal customer records. Describe the integration and use anonymised examples until access is actually needed.
Send us the scope you have in mind.
An outline is enough to start. We will clarify what is needed before quoting.