Independent UX Audit · B2B SaaS
Your product has UX problems your team has stopped noticing.
I independently audit complex SaaS products, combining hands-on expert review with agentic exploration. The output isn't a UX presentation — it's a prioritised, evidence-backed, engineering-ready backlog showing what's broken, why it matters, and what to fix first.
- Experience
- 7 years building products
- Shipped
- 20+ products, most of them operational SaaS
- Built
- Dashboards, design systems, enterprise workflows
Illustrative findings in the report's real format. Not a client's product, and not real data.
01 — Coverage
Seventeen ways a product quietly gets harder to use.
Complex products don't fail in one place. They accumulate small contradictions across modules until the whole thing feels heavy. The audit works through every surface below, module by module.
02 — Method
Agents explore. A human decides.
Systematic coverage is a machine problem. Judgement isn't. The two halves do different work, and only one of them signs off.
-
A
Agentic exploration
A system works through the product methodically, in a way a person can't sustain across a hundred screens — and doesn't get bored on screen sixty.
- Routes
- States
- Forms
- Tables
- Filters
- Navigation
- Responsive conditions
- Common flows
- Interaction states
- Accessibility
-
B
Expert review
Everything the agent surfaces is then judged by a person who has built products like yours — because most of what a machine flags doesn't actually matter, and some of what matters most it never sees.
- Business context
- Workflow intent
- Severity
- User impact
- Design consistency
- Product logic
- False positives
-
C
Verified findings
Every finding that reaches the report has been through a human. Each one carries its provenance, so you can weigh it accordingly.
- Human discoveredFound by review, in context
- Automated discoveredSurfaced by systematic exploration
- Automated → Human verifiedSurfaced by the agent, confirmed and rated by me
No agent writes the final audit. Automation buys coverage and consistency; it doesn't buy judgement, and it isn't sold as if it does.
03 — Engagement
Six steps, then it's finished.
A defined shape with a defined end. One clarification round is included; after that the engagement closes and you own the output.
-
01
Discovery
Who uses the product, what it does, which workflows carry the business, which modules matter, what you already suspect, what constrains you, and what you want the audit to settle.
-
02
Scope
Surfaces, workflows, access requirements, timeline, deliverables, confidentiality and commercial terms — agreed and documented, so nothing about the engagement is a surprise.
-
03
Audit
Hands-on expert review across the agreed surfaces, with agentic exploration running underneath for coverage. Evidence is captured as findings are recorded, not reconstructed afterwards.
-
04
Report
Prioritised findings, each with evidence, severity, user impact, implementation complexity and a specific recommendation — plus the executive summary and the patterns that repeat.
-
05
Walkthrough
We go through the highest-impact issues together, so the reasoning transfers to the people who'll act on it and the debate happens with me in the room.
-
06
Iteration
Your team challenges findings, asks for clarification, or flags context I didn't have. A Product UX Audit includes one consolidated iteration; a Health Check covers clarifications. Then the engagement closes.
04 — Deliverables
Written to be worked from, not admired.
The test of an audit is whether a sprint can pick it up on Monday without a translation layer. Everything is written to that standard.
Every finding carries
- Issue ID
- Product / module
- Workflow
- Severity
- UX category
- Description of the problem
- Evidence — screenshot or capture
- Why it matters
- A specific recommendation
- User impact
- Implementation complexity
- Confidence
- Discovery source
And the report itself
- Executive summary Product UX Audit
- UX health score with a category breakdown
- Priority matrix — impact against effort
- Recurring patterns and root causes Product UX Audit
- Top recommendations
- Engineering-ready backlog
- CSV export, optional
- Jira-ready formatting, optional
05 — Sample
Five findings, in the format you'd receive them.
These describe patterns common to operational SaaS products. They are written examples — not drawn from any client's product, and not real data. Open one to see the full record.
06 — Scoring
One number for the room. Seven for the team.
The headline score travels well in a board deck. The breakdown is what a product team actually plans against.
How severity is decided
Severity weighs user impact against how often the workflow runs, how central it is to the product, and what it costs the business when it goes wrong.
- Critical
- Users are misled, lose work, or cannot complete a core task. Fix before the next release.
- High
- A frequent workflow is meaningfully harder or riskier than it needs to be.
- Medium
- Real friction with a workaround, or an inconsistency that will compound.
- Low
- Polish, edge cases, and small breaks in the system's own rules.
This is a consistent judgement, applied by one person across the whole product — not a formula. Anything that claims decimal-point precision on questions like these is selling arithmetic, not analysis.
All scores and counts shown on this page are sample data.
07 — Difference
Most UX problems aren't visual problems.
They're behavioural — and they're usually a consequence of how the frontend is built. Recognising that is the difference between a finding you can act on and a finding you can only agree with.
- Components that behave differently in different modules
- Permissions that expose actions the role can't perform
- Filters that don't persist across navigation
- Loading and error states that were never built
- Controls that promise something the system doesn't do
- States the interface allows but the product can't handle
- Navigation that disagrees with the information architecture
- Component reuse that quietly diverges over time
- Client and server state drifting out of sync
- Frontend architecture producing UX inconsistency by default
I've spent seven years building these systems — design systems shipped to two frameworks, analytics products, realtime dashboards, enterprise workflows and the AI interfaces on top of them.
So when something is wrong, I can usually tell you the likely shape of the cause: a shared toolbar rendering a capability it shouldn't, state held in a component instead of the URL, an API returning per-row results the interface throws away.
That's what makes the backlog estimable. Your engineers get findings that already account for how the thing is probably built.
This doesn't replace your design team, and it isn't meant to. It's an outside read on a product they're too close to — which is the only kind of read they can't do themselves.
08 — Fit
Built for products with a lot going on.
A strong fit
- Complex B2B SaaS
- Operational products
- Dashboards and analytics
- Admin systems
- Internal tools with external customers
- Workflow-heavy applications
- Products that grew fast and accumulated UX debt
- Teams preparing for a redesign
- Teams who suspect usability problems but can't locate them
Someone else is better
- Marketing websites
- Brand-only projects
- One-page landing pages
- Work that needs a full design agency
Not a judgement on the work — it's just a different craft. This practice is specialised in dense, operational software, and that specialisation is the whole value.
09 — Engagements
Scoped like consulting, because it is.
Two fixed scopes at launch prices, and a custom one for anything bigger. The right fit usually becomes obvious in the first fifteen minutes of the intro call.
10 — Confidentiality
Your product stays confidential.
Scope, confidentiality, IP ownership and payment terms are documented before any work begins. What's below is how I work — the agreement is what makes it binding.
- Engagements are NDA-friendly. Send yours, or I'll provide one.
- Access is used solely for the agreed review, and for nothing else.
- Dedicated test or audit accounts are strongly preferred over anyone's personal credentials.
- A staging environment is preferred over production wherever one exists.
- Sensitive production data shouldn't be provided unless the review genuinely requires it.
- Reports stay private. Nothing about your product is published, shown or referenced without your explicit written permission.
11 — Start here
Tell me about the product.
A few questions first, then you'll pick a time. The context means the call opens with your product rather than with introductions.
Received
Thanks — I've got the context.
I've read what you sent before we speak. Now choose a time for the intro call — 30 to 45 minutes, and we'll spend it on your product rather than on introductions.
Choose a time for the intro call
45 minutes. If nothing here works, reply to the confirmation email and we'll find a slot.
Loading the calendar…
12 — Questions
The ones that come up first.
How long does an audit take?
It depends on scope — how many modules, how deep the workflows go, and how quickly access is arranged. A focused health check is short; a multi-module audit is not. The timeline is agreed on the intro call and written into the scope, so I'd rather commit to a real date then than quote a generic one now.
Do you need production access?
Usually no. A staging environment or a dedicated test account is preferred, and is almost always enough. If a workflow genuinely can't be reviewed outside production, we agree that specifically and keep the access as narrow as possible.
Can you sign an NDA?
Yes — engagements are NDA-friendly. Send yours and I'll sign it, or I'll provide one. Confidentiality and IP ownership are settled in writing before the work begins either way.
Will you redesign the whole product?
No. The deliverable is analysis, prioritisation and recommendations — what's wrong, why it matters, and what to do about it. Design work can be scoped separately if you want it, but it isn't what you're buying here, and conflating the two makes both worse.
Do we get implementation guidance?
Yes. Findings are written to be engineering-aware: where the likely cause is visible from the outside, the recommendation says so. That's the practical advantage of an audit run by someone who builds these systems.
Can our team challenge findings?
Please do. You have context I don't, and some findings will turn out to be deliberate decisions. A Product UX Audit includes one consolidated iteration — I revise what needs revising and note what stands and why. A Health Check includes clarifications rather than a revision round.
Do you use AI?
Agentic systems assist with systematic exploration — routes, states, forms, tables, responsive conditions — because that's coverage work a person can't sustain across a large product. Every final finding is reviewed, rated and written by me. No agent signs off an audit.
Can you audit mobile apps?
Responsive and mobile web, yes — those are reviewed as part of any audit. Native iOS and Android app testing isn't currently offered, so if that's the core of what you need, I'd point you elsewhere rather than stretch to cover it.
Your users already know where the friction is.
Let's find it before they leave.