IDSE201 – Final Revision of a Thermostat
Explore, Build, Test, Revise
The past 8 weeks have been a iterative exploration into the design of a thermostat, but the lessons learned along the way are much more varied than simply ‘do it again’.
By utilizing a process of exploration, user testing, and iterative development of wireframes, I was able to gain insight into how to made a useful product while projecting my own opinion of design into the world.
What follows is a listing of my lessons learned, with explanations of the process and tactics for receiving actionable feedback to drive product improvements.
Lesson 1: Explore what already exists
With any new project, having a starting point is important. Exploring the field to see what already exists can serve as a icon to aspire to, or a warning sign of what to avoid. In any product or service, tradeoffs have to be made. Seeing what was prioritized by others allow you to gain insight into their view of the world.
Lesson 2: Map it out
Making models allows you to visualize the organization and hierarchy of a system. It also allows you to project your own opinions and receive feedback before making a single screen. Above, you’ll notice the concept map of the Honeywell model, below is the original concept map of my ideal thermostat.
Lesson 3: Have an opinion
Having an opinion, well formed or otherwise, allows you to start. You can always change your mind later. In the original concept model, I projected this concept of a thermostat as networked component, an instrument in the orchestra of a comfort control system. I also specifically split the interface between a central control located in proximity to the HVAC system and a mobile control which is in constant proximity to the user.
Lesson 4: Reduce the unnecessary
This is more relevant in legacy systems which have built up extraneous features over time due to politics and scope creep, but distilling an idea down to its essence is, in my opinion, good design. In the case of this thermostat, I view it as a means of controlling the comfort of the user. Every feature should be focused on maximizing the comfort of the user or be absolutely necessary for the proper functioning of the system.
Lesson 5: Build a thing
Until your concept is externalized, it avoids reality. The faster you can produce your first iteration, the sooner you will be able to expose and explore the difference between your ideals and what the real world expects.
One of the tools for rapid ideation are wireframes. These are medium fidelity illustrations which can be generated quickly, are easily editable, and give a reasonable amount of detail such that a feature can be developed by a software engineer without further explanation.
Lesson 6: The user is not like me
Thankfully, you don’t have to be an expert software engineer to build a prototype. Paper prototypes are cheap and fast to make (albeit slightly less than ecologically sound). Using these paper prototypes, and a list of actions which you wish the user to try, it becomes quite easy to know if your idea holds up against current cultural norms and expectations.
Lesson 7: Emotional resilience is a necessary skill for a good designer
Putting your ideas out in the world can be a very challenging task. To achieve an objective view of the quality of your work, you need to test your idea with strangers. The best method I’ve seen so far is to use a list of clearly defined tasks for the user and have them think aloud while attempting to achieve the defined tasks one at a time. Think-aloud testing allows you to quickly grasp if the user is understanding your system or if they are having trouble processing certain intermediate steps toward achieving their goal. Your ability to process this feedback from the user and use it to motivate change in your design is a critical factor to the success of your product.
Lesson 8: Try it again
Making revisions based on user feedback acquired via think-aloud testing with paper prototypes, allows you to build your way toward an ideal state without needing to have everything ironed out ahead of time. You can react to situations as they develop, like suddenly changing requirements, without scrapping the entirety of your product. Overall this method is a rock-solid way of articulating your vision and accommodating the user’s desires.
So how did my final revision stack up to my ideal? Let’s use what we’ve learned from Lesson 2 to find out:
If you compare this concept model versus the original ideal, you can see that I did not deviate too far. Having a clear vision of the technologies I wished to use and my philosophy of a thermostat as a user comfort system allowed me to focus on how to improve user flows rather than to explore (and likely get lost in) much larger ambiguous thoughts like whether to use a digital or analog interface, whether the device should be networked, and whether it should do more than control the HVAC system.
In summary, the method of explore, build, test, and revise is one which I am very comfortable with due to my background as a Software QA Engineer. This method of design maps very closely to Agile software development process and the expected outputs are rather similar. Rapidly developed, incremental changes based on real-world feedback, instead of large amounts of time in ‘the cave’ tend to result in higher quality products.