Eskeil / Website planning

A website redesign brief that leaves room for better questions

Clarify audiences, content, technical constraints and acceptance checks before committing to a website redesign.

Start with the job, not the reference site

A visual reference can help a team understand your taste. It cannot explain what your business needs the website to do. Before collecting inspiration, describe the person arriving, the question they need answered and the next step you want to make possible.

For an established business, that may mean making a complex service easier to evaluate. For a new venture, it may mean helping the right visitor understand the proposition and ask a useful question. Write these needs separately. One generic promise to ‘increase engagement’ is not a testable brief.

Bring the material that makes the story credible

List the pages, product information and project evidence you already have. Mark each item as approved, in review or missing. A testimonial needs permission and attribution; a performance claim needs a definition, a date range and a source. A compelling layout cannot replace those inputs.

Decide who can approve content and how feedback will be consolidated. If five people can request changes but nobody owns the decision, a delivery estimate will hide more uncertainty than it explains.

  • Primary audience and the decision they need to make
  • One useful primary action per important page
  • Approved copy, imagery and publication permissions
  • A named content approver and a practical feedback process

Define what must keep working

Inventory the existing URLs, forms, search visibility, integrations and account boundaries before choosing what to rebuild. Agree on redirects for pages that move. Test the destination of a form, not just the success animation. Identify whether analytics is needed and what privacy decisions must precede collection.

Ask for a handover plan covering code, hosting accounts, CMS access and documentation. Ongoing updates and support are a separate scope to agree on—not something to infer from the word launch.

Agree on checks before agreeing on a launch

Useful acceptance checks might include a successful inquiry stored once, a keyboard-operable mobile menu and important content visible in the initial HTML. Choose performance checks appropriate to the real page. A laboratory score is a controlled measurement, not a guarantee about every customer’s connection.

Once the unknowns are visible, the team can propose a discovery step or a bounded first release. Neither a public fixed price nor a confident deadline can remove unresolved content, integration or approval dependencies.

  • Owner, evidence and expected behavior for each acceptance check
  • A staging review with synthetic data
  • Backup and rollback responsibilities
  • A decision on what will deliberately wait until after launch