Designer baby

How easy to use is a baby? Paul Curzon, father to a newborn son and computer scientist at Queen Mary, University of London, investigates.

I recently acquired a new interactive gadget, better known as a newborn baby. How well-designed is he, I wondered. In particular how usable is he for a novice like me? Time to do a usability analysis.

Heuristic evaluation is one of the simplest and most commonly-used methods to evaluate the usability of a new system. It involves checking the system against a set of 10 design principles: things like the "the system should always keep users informed of what is going on". The usability expert judges the system under evaluation against each principle making a list of potential problems and suggests improvements to fix each. Here goes for our baby...

What’s going on?

The first principle to check, visibility of system status, is about whether you can tell what is going on inside a gadget as you interact with it. It's all about 'feedback'. Every interactive gadget has a hidden internal state to keep track of what it is doing, and users need to be able to tell what that state is when it matters. The feedback should not only be understandable but also be timely. It's likely to be useless if it comes too late.

So how does the baby do for visibility? Well there are five or six main internal states that seem to matter: happy, tired, hungry, in pain and needing his nappy changing. He certainly gives feedback about all of them. It's clear when he is happy. It’s all smiles, gurgling and cooing. When he enters one of the other states you definitely know it. He screams his head off. The feedback is timely too! The moment he leaves the happy state he starts to scream and he won’t stop unless you fix the problem, however long it takes. So far so good! There is a problem though: for a novice at least, there seems to be only one form of feedback for all non-happy states. It seems to be impossible to tell the states apart, and so to know what the right thing is to do: feed him? Change his nappy? Rock him to sleep? Kiss him better? All you can do is guess.

Our designer baby definitely needs something more. A screen on the forehead might be one option. It could flash a message that just says what the problem actually is. Simple.

Speak the lingo

The second design principle to check is about the match between the system and the real world. This is a convoluted way of saying it must be easy to understand. Does it use the same language and concepts as you or do you have to learn what everything means first to use it? Does it follow standard conventions?

Hmm! The baby doesn’t do so well here. He uses screams. It certainly would help if there was a bit of English there from the start. Just a few words like “hungry”, “poo”, and so on pre-installed when it came out of the box would be a big improvement.

Control!

Principle 3 is about user control and freedom. The user of the system should feel they have control. They should feel things happen when they want them to, rather than the system just doing things behind their back without them being able to stop it. There should be simple controls to get the state to where you want it, too – like an undo button for when something goes wrong and a home button that takes you back to the start rather than you having to navigate there.

What can I say? This doesn’t seem to have been taken into account at all in the baby’s design. In fact, since we had the baby, my whole life is out of control now, never mind the baby! Focusing on the baby though, I seem to have little control of it at all. Things just happen and I have to react, with little easy way of gaining back control. Take poo! You try and gain control by changing it before it leaks and what happens? Five minutes later, when it’s most inconvenient, he goes and poos. You have to change him all over again.

Some of the help books suggest you can gain control by fixing feeding times and sleep times, ignoring the screams of anger that result. After a while (and we are talking months of frazzled nerves rather than hours here) the baby will fall in to the routine and all will be fine. Why on earth didn’t the designer didn’t just build that behaviour in as standard? There definitely should be a home button. It would just put the baby back in the happy state it was in when it first woke up, allowing you to start the day again. A “poo now” button would also be good. In fact that is so obvious I can’t imagine why the designer never thought of it. He or she must have never had a baby themselves.

Same again?

The next principle is about consistency and standards. The system shouldn’t do different things at different times that mean the same thing.

At first sight this seems to be ok. The baby just screams whatever he wants something. That’s pretty consistent! However, with more detailed observation it’s clear there is more going on. When he is tired, sometimes he screams. At other times he starts to angrily throw his toys about. At calmer times he starts to twist his hair with his fingers, or just reaches up for a cuddle, all meaning I need to sleep.

We want consistency so for our designer baby. The designer should pick one way to communicate the message and stick to it. My preference would be for using the reaching up for a cuddle signal. We are focusing on usability here rather than user experience. However, user experience is important too. If the baby always used the “want cuddle” signal rather than the “scream” signal whenever he wanted to communicate “I’m tired” it would certainly improve my experience! User experience is good for business if you want repeat sales. If the designer had focused a bit more on experience it would have increased the likelihood I would get another.

Ooooops!

Next we have two principles about mistakes. The first is about helping users recognize, diagnose, and recover from errors.

