Ideal Thermostat Iteration 4: What Do Users Care About?
You might remember last week that version number three of the “ideal thermostat” was a total visual and functional redesign of the interface. After a series of think-aloud user tests where users would use my interface while telling me what they were doing, I went back to the studio to think about my intentions behind completely revamping the system in version 3.
In reflection, where I’d like my interface to be as simplistic as possible, I fear that I might have made some design decisions that confused users. Let’s take a look at the heat/cool functionality in version 3.
When I’m working on something, I like to ask “so what?” every time I think of something new to implement. What do users really care about when they are using a thermostat? Or, as one of my users in my most recent batch of user testing confessed,
“Why would you need a screen that tells you exactly what the temperature is going to be? I don’t care. I just wanna be cooler. I can take off my shirt for that.”
It’s true. Adding functionality to something just because you think it looks nice or it’s something to show off your skills does nothing for the user. So, taking that thought into Iteration 4, I redid the way the system provides feedback on its heating/cooling elements.
Let’s talk about what’s new in iteration 4—see the full PDF of wireframes here.
The current/set temperature has been combined into one number; on the main screen, when the user is just glancing at the temperature, the temperature is gray and displays, “Currently…” but when the user changes the temperature…
…the display changes to black to indicate that the temperature will now heat/cool up or down to that point. Once the temperature has been achieved, the new temperature will display “currently” and fade to gray. I brought back the functionality of the user pressing the up or down arrow three times to activate the heat/cool function, now with updated feedback for the user that clearly shows the heat or cool is on.
The scheduler has been tweaked slightly to show what happens when a user turns a schedule off or on.
If a user toggles the daily schedule on or off there is a feedback that displays on the main screen that shows the user that the schedule is running.
The scheduler itself is maturing, so I’ve only updated a few tweaks on the dialog boxes and how users confirm or delete schedules on the timeline.
At this moment, I’m being very careful to show things to the users when they want to see them, and to hide them when they don’t. For example, on the main schedule selection screen, you might have noticed a series of white dots where a user can add a schedule. When the user taps on a specific bubble to edit a schedule, the dots fade, and so do the colors of the other times slightly so that the user can focus on one single space on the timeline.
What Did the Users Say?
As always, what would an iteration be without user testing? If you are not already aware, we are not handed the users that we test with—we go out into the world and find folks who are willing to spend their time and energy tirelessly testing interfaces with us. My method of choice is bribery:
James Lewis and I set up shop in a throughway and offered free donuts to anyone who was interested in testing our interface. I learned several things through our users:
1) I should have anticipated this before, but the “push three times to heat/cool” was a hidden function that shouldn’t be so hidden. Users mentioned that they’d like the heat to be turned on as soon as they adjust the temperature upwards—the idea of a “heat” or a “cool” state separate from the actual temperature that you would like it to be didn’t make sense to them.
2) At first I thought that this was an edge case, but now I think it’s a confirmed issue—when users tried to toggle the fan on and off, it wasn’t clear to them what state the fan was in because of the words, “FAN OFF.” Some people assumed that the fan was already on, and they had to press it to turn the fan off; some thought the wording wasn’t as clear as what they’d hoped.
3) The Cancel/Delete states on the scheduler seemed to give some people trouble. They would automatically switch depending on which state the interface was in (creation state vs. an editing state), but this wasn’t as clear as I’d hoped. There were a couple of comments such as, “Hey! It changed!” and “Huh?” when the new menu popped up.
At this iteration, I can say confidently that I am liking where this interface is going. In the newer version, I’m going to re-map out all the states that I’m interested in having and get rid of the heat/cool state altogether—the most common feedback I’ve heard is that they want to have a “set it and forget it” interaction with their thermostat and I’m working with innovative ways of allowing that interaction between users and their device.
Ideal Thermostat Interface by Chelsea Hostetter is licensed under a Creative Commons Attribution-NonCommercial 4.0 International License.