A heuristic evaluation or expert review is the bread and butter of my design life. Anyone well versed in the principles of design for a particular domain or platform simply looks at the product (preferably a functioning one actually installed and running) and applies industry knowledge of what are best practices and expected user behaviors (the "heuristics") to identify key problems and estimate how well the product does or will work with actual users. Pretty much every project I work on gets at least one of these. Sometimes, they are quite formal, and other times just is the underlying practice behind acceptance testing.
There's been a bit of a secret crisis over these for the past 10 years or so. Many have promoted these with long checklists which are quite specific. Some of my first issues with these came with trying to apply web-centric tools to new technologies, or to the mobile web way back in 2003. It didn't work. Even simple specifications like the time that users are willing to wait for a page to load change. Over time, and with the type of service or expected audience. Expectations change, so strict heuristics are difficult to define.
But, that's fine, because I feel that's a totally misguided approach. Norman says " judge its compliance with recognized usability principles" and seems to reinforce the focus on principles (not specifications) with his 10 usability heuristics but then links to ''2,397'' usability guidelines. That's far too many, far too precise and leads to application problems. What about my B2B mobile, social site? Do I apply them all?
Fundamentals & Setup
As a regular practitioner of this, I have been asked to share my heuristics. Which I am therefore interpreting as sharing the basic principles, checkpoints and methods that I use instead.
- Know your audience - how they work...
- Know what your audience uses - getting the right devices...
- Know how your audience works - Just last week I kept going outside to check on the readability and legibility of an interface, both as I designed it and as it was built. Because this
A Process for Evaluation
on real devices in your hand...
measure, do not trust sizes...
orientation - enter data
F
reusable components...
In an ideal world, with infinite time, after doing the evaluation on the actual hardware it is good to take screen
Recording Your Findings
It is critical to take good, clear notes. You will find many things worth noting, so cannot rely on memory. Really, you can't. As you find more issues your brain will exaggerate or forget previous issues. Write them down, as you find them.
My favorite way is a spreadsheet. My favorite by far is Google Spreadsheet, as it can be shared, so multiple practitioners can work on one document, or it can be shared for the team to discuss what to do about the findings. See this example. Yes, real ones are much longer, but it was easier to sanitize a real one by just keeping a few real and generic points so pretend it's very long.
- You may need to add items to a bug tracking database instead. I still like lists and spreadsheets for discussion and tracking. Very often, you may find the same issue on multiple pages, which clarify the root cause so instea
The large checklist of hundreds of heuristics requires us to assign a value to each point. Meaning you say what is good as well as what is bad. I tend not to do this and only note the bad. Not just because I am mean and only like to talk about the bad things. Instead, for two reasons:
- Not much should be bad. When things get so bad that there are 100 items per page, I usually give up and write a different type of report talking about fundamental issues that need to be solved. You will hopefully find just a few items per view, and it won't be so overwhelming to just talk about things that should be improved.
Implementation teams don't know what to do with praise. Oh, sure, say it's lovely otherwise (if true) but if you give a list of good and bad points, they may all be added to a bug database, and there will be attempts to solve the good points. Really. I have seen this.
Next: Part I Page
Discuss & Add
Please do not change content above this line, as I am trying to keep this a well-organized, curated experience. Everything else you want to add goes down here.