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?)