All posts filed under “Usability

The ‘You Are Here’ Use-mark

You are here - Florence, Italy

Who really needs a “You Are Here” marker when other visitors’ fingers have done the work for you?

(Above, in Florence; below, in San Francisco)

You are here - San Francisco, California

Use-marks, like desire paths, are a kind of emergent behaviour record of previous users’ perceptions (and perceived affordances), intentions, behaviours and preferences. (As Google’s search history is a database of intentions.)

Indeed, while we’d probably expect the “You Are Here” spot to be worn (so it’s not telling us anything especially new) can we perhaps think of use-marks / desire paths as being a physical equivalent of revealed preferences? (Carl Myhill almost makes this point in this great paper [PDF].)

And (I have to ask), to what extent does the presence of wear and use-marks by previous users influence the use decisions and behaviour of new users (social proof)? If you see a well-trodden path, do you follow it? Do you pick a dog-eared library book to read because it is presumably more interesting than the ones that have never been read? What about where you’re confused by a new interface on, say, a ticket machine? Can you pick it up more quickly by (consciously or otherwise) observing how others have worn or deformed it through prior use?

Can we design public products / systems / services which intentionally wear to give cues to future users? How (other than “Most read stories today”) can we apply this digitally?

Instructable: One-Touch Keypad Masher

One-Touch Keypad Masher

It’s been a long time since I last wrote an Instructable, but as I’ve resolved that 2009’s going to be a year where I start making things again (2008 involved a lot of sitting, reading and annotating, and in 2007 most of what I made was for clients, and thus confidential), I thought I’d write up a brief (10 minute) fun little bodgey project which has, very marginally, boosted everyday productivity: the One-Touch Keypad Masher.

Wasting valuable seconds typing in a code every time you need to open the door?

This little ‘device’ streamlines the process by pressing the right keys for you, and can be hidden in your palm so you simply mash your hand against the keypad and – apparently miraculously to anyone watching – unlock the door in one go.

Time to make: Less than 10 minutes
Time saved: About 30 seconds per day in my case; your mileage may vary.
Payback time: 20 days, in this case

(There’s a (weak) correlation with some of the Design with Intent topics, since it could be seen as a device which allows a user to interact with a “What you know” security measure using a “What you have” method. At some point in the near future I’ll be covering these on the blog as design patterns for influencing behaviour.

It’s also a kind of errorproofing device, a poka-yoke employing specialised affordances. If used, it prevents the user mistyping the code.)

The Instructable is also embedded below (Flash), but for whatever reason there are a few formatting oddities (including hyperlinks being ignored) so it’s easier to read in the original.

Eight design patterns for errorproofing

Go straight to the patterns

One view of influencing user behaviour – what I’ve called the ‘errorproofing lens’ – treats a user’s interaction with a system as a set of defined target behaviour routes which the designer wants the user to follow, with deviations from those routes being treated as ‘errors’. Design can help avoid the errors, either by making it easier for users to work without making errors, or by making the errors impossible in the first place (a defensive design approach).

That’s fairly obvious, and it’s a key part of interaction design, usability and human factors practice, much of its influence in the design profession coming from Don Norman’s seminal Design of Everyday Things. It’s often the view on influencing user behaviour found in health & safety-related design, medical device design and manufacturing engineering (as poka-yoke): where, as far as possible, one really doesn’t want errors to occur at all (Shingo’s zero defects). Learning through trial-and-error exploration of the interface might be great for, say, Kai’s Power Tools, but a bad idea for a dialysis machine or the control room of a nuclear power station.

It’s worth noting a (the?) key difference between an errorproofing approach and some other views of influencing user behaviour, such as Persuasive Technology: persuasion implies attitude change leading to the target behaviour, while errorproofing doesn’t care whether or not the user’s attitude changes, as long as the target behaviour is met. Attitude change might be an effect of the errorproofing, but it doesn’t have to be. If I find I can’t start a milling machine until the guard is in place, the target behaviour (I put the guard in place before pressing the switch) is achieved regardless of whether my attitude to safety changes. It might do, though: the act of realising that the guard needs to be in place, and why, may well cause safety to be on my mind consciously. Then again, it might do the opposite: e.g. the steering wheel spike argument. The distinction between whether the behaviour change is mindful or not is something I tried to capture with the behaviour change barometer.

Making it easier for users to avoid errors – whether through warnings, choice of defaults, confirmation dialogues and so on – is slightly ‘softer’ than actual forcing the user to conform, and does perhaps offer the chance to relay some information about the reasoning behind the measure. But the philosophy behind all of these is, inevitably “we know what’s best”: a dose of paternalism, the degree of constraint determining the ‘libertarian’ prefix. The fact that all of us can probably think of everyday examples where we constantly have to change a setting from its default, or a confirmation dialogue slows us down (process friction), suggests that simple errorproofing cannot stand in for an intelligent process of understanding the user.

