A UX audit checklist for B2B software

A UX audit is a structured review of a product against the tasks its users come to do, ending in a ranked list of what to fix. For B2B software that means walking the five to ten tasks that matter most, noting every place a user hesitates, guesses or gives up, and scoring each problem by how often it happens and how much it costs. The checklist below is the one I use, grouped so you can run it on your own product in a few days.

What a UX audit is, and when it is worth doing

A UX audit is an expert review. Someone who did not build the product sits down with it, works through the main tasks the way a real user would, and writes down where it gets in the way. It is cheaper and faster than a full research project, and it catches the plain, visible problems before you spend money on usability testing or a redesign.

It is worth doing when a few familiar signs pile up. Support tickets keep asking where a setting lives. New customers need a call before they can use the product alone. Your own team exports data to Excel to answer questions the product was supposed to answer. Or a feature shipped months ago and hardly anyone uses it, and you can't tell whether the feature is wrong or simply hard to find.

An audit is less useful when the product has no users yet, because then there are no real tasks to measure against, only guesses. In that case a short round of interviews with five or six target buyers will teach you more. Nielsen Norman Group's argument for small test groups is a good read on why a handful of people is enough to surface most of the problems.

Set the scope before you open the product

Most audits that go nowhere fail here. Someone clicks through every screen, collects eighty small complaints and hands over a document no one can act on. Scope the audit around tasks instead of screens.

1. Name the users. In B2B software there are usually two or three: the admin who sets it up, the daily user who lives in it, and the manager who reads the output once a week. Their tasks barely overlap.
2. List the tasks per user. Write each one as a verb and an outcome: invite a colleague, approve an invoice, find last month's churn by plan. Five to ten tasks in total is plenty for a first audit.
3. Pick the area. Onboarding, the reporting module, billing settings. One area audited properly beats the whole product skimmed.
4. Collect the evidence you already have. Support tickets, session recordings if you run them, sales call notes, churn reasons. These tell you where to look first.
5. Use real data. Audit on an account with realistic volume: long customer names, hundreds of rows, a few empty fields. Demo data hides half the problems.

Write the scope down in one paragraph and agree it with whoever owns the product. That paragraph decides what counts as a finding later.

UX audit checklist, part 1: getting in and finding things

The first group of checks covers the moments before a user does any real work. I run them as a new user, then again as someone who has used the product for a month, because the two hit different walls.

• After signing up, is it clear what to do first? Is there one obvious next step, or a dashboard full of empty widgets?
• Do empty states explain what will appear there and how to fill them, or do they just say no data?
• Can a user find each task from the navigation without searching? Are labels written in the customer's words or the engineering team's?
• Are related settings grouped where a user would look for them, or scattered by whichever team built them?
• Does search find things by the names users really type, including partial names and common typos?
• Can a returning user pick up where they left off: remembered filters, recent items, the last project they opened?

For each check, note what you expected, what happened, and where you hesitated. Hesitation is the cheapest signal you will get. If you, a careful reviewer with time to spare, had to stop and think, a busy user probably clicked the wrong thing.

Part 2: the core tasks, forms and errors

This is where B2B software differs most from consumer apps. Your daily user may spend six hours a day in the same three screens, so small frictions multiply. A form that takes ten extra seconds is nothing once; done two hundred times a week, it adds up to over half an hour of someone's week, every week.

• Count the clicks and screens for each core task. Is there a step that only exists because of how the database is structured?
• Do forms validate as you go, and do error messages say what to do next? A message that reads invalid input is a finding.
• Is destructive work protected? Delete and bulk actions should ask for confirmation or offer undo, and undo is better.
• Can the user act on many records at once: bulk edit, bulk export, select all across pages?
• Do tables sort, filter and keep column widths? Can the user see the column headers after scrolling down?
• Are there keyboard shortcuts for the frequent actions, and do tab order and focus behave in long forms?
• What happens on a slow connection or a timeout? Is there a loading state, and does a failed save lose the user's work?
• Do permissions fail politely? A user without access should see why, and who to ask, instead of a blank page.

