Ease of use (pt 2) – the role of interaction design in managing change

Wow, some title eh? Quite pleased with myself - sounds more like an academic paper than a blog post. Jakob says the microcontent's important though, so I'll let it stand.

A couple of weeks ago I was driving back to Manchester from London with a friend of mine who's an IT management consultant. He works for the public sector (national and local government organisations) and one of the things he mentioned was the "change curve".

The change curve theory says that people (and organisations) go through a number of different stages when a change is introduced - shock/denial -> depression/anger -> hope/acceptance -> commitment/ownership. From his point of view, the important thing is to be aware of these stages, and put in place measures to minimise the depth of the curve (sometimes called the "valley of despair", apparently).

This got me thinking about how the perceived ease-of-use of new software systems could impact on this. More specifically, how when large new systems are being implemented, a system with a greater perceived ease-of-use could help to shallow the curve and speed participants through to stages three and four (acceptance and ownership) more quickly.

My follow-on thought from this was – in these situations, should perceived ease-of-use be given a higher priority than overall usability metrics? That is, could it actually be more efficient and effective overall for the organisation to have a smoother implementation of the new system, at the expense of efficiency and effectiveness of the software in isolation from its organisational context.

I don't know the answer to this – I guess some studies would need to be done (and I don't see then - please point them out to me if you know where they are), and a cost-benefit analysis done on a case-by-case basis.

I'd be interested to know what others think.

The change curve and organizational change

No scuffed shoes – Get what you know right

When you're selling something, or promoting yourself somehow, I think it's pretty obvious that you should take special care to make sure that you present well.

