1. IS4445 Principles of Interaction Design Lecture 11: UX audits
Rob Gleasure

2. Course structure Or more specifically Week 1: Introduction
Week 2: Empathise 1 (personas)
Week 3: Empathise 2 (empathy maps)
Week 4: Define 1 (journey maps)
Week 5: Define 2 (value curves)
Week 6: Ideate 1 (mind maps)
Week 7: Ideate 2 (6 hats)
Week 8: Prototyping 1 (storyboards)
Week 9: Prototyping 2 (wireframes)
Week 10: Test 1 (Testing cards)
Week 11: Test 2 (UX audits)
Week 12: Revision

3. The next next impossible problem
With a clear functional design in place, we now need to know whether it actually interacts well with users
We need to bring the humanity back to our new interaction
Testing cards typically focused on say/do
Now we turn up the volume on how our users think/feel
We want to stay flexible-minded and do our best to let go of all the biases we’ve been accumulated

4. Why UX audits? After all, weren’t we doing UX work all the way along?
An audit is more than just testing
Testing looks for problems based on user feedback
Auditing looks for problems based on a larger understanding of users in general
This is important, as think/feel feedback is difficult to obtain. Hence we need to draw on deeper explanations and general standards to fill in some of the blanks.

5. How to perform a UX audit?
We’re going to focus on Nielsen’s 10 Usability Heuristics
These give us a great start and they are commonly used in industry
Disclaimer: These are nowhere near comprehensive – no one tool or technique is.
These 10 heuristics give us a set of ways to critically analyse a design
They build on a couple of core concepts, most central of which is the idea of ‘mental models’

6. Visibility of system status
System interactions must included appropriate and timely feedback to keep users informed about what is happening
This empowers users and generates trust
Images from

7. Match between system and the real world
Use language and concepts familiar to the user and follow real-world conventions to present information as naturally as possible
Not only easy for users to understand, also reassures those users that the system understands them
Images from

8. User control and freedom
Users often need to try something to see whether it is what they wanted, hence need to feel they aren’t locked into a path of action with no escape
The power of redo and undo
Images from and

9. Consistency and standards
The same thing should be not be described with different words, nor should the same word mean different things
Most users will spend vastly more time on other websites and apps than yours, meaning they arrive with general expectations
Images from and and

10. Error prevention
Know where users make mistakes and either eliminate those parts of the interaction (if possible) or allow for them, e.g. with a ‘confirm action’ step.
User errors can be divided into ‘slips’ (when user isn’t thinking) or ‘mistakes’ (when user is)
Images from and

11. Recognition rather than recall
Users should be asked to recognise options, not recall them from their own memory
Show users things they may recognise to create a sense of context, depending on how often and how recently they have seen those things
Images from and

12. Flexibility and efficiency of use
Frequent users may be able to take shortcuts through an interaction once they’ve completed it (or a similar one) previously
Additional learning effort is trivial once the rest of an interaction is habitualised
Images from and

13. Aesthetic and minimalist design
Every piece of information makes an interaction more complicated and creates new interdependencies
Every avoidable piece of content requires at least some degree of processing by a user
Images from and google.ie

14. Help users recognize, diagnose, and recover from errors
Errors should be (i) presented in as simple language as possible (ii) accompanied by a suggested course of action (solution)
Remember – it’s not the user’s fault if a design has broken down
Images from

15. Help and documentation
Ideally, a system wouldn’t need any documentation. Even if this lofty ideal could be reached, the presence of documentation is reassuring to users
Keep it task-specific and ensure there is always an escalation step if users still can’t resolve the issue
Images from and

16. Posting online
Describe 1-3 changes you would make to your wireframes based on a corresponding heuristic.
Visibility of system status
Match between system and the real world
User control and freedom
Consistency and standards
Error prevention
Recognition rather than recall
Flexibility and efficiency of use
Aesthetic and minimalist design
Help users recognize, diagnose, and recover from errors
Help and documentation
Provide screenshot(s) to illustrate.

17. Building your report
Describe one change you would make for each of the ten heuristics, providing screenshots of those wireframes to illustrate.
Visibility of system status
Match between system and the real world
User control and freedom
Consistency and standards
Error prevention
Recognition rather than recall
Flexibility and efficiency of use
Aesthetic and minimalist design
Help users recognize, diagnose, and recover from errors
Help and documentation

18. Reading
Norman, D. (2013). The design of everyday things: Revised and expanded edition. Basic Books (AZ).
Nielsen, J. (1994). Usability engineering. Elsevier.
Nielsen, J. (1994). Usability inspection methods. In Conference companion on Human factors in computing systems (pp ). ACM.
Online summary from Nielsen-Normal group at