How and why we do Design Audits

How and why we do Design Audits

What is a Design Audit?

A Design Audit, sometimes referred to as a UX Audit, is a systematic assessment of the design and user experience (UX) of a product, website, or application. The goal of a Design Audit is to assess how well a digital product meets the needs and expectations of its users and to identify areas for improvement based on design best practices. This process involves a comprehensive analysis of various aspects of the user experience, including usability, accessibility, design, content, and overall user satisfaction.

Who might need a Design Audit?

At thoughtbot, we typically conduct a Design Audit at the start of a new client engagement. Some organisations may also schedule periodic Design Audits to ensure a product meets business and user experience objectives, or they may be prompted by user feedback to do so. This is a common need with products that have added a lot of functionality as they scale without a structured design system or a team of designers in place.

Why is a Design Audit beneficial?

The output of a Design Audit is usually a clear list of prioritised user experience issues that the team can then solve. By acting on this list of issues, companies can align their product to their customers and can create a product based on reliable data and best practices, rather than assumptions. Having a better user experience gives companies a competitive advantage which leads to an increase in sales and many delighted customers.

How long should a Design Audit take?

This question varies depending on the complexity of the project you are conducting the audit on. A small, contained application with around 10 “pages” and limited functionality might require an audit of around 10 days. An audit of larger and more complex applications might take as long as 3 or 4 weeks to complete.

What are the steps involved?

Understand

Our first step in a Design Audit is to get a better understanding of the product, the customer and the company goals. Usually we speak to team members and conduct customer interviews as a good starting point. Once we understand what the aim of the product is and what customers are looking to achieve by using it, it becomes a lot clearer which actions need to be taken.

Evaluate

Next up we will evaluate the existing application. Some key areas we might evaluate include:

Usability Testing

We evaluate how easy it is for users to accomplish specific tasks within the product. This often involves observing users as they interact with the interface to identify any usability issues.

Accessibility

We will assess the product's compliance with accessibility standards to ensure that it can be used by people with disabilities. This might involve checking for proper use of alt text for images, keyboard navigation, and other accessibility features.

Visual Design

We assess the visual design of the application. This will help us to identify areas where the visual design is negatively impacting the user experience. This can be accomplished by evaluating the overall look and feel of the product, including the use of colours, typography, imagery, and other design elements. Changes coming from this exercise could be as simple as changing the font family, increasing the font size or increasing the amount of white space around elements to improve readability and to make the hierarchy very apparent. On the other end of the spectrum, a more complex recommendation could be to run a branding workshop to reassess the brand colours, language and themes.

Content Evaluation

The written content of the application can be analysed by the quality and relevance of the content within the product. This includes assessing the clarity of information, appropriateness of language, and overall content structure. A simple suggestion we might make to a client after this exercise would be to remove some complex jargon. If most of their users will not understand what the jargon means or it is not relevant, the client should consider removing it. We find that clear, simple language is often best. A more complex example could involve reorganising the client’s content architecture. In this case, we might begin by trimming the content to make sure that only the most critical and relevant information is shown, before making it easy to uncover those extra bits of information the user might need if they are specifically looking for them.

We also often review the organisation of information and the effectiveness of navigation elements to ensure that users can easily find what they are looking for. Recommendations from this exercise range from simple things like switching from hover to tap/click actions to navigate mega drop downs (a common issue for large ecommerce websites), to a complete reorganisation of the applications flow (in extreme cases where it is very unclear for users where to go or what to do).

Performance

We will also usually check the speed and responsiveness of the product to ensure it has a smooth and efficient user experience.

User Feedback

We may even spend some time collecting and analysing user feedback, such as reviews, comments, and support inquiries, to understand user perspectives and pain points.

Recommendations

After conducting the audit, we typically generate a detailed report. This report outlines the findings, insights, and recommendations for improvement. The goal is to provide actionable insights that can guide the design and development teams in enhancing the user experience of the product.

A good way to report items is by listing “The Problem -> Why it is a problem -> A recommended solution -> The theory behind the solution (the “Why”) -> An example of the solution in practice”. If possible, try to prioritise each recommendation based on an “Impact” and “Effort” scale. A recommendation with a high impact and a low effort is something that will make a big difference and can be done right away. A recommendation with a low impact but a high effort involved to execute it is something that can probably wait.

Optional high fidelity mockups

If we struggle to find a good example of the solution we are proposing and if we have enough time, we might even do some quick high fidelity mockups to illustrate what applying the design theory and the recommendations could look like for that client’s specific application. The output of this could be an individual screen or even a clickable prototype. It is important to stress that these mockups are not to be implemented directly as they are; that is not the purpose of the audit. The mockups are simply to demonstrate the theory behind the recommendations rather than being the final solution.

What is the output?

Some assets that a client might be left with after a Design Audit include: - A detailed report which documents which problems were found, why they are problematic, a recommended solution, the theory behind the solution and an example of the solution in practice. - These action items should be organised based on effort and impact so that it is clear for the company what they need to prioritise. - An example of this report can be seen here. - Roughwork and documented thinking around the proposed solutions. - An example set of mockup designs to show the proposed solutions in action. This could even, if time permits, become a working prototype to test with customers. - An example design system complete with colour palette, font guides, components and branding work along with the theory behind each. - A design workflow demonstrating how to incorporate design and user testing into future development work if the company currently does not have this. - A compilation of resources may be required to help them with this.

Talk to one of our product experts about building success into your process.