News and blog posts from our students and faculty

Thermostat User Interface (UI) Testing

Wednesday, December 4th, 2013 | Posted by James Lewis

This is the latest installment of posts about the iterative design and user testing process I’ve conducted for designing a thermostat user interface (UI) – Read my last update about my latest redesign here.

One of the challenging aspects of conducting user testing for my thermostat UI has been recruiting test subjects. I’m new to Austin, don’t know many people outside AC4D, and I find walking up to strangers at a coffee shop painful (and often not successful.) So, with a little help from my friends I went along with fellow classmate Chelsea Hostetter to do some user testing at the University of Texas at Austin.  Chelsea and I each held up a sign on campus asking “Want Free Food? Help me test a design!” It was embarrassing but worked. UT undergrads are a curious bunch and many were enticed by the free donuts we provided.

I was using my thermostat designs from last week, which you may view in full here. The users were all able to complete the tasks I assigned them which were:

  • Change the temperature from 68°F to 72°F
  • Turn the system from heat to cool, and return home
  • Turn the fan off, and return home.
  • Set the schedule to 72°F every Sunday and Saturday

Users doing talk aloud testing on paper prototypes of my thermostat design

While I was psyched they could all complete the tasks, they typically did it in a manner differently from what I had anticipated. For example, when changing the system from heat to cool, users tapped on the “H” icon rather than swiping the system tab into the center.

While this worked for my second and third tasks, I ran into problems with the final task of setting the schedule: “Set the schedule to 72°F every Sunday and Saturday”

While the users understood how to set the schedule, I hadn’t anticipated all the different paths they could take to get there. For instance, they might have arrived on Sunday as the first screen on the schedule page, but their first action was to swipe to Saturday. That’s fine, except I didn’t have those mockups created! They eventually figured out the original flow I anticipated, but it was not the first path they wanted to try. Since I didn’t have all the screens available and it was pretty apparent I needed to, I finished testing early with only 3 of my 5 tests since I knew exactly what I needed to fix.

Secondly, I had thought after users created the schedule point on Sunday they would click the “copy” button to add the same point on Saturday.

However, the testers didn’t notice the text message and instead clicked on Saturday to set the same point. It might have involved more steps for them, but the option to copy the schedule point wasn’t in their mental model. I think instead this might be more of a feature for power users rather than the every day one.

Testers did respond to thermostat design as being easy to use; the touch interactions reminded them of an iPhone and they thought the language was easier to understand than their thermostats at home. One exception was referring to the temperature screen as “Home.” While it might function as the home screen, since it is never referred to as such in the design, it’s silly to ask users to return home during the tasks. I either need to tell them to return to the temperature screen or leave that part of the task out.

I have since come up with some subtle changes to the UI design on the scheduling screens. You may download those annotated wireframes here.

This week I plan on creating more screens to account for all the possible paths a user could take to complete the tasks I assign them. I’m excited with what I’ve come up with so far and feel like I have a strong design I can continue to develop.

No Comments »