How to brief a web designer without micromanaging

A useful web design brief explains what the website needs to achieve, who it serves, and what the project must take into account. It gives a designer enough context to make informed recommendations while leaving room to choose an appropriate solution. You do not need to decide every layout detail before the work begins.

I would rather receive a clear account of the problem than a list of components someone has seen elsewhere. A request for a booking widget becomes more useful when it explains how bookings currently work and where customers encounter difficulty. That context may justify the feature or reveal a simpler route.

Briefing well is a shared responsibility. You provide factual information, priorities, and constraints. The designer should ask questions, challenge assumptions where necessary, and explain proposed choices. The aim is a common understanding that supports decisions throughout the project, rather than a document that is approved and then forgotten.

Explain why the project is happening now

Describe the trigger. Your offer may have changed, publishing may have become difficult, or customers may repeatedly ask questions the website should answer. Separate an observed problem from an internal preference. Both can matter, but they should not be presented as the same evidence.

If the site feels dated, explain the consequence. Does the presentation misrepresent the quality of your work? Is the content hard to read on a phone? Are people uncertain about the service? These explanations give the designer something to investigate beyond the request to make the site modern.

For an existing website, identify what should be preserved. Useful content, working integrations, recognisable identity, and established search destinations may remain valuable. A redesign brief should acknowledge those assets instead of implying that replacement starts from an empty page.

Write the situation briefly enough that another person can explain it back to you. If the reason for the project remains unclear, a focused review may be more useful than a detailed design request. The brief can record that uncertainty without pretending the diagnosis is complete.

Define the audience through its tasks

Identify the people who need the website and what they come to accomplish. A prospective client comparing services needs different information from an existing customer seeking support. Naming everyone as an equal priority gives the designer little basis for deciding what should come first.

Explain the information needed before the intended next step. Include recurring questions from sales conversations, support requests, and customer feedback. Record their source and distinguish a real observation from what the team assumes visitors want.

The GOV.UK guidance on understanding user needs provides a useful principle: describe the person’s problem before prescribing a solution. Its context is public services, but the distinction can also inform a business brief. Asking for a feature is not the same as explaining the task it should support.

For an illustrative training provider, a visitor might need to identify a course suitable for beginners and check practical conditions. That task can guide content and navigation. It does not automatically justify a complex recommendation tool. Where evidence is limited, identify the questions worth investigating before the implementation is chosen.

Make success understandable and observable

Describe the result you want without promising that design alone will cause it. More useful enquiries may be a business objective; a clear explanation of service suitability and a dependable contact route are conditions the website can support. Keeping those levels distinct makes the brief easier to assess.

Include a few practical acceptance criteria. A visitor should be able to compare the relevant options, understand what happens after an enquiry, and complete the form with clear feedback. An editor should be able to update the agreed content without specialist intervention for every routine change.

Ask how those conditions will be checked. A visual review, a functional test, and an observation of user behaviour provide different evidence. The project should not present approval of an attractive screen as proof that every important task works well.

My article on UX work in project planning explains how these decisions can influence scope early. The brief should make uncertainty visible so the team can choose a proportionate way to reduce it.

Supply accurate content and usable evidence

Gather service details, contact information, relevant project material, and assets the business has permission to use. Identify what is ready, what needs editing, and what still needs to be created. A folder of notes can be useful input without being approved website copy.

Assign a factual owner. The designer cannot reliably infer the limits of a service from a few phrases or decide which claims your evidence supports. Someone within the business needs to confirm scope, working arrangements, and any conditions the website will communicate.

Use real content early enough to influence the layout. A page that looks balanced with a short placeholder may become difficult to read when the offer needs a longer explanation. Designing around the actual information reveals gaps before they become expensive changes.

If content is incomplete, name the missing decision rather than let generated text invent the answer. An unsupported testimonial or experience figure can make a preview look finished while introducing a credibility problem. A quieter page with accurate information is a stronger foundation.