On with the patterns, then: there’s nothing new here, but hopefully seeing the patterns side by side allows an interesting and useful comparison. Defaults and Interlock are the two best ‘inspirations’ I think, in terms of using these errorproofing patterns to innovate concepts for influencing user behaviour in other fields. There will be a lot more to say about each pattern (further classification, and what kinds of behaviour change each is especially applicable to) in the near future as I gradually progress with this project.



“What happens if I leave the settings how they are?”

â–  Choose ‘good’ default settings and options, since many users will stick with them, and only change them if they feel they really need to (see Rajiv Shah’s work, and Thaler & Sunstein)

â–  How easy or hard it is to change settings, find other options, and undo mistakes also contributes to user behaviour here

          Default print quality settings  Donor card

Examples: With most printer installations, the default print quality is usually not ‘Draft’, even though this would save users time, ink and money.
In the UK, organ donation is ‘opt-in’: the default is that your organs will not be donated. In some countries, an ‘opt-out’ system is used, which can lead to higher rates of donation


“That doesn’t work unless you do this first”

â–  Design the system so users have to perform actions in a certain order, by preventing the next operation until the first is complete: a forcing function

â–  Can be irritating or helpful depending on how much it interferes with normal user activity–e.g. seatbelt-ignition interlocks have historically been very unpopular with drivers

          Interlock on microwave oven door  Interlock on ATM - card returned before cash dispensed

Examples: Microwave ovens don’t work until the door is closed (for safety).
Most cash machines don’t dispense cash until you remove your card (so it’s less likely you forget it)

[column width=”47%” padding=”6%”]

Lock-in & Lock-out

â–  Keep an operation going (lock-in) or prevent one being started (lock-out) – a forcing function

â–  Can be helpful (e.g. for safety or improving productivity, such as preventing accidentally cancelling something) or irritating for users (e.g. diverting the user’s attention away from a task, such as unskippable DVD adverts before the movie)

Right-click disabled

Example: Some websites ‘disable’ right-clicking to try (misguidedly) to prevent visitors saving images.

[/column][column width=”47%” padding=”0%”]

Extra step

â–  Introduce an extra step, either as a confirmation (e.g. an “Are you sure?” dialogue) or a ‘speed-hump’ to slow a process down or prevent accidental errors – another forcing function. Most of the everyday poka-yokes (“useful landmines”) we looked at last year are examples of this pattern

â–  Can be helpful, but if used excessively, users may learn “always click OK”

British Rail train door extra step

Example: Train door handles requiring passengers to lower the window

[/column][column width=”47%” padding=”6%”]

Specialised affordances

â–  Design elements so that they can only be used in particular contexts or arrangements

â–  Format lock-in is a subset of this: making elements (parts, files, etc) intentionally incompatible with those from other manufacturers; rarely user-friendly design

Bevel corners on various media cards and disks

Example: The bevelled corner on SIM cards, memory cards and floppy disks ensures that they cannot be inserted the wrong way round

[/column][column width=”47%” padding=”0%”]

Partial self-correction

â–  Design systems which partially correct errors made by the user, or suggest a different action, but allow the user to undo or ignore the self-correction — e.g. Google’s “Did you mean…?” feature

â–  An alternative to full, automatic self-correction (which does not actually influence the user’s behaviour)

Partial self-correction (with an undo) on eBay

Example: eBay self-corrects search terms identified as likely misspellings or typos, but allows users the option to ignore the correction

[column width=”47%” padding=”6%”]


â–  Use the size of ‘portion’ to influence how much users consume: unit bias means that people will often perceive what they’re provided with as the ‘correct’ amount

â–  Can also be used explicitly to control the amount users consume, by only releasing one portion at a time, e.g. with soap dispensers

Snack portion packs

Example: ‘Portion packs’ for snacks aim to provide customers with the ‘right’ amount of food to eat in one go

[/column][column width=”47%” padding=”0%”]

Conditional warnings

â–  Detect and provide warning feedback (audible, visual, tactile) if a condition occurs which the user would benefit from fixing (e.g. upgrading a web browser), or if the user has performed actions in a non-ideal order

â–  Doesn’t force the user to take action before proceeding, so not as ‘strong’ an errorproofing method as an interlock.

Seatbelt warning light

Example: A seatbelt warning light does not force the user to buckle up, unlike a seatbelt-ignition interlock.


Photos/screenshots by Dan Lockton except seatbelt warning image (composite of photos by Zoom Zoom and Reiver) and donor card photo by Adrienne Hart-Davis.

