After eight weeks of Rapid Ideation and Creative Problem Solving, the sixth and final iteration of my ideal thermostat is complete. Last week, we were given the additional requirements of two extra tasks for our fifth iteration and I came incredibly close to an error free round of user testing. The only problem arose when users were prompted to delete a schedule. Every user I tested wanted to select the schedule first before tapping the delete icon.
After sketching out a few iterations of the delete schedule flow, I realized that a great interface is often flexible in that there is more than one way for users to complete a certain task. If some users want to tap on the schedule to select it before deleting, maybe I should incorporate delete into the edit mode. This solution seems so obvious to me now that I can’t believe I hadn’t realized it before. I was trying so hard to stick with the button conventions I created that I had forgotten to consider what would make sense to the user.
Re-listening to the audio recordings of my think-aloud user testing participants from last round, I heard one user ask, “what does the arrow on the schedule mean?”. While I was unable to answer her question while she tried to complete the tasks, it was a great question. The arrow was a remnant of functionality from an earlier iteration where users could skip ahead in the schedule. It no longer has any use as a stationary selection indicator, but I chose to keep it as a second indicator of the active schedule. This seemingly minor design detail had a large impact on the way the user viewed the capabilities of the system. I easily corrected this mistake by getting rid of the arrows.
Thinking about it now, I think this oversight highlights a flaw in my approach iteratively designing redesigning this thermostat. As designers, we have to realize that every design decision can portray unintended functionality if we don’t consider conventions already in place. In this case, the arrow still represented a stationary selection indicator that users.
So how did the user testing go this time?
Unfortunately, I did not have an error-free round of user testing, but I did learn a few more things that has altered the way I view my thermostat framework:
- Users appreciated that they could delete a schedule two different ways. Many initially deleted the schedule through the new editing mode delete option but noticed that there seemed to be another way to delete as indicated by the trash icon on the main schedule mode screen. Two users even asked to attempt the task again so they could experience this alternative flow.
- In this round of testing, two users interpreted the task “turn the fan on for two hours” as needing to enter schedule mode since the fan is on for a certain amount of time. Honestly, I think they had a good point. If every other function on manual mode stays activated until turned off, why wouldn’t the fan on manual mode work the same way? Timed usage of the fan would fit the users mental model better if it were included in schedule mode instead.
In this final blog post I would like to consider the evolution of my ideal thermostat by comparing the final design to the ideal thermostat concept model I created before I had even started designing the interface:
Just a few weeks ago, the vision I had for my ideal thermostat was simply a reduction of unnecessary features included in the Honeywell thermostat’s current concept and the addition of smart scheduling capabilities and an energy efficiency indicator. Let’s compare that first iteration of the concept map against one of the final design:
Clearly my understanding of the necessary components of an ideal thermostat has changed immensely over this iterative process. When I started this process, I was worried that I didn’t know enough about the way a thermostat worked and it prevented me from confidently designing an ideal thermostat concept map that was more than just a simplification of the Honeywell design.
This class has forced me to realize that certain rules such as universally conventions (green for okay/yes button) should be followed, but other “standard practices” should not constrict us. I can now think more critically about what I want in a design and not worry about whether it already exists or if other people would like it, because I have the skill set to test it and iterate on it. I have also realized that a poor user-testing round should not be looked at as a failure but as an opportunity pinpoint what worked and what needs more sketching to solve.No Comments »