People make mistakes and the designer of a system has to take that into account. If mistakes do happen the system should help you put things right. Above all, error messages should be easy to understand – so absolutely no codes like “Error 404”!

Giving too much milk is an obvious case to consider here. There have been times when I’ve thought the baby was hungry. He was screaming after all, so I gave him more milk, only to have him immediately puke up all over me. That is a pretty clear error message. It indicates exactly what the problem was and actually automatically fixes the problem for you. Good design!

Some mistake, surely!

The next principle is pretty straight-forward: error prevention.

Rather than just giving a good error message when the user does something wrong, it is far better to use good design to prevent people making mistakes in the first place.

Returning to the problem of giving the baby too much milk, the error message was clear and impossible to miss, but I would of course have preferred not to have been puked on. It would have helped not to make the mistake in the first place.

There is an easy fix for this. The baby needs a fuel gauge that shows when it is empty as well as when it is full. It needs to be very visible during feeding. It could possibly run up the bridge of the nose. That would make it clearly visible, at least when feeding with a bottle, though perhaps less so when breastfeeding. Perhaps a fuel gauge down each cheek would be better. Better still though, the baby could also include a mechanism that guarantees to prevent the bottle/breast being inserted in the mouth when full. It could stay shut for example. This is called a ‘forcing function’. Forcing functions don’t rely on warnings which you could miss, they prevent the mistaken action being done at all.

I do recall!

Another important principle to follow is about recognition rather than recall. People have poor memories, especially when they are tired, stressed or have a lot to think about. With a new baby you definitely tick all those boxes! So rather than expect people to remember the right command or how far you got before being interrupted, it should all be visible. Instructions and help should be very easily accessible.

Let’s say the options for quieting a screaming baby might be ‘feed’, ‘cuddle’ and ‘change nappy’. Rather than expecting the person to remember them, present them as options to choose from. Suppose you were in the middle of feeding when you had a poo emergency to deal with. When that is dealt with, the system should make it clear you hadn’t finished the feed, rather than depending on you to remember. (Ideally designers might come up with a better warning than just having the baby continuing to scream uninterrupted.)

Be flexible

As you move on from being a complete beginner with a system, flexibility and efficiency of use become more and more important. Novices and experienced users have different needs. The system needs to guide beginners through activities while still allowing experts to do things quickly. One way of achieving this is to allow people to tailor the way they do the most frequent common tasks so they can be done with a single button press.

I haven’t discovered any short-cut keys on the baby so far, never mind being able to set what they do myself. Now that he eats solid foods, feeding takes an overly long time to do, for example. An ‘open mouth’ short cut would certainly help. Waving the spoon around in front of him and saying “open up for the train”, while his mouth stays well and truly clamped shut, gets a bit frustrating after a while.

Looking good!

The next principle, aesthetic and minimalist design, is a bit tricky. Aesthetics is partly about looking good, but here that isn’t what matters most. The thing to keep in mind is that for every new piece of information you present to the user, and every new button you add, the harder it becomes to find the one you need right now.

It boils down to the KISS principle – Keep It Simple, Stupid – though that can be harder to do than you might imagine and it is easy to break the other principles if you focus on this naively. With our baby, for example, that might have been what the designer was thinking when they added the scream signal to mean something’s wrong. It is certainly minimalist, but doesn’t help! On the other hand the baby isn’t cluttered with buttons and screens, so generally it does well on this criteria. As we make improvements to fix other problems though we will have to be careful we don’t make things too complicated by adding too many new displays and controls.

Help!

The final principal is perhaps the most obvious of all: help and documentation. The system should be shipped with easily accessible and searchable documentation.

My baby came with no documentation at all! We had to go out and buy books to tell us what to do. They didn’t seem to be for our model of baby, though. They also gave conflicting advice. Should you “feed on demand” or “feed at the same times every day”? I still haven’t a clue. The designers need to provide a simple, straightforward manual that focuses on the task the parents are trying to do, like feed or bathe, and list the concrete steps needed for each task. The manual should be delivered with the baby.

Getting it right

Of course we haven’t done a fully rigorous heuristic evaluation here. To do that we would explore the system in lots more detail for a wide range of activities. We would also get several experts to do the evaluation in parallel, each drawing up a list of issues that they found. These would then be pooled with discussion about which were the most critical. All in all, though even with our light touch evaluation, it's clear that babies are not really designed as walk-up-and-use devices – they are certainly not for novices. Clearly until the design is improved in a subsequent release of the model they should really only be given to experts. New users need significant training in advance before being let loose with one.