Case 03 · pawaTech · UX review · Under NDA
UX problems, on the record
A monthly review that walks the live product against known usability principles and comes out as a ranked roadmap rather than a list of complaints.
- Role
- Head of Product Design & UX · UX review
- When
- Monthly, since Apr 2025
- Where
- betPawa · 9 live journeys
Challenge
Everyone knew the basic UX problems. Nothing recorded them, so they never competed for the roadmap and nobody could say whether the experience was improving.
Approach
Walk the journeys that matter on the live product, judge every finding against a named principle, and rank it by severity.
Result
The whole product reviewed in days instead of a quarter, ending in one prioritised list that design, product and tech work through together.
The problem
What was actually wrong
Every product carries a layer of problems everyone has met and nobody has written down: the confusing step in registration, the error message that explains nothing, the button you keep missing.
With no record they never reach a planning meeting, and quality stays an opinion — which loses every argument against a feature that has a number attached to it.
Before
After
My role
Who did what
Mine
- Defined what gets reviewed, what it is judged against, and what a finding must contain before it counts.
- Chose known usability laws as the standard, so every finding cites a principle rather than a preference.
- Picked the journeys by value — registration, payments, navigation — not by how easy they are to test.
- Insisted on reviewing the live product, where customers actually are.
- Made the output a ranked roadmap the teams work through, not a report that gets read once.
The team’s
- Design owns the findings in their areas and decides what a good fix looks like.
- Product weighs them against everything else competing for the roadmap.
- Tech closes them, and the next review says whether the fix held.
Process
How it went
- 01
Pick journeys by value
Registration, payments, navigation — where the money and the frustration are, and on the live product rather than on staging, because the difference between the two is the problems nobody has recorded.
- 02
Judge against a named principle
Every finding cites a known usability law, so a designer, a product manager and an engineer argue on the same ground.
- 03
Record what works, too
A review that only collects faults reads as an attack on the team that built it, and gets defended against instead of acted on.
- 04
End in a ranked roadmap
Severity turns the findings into one prioritised list across the product — a plan, not a verdict.
A list of problems
A list of problems and fixes
Decisions
What was chosen, and what it cost
Reviewing the live product
- Over
- Reviewing a staging environment
- Because
- The gap between the two is exactly the set of problems nobody has recorded.
- It cost
- Real journeys and real data, so the review has to be designed carefully rather than pointed and fired.
Judging against named principles
- Over
- Asking a model what it thinks of the experience
- Because
- A finding has to be arguable, with reasoning anyone in the room can check or challenge.
- It cost
- Principles miss what they were never written for, so this sets a floor on quality rather than a ceiling.
Ending in a ranked list
- Over
- Handing the findings over and letting teams triage
- Because
- A list of problems is work for whoever receives it. A ranked roadmap is a decision already made.
- It cost
- Ranking is a judgement call, and you own the argument when a team disagrees with where their issue landed.
Outcome
What came of it
The whole product gets covered against a known standard in days, so the problems are on the table while there is still time to act on them.
The output is a roadmap: every finding ranked and explained, worked through by design, product and tech together.
It sets a floor rather than a ceiling — it catches what should never have shipped, which frees research and design for the questions a principle cannot answer.
Lesson
What it cost me to learn
A review that only lists faults reads as an attack on the people who built the thing. Recording what works alongside what does not, and ending in a ranked plan, is what made teams ask for the next one.