State constraints without fixing the solution too early

Include the existing platform, important integrations, account ownership, language requirements, and operational limitations. Explain whether changing a particular system is possible. A constraint discovered late can invalidate a proposal that otherwise seemed suitable.

Budget and timing belong in the same conversation. If a launch date depends on an event, make that dependency explicit. If investment is provisional, distinguish essential work from ideas that can be reconsidered. The designer can then explain trade-offs without guessing which condition matters most.

Avoid prescribing a plugin or framework unless it is an established requirement. Describe what the system must enable and allow the provider to assess whether existing capabilities can meet the need. Additional tools create responsibilities as well as possibilities.

My website budget guide explains why scope and operating costs should be considered together. A constraint is useful when it clarifies the decision, rather than simply narrowing the project to a solution that has not been justified.

Use references to explain qualities, not to request copying

When sharing other websites, identify the specific quality you find useful. It may be readable typography, a clear comparison, a restrained navigation system, or an understandable contact route. Explain how that quality relates to your own content and audience.

Also describe what does not fit. A reference may have a strong layout while relying on imagery you do not possess or a service model unlike yours. This helps the designer use the observation without inheriting unrelated assumptions.

Choose a small, purposeful set of examples. A large collection of incompatible styles can leave the team uncertain about your priorities. References should support a conversation about the problem rather than replace the brief with a mood board.

My article on learning from competitor websites explores the limits of visible evidence. A competitor’s presentation does not reveal whether its journey performs well or what resources support it. Your website still needs an independent rationale.

Agree who can make which decisions

Identify who confirms facts and who can approve scope, design, and expenditure. If several stakeholders contribute, combine their feedback before issuing instructions. Conflicting comments arriving separately can force the designer to interpret a decision the business has not made.

Define which choices can be resolved within the agreed brief. Routine design decisions need enough freedom for the work to progress. A material change to the offer, cost, or customer journey may need a different discussion. These boundaries protect both momentum and accountability.

Keep a concise record of significant decisions: the issue, the choice, the reason, and any assumption still to be checked. It helps when a later stakeholder asks why a section was removed or a feature deferred. Record an accepted limitation as clearly as an approved addition.

The designer should also explain when new information changes the recommendation. A brief can evolve as the team learns. The important point is to update the shared understanding and assess the effect on scope, rather than quietly implementing a different project.

Give feedback in relation to the intended outcome

Describe what seems unclear and connect it to the audience task. If the two service options are difficult to distinguish, say where the explanation fails. Let the designer propose an appropriate response before insisting on a particular card layout or button treatment.

Personal preference is still legitimate, especially on a website representing you directly. State it as a preference and explain why it matters. You do not need to turn a dislike of a colour into an unsupported claim about what every visitor expects.

Review the complete journey with real content. A section may look strong in isolation but appear before the information needed to understand it. On a phone, the order and amount of information can become more apparent than in a wide desktop preview.

When requesting a revision, explain the expected improvement. A comment such as ‘make this stronger’ leaves the team guessing. Identifying that the opening does not explain who the service suits gives the next version a concrete question to answer.

Include handover and continuing responsibility

The brief should address how the business will operate the delivered site. Agree the required access, ordinary publishing tasks, documentation, and support boundaries. A successful launch is incomplete if nobody can update essential information or knows who handles faults.

Clarify what is included in correction of delivered defects and what belongs to ongoing maintenance or new work. Consider account ownership, paid licences, and the possibility of another professional taking over. These conditions affect the project’s useful life.

My article on choosing a web developer in Mauritius explains how those expectations make proposals more comparable. Include them before selection where possible, so that a low build price is not mistaken for the complete operating cost.

A strong brief makes the problem understandable and gives expertise room to improve the response. It should leave you able to assess a recommendation against the business and user need. Where that need remains uncertain, establish the evidence before commissioning a larger intervention. The next useful step may be clarification rather than another feature.