Performing a UX Audit on an Existing Product

Ask UXmatters

Get expert answers

A column by Janet M. Six
February 22, 2021

This month in Ask UXmatters, our expert panel discusses how to perform a UX audit to evaluate an existing product. A UX audit typically includes an evaluation of a product’s usability, learnability, and accessibility characteristics. There are several approaches you can use when conducting a UX audit. Our experts describe their preferred methods.

Understanding the user’s journey fully requires that you map the user journey for both the product and any related Web site, then evaluate both. Plus, it is important to understand the business requirements for the product to understand whether the product is fulfilling those requirements.

Champion Advertisement
Continue Reading…

In my monthly column Ask UXmatters, our panel of UX experts answers readers’ questions about a broad range of user experience matters. To get answers to your own questions about UX strategy, design, user research, or any other topic of interest to UX professionals in an upcoming edition of Ask UXmatters, please send your questions to: [email protected].

The following experts have contributed answers to this month’s edition of Ask UXmatters:

  • Bob Hotard—Lead UX Designer at AT&T
  • Janet Six—Product Manager at Tom Sawyer Software; UXmatters columnist
  • Andrew Wirtanen—Lead Designer at Citrix

Q: What is your preferred method for performing a UX audit on an existing product?

“When I hear the term UX audit, I think of usability-inspection methods,” replies Andrew. “The most popular inspection method is a heuristic evaluation, which commonly uses Jakob Nielsen’s ‘10 Usability Heuristics for User Interface Design.’ However, I think a better, more straightforward method for evaluating an existing product’s usability is ‘Practical Usability Rating by Experts (PURE).’ With PURE, two or more experts decide what tasks to evaluate, then break the tasks down into their individual steps. The experts independently rate the difficulty of each task. I’ve used the PURE method only a couple of times, but I believe the findings were more consistent and useful.

Starting with a Journey Map

Bob believes, “A good UX audit of an existing product should start with a journey map of the entire user experience, including user scenarios describing why they wanted to purchase a product or try a service. A journey map shouldn’t just start with Customer call’s store… or Customer goes to Web site…. This is one reason why it’s better to refer to these people as users. Unless you’re evaluating an account experience, the person who is the user might not yet be your customer, so keep an objective perspective. Ask users what their reasons are for starting a journey. Find out what they know about your product or service, then focus on a couple of key scenarios all the way through the audit process.

“One thing a journey map can do well is to identify the mood of the user throughout a scenario. Make sure you’re not ignoring the user’s mood when going into a process. Users aren’t always happy-go-lucky consumers, who would just say, ‘Yeah! Can’t wait to buy this widget.’ Some customers might be mad because they just saw an ad for a discount online or on their favorite streaming show and have realized that they didn’t get it! That could be what starts their shopping or purchasing process. Don’t be afraid to consider that negative use case, which is not an edge case. This could help provide a more accurate overall picture of the user experience.

“When you’re conducting a UX audit for an existing product, it’s good to include a content audit of your Web site. You can find many instances of necessary content upgrades and errors of brand-voice consistency by employing this method.

“Finally, when you’re auditing an app or Web site, you should create a page-to-page flow diagram of the major use cases you’ve identified in your journey map or just simple use cases you’ve identified. This is not just a click analysis. A good usage-level flow diagram shows a user’s options, expected path, actual path, and possible paths, which can be very enlightening to a client or stakeholder.

“For example, a common impediment for many users is a log-in requirement just to enter a Web site or app. A key stakeholder might have the misconception that ‘a user logs into the Web site, then does [A, B, C…],’ but they might never have considered the actual experience of the user—or more accurately, the customer’s experience of forced reauthentication. Showing the back-and-forth of a password-reset user experience can be eye opening if not mind blowing for some. Including a check email screen in your flow diagram can show how exasperating it is for some users who just want to check their balance or cancel their order. Now add the parallel flow of a mobile Web or app experience, and you have the opportunity to improve the overall product experience significantly. Be sure to include a solution-based analysis with your boxes-and-arrows diagrams. What should the user experience optimally be—or what is a best-in-class user experience. It might not be within the product roadmap, development plan, or budget, but your stakeholders need to see these sorts of issues and understand what a good UX team could deliver to them.”

Understanding Business and Design Requirements

When conducting a UX audit, it is important to revisit the original business and design requirements for an existing product or Web site to determine whether the current implementation has fulfilled them. If your team has fallen short of satisfying some of these requirements, it is important to understand why. Was there a technical limitation or other limitations that prevented your team from meeting some requirements? If so, investigate whether it is now possible to augment the product design and the product’s Web site so you can fulfill those requirements.

Also, it is important to conduct a new survey of the marketplace and your competitors. Do you need to add new requirements to ensure you’re offering a competitive product?

If your team did not originally define solid requirements for the product, create them now! Then ask the appropriate stakeholders review them. Why should you go back and write requirements for an existing product? First, it is important to understand the product’s current features and capabilities. Second, this evaluation could highlight important functionalities or characteristics that your team missed and you need to add. Third, these requirements are necessary for the Quality Assurance, Documentation, and Marketing teams to understand how to test, document, and market the product. 

Product Manager at Tom Sawyer Software

Dallas/Fort Worth, Texas, USA

Janet M. SixDr. Janet M. Six helps companies design easier-to-use products within their financial, time, and technical constraints. For her research in information visualization, Janet was awarded the University of Texas at Dallas Jonsson School of Engineering Computer Science Dissertation of the Year Award. She was also awarded the prestigious IEEE Dallas Section 2003 Outstanding Young Engineer Award. Her work has appeared in the Journal of Graph Algorithms and Applications and the Kluwer International Series in Engineering and Computer Science. The proceedings of conferences on Graph Drawing, Information Visualization, and Algorithm Engineering and Experiments have also included the results of her research.  Read More

Other Columns by Janet M. Six

Other Articles on Expert Reviews

New on UXmatters