All articles

Business needs & planning

How to write a website brief around your business needs

Turn a broad idea into a clear website or system brief with customer tasks, priorities, example workflows and testable acceptance criteria.

Aites4 min read
Customer needs connected to a prioritised website project plan

A useful website brief explains the problem before prescribing the technology. “We need a modern website” describes a preference. “Customers cannot compare our services or submit a complete enquiry” identifies a task the project can address. Start with the second kind of statement.

Describe the offer and the customer

Write one sentence covering what you provide, who needs it and the situation in which they seek it. Then list the questions customers ask before choosing you. Use actual conversations, enquiries and feedback rather than inventing an ideal visitor.

For example: “We design custom shelving for small shops. Owners need to know whether we cover their location, what measurements to send and how installation works.” Those questions already suggest useful page content and form fields.

Review competitors to understand expectations

Look at a few relevant businesses serving a similar customer. Record how they explain services, demonstrate work and guide an enquiry. Note missing answers as well as good ideas. The purpose is to understand the decision customers face, not copy another company’s text or design.

Separate observations from assumptions. “The competitor asks for dimensions” is an observation. “Our customers will abandon a form with five fields” is a hypothesis that needs testing with your own audience.

Map one complete workflow

Write the steps from discovery to completion. In the shelving example: read the service page, view an installation, submit location and dimensions, receive confirmation, then hear from the team. Include the internal work: who receives the request, checks it and responds?

This often reveals that the project needs more than a public page. If requests require approvals, status tracking or integration with another tool, describe those rules. A custom website or system should be assessed against the workflow, not commissioned simply because it sounds more advanced.

Sort features into launch and later

Mark each item as essential for a complete first journey, helpful soon or optional. For the shelving business, a working enquiry form may be essential. A customer portal may be deferred if the team can initially manage a small volume of requests through its existing process.

For every requested feature, ask: who uses it, what problem does it solve, what information does it need and who maintains it? If you cannot answer, keep it out of the initial commitment until the need is clearer.

Write acceptance criteria people can test

Replace “easy form” with a specific outcome: a visitor can submit the agreed fields on mobile, sees confirmation and the assigned team receives the request. Replace “multilingual site” with a list of required languages and journeys, including navigation, forms and errors.

  • Project goal and the customer problem.
  • Main audience and its questions.
  • Required pages, languages and content owner.
  • Main journey and internal follow-up process.
  • Essential integrations and access permissions.
  • Launch priorities, later items and agreed exclusions.
  • Budget range, target date and dependencies.
  • Acceptance checks and maintenance responsibility.

Use the brief to compare proposals

Send the same brief to each provider and compare what is included, what is assumed and what requires your input. A lower price may cover fewer pages or leave content preparation to you. Resolve these differences before choosing. You can share your project requirements once the brief describes a concrete need.

Keep reading