UX and ergonomic audit: optimise what exists without tearing it all down
Your users are complaining, and you don't want to rebuild everything?
If we start from the idea that the existing product is going to be scrapped entirely, an audit is pointless, because we're starting from a blank page. The idea of an audit is that there's an existing product you don't want to transform entirely, you want to optimise it, and it always comes on the eve of a redesign. We use standardised criteria grids.
When an audit is the right call
Generally, you've identified things that don't work, either internally or, most typically, through customer feedback coming back to you.
- Customer support reports dissatisfaction.
- Sales teams regularly hear comments when they show the product to prospects.
- Users complain about the product's usability.
- The product has a history, it may have been built without any ergonomics work in the first place, and your teams realised through use that things weren't working.
The takeaway
What's certain is that all our clients then ask us to identify the problems and prioritise them.
How we go about it
How much weight should each piece of feedback carry?
We go through the documentation, get access, with test accounts if needed, and we like to interview the stakeholders to see how they make sense of the problems reported to them. Typically, some teams feel that all you ever hear about is the trains running late, that in fact most users are very happy, and so it may not be very important to focus on that problem. Conversely, it's important to understand why a point that may seem marginal needs us to put our full weight behind it. These interviews, and the time you set aside for them, matter, because they're also what will allow us to get up to speed on the context of your project. We're experts in our field, we work on the basis that you're experts in yours, and that it's the compromise between your view and ours that will produce the best result.
No finger in the air
We identify each problem and match it to an ergonomic criterion. The criteria we use are Bastien and Scapin's criteria and Nielsen's heuristics. And then we have broader criteria, because we also look at what relates to use in eco-design, accessibility and web quality, with the Opquast criteria. The idea is to have an approach that's systematic, exhaustive and comparable, and if two different people on the team carry out the audit, they should reach comparable results. From one client to the next, the approach should be comparable too.
Friction, frustration or blocker?
From our point of view, prioritisation is tied to use. For each problem, we ask whether it creates just a point of friction, a frustration, or a blocker that outright stops users from doing what they'd want to do. It can also be a technical prioritisation, and there we're extremely cautious, because development isn't our job. As far as we know, is it simply cosmetic, or is it functional, and therefore riskier and more costly?
Sorting priorities with the stakeholders
We present the diagnosis and sort out with you what matters and what doesn't. For these decisions, we need the extended project team, basically the people who will say whether what we've done is good or not.
No solutions during the diagnosis
An audit can simply be written recommendations. The other option is to illustrate the recommendations to be very concrete, and that's something we avoid doing during the diagnosis. We believe that making recommendations in isolation, without working directly with you, is somewhat counterproductive, because we'd be giving you recommendations you wouldn't be in a position to implement. Once the sorting is done, we can prepare them on our side, but we prefer to co-design them in a workshop with the core project team, starting to sketch ideas live.
Ideas sketched, then consolidated
Then we consolidate these ideas, almost always illustrated with wireframes, to deliver something you can use.
What you get at the end
The problems, one by one
Every problem found within the scope is described, along with the ergonomic criterion it breaches.
What works well
We also record the things users have identified as working well, so you're not led to change them.
A roadmap
It's a list of all the elements that need to be changed, fixed or improved, which lets you define different levels of priority.
Teams that can carry on
Each problem is tied to a criterion, which makes your teams to some extent independent in understanding the audit, so the idea is also to give them a bit of a leg up to apply it, potentially, to other pages, other areas, perhaps even other products.
The Défenseur des droits claim form
Before the redesign, more than 70% of users abandoned the form. Its journeys had been designed with the business teams, notably the lawyers, without consulting users. We assessed it against ergonomic criteria (date fields with no explicit input format, for instance), then had it tested at the Maison de la Justice et du Droit in Bordeaux, where the word "jurisdiction" turned out not to be understood by some users. The journeys were streamlined without being entirely rethought. After the redesign, 83% of claims go through the web form and phone calls have dropped by 29%.
Read the case studyFrequently asked questions
It's always tailor-made. It depends essentially on the number of screens and how complex the journeys are. Everything else, in fact, is very secondary. There's also the number of breakpoints, and the more there are, the more complicated it gets. Basically, it's the number of screens to audit, it's as simple as that.
We need access to the product, with test accounts if necessary, its documentation and time with the stakeholders for interviews. We may also take a look at the analytics, even though that really isn't the data we favour. For a recent audit of a banking application, paired with user testing, the client gave us exactly that.
In principle, user testing is always useful. We often say that when you listen to users too much, you realise they talk nonsense, but if we're the only ones listening to ourselves, we talk even more of it. What matters is combining viewpoints, so involving users as often as possible. And involving users doesn't mean involving a lot of them, it means stepping outside our own perspective with a handful of users, and sometimes that can be enough. We settle for an audit alone when the profiles are extremely hard to reach or very expensive, only available at odd hours, or when the project is too rushed to take on the logistics of guerrilla testing, or the even longer logistics of dedicated recruitment through a panel provider. Not doing user testing is perfectly feasible when you want to over-optimise the schedule or the budget. But you have to be very clear-eyed about the fact that it has a not insignificant impact on quality.
Yes, our audits almost always cover responsive layouts, on desktop and mobile, and our recommendation is to pool the effort. If the responsive work was done properly in the first place, what we've seen on desktop rules out a number of things that would otherwise be flagged on mobile, so less effort is needed. Tablets or very large screens remain possible, but in 2026 a tablet breakpoint is still somewhat unusual.
We audit business tools or consumer services, brochure websites or applications, on desktop or mobile. We were recently approached to audit control workstations in the rail sector, and as soon as there's a user or an operator facing a socio-technical system, we're able to step in.
Across all our projects, we try to encourage you to set up two project groups on your side. The core project team is our day-to-day contact on very operational questions. The extended project team includes the stakeholders who will be able to say whether the result fits the original vision of the project, and that's the team we bring together to make decisions.