One partner wants a dramatic homepage. Another wants better practice-area pages. Intake wants the form repaired. The designer receives all three requests and is asked for a proposal before anyone has decided which problem the project should solve.
Have that conversation before the designer starts. A useful website brief gives the team a shared explanation of the problem, the work you're asking for, and how you'll check the result. It can save you from trying to settle the project's purpose by arguing over a mockup.
You don't need a long document to begin, just enough specific information for the team to make decisions without guessing.
Key takeaways
- Start with a problem the team can inspect and the tasks important visitors need to complete.
- Assign responsibility for verified content and consolidated approvals, then turn broad requirements into acceptance tests.
- Use the brief after launch to check the public website and review whether the original problem is improving.
State the business problem in observable terms
“Modernize the website” describes an intention, but it doesn't say what needs to improve. Identify a problem the team can inspect.
For a hypothetical employment-law firm, the problem might be: “Visitors can't distinguish severance review from litigation representation, and intake receives repeated inquiries based on that confusion.” That leads to a clearer requirement: explain each service and provide the appropriate contact route.
Use current evidence where available. If you don't know the inquiry pattern yet, make discovery part of the scope rather than inventing a baseline.
Name the audiences and their tasks
Identify the important groups without assuming everyone wants the same next step. Prospective clients need service information. Referring lawyers may need practice scope and attorney contacts. Recruits may need employment information.
For each priority audience, record a task: find a suitable practice area, evaluate attorney experience, understand the consultation process, or contact the right team. Those tasks help the designer choose navigation and content structure.
You don't need to invent a visitor's age, hobbies, and life story to give the designer useful direction. Start with the questions intake really hears, because those show what someone needs to learn from the page.
Include the facts and content the firm must supply
List the pages that will be retained, revised, or created. Identify who provides service descriptions, credentials, photographs, and approved claims. Assign an attorney reviewer for legal information.
Let the writer suggest a clearer explanation of the consultation process, then have the firm check it. Does someone actually call back within that period? Is the first conversation really with an attorney? Clear wording only helps if it describes what happens.
Provide realistic sample copy early, because long attorney names, substantive headings, and real comparison tables can change the layout in ways that placeholder text won't expose.
Write a brief the team can use
Here is an abbreviated example for a fictional firm. It illustrates the level of detail; the services and requirements aren't claims about a real client.
Purpose: Make the firm's two employment services understandable and route initial inquiries to the relevant team.
Priority visitors: People considering severance review or representation in an employment dispute in the jurisdiction the firm serves.
Launch scope: Updated homepage, two distinct service pages, attorney biographies, and a tested inquiry route. Existing educational articles remain available and are inventoried for later review.
Content responsibility: The practice lead verifies service scope and legal explanations. The project editor organizes the copy. One internal approver consolidates feedback.
Contact requirement: An initial form records basic contact information and the service being asked about. Detailed legal information uses the firm's approved intake process. Test messages must reach the assigned team.
Acceptance: A visitor can distinguish the services, find relevant attorney information, and submit an inquiry at phone, intermediate, and desktop widths. Keyboard and enlarged-text tests are included.
Search continuity: Preserve useful existing URLs. Any approved replacement needs a permanent redirect, updated links and canonical references, and live verification.
After launch: The firm controls essential accounts. A named owner maintains service facts and receives failure alerts. Marketing reviews broad inquiry patterns against the original problem.
There's still plenty for the designer to decide in that brief. What they don't have to guess is what the firm needs the site to explain or what a successful inquiry process should do.
Turn broad requirements into acceptance tests
“Mobile-friendly” should become a task someone can perform. “Accessible” needs a defined technical target and evaluation scope. “Fast” needs a measurement method and realistic performance criteria.
Check the visitor experience with manual tests as well as automated tools. W3C's accessibility checks help introduce that work. Assess the firm's legal obligations separately rather than treating a technical target as a universal legal guarantee.
For analytics, identify the decisions the firm wants to make and the permitted data collection. More tracking isn't automatically better, especially if it turns confidential intake detail into a marketing event parameter by default.
Agree on scope, decisions, and changes
State what the proposal includes: discovery, design, copy, development, migration, testing, and maintenance may be priced separately. Identify dependencies such as attorney review or access to an existing platform.
Give one person responsibility for consolidated feedback and identify the final approver. If partners disagree, resolve the decision within the firm before asking the designer to interpret conflicting instructions.
When someone requests another feature, discuss what it adds to the price and schedule. The integration may be worth doing, and treating it as a new decision gives both teams a clearer agreement than pretending it was part of the original brief.
Use the brief after launch
Verify the acceptance tasks on the production site. Record unresolved items and their owners. Then review the business question the project was meant to address.
You can test whether the form works as soon as the site launches. To find out whether inquiries are a better fit, you'll need to review what comes in afterward. Search rankings need their own evidence, too; a new design doesn't promise an improvement.
Start with the problem, the audience, and three tasks the website needs to support. Morpheus Consulting Inc. can help turn those decisions into a usable design brief and an appropriate project scope.
