Should a London product team commission a UX audit or redesign?

A London product team should commission a UX audit when it can point to a troubled journey but still needs to learn why it fails. It should commission a redesign when the problem is supported by evidence, an accountable owner can choose a direction, and the team can implement and evaluate the change. If any of those conditions are missing, buy the work that closes that gap first.

The choice is about the next decision, not the size of the interface. A large product can need a narrow investigation. A small flow can require a redesign when the cause and constraints are already clear.

What should an audit establish?

An audit should connect a specific user task to evidence about where it becomes difficult. That evidence might include product analytics, support themes, usability sessions, research already held by the company, or an expert review of the interface. The report should label what was observed separately from what the team suspects.

For example, a subscription product may show a sharp exit during account setup. That tells the team where to look, not why people leave. Interviews or task observation may reveal that users do not understand a permission request, while support messages may point to an unclear recovery path. Each explanation suggests different design work.

Use an audit when the team cannot yet answer:

• Which user and task are affected?
• What evidence points to the failure?
• Which product, service, or operational dependency might explain it?
• What decision should the next piece of work enable?

Research can be planned for London users without assuming a single “London customer” profile. Write recruitment criteria around the real product roles, recent experience, devices, and access needs in scope. GOV.UK’s participant guidance recommends criteria tied to the research question and a spread of participants; that is useful planning guidance for product teams, not a rule that governs private companies. Read the participant recruitment guidance.

When is a redesign ready to start?

Move into redesign when the team has enough evidence to define the problem and the people with authority to resolve product questions can take part. The design team also needs a path to implementation. If engineering cannot make the proposed changes, the brief should account for that constraint before interface work begins.

Readiness does not mean every uncertainty is gone. It means the remaining questions are visible and can be tested within the redesign. A team might know that people cannot distinguish a saved draft from a submitted application, while still needing to test the clearest wording and status treatment.

Before asking an agency for redesign work, confirm who will approve product behavior, provide technical context, handle dependencies, and assess the released change. If there is no implementation owner, a polished prototype may answer a design question while leaving the business problem untouched.

How can a team choose the right scope?

Use this short decision path before comparing proposals:

1. The failure is unclear. Choose an audit or focused research phase. Ask for evidence, prioritized findings, and a decision meeting.
2. The failure is known, but causes or constraints are uncertain. Commission a bounded discovery phase that tests those uncertainties before committing to a full redesign.
3. The failure and constraints are understood, and an implementation owner is available. Commission redesign work with testing and handoff included.
4. The team cannot implement or measure a change yet. Resolve that dependency or scope it explicitly before paying for a full redesign.

For every option, ask what artifact will make the next decision easier. “Recommendations” is not precise enough. A useful audit output may map a finding to its source, affected task, confidence, proposed response, and owner. A redesign output may include tested flows, specifications, accessibility states, and a handoff the product team can use.

What should a London brief include?

Give each candidate the same short evidence pack: the journey, what the team has observed, relevant analytics or support material, known technical limits, and the decision the work should enable. State whether the team expects on-site sessions, remote research, or a mix. The right format depends on participants and tasks. GOV.UK guidance notes that remote research can widen access but may miss contextual information, and the team should choose a format that suits participants and the task. Compare remote research considerations.

Ask who recruits participants, what happens if access is delayed, who attends decision sessions, and which internal people must be available for implementation questions. London-based teams may choose hybrid sessions for practical scheduling, but the arrangement should follow the participant’s needs and the work, rather than the agency’s default.

How should the work be evaluated?

Agree on a test before selecting a visual direction. Define the task, intended users, evidence of completion, and any important failure or misunderstanding to watch for. GOV.UK’s moderated testing guidance recommends believable tasks that do not reveal the answer. Its task-design guidance is a useful model for testing a current flow and a proposed one consistently.

Keep the threshold proportional to the method. A few sessions can uncover a confusing label or missing state; they do not estimate how common the problem is across a market. Product analytics after release can answer a different question, if the events are reliable and the team accounts for other changes.

For a starting point on the brief and baseline, see the product redesign baseline guide. London teams can also review Humbleteam’s London product design services while comparing research and delivery options.