A website redesign brief that gets useful answers

Begin with the decision your customer is making

“We need a modern website” is a starting feeling, not yet a project brief. A useful brief says who the website is for, what they need to understand and what they should do next. That gives the design a purpose and makes proposals easier to compare.

For a Buffalo or Erie County service business, the next step might be an estimate request, a phone conversation or a project inquiry. Choose a primary action. Explain what a qualified inquiry looks like so that a form can collect useful details without becoming a long application.

1. Describe the actual business

• What do you sell, and which one or two service lines matter most?
• Who is a good fit, and who is outside the scope?
• Where do you deliver the service? Distinguish online work, customer visits and a staffed location.
• What should a visitor know before contacting you?
• Which claims, qualifications and examples can you support?

Be specific about geography. Serving customers in Amherst or Hamburg does not imply a public office there. If the business works online, say so. Accurate service information is more useful than a list of town names pasted into every paragraph.

2. Inventory the content before redesigning it

List the current URLs, page titles and purpose of each page. Mark what should remain, what needs rewriting and what can be retired. Identify pages that receive valuable inquiries or search visits before merging them.

Collect approved service facts, contact details, photographs and evidence for any testimonials or results you want to publish. Record media permission and the person who can approve factual changes. A missing logo file is inconvenient; an unsupported business claim can change the entire page.

If URLs will change, use the migration checklist to map each useful old address to the most relevant new destination.

3. Decide who edits and what the site must do

Describe updates in everyday terms: “I change opening hours twice a year,” “our team publishes weekly,” or “prices come from another system.” Those are different requirements. A custom static website may fit infrequent changes; regular nontechnical publishing may justify a separately scoped CMS.

• Does the site need only an inquiry form, or does it need booking or payment?
• Will people sign in or view private information?
• Does data move into a CRM or another service?
• Who maintains integrations and pays the provider bills?
• What happens if an external service is unavailable?

Write required features separately from ideas that would be nice later. That protects the initial project from quietly becoming a different product.

4. Define how the project gets approved

Name one approver, input dates and realistic review windows. Agree which pages, form paths, phone sizes, keyboard actions and recovery steps must work. Capture changes in one consolidated list so decisions do not conflict across messages.

Before launch, approval should identify the actual version and destination. After launch, handoff should include paid source, assets and licenses, account ownership, provider renewals, form-data handling and recovery notes. Wonder and Method includes 30 calendar days of correction for defects against accepted scope; later Care or Search is optional.

See the studio process, compare website scopes, then start a conversation.