Being Your User
By: Nicholas Hill
Chief Executive Officer
19th December 2018
One of the important steps in the Design Council’s recommendations for good design is called “Being Your Users” and is a “Method to put yourself into the position of your user.” Its purpose is “building an understanding of and empathy with the users of your product …” Approaching product design from this perspective is critical to ensuring that the features incorporated are actually beneficial to the user – as opposed to features that are of benefit to the manufacturer, for example, or “because we can” features that have no obvious benefit at all.
It’s clear that domestic appliances are becoming more sophisticated, a trend which is facilitated by the availability of low-cost sensors and processing power. This has some clear benefits, such as the availability of more energy- or water-efficient wash cycles for example. And if designers stay focused on providing something of value to the end user this is a trend to be welcomed.
In practice, I see examples of what looks rather like engineers wondering what else they can do with all this additional sensor data, rather than being driven by user need. One example is the growing size of the error codes table in the back of most appliance manuals. These may occasionally add value, but for the most part, I see them as reasons why the product you paid good money for is refusing to do the job it is supposed to.
Here’s an example: the “smart” washing machine that I own doesn’t like low water pressure. It has a number of error codes associated with this. What does it do if the mains pressure drops temporarily – e.g. if simultaneously a toilet is flushed and the kitchen tap is running? It stops dead, displays the error code and refuses to do anything else until you power off the machine at the wall socket, forcing you to start the wash cycle again from scratch. This gets even more annoying if you’d set the timer and come back to a half-washed load. In the days before “smart” appliances, a temporary pressure drop would have either simply caused the water to fill more slowly, or else the machine would pause until pressure returned.
In what way does this behaviour benefit the user? Clearly, it doesn’t, and a few moments thought from a design team that was focussed on user needs, “being your user”, would have resulted in a different requirement specification being handed to the engineering team. It’s a good example of what happens when you start implementing a solution without properly considering the problem you are trying to solve.
My “intelligent” dishwasher has a different but equally maddening feature: it doesn’t like soft water. Its designers have clearly put water saving above all else, and the machine relies on either hard water or very dirty plates to counteract the natural foaming of the detergent tablets. With soft water, if you try washing lightly soiled dishes on a quick wash cycle (as you might expect appropriate), the machine is unable to rinse off the detergent. About 20 minutes into the cycle it skips to the end and gives up, leaving you with foamy, unrinsed plates.
I say unable, when the machine is actually unwilling, as all that is required is the application of sufficient water to rinse off the detergent – which is what I, as a user, then have to do manually. Who is working for whom here? Once again the user’s needs have not been at the top of the designer’s agenda when the requirement specification was passed to the engineering team. A truly smart device would finish the job properly, using as much water as was needed, and possibly suggest using less detergent next time.
Unless designers get a better grip, keeping the end user experience on the agenda, I fear examples of this type of machine behaviour will proliferate. We will see our devices, appliances and perhaps vehicles develop an increasingly long list of reasons why they can’t (won’t) perform the function you bought them for – because they’re having a bad hair day today, which becomes your problem to solve.
All to a refrain of “I’m sorry Dave, I’m afraid I can’t do that.”
One of the important steps in the Design Council’s recommendations for good design is called “Being Your Users” and is a “Method to put yourself into the position of your user.” Its purpose is “building an understanding of and empathy with the users of your product …” Approaching product design from this perspective is critical to ensuring that the features incorporated are actually beneficial to the user – as opposed to features that are of benefit to the manufacturer, for example, or “because we can” features that have no obvious benefit at all.
It’s clear that domestic appliances are becoming more sophisticated, a trend which is facilitated by the availability of low-cost sensors and processing power. This has some clear benefits, such as the availability of more energy- or water-efficient wash cycles for example. And if designers stay focused on providing something of value to the end user this is a trend to be welcomed.
In practice, I see examples of what looks rather like engineers wondering what else they can do with all this additional sensor data, rather than being driven by user need. One example is the growing size of the error codes table in the back of most appliance manuals. These may occasionally add value, but for the most part, I see them as reasons why the product you paid good money for is refusing to do the job it is supposed to.
Here’s an example: the “smart” washing machine that I own doesn’t like low water pressure. It has a number of error codes associated with this. What does it do if the mains pressure drops temporarily – e.g. if simultaneously a toilet is flushed and the kitchen tap is running? It stops dead, displays the error code and refuses to do anything else until you power off the machine at the wall socket, forcing you to start the wash cycle again from scratch. This gets even more annoying if you’d set the timer and come back to a half-washed load. In the days before “smart” appliances, a temporary pressure drop would have either simply caused the water to fill more slowly, or else the machine would pause until pressure returned.
In what way does this behaviour benefit the user? Clearly, it doesn’t, and a few moments thought from a design team that was focussed on user needs, “being your user”, would have resulted in a different requirement specification being handed to the engineering team. It’s a good example of what happens when you start implementing a solution without properly considering the problem you are trying to solve.
My “intelligent” dishwasher has a different but equally maddening feature: it doesn’t like soft water. Its designers have clearly put water saving above all else, and the machine relies on either hard water or very dirty plates to counteract the natural foaming of the detergent tablets. With soft water, if you try washing lightly soiled dishes on a quick wash cycle (as you might expect appropriate), the machine is unable to rinse off the detergent. About 20 minutes into the cycle it skips to the end and gives up, leaving you with foamy, unrinsed plates.
I say unable, when the machine is actually unwilling, as all that is required is the application of sufficient water to rinse off the detergent – which is what I, as a user, then have to do manually. Who is working for whom here? Once again the user’s needs have not been at the top of the designer’s agenda when the requirement specification was passed to the engineering team. A truly smart device would finish the job properly, using as much water as was needed, and possibly suggest using less detergent next time.
Unless designers get a better grip, keeping the end user experience on the agenda, I fear examples of this type of machine behaviour will proliferate. We will see our devices, appliances and perhaps vehicles develop an increasingly long list of reasons why they can’t (won’t) perform the function you bought them for – because they’re having a bad hair day today, which becomes your problem to solve.
All to a refrain of “I’m sorry Dave, I’m afraid I can’t do that.”
