90 percent of everything : Usability Blog

Written by Harry Brignull

A great quote that sums up the art of User-Centered Writing:

“Bad writers worry about whether the reader will understand them. Good ones are more concerned about how well they understand the reader.”

- Paraphrased from Lindsay Camp (2007)

Finally we’ve managed to get our new site out the door. Please do drop by and take a look. In case you’re wondering, Flow interactive is a London-based User Experience consultancy. I’m a consultant there. We’re hiring.

By the way, my posts from this site (90percentofeverything.com) will also be appearing over on the flow blog.

This should be the mantra for user experience designers everywhere.

Image stolen unashamedly from Jonny Baker’s Photostream. The concept came up in a chat with Simon Johnson today over lunch.

Douglas Karr pointed out that I should put my money where my mouth is and explain how it should be redesigned. Having given it some thought, I’ve realised this is a particularly tricky dialog box - the problem does not exist just at the level of the dialog box but more widely, for example:

• The keychain: what the hell is it? To a naive user this is a hairy concept.
• The security of your computer: What caused the application to update? Was the source trustworthy?
• The repercussions: what does the decision actually mean? What’s the worst that can happen? How can I recover from making the wrong decision?

I’ve also just realised that this has been blogged about elsewhere, with some great comment discussions. Read more here, here and here.

My working “solution” is shown here. It’s still fairly wrong but at least it’s more clearly worded and the button labels actually correspond to the question.

I welcome critical comments so feel free to get your knives out

These days when you see someone wondering down the street looking lost, chances are they don’t have a shop-bought map in their hands – it’s much more likely they have a scrappy looking print-out from a web-based route planner service. And chances are they are looking very lost.

Take Google Maps for example - the directions they give you are completely linear. If you mess up on one step, you are completely lost as none of the steps are relevant to you anymore. And the maps it gives you are equally hopeless, only showing you the happy route, with little detail of the areas you so desperately need if you get lost.

What I want when I ask for directions on Google Maps is a series of high quality A4 maps that show me the route AND the surrounding area.

It’s like that film American Werewolf in London - “Don’t stray from the path, lads. Whatever you do, don’t stray from the path!

This post by Christopher Fahey of graphpaper.com got me thinking about the longitudinal nature of usability issues, and what it means for user experience research & design.

Now: the teething problem
This is a usability issue that you experience at first, but eases off as you get used to the product. For example, the first time you used an ipod you probably had at least 30 mins of familiarization and teething problems (”hey, this isn’t like my minidisc player, but it is kind of cool…”).

Later: the ill fitting shoe
This is a usability issue that you don’t notice at first, but it becomes increasingly bothersome as time wears on. For example, some voicemail systems that plays you the same long introductory message every time - educational at first, but after a while you start to notice every second it is stealing from your life.

So, what does this means for evaluation?

User tests often evaluate the first 60-90 minutes of use. This is a defining period but how much time the average person will use the product in total? If they are clocking up many hours of use every week, then the first hour of use is, in a sense, just a edge case.

To evaluate this product’s user experience, you’d have to employ longitudinal techniques - diary studies, repeat testing, telescoping, betas, and of course maintain an open dialogue with your customers.

If you don’t take a longitudinal view, then you are at risk of angling your product too specifically at beginners, and in doing so alienate the experienced users - or vice versa. Research methods are like a narrow beamed flashlight in a dark cave. To get a good view of things you have to expend a fair amount of effort looking at things from different angles.

And what does it mean for innovation?
Sometimes, when you try to avoid teething problems, you conform to the status quo, and you don’t help users in the long run. Imagine if the iPod ended up looking like the Creative Rio Mp3 player, because people in the user test sessions couldn’t quite get their heads around the concept of click-wheel navigation.

But sometimes arrogance can get the better of you. So some teething problems go away - how do you know if your design will do this? And, even if it does, can you justify the pain?

Having worked at 3 different User-Centred Design (UCD) consultancies in the last few years (Flow Interactive, Amberlight, and Oyster Partners), I can confidently say that the type of project most commonly requested by clients looks like this:

