Defining the problem: Thermostat (part 1)
“Defining the problem” is the process of determining why we are making this product in the first place and for whom. It is in this stage where clients reap a large part of the value of hiring a designer. That can be a confusing notion for clients because they often think that they have hired a designer to solve a problem that has already been defined. A client recently asked me to create a proof of concept for an iPad thermostat and I thought this would be a great opportunity to talk about how defining the problem can be more complex and nuanced than it first appears and how a better understanding of the problem can lead to a better solution.
The “ask”
My client’s functional requirements were fairly simple: that there should be a simple interface where the user could adjust the heating and cooling set point. The “set point” is the point at which the heating and cooling system kicks in. So, for instance, if my heating set point is 68 degrees, then the heating system will kick in when the room temperature drops below 68 degrees. This was not intended to be a “smart” thermostat where the system anticipates the users needs and schedule — such as automatically shutting down when the user is at work. Nor was it intended to take into account other variables such as humidity, air flow, or human activity — which have a huge impact on our sense of comfort. The challenge in this instance was to create an interface for a fairly conventional thermostat function. In other words, keep it simple.
User research
I began by interviewing 4 home thermostat users. I “shadowed” them while they performed their most common thermostat tasks for me.
Although the thermostat systems they used varied considerably, their experiences often overlapped. Here are my summarized findings:
Too many options. Users were faced with more options than they had desire to learn. And the options did not impress them; it made them feel inadequate. One of the 4 was more of an “energy nerd” who desired to master the gadget but the others wished it would just work and go away. They did not want it to divert energy from other tasks in their life.
Context was missing. All of the users’ homes were multi-zoned, that is, they contained areas that could be controlled independently of each other. Yet none of the systems offered users a snapshot or birds-eye-view of what was going on in their house overall. Three of the 4 interviewees asked for this feature specifically.
Users failed at programming and/or programming failed them. All of the users’ thermostats were, in theory, “programmable”, that is the user was able to create a schedule and that thermostat would follow, yet only 2 of the 4 used this feature. The ones who did not use programming were vaguely aware of it but were intimidated by it. Both of the users who did use it described the problem of having irregular schedules that required constantly overriding the programmed schedule.
Visual feedback was inadequate. All of the thermostats told their story largely by using monochrome numbers and symbols. Although the users had come to learn the meaning of the what was being represented on the display, they sometimes stumbled when they tried to explain it or had to pause to remind themselves the meaning of what was being displayed. The clearest example of this is when the actual temperature of the zone differs from the “set to” temperature of the zone — users sometimes had to remind themselves which was which.
Thermostat was an alien object. In general, the thermostat design did jibe with their other useful objects like their phone or their coffee maker. These everyday objects had been chosen because they were easy to use or elegant. The thermostat was neither; it was necessary and awkward.
What’s been published?
Luckily there is quite a bit of published research on thermostat usage. I will point out here just a few of the papers that were most useful to me. In “Usability of residential thermostats: Preliminary investigation”, the authors point out that there is a “widespread misunderstanding” regarding the thermostat operation, namely, users think that turning up the thermostat dial increases the intensity of the heat/cooling while in reality adjusting the thermostat simply tells the system when to turn on and when to turn off; the intensity remains static. This misunderstanding can cause cycles of over heating and over cooling which leads to user discomfort and frustration. In addition, by far the majority of users bypass the scheduling feature of the thermostat in one way or another.
“How People Actually Use Thermostats” is a report on the usability of common thermostat models and found that for the most part the interface obscured the actual operation of the thermostat. Users resorted to trial and error in their attempt to get desired results.
One article that I found particularly salient was “Emotional Design Fail: I’m Divorcing My Nest Thermostat”, in which author Kara Pernice uses usability visionary Don Norman’s principles to explain the failings of the Nest thermostat. The complaint is that it takes away the users control in a non-transparent manner. The Nest makes decisions but does not the tell the user why. When the user tries to override, things get very, very complicated.
Persona and scenario
In this case I chose to assimilate the above research into a single persona. In creating the persona, I took my cue from lean UX advocates, Jeff Gothelf and Josh Seiden. Gothelf and Seiden recommend folding a piece of paper into quarters. The top left quadrant contains some relevant demographic info and a tagline. The top right contains a description of the persona — key factors in her life that will influence this design. The bottom left quadrant describes what she needs from this product and the bottom right describes what features she would be served by, i.e., what would address her needs.
If this hand drawn sheet all seems provisional — that’s because it is. The persona itself is a hypothesis that will have to be tested and revised as needed. If, for instance, we find that real life users do not prioritize their “needs” according to our initial assumptions, we make adjustments to our persona; the persona is merely a snapshot of our mental model of the user at this moment in time. This approach flips the traditional persona on its head. Instead of establishing a set of iron-clad assumptions as a foundation for our design, we keep it flexible. This fits with the lean design philosophy of testing every assumption, no matter how “self-evident” it is perceived to be.
Once the persona was established, I outlined common scenarios. The product design must be able to address these essential scenarios in order to be successful.
So, this is the basic framework or “problem” for the design work ahead. Part 2 of this article will describe how I used this framework to come up that a design solution. Read Part 2…