For instance, if your company sells doors then it's a no-brainer that the door to your showroom should be of the best quality, well-fitted, and so on. If you sell shoes, your staff shouldn't be wearing old, scuffed brogues (unless that's the type you sell).

I received an e-mail from Userfocus the other day though, inviting me to a seminar on web usability. The seminar sounds great, and I receive the e-mails because I've signed up for them on Userfocus's well put-together and informative website.

I sounded so good that I clicked the link in the e-mail, for Brochure and more information (link working exactly as in the e-mail). So then I tried the other link, for Booking form. For the record, both of these links fail to work (due to a '>' being appended to the link in the e-mail, I think), and instead go to Userfocus's default error page.

For me, this is the usability equivalent of scuffed shoes.

This whole episode seemed particularly relevant to me as I had just read David Hawdale's post on companies spending money on Google advertising, getting people to their site, then not being able to deliver what their advert suggested. This is poor user (and in this case, customer) experience.

It also reminded me of a technical communications manager I talked to, who recounted his amazement at how few of the CVs (resumes) he received used proper styles, and were instead a hodge-podge of in-line Word formatting. In this case, your CV says enough about you before a word is even read.

Whatever you get wrong when you're selling your product or yourself, don't make a mess of your own profession. I'll accept spelling mistakes from a butcher, and a web editor who can't joint a chicken, but not the other way round.

David Hawdale's post on real availability not matching the advertising
A working link (as of today) to Userfocus's web usability seminar

Apologies for the interruption in service

I've missed my schedule for posting this last week. This is for two reasons:

• I've just had my broadband installed, and I've been working on getting my main website up and running.
• It's Christmas, and parties are all over the place.

There'll be another, proper, post in a couple of days....

The ease of the common – "docking" toolbars

I had an interesting experience the other day with, of all things, a toolbar.

I was using Adobe Framemaker - a publishing application I use quite a lot during my normal working day. I kind of knocked my mouse and clicked at the same time, and suddenly my editing toolbar (copy, paste, yadda yadda) was floating around instead of comfortably glued to the menu.

So, obviously, I tried to dock it. Gripping the top of the palleted toolbar and dragging into the corners, over the other toolbar: slowly, quickly, in little circles . . . Then I tried docking it somewhere else: the bottom, the top, the right-hand side. Anywhere so long as it wasn't drifting around in the middle of the page. No joy.

After about five minutes of this, I even resorted to the help. "Docking", I searched for. Nada. "Dock". Zilch. So I asked my colleagues – all experienced Framemaker users. One of them had had this happen before, but didn't know how to fix it. He'd given up – his toolbar was now floating. He suggested looking in the help . . .

So, does Framemaker have a crazy feature where you can un-dock a toolbar and then never re-dock it? Nope. It has a perfectly sensible system, and it's right in front of your eyes.

It has a button.

(c) 2002 Adobe


A button on the toolbar (second one along, if you haven't spotted it yet) that un-docks the toolbar, and a button on the pallet toolbar that re-docks it. And they call it "Vertical/Horizontal QuickAccess Bar", not docking.

And what did this tell me? That our current knowledge and ideas about the world are crucial in how we can learn and recall an interaction design. Docking is neither more "intuitive" (see my rant on that word) nor less. Docking is certainly more versatile, in that it has the potential to support many more locations for a toolbar, and it reduces button clutter. But having a button on the toolbar is pretty obvious isn't it?

The fact that it took me the best part of ten minutes constant effort, a couple of stabs at a help file (where I was using the "wrong" word, because that's what I'm familiar with), and two colleagues' efforts, tells us that it's not pretty obvious - how users understand their world is fundamental to successful design.

If a button was the best solution by far, and if you didn't have any casual users, you should probably still go for the button. In all other circumstances, you've got to do what everyone else does.

Jakob Neilsen on following convention on websites
Jared Spool on taking into account users' current knowledge before you start (this is very relevant - Framemaker is not a particularly modern product: was the docking concept firmly entrenched when they made this decision?)

Ease of use – to the detriment of user experience?

User experience is, according to Wikipedia, "used to describe the overall experience and satisfaction a user has when using a product or system". I think this is a fairly decent definition, and will be the one I use for the purposes of this post.

Usability is, according a definition derived from Nigel Bevan,"the effectiveness, efficiency, and satisfaction with which specified users can achieve specified goals in a particular environment."

These two thing clearly overlap: a product or service with great usability is likely to translate into a good user experience. But what of sub-optimal outcomes – products or services that do not achieve perfect usability (that is, every product and service ever produced)? What are the trade-offs between usability/user experience, and ease-of-use?

The question can be more clearly phrased using an example. Imagine a complex software product, providing computational capabilities that no comparable software product can achieve. The managers of the company producing this product need to provide an update to keep ahead of their competitors. They have limited resources. Should they:

(a) apply all their resources to enhancing the algorithms to provide better results, or
(b) apply some of their resources to enhancing the algorithms and some to making the product quicker and easier to use

Easy, right? (b)? I guess that's what many people would say. Making a complicated, difficult, unwieldy product will increase support costs, put some people off buying the software, make the documentation more difficult and expensive to write, and so on. All of this is true. It's also true that if the developers think with more of a user-focus at the outset, then the product will be better to use without any additional resource.

But still, from a user experience point of view, (a) might be better than (b). It all depends on your user. If your users are all (or mostly) demanding better computational results over all others, then their user experience – their overall experience and satisfaction when using the product – is likely to be better with the more functional product than with a slightly less functional product that they can learn and use faster. Of course, if they can't get the results that the product is capable of, their user experience will be poor whatever.

The conclusion of this, I think, is that "satisfaction" is the key word in both the definitions. Something cannot be usable unless it satisfies the needs of its users, and neither can it provide a good user experience. And in order to provide satisfaction, we must "know our users". A product that's nasty to use will depress and upset most user experience professionals, but on a given day it may still be the best experience we can deliver.

User Experience definition
A paper by Nigel Bevan (discussing how usability can be approached from a quality perspective, but discussing how user satisfaction can be considered, measured, and tested)

User testing - is it worth it, and should we tell anyone if it's not?

I was sent an interesting article today, written in 1998 by Jacobsen, Hertzum, and John. It's hardly brand new, but it addresses something that doesn't seem to be addressed often elsewhere.

Their thesis, based on an experiment they carried out, is that the number of evaluators you have of the evidence collected from a user test is (at least) as important as the number of users. That is, more evaluators will find many more issues from exactly the same evidence, and the way they classify the issues they find is very varied. Evaluating, they suggest, is a very subjective process.

Taking into account other evidence that calls into question the classic '5 users = 80% of issues' equation (one study found issues being reported at the same rate at the 16th user), is user testing a valid, cost-effective thing to be doing? Will we really gain wisdom this way? And, if not, what are the consequences of telling those decision-makers not sold on usability that the most high-profile method is dogged with difficulty?

From looking at the evidence, it seems to me that there a few factors still supporting user testing:

1. Nielsen's quote that "The most striking truth . . . is that zero users give zero insights."
2. Most of the problems reported are down to loose definitions.
3. Evidence still suggests that properly organised and controlled user testing yields great results.

So the challenge seems to be:

• define the study properly
• choose your users carefully
• brief your evaluators comprehensively (and use more than 1)

If we do these things, I think user testing still has a central important role to play in improving user experience.

Jacobsen, Hertzum, and John's paper
Jakob Nielsen on 5 users
CHI 2003, a panel discussion on the number-of-users problem

Intuitive - a word much abused?

'Intuitive' is a word you hear a lot. Sometimes it's users telling you that they think something is, or isn't, intuitive, sometimes it's people on the fringes of usability endeavours suggesting ways that interfaces could work more intuitively.

More often than I can believe, it's skilled and experienced usability professionals.

It is, in many ways, a holy grail to produce 'intuitive' interfaces and experiences - that is, interfaces that require no reasoning or learning through observation. Whether there is, or ever can be, an 'intuitive' interface is a point for discussion.

This is not merely semantics though - it is not merely that the word is used without proper reference to its meaning that I object to. It is that it gives the impression that interfaces, and interaction in general, can be designed in such a way as not to require:

1. Learning
2. Reasoning

This is problematic in that it leads designers to overlook the need to understand people's mental models - the things they've already learnt during their lives, the way they make sense of the world.

It is through understanding how people's minds work that we can best work towards 'intuitive' interfaces. And people's minds work differently across education groups, skill sets, cultures, experience, and so on. By using the word intuitive, we overlook the need to understand our users, and mistakenly assume that an interface is, or is not, intuitive.

I therefore suggest that the word is hereby banned from use in a user experience context, and that, instead, professionals describe what they actually mean.

Who's with me?

A couple of interesting links on this:

http://www.uie.com/articles/design_intuitive/
http://www.usabilityfirst.com/glossary/term_444.txl
http://www.asktog.com/papers/raskinintuit.html

Welcome

Welcome to my blog.

This site will contain information (and, most probably, links to information) relevant to the fields of user-centred design and information architecture.

It'll be based on the things I'm working on (as a usability lead in technical communications) and things I'm thinking about (as a 'normal' guy, interested in how we use things and access information).

It won't be the most authoritative source on the web, by any means, but it might just link to some really great stuff.

I also hope to get into some interesting discussions with folks a bit brighter than my self too....