Observation, stumbles and smiles

By Gordon Rugg

If you’re designing something that’s going to be used, as opposed to something decorative, then it’s a really good idea to make it fit for its purpose.

How can you do that? Observing the users is a good start.

“Observing” is a broad term that includes various specialised forms of observation and analysis. In this article, I’ll describe a simple way of doing basic observation of users, which involves watching out for four key alliteratively-named actions:

stumbles
scowls
swearwords
smiles

It’s simple, but it’s powerful, and it usually catches most of the main problems, and it gives you a good start towards designing something that the users will like.

Not great art, but useful: Four things to watch for in task analysis

Sources of original images are given at the end of this article

Observing

“Observing”at the most basic level is what it sounds like; you observe what someone does. I’ve blogged about various forms of observation previously, including a general overview, structured observation of the environment (STROBE), and ways of recording what you observe, such as timelines and tally sheets.

You can gather a fair amount of useful information just by watching and looking for regularities in what happens. However, that simple approach only gets you some of the way.

One problem with the simple approach is that you’ll probably overlook a lot of important regularities precisely because they’re so familiar that you take them for granted, or view them as not worth mentioning.

Another problem with the simple approach is that it doesn’t give you any numbers that you can use for purposes such as assessing which regularities are most important or most common.

One simple, practical way of recording your observations more systematically is to use a timeline chart, such as the one below, from one of our previous articles.

Copyleft Hyde & Rugg, 2015

This particular chart is designed to let you track the sequence of actions performed by one person, action by action. Each column is a time slice, starting at the left. In this example, the person starts by reading something (shown by the tick in the first column) and then hesitates (the tick in the second column), then clicks on an option, puts in text, and then swears.

This type of chart is useful for identifying where things go wrong; you can work back from the swearword and see what came before it.

This basic design of chart can easily be adapted to record other aspects of observation. For instance, suppose that you want to record what people do once they walk through the door of a medical practice or hospital. It would be useful to know how many people hesitate, as opposed to walking straight on towards their destination; it would be useful to know how many people read instructions and signage. You can record this by using a tally chart, where you tick the relevant row every time someone performs a particular action, as in the example below. You then count the ticks in each row, once you’ve finished collecting the data.

Copyleft Hyde & Rugg, 2015

This raises the question of how you know which actions you should record. There are various answers.

One answer is to get the actions from a critical review of the relevant literature. That can be very useful if you’re looking for actions whose significance you might have missed otherwise; previous researchers may well have spotted that significance.

Another answer is to look for any departure from “not committing a breach of the peace”. It’s a well-established joke in Britain that almost anything can be construed as a breach of the peace by a suspicious police officer. A cynical legal commentator once commented that walking in silence while breathing through the nose and looking only at the route ahead was probably just about okay; anything else could be construed negatively.

The way that this translates into observation is that you can treat “walking in silence while looking only at the route ahead” as the default activity. You can then notice when someone departs from that activity in any way; for instance, by making eye contact with someone, or by slowing down, or by saying something. Any of these departures might be a suitable action to include in your recording; you’ll need to use your judgment.

Some of those other activities are clearly planned and intended. Others, however, aren’t. Those are the topics of today’s article. Three of them are indicators that something has gone wrong (so you know that something needs to be fixed). One of them is usually an indicator that something has gone well (in which case, something needs to be kept in).

The next section goes through each of these in turn.

Stumbles

I’m using the word “stumble” here in a broad sense, to describe any sudden break in a previously smooth pattern of actions. Examples include:

a sudden change from walking smoothly to walking irregularly, or tripping
a sudden change from using a computer interface swiftly and confidently to hesitating or stopping and reading instructions
a sudden change from talking fluently to talking in broken phrases, using hesitation noises, or silence

I’ve blogged previously about how you can use this approach to identify significant points in a transcript, when the speakers suddenly realise that something unexpected has happened that they don’t understand.

