Fil Salustri's Design Site

Site Tools


Coffeemaker Case Study

An example of how important it is to see design situations as your users see them.

lh4.googleusercontent.com_-pij0mmngcba_uxixp6nvrdi_aaaaaaaaq4y_vl65xu2rrlk_w709-h945-no_20140301_122146.jpgFig. 1: Our coffee-maker.

My wife and I once bought a nice, new, reasonably expensive coffee-maker for our home. It was made by a reputable company and bought at a reputable store. It was similar to the one in the photo to the right.

There were (at least) two things wrong with it, that neither my wife nor I noticed till we started using it. They are evident in the photo.

Exercise for the reader Take a moment, and sketch out some usage scenarios for this coffee-maker, before you continue reading the case. In particular, consider the scenarios of preparing the coffee-maker to make coffee, and using it to dispense coffee.

Try to summarize what you think could go wrong with some IECs.

My wife and I set up the coffee-maker before bed, so that it will start itself in the morning (it has a timer) and the coffee will be ready for us - because we're both quite useless in the morning without it.

However, in the evenings, when we set up the coffee-maker for the following day, we are also usually incredibly tired. And that is where two serious design flaws become evident.

Is there any coffee left in the carafe from that day? We don't always finish the coffee that gets made in a given day. I have no problem with day-old coffee, but my wife does. In either case, it is actually possible that there's so much leftover coffee in the carafe that making more will only make it overflow.

How do I know if there's water in the coffee-maker? Sometimes my wife or I will start making coffee, but get distracted by something and forget what we were doing. Later in the evening, one or the other of us will finish the preparatory work. Sometimes, my wife will already be asleep by the time I get to it. I won't wake her just to ask if she put water in the coffee-maker. How can I be sure?

If a designer had asked us before we'd bought this coffee-maker, we would not have told him that it's important to us that we need to see how much coffee is in the carafe and how much water is in the coffee-maker. These things wouldn't have occurred to us, because our old coffee maker had a water level in the maker and a transparent carafe. We were used to it, so it wouldn't have been noteworthy.

After buying the new coffee-maker, however, we were completely aware of these things and would have certainly brought them to the attention of anyone who asked us.

This raises a problem for designers. They can ask users what they need, but - as this case clearly indicates - the users themselves may not have any idea what they really want.

This is why it's important to ask users what is wrong with what they already have, rather than asking them what they want. Even more importantly - because users may not actually know what's wrong with a design (as we did not know) - designers must actually study and watch users, because their behaviours will often make clear what is really wrong with a situation. This is sometimes called design anthropology or design ethnography. Clearly, this analytic aspect of understanding ones users is very important in problem analysis.

This also raises an important use of usage scenarios, situated use cases, and interaction error charts: they help people communicate and share information about how they use products, which in turn helps designers find those situational aspects that they might not otherwise have thought of.

design/coffeemaker_case_study.txt · Last modified: 2020.03.12 13:30 (external edit)