Brent Nygaard
Design

back to all posts

how to perform a mini UX audit in 5 steps

By Brent Nygaard |

ux design, guide,

Learn the basic, big-picture steps needed to perform your own UX design audit on your web apps, websites, and mobile apps.

There are many reasons why you might want to audit the UX of a digital interface. Maybe there is a known performance or business problem, but why it's happening isn't clear. Perhaps people just aren't using the software much, despite being well known or having good marketing. Maybe your client has asked you to do a redesign of their website and you want to make sure you don't waste time "improving" the wrong things.

Whatever your reason, a UX audit is a valuable exercise, and if done well will give you quality data that you can use to improve the user experience of the software, thus improving the business performance too!

1. Define the goals and outcomes

What is success for the user?

What does this app/website/piece of software promise to do for the people using it? When a user completes a successful session of using the interface, what makes them feel like it was a good use of time?

Get in touch with a few people who actually use the software regularly and ask them.

What is success for the business?

What does the business get out of creating, serving, and supporting this app for these users? Is it purely financial? Increased corporate productivity? A marketing or PR stunt? What outcome would make the owners and stakeholders throw a party?

2. Review analytics (if any)

Review data from analytics tools (such as Google Analytics etc.) and company records. Clues that there might be a problem could be people exiting a flow at the same point each time without completing a function, high bounce rates, etc.

These stats should just give you some ideas of where there might be problems. You will need to investigate further to confirm them.

Be careful not to rely too heavily on analytics or business-defined metrics (such as KPIs or other performance metrics). Sadly, business goals are sometimes in opposition to true user satisfaction!

3. Identify the core states of the interface

Go through the interface now and systematically identify the following "states" of the software:

  1. The blank state - What users see the first time they log in or launch the software.
  2. The working state - What users see during the normal course of use. With data and content in place. This is the interface "in action".
  3. The error state - What users see when something goes wrong!

As you identify and define these states, make lots of notes about what you see and what you experience.

4. Review the core states

For each of the three states above that you have now identified and defined, review them across the following UX heuristics:

  1. Language - Are the words, sentences, and paragraphs used throughout the app appropriate and clear for the users? Is there a lot of jargon or lingo used? Confusing sentences? Ambiguous messages?
  2. Priority - What matters most to the users? What do they spend the majority of their time doing and in what order? Is that being serviced and supported, or hindered, by the interface?
  3. Universality - Across visual cues, language and labels, can anyone, even users who aren't the target audience, "get it" and understand how this interface works and what it does?
  4. Visual Clarity - Are interaction cues obvious (such as animations when you click on controls, or alerts that confirm your actions)?
    Is the overall visual hierarchy of information clear: can you tell what is most important on a screen?
    Is there a clear separation between content and controls (what is read-only information, and what a user can interact with)?

As you review the interface with these categories in mind, take note of any and all problems you come across. Big ones and small ones, and all in between.

5. Present your findings and recommendations

Well done! You've done the hard work, now it's time to put it all together and prioritize the data!

Take your list of problems and start sorting them by how important they are to fix. Remember, when rating a problem you need to consider both what it means to the user and to the business and who will be best served when/if it is fixed.

After you have sorted your problems, you will have a good set of objective and actionable steps that you can either present to your client or use internally to guide your design and development teams!