Start with a decision, not a style
“Make it modern” describes a preference. It does not say what the website needs to do. Start by naming the decision your visitor should be able to make: request a proposal, compare a product, book a consultation or understand whether you are the right partner. Pick the most important action for each page. A page with five equally loud priorities makes the visitor do the prioritization themselves.
Write one sentence: “This page helps [audience] decide [decision] by showing [evidence].” Keep it beside the design during review.
Describe the audience’s situation
A useful audience description goes beyond age and location. Explain what brought someone to the page, what they already know and what might make them hesitate. A first-time store visitor may need delivery clarity; a returning buyer may simply need to find the right variation. Those are different design problems even when the product is the same.
Collect three questions customers actually ask. If no customer evidence exists yet, label the questions as assumptions to test.
Inventory the evidence you already have
List the material the site can use: product photographs, approved copy, service scopes, original work, genuine customer feedback and business details. Identify who owns each item and whether permission is needed. A case study without a result can still explain the problem and the work honestly. An invented result cannot make the brief stronger.
Create three columns: ready, needs approval, needs creation. Give every missing item an owner before estimating the launch date.
Separate essentials from later improvements
A working inquiry route may be essential. A complex customer portal might be a later phase. Record each feature with its user, purpose, required inputs and expected result. This makes it easier to distinguish a real need from a fashionable interaction. It also reveals dependencies: a catalogue cannot be accurate before product information exists.
For each feature ask: can the core customer journey work without it at launch? If yes, it can be discussed as a later phase.
Define what “finished” means
Acceptance criteria should describe observable behavior. “The mobile menu works” is less useful than “the menu opens by keyboard and touch, exposes all primary routes, closes after selection and leaves the destination readable.” Include error, empty and loading states where the feature needs them. Agree who reviews content, who tests and who signs off.
Use a short launch list: routes, content, responsive layout, accessibility, forms, metadata, hosting and handover. Record incomplete items instead of hiding them.
A brief you can use today
Write the business objective, primary audience, key action, required pages, available evidence, essential features, constraints and approval owner. Add the existing URL if there is one. You do not need to solve the design before speaking to a team; you need enough context to have a specific conversation.
Bring this brief to discovery. The next step is to challenge assumptions and agree scope—not to treat the first draft as an unchangeable specification.
Bring your next question.
Share your website or store and tell us what you want to improve. We can discuss the right service or digital audit.
Start a conversation ↗