Performing a UX Audit on an Existing Product

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.