Heuristic Evaluation (HE)

In this session, I'm going to be talking about something that's referred to either as *expert evaluation* or *heuristic evaluation*. It's an evaluation done by one or more experts  using a set of guidelines, and evaluating whether a solution meets those guidelines, how well it meets the guidelines, where it is deficient. So, expert or heuristic evaluations rely on the experience and the expertise of the evaluator.

So, you can't really do these things without  understanding some of the basic concepts of interaction design and usability. I mentioned at the outset that you would be using guidelines, but those guidelines are *not* self-explanatory, so you have to understand what a good solution to a particular problem, what you're trying to achieve, would look like because as you're doing evaluations and as the industry changes on a  regular basis,

then you have to appreciate whether or not the solutions you're seeing actually conform to the guidelines in front of you. Heuristics are these rules of thumb based on *good  practice and known problems in design*. And they can be used from the very early design through to finished solutions. And you can even do expert or heuristic evaluations on just sketches if that would be helpful. It probably is more sensible a little bit later in the process, but certainly there's no impediment to looking at maybe the general layout of screens

and saying, well, this screen is quite possibly overly complicated for the problem in hand and the customers or users that you're trying to target. It is relatively inexpensive in that hiring in a consultant for one or two days is actually very much cheaper than conducting usability evaluations.

But immediately following, you'll notice that I mentioned that it's *not as effective as testing with real users*. And that is certainly the case. However, if you had a lot of novel designs and you wanted to get some idea about whether they were going to be effective, then inviting people in who actually do  usability testing who are experts in the field will get you a lot of feedback without nearly so  much cost as a lot of usability testing, which can get quite expensive just because of having  to recruit, reward, hire facilities, and so on.

Jakob Nielsen published his book on User  Interface Engineering back in the early 1990s, and these are his 10 basic UI (user interface)  heuristics. And they haven't really changed, although when we actually go out to do something like benchmarking, we have a very much more detailed set of heuristics.

But these are a useful starting point, and they're talking about fairly generic concepts like *visibility of system status* and making sure that people understand where they are in the process. And that, of course, is  a good thing no matter what you're doing. And detailed design does actually flow out of that – for example, letting people know that they've got things in their shopping basket. That is an example of the visibility of system status.

*Match between the system and the real world* – and that's something I've already alluded to when I was referring to terminology. The mapping sometimes is also physical. If you're talking about the natural tendency for increasing the quantity of something, it tends to be *up*. So, if you've got a slider, then up or to the right is 'more' and down or to the left is 'less'. And that's just what we call *natural mapping*. *User control and freedom* – being flexible, allowing people to go back and fix things.

Bear in mind that when user  interface design was relatively new on sort of the large scale back in the 1990s when Windows 3.1, which was kind of the very first successful version of Windows, and of course the World Wide Web came around about the same time, it was uncommon, it was very unusual to have Undo functions. If you made a mistake and you needed to fix it, then you had to fix it yourself. There was no Control-Z or any kind of undo facility.

It was something that you had to do, and we take that for granted now, but it was not the case in the early days. *Consistency and standards* – users should not have to wonder whether different words, situations or actions mean the same thing. And this continues to be a problem in some areas. Certainly on intranets within large organizations, you would find that one department had its own set of visual guidelines with its own visual language which was totally different to the next department.

And if you were unlucky enough to have to move between those departments on the intranet, then you were in a bit of trouble. It doesn't happen so much these days with the web – e-commerce, for example; people do try very hard to make sure that users are going to have a fairly painless experience, and so we do tend to see things laid out with very *similar terminology and visual language* between totally different e-commerce sites. And to be honest, there,

Amazon, because they are so large and popular, has been something of a yardstick. And most people, when they're asking for advice on how to do something in e-commerce, I would refer them to the Amazon site and usually for very good reason. *Error prevention* is much more successful than dealing with errors. Certainly if you're having to discard data or reject data because users did not understand how you wanted it formatted, you should *not insist that people punctuate things exactly the way you need them*.

You can do whatever you like with the punctuation once you've got the basic data from them. If you want the phone numbers without punctuation, then take the punctuation out of the phone number after you've got it. If you don't like the spaces in the credit card numbers, then take the spaces out of the credit card numbers. So, that isn't something that Jakob talks about here, but it is a different form of error prevention, and I wholeheartedly recommended presenting users  with errors and telling them they've done bad

and should do it over is *not good user experience*. *Recognition rather than recall* – and this is the basic premise of *all* user interfaces these days. That's the way that we've moved. Back in the 1970s and 1980s, most systems were command line based and you had to remember the syntax and spelling of the next command you wanted to enter. And when Windows and the Mac came along, both having stolen their designs from Xerox PARC,

then we got what we used to refer to as *WYSIWYG* – What You See Is What You Get. We don't talk about that much these days, but it was all about *recognition*, which people are very much better at, than recall; so, you can *recognize things much more easily* than you can recall them from scratch. *Flexibility and efficiency of use* – and usually there is a trade-off between what you might call *design for learning*  and *design for efficiency*. That is all tied up with flexibility and efficiency of use.

By making things *flexible and efficient*, you're often making them *harder to use*. So, that's where the tension in the design comes in. *Aesthetic and minimalist design* – people like  websites that look attractive and that they trust from a visual design perspective. And it is important that we *do not put too much in front of users at once*. And so, that's what we mean  by minimalist design. *Help users recognize, diagnose and recover from errors* – something that's actually these days largely overlooked,

but it's still extremely important on more complex systems; things like Microsoft Office, most of the Adobe apps do have behind them a huge body of *help and documentation* – usually pretty awfully organized and presented, I have to say. It used to be better ten years ago, and we've just for some reason stopped worrying too much about that. So, it used to be that if you were looking at a dialog and you wanted help

with that dialog, you could click on a button  and you would get help on that dialog. The best you can hope for these days is that you click on Help and you get taken to a website, and you now have to work out how you're going to find out about this specific issue that you are having with this specific dialog. So, things have gone a little bit backwards in recent years on that front.