The ten usability heuristics from Nielsen Norman Group are worth keeping open during this part. They are more than thirty years old and still the best short vocabulary for naming what you see, which makes the final report easier to read.

Part 3: SaaS UX for screens full of numbers

Most B2B products end up with a reporting area, and it is often the weakest part of the product because it was built last, by whoever had time. This is the part of SaaS UX I care about most, since my day job for 5+ years has been as a Power BI data and business analyst, and a lot of what I see in product dashboards would never survive a finance review.

• Does each report screen answer a question a user actually asks, or does it show every metric the database happens to hold?
• Is the most important number the most visible thing on the screen, with a comparison next to it (target, last month, last year)?
• Are numbers formatted the same way everywhere: same decimals, same currency symbol, same date format?
• Do the totals on this screen match the totals in the export and in the billing page? Mismatched totals destroy trust faster than any layout problem.
• Is it clear what period and what filters a number reflects, and when the data was last refreshed?
• Do charts use one accent color for the thing that needs attention, or a rainbow where everything shouts?
• How long does the report take to load with a large account? Slow reports get abandoned for spreadsheets.

If you want a reference for what a readable data screen looks like, the example dashboards on my work page are built on sample data for that purpose, and my guide to Power BI dashboard examples by department covers which numbers each team usually needs to see.

Accessibility checks that take an hour

You don't need a full accessibility audit to catch the common failures, and in B2B they matter more than people assume, because many of your users read the same screens for hours a day.

• Check text contrast. WCAG 2.2 asks for a contrast ratio of at least 4.5:1 for normal body text. Light grey labels on white are the usual offender.
• Unplug the mouse and try one core task with the keyboard alone. Can you see where focus is at every step?
• Zoom the browser to 200% and check that nothing overlaps or disappears.
• Make sure color is never the only signal. A red cell should also carry an icon, a sign or a label.
• Check that form fields have visible labels, not just placeholder text that vanishes when you type.

These five checks will not make a product compliant on their own, but they find the problems that affect the most people for the least effort.

How to rank what the UX audit finds

A long list of findings is easy to produce and hard to use. What makes an audit valuable is the ranking. For each finding I record four things: which task it affects, how often users hit it, how badly it hurts when they do, and roughly how much effort the fix takes.

Frequency and severity can each be scored from one to three. Severity three means the user fails the task or gets a wrong number; two means they succeed but slowly or with help; one is cosmetic. Multiply the two and you have a simple priority score from one to nine. Then sort by score and look at effort: a nine that takes a day to fix goes to the top of next sprint, and a two that needs a rebuild goes to the bottom of the backlog, possibly forever.

Be honest about the evidence behind each score. A finding backed by a pile of support tickets deserves more weight than one based on your own hunch, so mark which is which. I also keep a short list of things that worked well, because a redesign that breaks the parts users like is a real risk, and the team deserves to hear what to protect.

Running it yourself or hiring UX audit services

You can run this checklist in-house, and for a first pass you should. The weak spot is familiarity: people who built the product know where everything lives, so they stop seeing the friction. If you audit internally, give the job to someone from a different team, a recent hire, or a customer success person who hears the complaints every day.

Outside UX audit services make sense when the stakes are higher: a redesign is coming and you want to spend the budget on the right screens, a large customer is threatening to leave over usability, or the product grew screen by screen over years and no one inside can see it whole anymore. Before you hire, ask what the deliverable looks like, whether findings are ranked, and whether the person has designed products like yours. A consumer app specialist and a B2B data product specialist will notice different things.

The fixes themselves are often small. Labels, empty states, a better default filter, moving a setting to where people look for it. Bigger problems, like a client portal that grew without a structure or a report that takes a minute to load, need more work, and for reports built in Power BI my guide on fixing a slow Power BI report covers the usual causes.

If you'd rather have someone outside the team run it, a UX audit of one product area is how I usually start with B2B software teams: a fixed price, a written report with annotated screens, and the fixes ranked by impact and effort. The details are on my UI/UX design services page.

Frequently asked questions