Angular measure

OXO Good Grips Mini Angled Measuring Jug

A few years ago I went to a talk at the RCA by Alex Lee, president of OXO International. Apart from a statistic about how many bagel-slicing finger-chopping accidents happen each year in New York city, what stuck in my mind were the angled measuring jugs he showed us, part of the well-known Good Grips range of inclusively designed kitchen utensils.

The clever angled measuring scale – easily visible from above, as the jug is filled – seems such an obvious idea. As the patents (US 6,263,732; US 6,543,284) put it:

The indicia on an upwardly directed surface of the at least one ramp allows a user to look downwardly into the measuring cup to visually detect the volume level of the contents in the measuring cup, thereby eliminating the need to look horizontally at the cup at eye level.

OXO Good Grips Mini Angled Measuring Jug

Now, this is an extremely simple way to improve the process of using a measuring cup / jug. It’s good if you find it hard to bend down to look at the side of the vessel. It’s helpful if you’re standing over it, pouring stuff into it. It reduces parallax error – so potentially improving accuracy – and it also, simply, makes it easier to be accurate.

In this sense, then, improved / easier-to-read scales can influence user behaviour. I guess that’s obvious: if it’s easy to use something in a particular way, it’s more likely that it will be used that way. It’s a persuasive interface, in an extremely simple form.

Kenwood JK450/455 kettleSo, the question is, if I build an electric kettle with an angled scale like this, will it make it more likely that people use it more efficiently, i.e. fill it with the amount of water they need? If you’re standing with the kettle under the tap, putting water in, is this kind of angled scale going to make it easier to put the right amount in?

Kenwood sells a kettle which has angled scale markings, the JK450/455 (right), though they’re implemented differently to (and more cheaply than) the OXO method, simply being printed on the side of the kettle body. It’s still a clever idea. This review suggests an energy saving of around 10% compared with Kenwood’s claimed “up to 35%” but of course this saving very much depends on how inefficient the user was previously.

I think something along the lines of either the OXO or Kenwood designs (but not infringing the patents!) is worth an extended trial later this year – watch this space.

OXO Good Grips Mini Angled Measuring Jug
Thanks to Michael for the Buckfast.

Heating debate

Thermostat with friendCentral heating systems have interfaces, and many of us interact with them every day, even if only by experiencing their effects.

But there’s a lot of room for improvement. They’re systems where (unlike, say, a car) we don’t generally get instantaneous feedback on the changes we make to settings or the interactions we have with the interface. It’s a slow feedback loop. We don’t necessarily have correct mental models of how they work, yet the systems cost us (a lot of) money. How effectively do we use them? Around 60% of UK domestic energy use goes on space heating, and 24% on water heating. (See this Building Research Establishment report [PDF] for more detailed breakdowns.) That 84% cost me and my girlfriend £430 last year. It’s worth thinking about from a financial point of view, regardless of the environmental aspects.

Frankie Roberto and colleagues at Rattle Research have carried out a brilliant exercise in exploratory design thinking about central heating*:

Heating systems are something we all interact with, especially in the depths of winter where we depend on them, and yet there seems to have been very little evolution in the design of their interfaces. What’s more, with an ever increasing focus on energy efficiency, both from an environmental and economic standpoint, there’s a need for heating systems and their interfaces to be smarter, more efficient and transparent.

Design Monday #1 – Central Heating (short version) from Rattle on Vimeo.

Read the full post.

The Rattle team think through existing systems and consider a number of possible revisions to improve the way that information is presented to users, and the level of control that it might be useful for users to have. This is a great piece of work, impressive and very thorough, and it’s interesting to see how their thinking evolved: I get the impression that (as service designers) they’re a lot more focused on users’ needs than the designers of many heating systems are. It’s also an exciting thing for a design company to be able to take time to address problems outside their immediate sphere, since they’re bringing a whole new level of domain expertise to it.

The ‘I’m working’ indicator is a really good idea – it reminds me of some higher-end car tyre air pumps at petrol stations where you can just set the pressure you want to achieve, and the pump cuts out (and alerts you) when it reaches it. But the idea of doing away with the ‘desired temperature’ setting and just having warmer/colder is also interesting – “forc[ing] people to always make decisions based upon how they’re feeling right now”.

Equally the ‘shift to service’ approach of having an API and making clever use of it has a big potential to help in energy saving (and cost saving for the user), especially if the usage data were (anonymised or otherwise) available for analysis. Just being able to tell users “it’s costing you £X more to heat your home than it does for a similar family in a similar house down the road – if you insulated better you could save £X every month” would be an interesting mechanism for persuasion. As with so many things, it relies on having that API or other interface available in the first place…

Folk theory of thermostats

