A User Experience Audit, or UX Audit for short, is something that should be conducted in the very beginning steps of a website, web application, dedicated app, or similar redesign project. Sometimes referred to as a deck or part of a design brief, UX Audits are typically done before user interface (UI) design occurs, and primarily consists of data intake, data compiling, research, and data visualization through presentation.
A UX Audit is simultaneously in-depth design research, and a cursory presentation of data. The UX Audit doesn’t jump to conclusions, or proposes finite UI and UX mechanics, but more so evaluates the project’s current state in order to:
- compile qualitative data
- conduct peer evaluation
- discover interactive pain points
- evaluate quantitative data
- identify accessibility errors
- survey information architecture
- point out any branding violations
- propose additional UX testing
Ultimately the UX Audit should serve as a compilation of the previous mentioned research, identify what data is missing or would need to be captured going forward, and would function as a point-of-departure for the next steps – which commonly would be sketching, wireframing, interactive wireframing, or prototyping depending on your development process.
The UX Audit is not a wireframe, it isn’t a design or user interface proposal, and it typically doesn’t highlight project requirements from stakeholders (although this is not uncommon). Additionally, a UX Audit’s summary does propose and provide recommendations based on the data compiled, but doesn’t do so in a way that graphically exceeds anything more than facilitating understanding (so no high fidelity solutions or graphics). As such, a UX Audit acts as a timestamp or bookmark as to project’s history, and serves as documentation for improvement. UX Auditing is also the prefered mode for project development, which is opposite of simply giving a project a ‘face lift’ without concern or regard to a project’s history or incremental improvement.
Once completed, the UX Audit and its recommendations are then given to a UI designer, front-end dev, web designer, or similar position who would begin designing, iterating, or wireframing (preferably in a medium that is close as possible to the final deliverable). The UI professional would then be in a better position going forward to wireframes (for example), and would be aware of the target audience, previous errors, and what data is present and what data is missing.
Possible Parts of a UX Audit
Depending on the project – be it a web application, website, or native app redesign – and on what data is available, each UX Audit is going to be different. Whenever possible, intake as much data as possible, because this data is a UX professional’s bread and butter, and they should spend a decent amount of time collecting, collating, filtering, interpreting, and visualizing it for stakeholders, developers, and UI professionals.
Although most UX Audits are essentially made from the same data and parts, they can follow any format or order. The following sections are some suggestions as to what can be included in a UX Audit:
This sometimes is called an Executive Summary, a Project Overview, or even an Introduction to the Problem. Despite what it’s called, the Introduction serves the function of briefly and succinctly introducing the the intent of the redesign, who all/what departments are involved in the project, and the scope of the UX Audit. Also accompanying, or contained in the Introduction are Research Objectives and a Table of Contents.
The Research Objectives highlights and presents the hard deliverables of the UX Audit, as well as sets up the expectations of the reader as to what research will be presented.
The UX Audit’s competitor analysis section is usually derived from data from a parent organization or competitors. A parent organization could be a policy commission, an accrediting body, location peers, etc. As for competitors, this can be determined by competitive sales, customers, consumers, goods, or services – all of which are being viewed for usage, and are best on increasing conversions.
The Competitor Analysis section can be comprised of a list of these peers, and hyperlinks to the similar projects’ website, web application, or native app. It also contains a features, functionality, and interactive elements comparison, in the form of percentages, and usually presents the comparisons through data visualization. This enables readers to see what percentage of peers have a responsive website, a homepage newsletter sign-up, sticky navigations, or other such features (which establishes baseline/industry UI standards).
Quantitative data refers to ‘the numbers’, or project traffic, usage, device/browser statistics, referrals, add-on blockers, social media sharing, and pathway mapping. All of this is quantitative data, is part of design research, and hopefully has already been set up on the project you are redesigning. Adobe Analytics and Google Analytics offer a lot of different solutions, but require a lot of customization, learning, or a significant financial investment. The following is a list of common industry software for this type of quantitative data:
- Adobe Analytics
- CrazyEgg (heatmaps)
- Google Analytics
- PageFair (ad-blocking detector)
- ShareThis (social media sharing and tracking)
- Webalyzer (server-side statistics)
Qualitative Data usually refers to the customer experience (CX) side of data, and can contain customer behavior, demographics, feedback, and search terms. This is usually derived from surveying mechanisms like Qualtrics or SurveyMonkey, embedded feedback tools like Adobe Experience Manager, search engine optimization (SEO) information from titles, spent advertising, and meta data tracking over time, and Google Trends and Google Insights.
Interactive Pain Points
Interactive Pain Points refers to egregious UI and UX errors, non-typical animations or interactions, and unexpected functionality. This can be as little as forms and buttons being too small to click on a touch-based or mobile device, dysfunctional carousel buttons, all the way to hover navigations being jerky, and counter-intuitive forms wherein the labels cover up the input fields. This is usually best presented in the UX Audit through screenshots or videos, with annotations about what is occurring in contrast to user’s expectations.
Brad Frost has an excellent Interface Inventory Checklist available on Google Docs; this is a great place to start to know what all to look for, and what interactions to examine for improvement. A checklist like the one he shared is very helpful, but the most important thing is to demonstrate things like inconsistent button sizing, or if interaction elements are confusing/not functioning.
Information Architecture (IA) is the structural design of information, interaction, and UX with the goals of making things both findable and discoverable. This part of the UX Audit focuses on the findability and discoverability of navigation items, general content strategy deficiencies, reading levels, and label auditing.
For example, analyzing the IA of a project could potentially identify that label auditing for primary and secondary navigation items, quick links, buttons, and calls-to-action is necessary. Analyzing IA could also demonstrate that the project’s Flesch readability score – a score which uses the sentence length and the number of syllables per word in an equation to calculate the reading ease – isn’t written for a 8th grade level (or that your content with specific instruction requires a 6th grade reading level). For more information the Nielsen Norman Group has a great article about legibility, readability, comprehension, and anyone can use Microsoft Word to analyze content’s Flesch readability scores.
This mainly depends on an organization or company’s established style guides and pattern library. If the project being redesigned is particularly old and in need of a UX Audit, there may be a lot of color, font family, interaction elements, and UX patterns that are out of sync. If a company or organization doesn’t have a set style guide or pattern library, maybe that’s the best place to start before a UX Audit. The following are some really great style guides and pattern libraries from companies, entities, and organizations you might know already:
“Over the past few months, conversations about Responsive Web design have shifted from issues of layout to performance. That is, how can responsive sites load quickly -even on constrained mobile networks.” Luke Wroblewski
Product Director at Google
When conducting a UX Audit, the Chrome web browser’s DevTools has a ‘Network’ and ‘Timeline’ view that analyzes and displays the loading of assets – images, scripts, code libraries, external resources, etc. – in real time. This information can and should be included in a UX Audit to document project load times, emulate different network conditions, verify any load time issues, and ultimately point out potential pain points for users.
Google Insights or even PageFair is desirable. This is place in the UX Audit where a UX professional really gets to shine, because they already demonstrated their data collection and presentation skills, and now they get to advise the stakeholders, UI, and development on what steps and UI decisions should be taken going forward.
How can UX Audits be used?
UX Audits can and should be incorporated as a non-bias and essential part of any redesign project. Many times a UX professional also has to be a librarian, or a UI designer, or even a front-end developer – so it’s easy to skip this important step of the redesign process, with limited staff and short deadlines.
However, performing a UX Audit will enable you to slow down, focus primarily on UX for a change, and perform an audit that will provide a lot of valuable information for stakeholders, designers, and developers. This will ultimately make everyone’s job easier, and what’s wrong with working smarter rather than harder?