Brand websites and digital experience: from structure to task completion

How can a brand website support both identity and useful work?

A brand website should help visitors understand who the organisation is, what it can help with, why its claims deserve consideration, and what to do next. Start with a small set of important visitor tasks. Give each task an entry point, a complete explanation, credible evidence and an appropriate action. Visual identity, information architecture and interaction design serve different parts of that job. A striking homepage cannot compensate for missing evidence or an unusable inquiry form. The procedures below are editorial recommendations, and the examples describe hypothetical organisations rather than reported client results.

Translate departmental content into visitor questions

The GOV.UK principle of solving a whole problem places user needs ahead of organisational divisions or a predetermined technology.[S1] Applied to a company website, this means asking what a purchaser must understand before comparing options. A page called “Technology department” might instead answer how a proposed service handles business information. Recruitment and procurement visitors need different routes; forcing every visitor through the same sales funnel can obscure useful content. State which audience a page serves, and which decisions it intentionally leaves to a later conversation.

Step one: write task cards with observable outcomes

Collect inquiry records, site searches, questions heard by sales teams and existing pages. Mark assumptions when evidence is missing. A researcher should discuss recent decisions with intended visitors, while a content owner converts those findings into task cards. Each card records the situation, intended reader, question, starting point, required information, concerns, completion action and fallback support. The output is a prioritised task inventory linked to proposed pages. For enterprise knowledge search, a plausible task is understanding source documents, permission boundaries, evaluation scope and preparation for consultation. “Understand our innovation” is too vague to test. Do not invent a research finding simply because the team agrees that it sounds plausible.

Step two: test the structure without relying on visual cues

Use exploratory card sorting to examine how readers group topics, followed by a text navigation exercise to see whether they can locate answers. Record first choices, mistaken branches and reasons for giving up. Preference for a label is different from successful navigation. Pair specialist terminology with a concrete explanation, such as “Enterprise knowledge management: organise, find and update company knowledge.” Important explanations need their own stable URLs so that a reader can share, revisit and cite them. Do not make a hover state or a content modal the only way to read essential information. Keep related pages linked without creating several contradictory copies of the same answer.

Step three: make each page a complete decision unit

Give the content owner a working sheet with audience, problem, method, inputs, outputs, limitations, evidence and next action. Replace “improves productivity” with the task the proposed system is intended to perform: answer questions from specified documents, provide source references and indicate when information is insufficient. If that behaviour is an evaluation objective, label it accordingly. An architecture diagram can clarify roles and information movement, but it does not establish operational readiness. Explain what the diagram represents in selectable text, identify important conditions, and distinguish an illustrative workflow from a verified production capability.

Step four: design failure and return paths

Walk through discovery, article reading, related capability pages, inquiry, submission feedback and return navigation. Button labels should describe the actual action. Forms should explain why information is needed and identify errors beside the affected fields. Client-side navigation still needs an updated URL, document title, focus position and browser history. Smooth animation without these behaviours can strand keyboard users or make the Back button misleading. When readers return to a long explanation, preserve an understandable reading context. Give people a way to continue without submitting unnecessary personal information, and test what happens if a request fails or a network connection is interrupted.

Hypothetical scenario: a comparison route for procurement

Imagine a maintenance software provider with three similarly named plans. Research questions focus on how a purchaser compares site coverage, integration and support. A proposed comparison page uses the same fields for all plans and links to detailed explanations. The test task asks a visitor to find an option for two locations, explain integration requirements and identify what still requires confirmation. The team records whether the person can answer accurately without coaching. This is an executable study design, not a claim that the redesign increased sales. Findings could show that the commercial offer itself needs clarification before any interface change will help.

Step five: check accessibility and the complete journey

WCAG 2.2 includes a reflow requirement at an equivalent width of 320 CSS pixels, with exceptions for content that necessarily needs two dimensions.[S2] A 375-pixel screenshot alone does not establish conformance. Test text enlargement, keyboard navigation, visible focus, image alternatives, field errors and browser history as well as narrow layouts. GOV.UK describes task observation as a way to benchmark whole websites and journeys.[S3] Keep a record of the failing step, observed behaviour and likely obstacle. A small exploratory study identifies issues; it does not justify a population-wide completion percentage or a complete accessibility claim.

Measure whether visitors can make the intended decision

Record successful task attempts divided by actual attempts, time to locate an answer, mistaken routes, completeness of inquiries and the quality of subsequent questions. Define success before observing results. Clicking a button may not mean that a visitor understood the offer. When comparing versions, keep tasks and participant conditions comparable and record campaigns, product changes and seasonal influences. Do not send inquiry text or sensitive form values to analytics merely because an event platform accepts them. A useful dashboard connects a change to a specific visitor obstacle and shows uncertainty when data is limited.

Common mistakes and limits

Departmental navigation labels, repeated vague promises, homepage-only testing and a chat box that replaces written explanations are concrete problems to audit. Low traffic may make a split experiment uninformative; interviews, task testing and inquiry analysis can be more useful initially. Search and generative discovery benefit from clear questions, direct answers, readable text and traceable sources, but these practices do not guarantee rankings or AI citations. Assign a content owner and review triggers such as a changed offer, broken integration, expired claim or repeated support question. Improvement may require correcting service delivery rather than adding another page.

Frequently asked questions

Does a website convert better simply because it has fewer pages? No. Decide which explanations must stand alone to support a task; excessive consolidation can make answers difficult to find. Can diagrams replace technical articles? No. Explain roles, information movement, limitations and supporting evidence in text as well. Is a complete redesign always necessary? No. Begin with the journey causing the greatest difficulty, and widen the change only when a shared structural problem requires it. The acceptance record should show what was tested, under which conditions, and what remains uncertain.

Sources and evidence boundaries

1. S1 · GOV.UK Service Standard: Solve a whole problem for users

   Government Digital Service · Accessed 2026-10-22

   Supports the cited principle; operational steps and illustrative scenarios are editorial recommendations rather than reported customer results.

2. S2 · Web Content Accessibility Guidelines (WCAG) 2.2

   W3C · Accessed 2026-10-22

   Supports the cited principle; operational steps and illustrative scenarios are editorial recommendations rather than reported customer results.

3. S3 · Usability benchmarking a website or whole service

   Government Digital Service · Accessed 2026-10-22

   Supports the cited principle; operational steps and illustrative scenarios are editorial recommendations rather than reported customer results.