The ‘folk theory of thermostats’ which Frankie mentions, popularised in Don Norman’s The Psychology / Design of Everday Things, has long intrigued me:

There are two commonly held folk theories about thermostats: the timer theory and the valve theory. The timer theory proposes that the thermostat simply controls the relative proportion of time that the device stays on. Set the thermostat midway, and the device is on about half the time; set it all the way up and the device is on all the time. Hence, to heat or cool something most quickly, set the thermostat so that the device is on all the time. The valve theory proposes that the thermostat controls how much heat (or cold) comes out of the device. Turn the thermostat all the way up, and you get the maximum heating or cooling. The correct story is that the thermostat is just an on-off switch. Setting the thermostat at one extreme cannot affect how long it takes to reach the desired temperature.

People’s mental models of heating systems are often stereotyped or played with (as we’ve discussed before here), but as Willett Kempton found out in a classic study, there are some nuanced versions of the theories, which, in practice, are perhaps not as silly as Norman suggests. People satisfice.

Say you come in from outdoors, and are cold. Because of the delay in your exposed skin warming up to room temperature, it surely does warm you more quickly if you stand near something that’s hotter than you actually want to be, e.g. a log fire / stove. So the heuristic of ‘turning up the heat to more than you need, in order to feel warmer more quickly’ is pretty understandable, especially when the temperature controlling the thermostat is the temperature of the thermocouple/probe/whatever and not actually the body temperature of the users themselves. (That would be a good innovation in itself, of course!) Am I wrong?

Given that a lot of people do try to control heating systems as if they worked on the valve model, would it be sensible to develop one which did? Do they already exist?

*Rattle’s second ‘Design Monday’ session, on ‘Lunch’, is also well worth a look.

Staggering insight

Staggered crossing in Bath

I’ve mentioned a few times, perhaps more often in presentations than on the blog, the fact that guidelines for the design of pedestrian crossings in the UK [PDF] recommend that where a crossing is staggered, pedestrians should be routed so that they have to face traffic, thus increasing the likelihood of noticing oncoming cars, and indeed of oncoming drivers noticing the pedestrians:

5.2.5 Staggered crossings on two-way roads should have a left handed stagger so that pedestrians on the central refuge are guided to face the approaching traffic stream.

When I gave this example of Design with Intent at Lancaster, the discussion – led, I think, by Lucy Suchman and Patricia Clough – turned to how this arrangement inevitably formalised and reinforced the embedded hegemony of the motor car in society, and so on: that the motorist is privileged over the pedestrian and the pedestrian must submit by watching out for cars, rather than the other way around.

Now, all that is arguably true – I had seen this example as merely a clever, sensible way to use design to influence user behaviour for safety, for everyone’s benefit (both pedestrians and drivers) without it costing any more than, say, a crossing staggered the opposite way round – but this is, maybe, the nature of this whole field of Design with Intent: lots of disciplines potentially have perspectives on it and what it means. What a traffic engineer or an ergonomist or a mistake-proofer sees as a safety measure, a sociologist may see as a designed-in power relation. What Microsoft saw as a tool for helping users was seen as patronising and annoying (at least by the most vociferous users). It’s all interesting, because it all broadens the number of interpretations and considerations applied to everything, and – if I’m honest – force me to think on more levels about every example.

Multiple lenses are helpful to designers otherwise stuck at whatever focal length the client’s prescribed.

Back to the crossings, though: the above crossing in Bath is a bit unusual in how it’s arranged with so many control panels for pedestrians. But in general, with simple Pelican and Puffin crossings in the UK, there is a design feature even more obvious, which only struck me* the same day I photographed the above crossing in Bath: the pedestrian signal control panel is usually also to the right of where pedestrians stand waiting to cross, i.e. (with UK driving on the left), in order to press the button, pedestrians have to turn to face the oncoming traffic.

The guidelines actually mention this as helping people with poor vision, but it would seem that it really assists all users, even if only slightly. It means you can watch the traffic as you decide whether or not you actually need to press the button, and will be more likely to be standing in a position where you can see the oncoming traffic at the point when you walk out into the road.

5.1.7 To assist blind and partially sighted pedestrians, as they approach the crossing, the primary push button/indicator panel should normally be located on the right hand side. The alignment should encourage them to face oncoming vehicles. The centre of the push button should be between 1.0 and 1.1 metres above the footway level.

This is the sort of ‘hidden’ intentional, strategic design detailing which fascinates me. It is obvious, it is quotidian, but it’s also thoughtful.

Staggered crossing in Bath

*Looking back through my notebooks, I see that someone actually mentioned this to me at a seminar at Sheffield Hallam in September 2007 but I forgot about it: many thanks to whoever it was, and I should be better at reading through my notes next time!