In part 1 of this article, I discussed how I defined the design problem for a particular client. This article will cover how I went about finding a solution to that problem.
My design process is essentially non-linear. I start with what I believe to be a good solution and then put it though the wringer of user testing. Invariably, it turns out I got something right and a lot of things wrong — and that’s when things begin to get interesting. After each test, I go back to work and repeat the process, again and again, until the product ultimately is adopted.
A “design hypothesis” is simply taking a stab at solving the problem. I call it a “hypothesis” because I consider all designs tentative until confirmed by actual real life users. That helps to keep my designer ego in check and it also serves as a reminder to get the users involved early.
I created the following list that incorporated the key issues (gathered from the research done in part 1 of this article) and my corresponding design hypotheses.
Sketch and think
In this early sketch, I rough out a very simple and shallow navigation system. Users start from a home page showing their entire domain — all zones — and touch a single zone to take action.
A question arose: Since we know what zone the user is currently sitting in, why not have the user always start their navigation from inside of their current zone? That would mean much fewer clicks for the most common use case. However, this “smart” contextual navigation brings along with it some other problems and creates some confusion over consistency. Therefore, I decided that as long as the navigation was extremely shallow, the user should always start from the map of all zones.
Looking at other designs
Starting the process of doodling usually triggers deeper thinking about the problem. At this point in the process, after I feel fully immersed in the problem and have had time to mull it over, I like to check out how similar problems have been solved by others in UX/design community. In this case, that included reviewing the much ballyhooed Nest, Honeywell Lyric, and ecobee3 thermostats but also some lesser known designs. I was interested in how Nest, in particular, used conversational text that told the user how much time it would take for the actual temperature to reach the set point temperature.
This created a temporal story for the user and in so doing it bridged the disjuncture, that I mentioned in part 1, between the user mental model (namely, turn it up for more intensity) and the actual system (intensity stays the same, duration is increased).
Sketch and iterate
I kicked off a round of rapid fire sketching and feedback from my test subjects. The test subjects were a combination of home thermostat users and design studio mates.
As you can see my method of choice for early sketches is pen and paper with post-its representing user feedback and my own notes.
At one point, I looked at the feasibility of direct “call to action” buttons with direct colloquial labels like: “leave home” for when the house would be vacant or “warmer” instead of users choosing a numerical value. But test users did not take to them as readily as a more tool-like approach to the interface.
Earlier iterations included allowing the user to choose an icon for each zone — reinforcing the user’s personal geography. These ultimately were not useful enough to warrant the extra clutter and complexity that they added to the interface.
In the sketch below, each zone is represented with 3 numbers — the large one representing the current temperature and the smaller ones, at bottom, with up and down icons to their right, representing the cooling point and the heating point. This, as you might imagine, was not popular with users. It meant an increased cognitive load as users deciphered which number represented which concept.
An alternative was to show the heating/cooling set points as a chart below the current temperature. Users understood this arrangement intuitively.
After testing several layouts, I determined the chart worked best when the current temperature is always centered within the zone rectangle, with the heating/cooling set points offset to the left or right as appropriate. The “you are here” icon, became a simple map-marker. It needed no explanation for most test users.
As I started showing users comps in html/css some other interesting facts came to light. Although the concept of having the user arrange the zones to replicate their home geography initially seemed like a good idea, in practice it became a distraction from the task at hand. Users had questions about the proportions of the zones. Was the “Living room” zone wider because it actually contained more square feet in real life, or because it was the only zone on the floor? Furthermore, creating a replica of the user’s actual home in the zone map add little extra value once they were able to name the zones themselves and reorder them. It also was harder to visually convey that these zones were actionable buttons when each zone was a different shape. Here is a revised version. Zones are uniform in size and have 2 pixel drop shadow to indicate that they serve as both charts and buttons.
Colors and typefaces
One of the first things I learned from the users I interviewed was that they were not “wowed” by their thermostats — nor did they necessarily want to be. They wanted a tool that responded to their needs and did not disrupt the coziness of the home. My typeface, Helvetica Neue 500 weight, was a response to this sentiment; it is clean and elegant and is perceived as neutral and non-obtrusive. The text color was set to a Black coffee #554646 — giving a slightly warmer feel to the design.
I decided that the palette should revolve around a set of complementary colors. This would create enough visual variation and “pop” without overwhelming the user. I chose Leaf #0AE19C because it felt crisp and clean and while Tomato #FF7250 felt earthy and grounded. These colors are bright and warm and, in my view, would be welcomed in the more domestic areas of a home. And perhaps more importantly, they did not feel particularly complex or technological. This corresponded with my design hypothesis that the feel should be “bright, clean, and calm”.
The neutral page background color was set to be a Cream #FAFFF3 as opposed to a stark white — again to add a cozy feeling to the design. Lastly tool icons were set to Medium gray #88888; light enough to fade into the background at a glance, but dark enough to be quickly located when needed.
Use case mock-up
Here is an html mockup of what the interface evolved into, shown as my persona, Lydia would see it as she steps through the “I’m chilly” scenario described in part 1.
Lydia has been sitting stationary at her studio desk for a few hours and is now feeling chilly. She wants to raise the temperature in her zone.
1. She opens iPad app and reviews current zone temperatures. She quickly locates her own zone based on labels and the map marker icon.
2. Lydia touches the zone label “Studio” and opens the Studio detail page.
3. Lydia presses up arrow next to the “Heating set point” field. She observes that the “Target” temperature is now 69°but the current temperature is still 68°. An alert informs her that her target temperature will be reached in 4 minutes and an animated progress icon indicates that the system is working to rectify the situation. Satisfied with this, she closes the zone detail window.
4. Now she sees the overview of all zones once again. She can monitor as the the countdown to the target temperature proceeds.
This mock-up was shown to our test users and once again it was necessary to make some modifications to the design but these course modifications were more minor than previous ones. The general idea is to solve the big usability problems as early as possible in the process.
Restraining the variety of colors provided some big advantages in this design. While Leaf represents the application itself, Tomato is a kind of thread that leads the user along a path. Hence, on the main zone page, the set point range was represented as a Tomato rectangle chart. When the user clicks in to see a detail zone page, the set point controls are place inside a Tomato “well”. In addition, the graphic display of target temperature and the messages related to it are also in Tomato. Hence color was used to visually tie together the user task.
Dotting the i’s
The design so far has satisfied our key scenarios as described in part 1.
But there still a lot of functionality issues that need to be thought out before the design can go live. For instance: How do you label a zone (kitchen, living room, etc.)? How do you add/remove/edit zones? How do you rearrange the order of the zones? How does the application display edge cases, like 20+ zones? These much less frequent, but essential tasks were drawn out in wireframes.
If a user adds more than 4 zones, we have an alternative 3 column layout, that uses the full width of the iPad. Scroll is implemented when necessary. (Homes with more than 4 zones are rare.)
Touch and hold puts zones in drag mode and allows the user to change the zone order.
Users swipe left on a zone to see an affordance to delete.
Edit icon (pencil) to the right of zone puts the zone name into edit mode. Click outside of field commits. At bottom, character count warns if you are using more than 32 characters and does not allow commit.
Here are full set of the annotated wireframes.
If time and resources permitted, I would have made a fully functional wireframe prototype. This would allow test users to click through on the iPad and we could red flag any interaction that looks awkward or feels unnatural. But this project was simple enough that we would save time by just going into production and doing further tests on the real app.
If you have comments about my process in general, or this project specifically, please send me a message. You can learn more about my practice at www.whatsbeyondnumbers.com