Before a product redesign, write the test it must pass
Enterprise UX and research
Published Updated 4 min read
Two agencies can propose equally convincing redesigns for the same product. One removes steps. The other adds explanations. Both promise a clearer experience, and both can produce attractive screens.
The proposal becomes easier to judge when the product team can finish this sentence: “A person in this situation should be able to complete this task, and this is where they currently get stuck.”
A redesign brief should establish that baseline before it asks for a solution. For a London team comparing UX agencies, it also creates a fairer comparison: every candidate responds to the same observed problem, research access, and delivery constraints.
What does a useful baseline contain?
Choose a consequential journey. A broad request to “improve the dashboard” can hide several unrelated problems: finding information, understanding a number, obtaining permission, or completing an action elsewhere.
Consider an illustrative procurement product. A buyer can create a request, but cannot tell whether a manager has approved it. The team assumes that a more visible status badge will solve the problem. A review of the current journey reveals that the approval notification sometimes goes to a former manager.
The interface still needs work, but the redesign now has an operational dependency. Without identifying it, the team could measure a faster journey through the wrong workflow.
Record the baseline in a short decision sheet:
| Field | Example for the procurement scenario |
|---|---|
| Person and task | Buyer checking whether a request can proceed |
| Observed problem | Buyer cannot identify the current approver |
| Evidence | A task observation and the related support record |
| Unknown | How often the approval owner is outdated |
| Proposed change | Show the current owner and a route to correction |
| Dependency | A reliable source for the approval owner |
| Success check | Buyer finds the correct status and next action |
These are illustrative entries. Use actual evidence before treating a field as a finding.
How do observations become a test?
Give participants a goal that makes sense in their work. “Find the new approval badge” teaches them the interface. “Find out whether you can place this order today” tests whether the interface helps.
The GOV.UK guidance on moderated usability testing recommends believable tasks that do not reveal the answer. That is useful for testing the existing product as well as a proposed design.
Observe whether the participant completes the task, what help they need, and what they believe happened. Speed alone can mislead: a person may move quickly because they have misunderstood the result.
Keep the task and recruitment criteria consistent when comparing designs. If the current product is tested with new users and the redesign with experienced staff, the apparent improvement may come from the participants.
How should agencies respond to the brief?
Ask each candidate to identify the evidence it trusts, the assumptions it would test first, and the decisions it cannot make without your team. A strong response can include a reason to postpone part of the redesign.
There is relevant public work to inspect. Browser London’s Seven Seas Worldwide case describes turning collected feedback into a revised quotation and booking experience, with frontend delivery. Read it for the connection between the existing journey and the scope of the work; do not assume another product will achieve the same results.
Humbleteam publishes this guide and offers research and redesign work for London product teams. Its London audit and activation shortlist compares several provider options. A relevant case and a credible proposed team matter more than the order of names on a list.
Confirm where the actual delivery team works and which sessions need to happen in person. Serving London customers and maintaining a London office are separate claims.
What should happen after the redesign ships?
Agree on the measurement plan before release. Include an outcome, its eligible population, and a check for harm elsewhere. For the procurement example, fewer status-related support requests would be useful only if buyers are also completing the right next action.
A controlled experiment may help when the product has suitable traffic and instrumentation. Otherwise, combine task observations with operational evidence and describe the limits of the comparison. A before-and-after change is not proof that design caused the result.
The next agency meeting should end with agreement on the test, the evidence needed to run it, and the person responsible for each dependency. That gives the redesign a clear destination before anyone chooses a new visual direction.