1. Client delivers test materials (e.g. prototype of new website)
2. 8-12 user test sessions are carried out by the UCD consultant (the client may watch a small number)
3. UCD consultant locks him/herself in a room, analyzes data and writes a report
4. Report is delivered in a debrief presentation to the client
5. Project ends, UCD consultant leaves and doesn’t get spoken to again for weeks or months.

It suddenly stuck me today how un-user-centred this method actually is. Sure, you get a cheaper project with a good number of users, but ultimately the consultant just throws their findings over the wall and hopes that their client catches them.

The amount of times I’ve seen a UCD consultant looking at the finished implementation months later, saying something like “Oh man! Didn’t those guys listen to the presentation?”

The problem is, the client stakeholders simply aren’t very engaged in this kind of project. Watching a few sessions just doesn’t cut it. Have you ever tried watching a series of user testing sessions? From a darkened room behind a 2-way mirror? The passiveness and repetitiveness can really send you off to sleep.

So how do you get the client stakeholders involved? The solution I’ve been using recently at Flow Interactive is Rapid Iterative User Testing. Put simply, you run design workshops between the test sessions. You talk to the client, you analyze the findings together and then, most importantly, as a group you tweak the design of the thing you’re testing. (Often the prototypes we test are UI mock-ups, so tweaking is a cinch).

Not only does it involve everyone and keep them interested during the test sessions, but it means that you get to make sure your design recommendations actually work in practice.

The main problem with this method is that it can cost more. More client stakeholders need to turn up, and the sessions may need to be spread over more days. But it hugely improves the output of the project. Instead of a report detailing the prototype’s failures, the final prototype that emerges from the testing is a living, tested implementation of your design recommendations.

Try it!

Four good reasons for you:

1. This year it’s all about user experience design.
2. The conference is small and friendly enough to actually meet and get to know new people.
3. You actually stand to learn something useful since there are some great presenters and workshops.
4. It’s in Brighton, about 3 minute’s walks from the beach and right by the Pavillion gardens.

And three reasons to tell your boss:


5. Registration is really cheap
6. It’s commutable from london
7. It’s short - you’ll only be out of action for a day (or two if you do a workshop)

Hope to see you there!

Read more at dconstruct.org

Microsoft Surface is a pretty amazing piece of research: tabletop touchscreen computing done really well. But, the “origins” section on the Surface website strongly implies that the whole concept of tabletop computing originated from Microsoft. It didn’t. If you find this stuff exciting, you should check out some of the prior research in this area.

MERL’s diamond touch : one of the first multi-touch technologies (works by running an electronic signal to your finger via your chair to identify each user).

IPSI’s roomware: this is an entire room decked out as touchscreen surfaces that are all linked together.

Stanford’s Tabletop groupware: they’ve done tons of stuff in the area. You may recognise some of the gestural stuff that also appears in the MS video.

Jun Rekimoto’s work (Sony) this includes “holotable”, “smart skin” and “augmented surfaces”. Jun is a genius- in my opinion, his research is genre defining.

I’m not saying that it’s a bad thing that Microsoft are building on top of prior research - this is, after all, what research is all about. I’m just trying to say that there are some talented people and research groups out there that also deserve recognition for the state of the art today.

I’ve been having a lot of fun doing out of box experience design consultancy over the last few weeks (OOBE as it is pretentiously called by those in the know). If you’ve ever opened an Apple product then you’ll know what an excellent out of box experience is; and, if you’ve ever opened a packaged copy of Windows Vista you’ll know what a bad out of box experience is. [See a nice comparison on Robert Hoekman’s blog, via Reaction.]

If you look around on the web, there isn’t much in the way of out-of-box design guidelines, with the notable exception of IBM’s offering. So I’ve put together a mini set of guidelines based on a metaphor of the bento box.

A bento box:

• Is a joy to use.
• Actively improves your perception of the contents, through attention to every minute detail.
• Encourages an order of consumption - the physical structure affords consumption of the top layer first. This is very useful if you need your user to do things in a certain order.
• Compartments are spacious enough to allow easy access to contents.
• Makes it just as easy to put things in as to take things out.

So next time you’re doing OOBE design with a bunch of non-UX people, introduce this metaphor to your team. It’s quick, it’s easy and it’ll give you a piece of common vocabulary to hang your ideas off.

I’m really interested to hear your comments - so please comment below! >>>