Start with one customer task
“We need a modern website” leaves almost every expensive decision open. A more useful brief says: “A property manager should be able to understand our maintenance services, check our coverage area, and send a request with photos from a phone.” That sentence gives a designer a journey to organize and a developer a flow to test.
Write down the main visitor, the decision they need to make, and the action the website should help them complete. If there are several audiences, rank them. A site for prospective customers and job applicants can serve both, but the homepage still needs an order of importance. Treat that order as a business decision, not a layout preference.
List page types, not just a page count
Ten pages can mean ten carefully designed layouts or one service template filled ten times. Those are different scopes. List each type of page, the number of entries, and the information it needs. For a small service business, that might be a homepage, a reusable service detail page, an about page, a contact page, and a reusable article page.
Then name the less visible states: the mobile menu, a failed form submission, a thank-you message, a missing page, and an empty search result if search is included. These states affect how finished the site feels. Ask whether they are included in the proposal rather than assuming they are part of a general “responsive design” line item.
Make the content work visible
Create a simple content inventory with four columns: item, current location, person supplying it, and due date. Include service descriptions, photographs, product data, brand files, and any case studies you have permission to publish. Mark whether existing text needs editing or a full rewrite. A blank content plan is a schedule risk even when the design is ready.
Separate real evidence from material you would like to have. A customer quotation needs an actual source and permission. A concept image can explain a design direction, but it should not be presented as a delivered customer project. If proof is limited, show the work itself and describe the scope precisely. Specific, modest evidence is more useful than impressive claims nobody can verify.
Describe what happens after submission
“Contact form” is not a complete requirement. Specify the information collected, who can access it, where the submission is stored, whether anyone receives an email, and what the visitor sees next. For a quote request, decide whether an attachment is truly necessary at the first step. Every extra field adds another decision for the visitor and another piece of information to manage.
The W3C forms guidance recommends clear labels, useful instructions, and feedback for success and errors. Put those behaviors in the brief. A concrete acceptance check might be: “On a phone, submit an incomplete request, correct the identified field without losing the message, then confirm the completed request appears in the owner’s inbox.” That describes an outcome both parties can inspect.
Reference: W3C WAI: Forms tutorial (opens in a new tab)
Protect the useful parts of your existing site
A redesign should begin with an inventory of current URLs, especially pages that receive inquiries, search traffic, or links from elsewhere. Record which pages stay, which merge, and which disappear. Share any existing analytics and Search Console access through an appropriate account invitation rather than putting passwords in the brief.
If URLs change, Google recommends mapping old addresses to relevant new destinations, using permanent redirects, and updating internal links and sitemaps. Ask for that work explicitly. Sending every retired page to the homepage is not a thoughtful migration plan. Also decide who will check for errors after launch and how long that follow-up is included.
Reference: Google Search Central: Site moves with URL changes (opens in a new tab)
Compare proposals against the same finish line
End the brief with responsibilities and acceptance. Name who supplies copy, who approves designs, who owns the domain and hosting accounts, and who makes ordinary edits afterward. List recurring services separately from the build fee. Ask what is included in support, how changes outside scope are priced, and what files and access you receive at handover.
You do not need to prescribe a framework to write a useful brief. You need a shared definition of the work. Send the same brief to each provider, ask them to identify assumptions, and compare the proposed result rather than the number of pages in the proposal. Before signing, walk through one complete customer journey together. Any unanswered step belongs in the scope.
