Swipe Thermostat

Teammembers
Peter Hogaboam          Andrew Tatge

Timeline
9 days

The project Brief

Thermostats are a simple technology that many misunderstand. The mental model consumers have is that thermostats work harder if “cranked.” People often set a thermostat beyond the desired temperature (which won't make it go faster), and forget to readjust it once it reaches the ideal temperature. When it passes beyond the ideal temperature, they have to adjust the thermostat again. Aside from the inconvenience of changing the temperature repeatedly, there are energy and financial losses that have a large impact at scale. Even "smart" thermostats, like the Nest, receive mixed reviews about some of their features and whether it saves energy and money.

So… could we do better than the status quo?

The Team

I was paired with Peter Hogaboam (pictured left), from Indiana University’s School of Education. During testing we took turns at recording responses and asking questions with each of the usability test subjects. As we got closer to the end Peter made the final sketches and I did layout of our documentation in InDesign.

Our Process

Personas

We made two personas—Ryan the welder and Eleanor the retiree—who informed a lot of our decisions (e.g. cramped and precise controls wouldn’t be good for Eleanor, handing all control to a machine learning solution would take agency away from Ryan). Later in the term we discovered personas should be based on research. Despite incorrectly using personas, they helped us avoid designing for ourselves.

Early Ideas

Some of the directions we considered included: sharing usage statistics for the area, suggesting temperatures, studying a users schedule, sensors to detect when people left the apartment/home, and gesture control. We decided a swipe motion was easy and didn't require much precision for Eleanor, who might have trouble with dials or cramped buttons. Making one swipe adjustthe temperature by one degree might satisfy a tinkerer's desire to adjust without making it easy to drastically change the temperature drastically.

Secondary Research

I searched on the ACM Digital Library for research papers on the Nest Thermostat to identify existing issues that we should be aware of and could possibly address. The secondary research revealed that owners had little control over what the thermostat learned and ignored. This inability to distinguish the two led to confusion and frustration regarding the self–learning mechanism. The paper suggested a “flagging” feature so that some temperature adjustments wouldn’t be logged.

Informal Peer Evaluation

As we were getting ready to go into usability tests on a design we liked, we informally ran the design by some peers and encountered a glaring issue: people mistook our heating and A/C mode buttons for incremental temperature control. User testing would have been a waste at this point, so we iterated more.

Back to sketching… 

Preparing and Testing the Paper Prototype

With some key aspects we wanted to get an opinion on—interface usability, the self–programming feature’s intuitiveness, the gear motif—we went to the university library and tested the paper prototype with two people and surveyed them about their use of thermostats.

Testing results

Testing showed that changing into different modes and changing the temperature were fairly straightforward. The gear animation that showed how hard the air conditioning would work had mixed results: it did give one subject the impression that the air conditioning was working harder, but they weren't too confident in that assessment. It was not clear what "smart mode" did, nor if it related to the "learn" toggle (which it was). 

Taking their feedback into consideration, we decided to scrap our “self–programming” feature for simplification. In its place we came up with a day–to–day programming feature. This allowed people to program a day without forcing them to program an entire week, which could be overwhelming. For atypical occasions, the thermostat could be adjusted using a manual mode that would keep the daily routine in storage, but not operate by it.

Takeaways

• Failure is something we need to become comfortable with. Even simple things, like a thermostat, are never “finished.” There’s always room for improvement, skills to be practiced, insights to glean. As beginners with roughly a week to work, we probably weren’t going to design the perfect thermostat. We should strive to address problems, but not expect to produce Jonathan Ive quality products on our first attempts. If we could, we wouldn’t be MS students. 
• Trying to identify and tackle one small problem (e.g. users' mental model, scheduling, motion detecting, cranking the settings) is often more fruitful than trying to tackle all problems at the same time.
• In general, we put a lot of thought into some decisions, but we did a poor job communicating them in our documentation. 
• We used our personas a lot…but we later learned they should be based on statistics and thorough research, not people we knew or caricatures.