In this session, I'm going to be talking about something that is 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 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 that 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 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 the 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 in 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
– ecommerce, 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 ecommerce 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 ecommerce,
I would refer them to the Amazon site
and usually for a 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 recommend that 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 we 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*.
Finally, something that's actually these days largely overlooked,
but it's still extremely important on more complex systems – things like Microsoft Office
and 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 dialogue and you wanted help with that dialogue,
you could click on a button and you would get help on that dialogue.
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 dialogue.
So, things have gone a little bit backwards in recent years on that front.