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.

Which Heuristics?

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 amount of time that users are willing to wait for a page to load will 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 to "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 fully 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?

Guidelines like those I offer on the previous page are better to start with (for mobile, go back to Norman for general guidelines and other platforms). See other sections like General Touch Interaction Guidelines, General Touch Interaction Guidelines, and really lots of stuff in the Appendix for some additional guidance and details, with caveats and principles to help you apply them to your design.

When encountering a specific widget, like an Infinite List you can refer to the pattern principles to determine if the implementation was well-done. This is a particular gripe of mine; infinite scrolling has gotten a bad name as a whole, but only because the patterns are not being applied correctly. Patterns are (usually) not evil, but bad implementations can ruin them. This is what heuristic evaluation is very good at discovering.

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. Since I spent last night doing a review of a new app on Android, for a global audience, for five hours, you are getting a lot of that as the for-instances. Interpret as needed for your domains.

• Set constraints - The project will have limits of engagement. Even if answers below are different, and your users actually have lots of featurephone use of the Web, if the business has decided to only address how it works on iPhone 4 and above, there's no point in logging issues on Android or Blackberry much less featurephones. It's not ideal, but it's how the world works. Argue that in a different document and discussion.
• Know your audience - You are an office worker. 25% of us remote work, so it's irrelevant if your office is the park, your back yard or Starbucks. You are therefore not who most of your users are. Make no assumptions,a and find out how they work. What do they expect, what do they use on their device right now and how often.
• Know what your audience uses - Within the limits above, find out what devices and browsers your users employ. Ideally, you have specific research and maybe even analytics from the first launch or similar products. Otherwise, use basic knowledge of the industry and regions. For me, last night:
  • Galaxy S4, Galaxy Nexus - For modern OSs on a few different platforms. Carrier locked and unlocked devices, for example.
  • Hero 200, Casio Commando, Galaxy S1 - Some say 80% of the installed base in China is on Android 2.3. Not on old phones, that's just what they put on new ones. Ideally I'd get some of these but they are in China so this will do to check old versions of the OS. Even Apple doesn't have perfect migration to the new OS. Check your audience. Also, one has a keyboard. Good to check on since in some markets keyboards are still big.
  • Nexus 7, Polaroid PMID701 - Test on different sizes, form factors. The Polarioid is a Cheap Chinese Tablet, so even though it runs 4.0.3 it is a good example of the popular tablets in other markets. And it didn't work the same as the Nexus.
• 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 product is for mechanics who might be in repair shops, truck cabs or even outside. It has to work everywhere. Ideally, I'd account for dirty fingers also, and within the limits I have (I don't make phones) I did by making targets even bigger than usual for the basic functions. Editing the equipment name? That's a small target, because you do that when there's time to stop and think.
• Do not forget browsers - In some markets, the default browser is not used, or is no longer the default browser due to language or other regional needs. Know this, and check in the correct browser, or in several.
• Don't get lost - Make a chart of what you are going to test, both process and platforms, and mark it off as you go. Some of these can take all day. Or two days. You will forget what you did or where you left off at lunchtime.

A Process for Evaluation

All those devices you have identified (and acquired) need to get charged and laid out in front of you. If you worry it's expensive, get used ones and no plan. WiFi works fine for all this. Check connectivity, and get the app installed if needed.

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.