UX Audits for existing products
Reviewing existing interfaces for usability, accessibility, and consistency, with documented findings and prioritized recommendations that can move directly into the roadmap.
What a UX audit actually is
A UX audit is a structured review of a digital product by an experienced outside designer. It identifies friction points, inconsistencies, accessibility gaps, and missed opportunities, and turns them into a concrete list of recommendations, sorted by impact and effort.
The point of an audit is not to criticize. It is to give a product team a clear, prioritized view of what to fix, what to leave alone, and what to think about more deeply. Most teams know their product has problems. An audit makes those problems specific enough to be addressed.
Audits cover web applications, mobile apps, and enterprise software. The output is a written report with screenshots, annotations, and prioritized recommendations — formatted for direct use in design and engineering planning.
When a UX audit fits
- A product is live but engagement, conversion, or retention is below expectation
- A team suspects usability issues but cannot pinpoint them precisely
- Accessibility compliance needs to be assessed before a release or a contract
- Stakeholders disagree about what to fix first, and a neutral perspective would help
- A redesign is being planned and the current state needs to be documented
- The team is too close to the product to see it with fresh eyes
Not the right engagement when the question is "should this product exist at all" — that needs strategy, not audit. And not the right engagement when nothing is built yet — in that case, prototyping or research is the better starting point.
What you get
- Executive summary with top three to five priorities
- Detailed findings organized by area or user flow
- Screenshots with annotations marking specific issues
- Severity rating (blocker, major, minor) for each finding
- Recommended next steps with rough effort estimates
- Accessibility findings against WCAG 2.2 or BITV 2.0 if requested
- Optional: review meeting with the team to walk through findings and answer questions
UX audit checklist: what I review
Every audit follows a fixed checklist, weighted to the product. These points are always part of it:
- Orientation: Is it clear on every screen where you are, what you can do here, and what comes next?
- Information hierarchy: Is the important stuff up front, or is everything equally loud?
- Paths and navigation: How many steps does the most frequent task take, and where are the detours?
- Language: Does the interface speak the users’ language or the organization’s?
- Forms and input: Are there sensible defaults, clear required fields, and helpful error messages?
- Feedback and system status: Do users learn what is happening and whether an action worked?
- Consistency: Do the same elements behave the same everywhere, and does the product follow its own design system?
- Error prevention: Can errors be prevented, and can they be undone?
- Accessibility: Contrast, keyboard use, screen readers, focus, and target sizes according to WCAG 2.2
- Mobile use: Does the core task work on a phone?
- Trust and privacy: Is it clear what happens to people’s data?
- AI features: Is it visible what the AI does, how confident it is, and how a result can be corrected?
The basis is Nielsen’s ten usability heuristics, the dialogue principles of ISO 9241-110, and WCAG 2.2, plus a flow analysis of the key tasks. The UX audit of Germany’s ELSTER tax portal shows what that looks like in practice.
How the process runs
A typical UX audit runs across two weeks:
- Scoping conversation (one to two hours): clarifying the product, the audience, the goals, and the focus areas of the audit.
- Analysis phase (three to five days): systematic review along the checklist, first the key user flows, then the product in breadth. Where it makes sense, an agent-assisted audit runs in parallel, and I review and weight its findings.
- Synthesis and prioritization (two to three days): findings are organized, ranked, and written up.
- Handover (half day): written report delivered, optionally a meeting to walk through findings.
For smaller products or focused audits, one week is sufficient. For complex enterprise software, three weeks may be appropriate.
Why a freelancer and not an agency
With an audit by me, the team talks to the same person from start to finish, the one who also does the review and writes the report. There is no pitch team that hands the work to junior colleagues after the contract is signed, and no internal alignment rounds that end up on the invoice.
More than twenty years of experience with products in telecommunications, the public sector, healthcare, and mobility go straight into the findings. I work from Berlin, on site or remotely, in German and English.