Ideal Thermostat – Iteration #5: Design Details

Last week, I posted the fourth iteration of my ideal thermostat interface in which I aimed to give users a better understanding of what the system was accomplishing through visual indicators. I also made changes to my schedule mode which showed a huge improvement in user testing when it came to adding and deleting schedules but I now realized that I had designed two different interactions based on the same action of tapping a schedule—entering edit mode and selecting a schedule to delete. This is a problem because the system would not be able to determine which action the user intended to do. I decided to rework the flow so that users would tap the trash icon to enter into a delete mode, similar to the way they tap the add icon to enter add mode…

…then the user taps on the schedule the want to delete…

…and confirms that they want to delete the indicated schedule.

View the full PDF of annotated wireframes here.

Think aloud user testing of the previous iteration indicated that the difference between the auto and on setting for the fan setting was not clear. I realized that I was trying to inform users of the fact that the fan activates when heating or cooling is needed. While this is true, it is not necessary for the user to understand this technical reality. I have since eliminated the auto fan icon, so that the fan’s functionality matches the user’s mental model; turning on the fan is used to manually circulate air for a period of time.

Lastly, I realized that too many users seemed confused about which days of the week were selected in the add schedule menu so I filled in the circles of selected days.

Adding new tasks

Up until the last iteration, we have been creating the core functionality of our ideal thermostat meaning that we did not have to create flows for tasks that users would interact with infrequently. Now that we have worked through the basic functions, we have been given two new tasks to set-up the necessary technical considerations that allow the basic functions to work properly.

  1. Allow the user to connect to a wireless network or enter the date and time necessary for the scheduler to work
  2. Prevent the user from being able to turn on the A/C during the winter, which would break the system.

Keeping with the simple nature of my thermostat, I decided that a connection to a wireless network would be unnecessary since no functions require it. Instead, the first time a user enters schedule mode, they are prompted to manually enter the time and date. This allows the schedule mode to function off this information. Once the user input the date and time, the settings icon is pointed out should they need to change the time or date.

To address the users that try to turn on the air conditioning in the winter, I added a modal that will pop up to alert users that cooling could break their A/C unit.

So how did the user testing go this time?

For this round of user testing, I approached people at Mozart’s. I discovered a few things this round:

  1. Users had no problem navigating the new fan functionality. They would tap the fan and then tap to add more time until the desired amount of time was displayed. This seems to better fit user’s mental model like I suspected.
  2. Problems arose when users were prompted to delete a schedule. Every user I tested wanted to select the schedule first before tapping the delete icon. One user told me she viewed the colored schedule as in a selected state. It seems like I may be sending unintended signals to the user.

I will have to think long and hard about how to address the issues with deleting a schedule and how to indicate which schedule is active without it looking selected. However, if I can fix that, I think the next round of think aloud testing could be error-free!