This note turns the central question into concrete decisions, checks, boundaries, and ownership.
The symptom is usually visual, but the cause is verbal
A team often asks for a new homepage after noticing that the current one feels dated, crowded, or indistinguishable from competitors. Those observations may be accurate, but a layout cannot decide who the offer is for, which problem matters most, or why the organisation is a credible choice. If those decisions remain unresolved, a redesign merely gives the ambiguity better typography. Start by writing the claim the page must earn. Then list the evidence available today: process details, constraints, examples, qualifications, ownership, or useful specificity. The gap between claim and evidence is the real brief.
Write the audience decision, not an audience persona
A fictional persona with a name, age, and favourite coffee rarely helps determine page order. Instead, identify the decision a real visitor is trying to make. They may be deciding whether the service fits their scale, whether an approach is safe, whether a programme is accessible, or whether the team can support a migration. Write the decision as a question. For example: ‘Can this studio replace our inherited website without losing findability?’ A precise question tells the homepage what to explain and tells supporting pages what evidence to carry.
Separate the offer from the list of capabilities
Capabilities describe what a team can do. An offer explains which connected set of capabilities solves a meaningful situation. Branding, content modelling, interface design, development, and maintenance are not automatically an offer when placed in six boxes. Connect them through a sequence and a boundary. State when the sequence is appropriate, what the client must bring, and what the studio will not pretend to guarantee. A smaller service menu with visible logic feels more credible than an exhaustive menu built to capture every possible keyword.
Use an evidence inventory before writing headlines
Create four columns: claim, evidence, source, and freshness. A claim such as ‘accessible by default’ requires evidence in process, components, testing, and ownership. A claim such as ‘easy to maintain’ requires named content patterns, documentation, access controls, and a rehearsal of a normal update. If a claim has no evidence, weaken it or convert it into an objective. If evidence exists but is confidential, decide what can be described without inventing a client story. This inventory prevents decorative case studies and unsupported performance promises.
Choose one remembered sentence
The homepage does not need one sentence total, but it benefits from one sentence that can survive a phone call. It should say what the organisation changes, for whom, and how it approaches the change. Test the sentence aloud. Remove phrases that any competitor could use, including ‘tailored solutions’, ‘passionate team’, and ‘results-driven’. Add a boundary that makes the position sharper: small organisations, inherited sites, content-heavy programmes, or accountable launches. The sentence becomes a filter for navigation, imagery, and calls to action.
Map objections into the page sequence
List the objections a reasonable visitor will have after hearing the remembered sentence. Common objections concern relevance, risk, effort, cost range, internal workload, technical ownership, and what happens after launch. Order those objections by when they arise. The page sequence should answer them without forcing the visitor to infer connections between unrelated cards. A strong sequence may move from position, to representative pattern, to method, to boundaries, to next step. Each section earns the following section instead of merely filling space.
Know when a homepage is not the next deliverable
If stakeholders cannot agree on the audience decision, evidence, or scope boundary, the next deliverable should be a short positioning workshop or content inventory—not a homepage concept. This is not delay for its own sake. It prevents expensive visual exploration around unstable assumptions. A useful stop condition is simple: if three decision-makers describe the offer in incompatible ways, do not begin high-fidelity design. Resolve the disagreement and record the resulting choice before asking design to amplify it.
A compact pre-design checklist
Before design begins, confirm that the primary audience decision is written as a question; the main offer is distinguishable from a capability list; important claims have current evidence; one memorable sentence survives plain language; objections are ordered; and a realistic next action exists. Also name the owner who can approve content and the owner who can verify technical statements. If any item is missing, label it as a project risk rather than silently filling the gap with generic copy. Clarity is not a creative limitation. It is the material from which distinctive design is made.
Run a twenty-minute plain-language test
Give a colleague who was not in the strategy meetings the current homepage, the proposed remembered sentence, and three representative service descriptions. Ask them to explain who the organisation helps, what changes, and what the visitor should do next. Do not correct them during the test. Record where they substitute a broad category for the actual offer, confuse a capability with an outcome, or search for evidence that is not present. Repeat with a second reader from outside the sector. The purpose is not statistical certainty; it is to discover whether the intended meaning survives without an insider narrating the page. Revise the sequence, then test again using the same questions.
Price and timing language need boundaries
A homepage does not always need published fees, but it should not manufacture confidence with phrases such as flexible pricing or fast turnaround. Decide what can responsibly be said: a minimum engagement shape, factors that affect effort, the sequence used to establish scope, and conditions that delay work. If no pricing position is ready, explain how scope is formed rather than hiding behind a generic contact button. Likewise, avoid promising a reply window unless someone owns it. A credible next step tells visitors what information helps, what happens locally or remotely, and what is not yet guaranteed.
Review the mobile argument separately
The desktop composition may communicate a nuanced sequence through scale and space while mobile collapses it into a long stream. Review the small-screen page as its own argument. Confirm the remembered sentence arrives before decorative context, the first supporting evidence remains nearby, labels do not become cryptic, and the primary action is not displaced by consent or fixed controls. Remove repeated orientation copy instead of merely stacking everything. Mobile direction is not a compressed screenshot; it is the same decision expressed under stricter attention and space constraints.
Document what the homepage deliberately delegates
The opening page should not contain every qualification, process detail, policy, and article. Record where each unresolved question is answered and make those routes visible at the moment the question arises. A service page can carry scope boundaries; a standards page can explain evidence; a contact route can describe the handoff; detailed notes can teach methods. This delegation prevents the homepage from becoming a wall of compressed answers while preserving a coherent journey. During review, follow each path and confirm it lands on substantive content rather than another summary and another call to action.
Turn the method into a reviewable record
Apply the ideas in A Homepage Cannot Fix an Unclear Offer to one real route, decision, or update rather than discussing the entire website in the abstract. Record the current condition, the audience question, available evidence, responsible owner, proposed change, risk, and acceptance check. Attach screenshots or route lists where they clarify the record, but do not substitute visual evidence for an explanation. Ask a reviewer who did not prepare the record to identify the decision and reproduce the check. If they cannot, revise the language or evidence. Keep the record with the project source so a future maintainer can distinguish an intentional rule from an accidental implementation detail. This small discipline reduces repeated debate and makes later corrections safer.
Use a stop condition, not endless refinement
Define what would make the recommendation inappropriate, incomplete, or unsafe. A missing content owner, unverifiable claim, inaccessible interaction, unmapped legacy route, unknown data destination, or absent recovery path may be a reason to pause. Write who can resolve the condition and what evidence allows work to continue. This prevents schedules from converting uncertainty into silent assumptions. It also protects creative work: once the named conditions and acceptance checks pass, the team can stop polishing details that do not improve the audience decision. Review the condition after an ordinary publishing cycle, because real use may reveal a different constraint from the one imagined during design.
The useful standard is a decision somebody else can understand, test, and maintain.
Questions to carry into the project
- Which decision is this work meant to improve?
- What evidence is available now, and who can verify it?
- Which owner can maintain the result after launch?
- What condition should stop, revise, or reverse the release?