In a lot of cases of stumbles, what is involved is a switch from a compiled skill to deliberate reasoning. Compiled skills are known in different fields under different names, such as “muscle memory”. They are skills that are so well practised that the person can perform them without the need for conscious thought.

Not needing conscious thought is a great advantage of compiled skills, since they free the brain up for doing other tasks at the same time – for instance, talking while doing routine driving. This is one reason why walking in a busy street is usually much more tiring than walking the same distance in a quiet street; in the busy street, you’re constantly having to switch out of walking as a compiled skill because you need to adjust pace to avoid bumping into the person in front of you.

If you’re designing a product, whether it’s a computer interface or a toaster or a building, it’s a good idea to design it so that the user can work with it smoothly, without stumbles.

This is at the heart of the concept of the transparent interface for software; it’s an interface so easy to use that it doesn’t require conscious thought, and the user doesn’t even notice it.

When you start looking for stumbles, you soon notice how common they are. Automatic doors are a good example. A lot of them only start opening when you’re very close to them, so you have to change your walking pace to avoid colliding with them.

People don’t usually like having to switch from a compiled skill into having to use deliberate thought, so when this happens, you often observe one of the next two actions.

Scowls

I’m using “scowl” in a broad sense, to include expressions of puzzlement as well as annoyance. A common pattern is a frown, followed by looking more closely at whatever caused the problem.

This is often the point where people read the instructions, such as “pull” on a door that they have just tried to push. Reading instructions is another example of deliberate thought, and people usually only use deliberate thought (and reading) as a fallback strategy, not as a first choice.

Swearwords

Swearwords are invaluable to anyone designing a product or a system, because they tell you clearly and audibly that a problem is significant. Problems that regularly cause swearing are problems that go high on the “to fix” stack.

If you’re working with data collected by someone else, swearwords are something to check for. If there aren’t any swearwords in a transcript, or the swearwords are only mild ones, then you need to wonder whether the transcriber has edited them out or toned them down. If so, you need to wonder what else the transcriber might have got up to.

If you hear angry swearwords when you’re observing someone who’s trying out a product that you helped design, there’s a strong temptation to try to defend or explain the product to them. It’s a temptation that you need to resist. If that product is rolled out commercially to tens of thousands of users, you won’t be sitting there next to each of them to explain it. The product has to be good without your explanation.

What you need to do instead is to practise putting yourself into the tester’s position, and seeing things through their eyes, and working out where the product didn’t behave in the way that they wanted or expected. Then you can start working out how to make it behave in a way that they will like, which leads us on to the next type of response.

Smiles

When you get a design really right, you know about it in two main ways.

One is an invisible compliment; the product or service works so smoothly that people don’t notice it.

The other is much more immediately gratifying. You see users smiling, or you see a metaphorical light bulb switch on above their head as they realise what they can do with the thing that you’ve designed, or you hear them saying “wow” or good swearwords. It’s a very, very satisfying moment.

Which is a good note on which to end.

Notes and links

You’re welcome to use Hyde & Rugg copyleft images for any non-commercial purpose, including lectures, provided that you state that they’re copyleft Hyde & Rugg.

There’s more about the theory behind this article in my latest book:

Blind Spot, by Gordon Rugg with Joseph D’Agnese

http://www.amazon.co.uk/Blind-Spot-Gordon-Rugg/dp/0062097903

Sources of images in the banner:

https://openclipart.org/detail/14453/trip-hazard-warning-sign

https://openclipart.org/detail/190668/frown

https://openclipart.org/detail/215785/yellow-angry-head

https://openclipart.org/detail/22035/smiley-cool

Related articles:

https://hydeandrugg.wordpress.com/2015/05/01/people-in-architectural-drawings-part-5-common-requirements/

https://hydeandrugg.wordpress.com/2014/05/03/the-compass-rose-model-for-requirements-gathering/

https://hydeandrugg.wordpress.com/2014/03/09/finding-out-what-people-want-in-a-nutshell/