The course brief asked us to redesign the Google Nest Thermostat for people who care about energy use and cost. For an affordable product, we built on Nest’s affordable model. Its display sits behind a mirror, and it has one input: a touch strip on the side that takes a swipe and a tap.

The team divided the work by surface. I took the device, and the team designed the app. On the phone, a schedule is one screen with sliders and buttons. On the wall, the same task had to fit a mirror and two gestures.

The first decision was which parts of the product belonged on the wall. I treated the thermostat as a subset of the product. It kept what people do while standing in front of it: set the temperature, change the mode, and edit a schedule. The phone does everything the device does, with more room: a week of schedules at a glance, plus and minus buttons on the home screen, and every room.

Energy history stayed on the phone. On a small display reached only by swipe and tap, it would have added depth to every path, and the phone shows it far more clearly.

I gave the two gestures one meaning each, everywhere on the device. A swipe moves through whatever is on screen: menu items, days, schedule blocks, or a value. A tap commits to what is selected and goes one level deeper.

From that rule, the device became a stack of short lists. The home screen shows the set temperature. A tap opens the main menu: Mode, Hold, Fan, Schedule, and Settings. Schedule opens the days of the week, a day opens its schedule blocks, and a block opens its settings. A new block is added from the same list as the existing ones.

The device has no back button, so Back is an item in every list. Leaving a level works the same way as entering one: swipe to it and tap. In the first rounds, Back and the add and delete actions sat outside the list as icons. In the final design, every action is a card in the same carousel, reached with the same swipe.

On the phone, a schedule block is set with two range sliders, one for time and one for temperature, and both ends of each range move on the same screen. The touch strip moves one value at a time, which made sequential editing the natural model. It was the structure of the device from the first wireframe.

I structured schedule editing in the order people define a range: start time, end time, low temperature, then high temperature. The temperature order follows Auto mode, where the system heats to the low value and cools to the high one. Each screen asks for one decision and names it in a label above the number, such as STARTS AT or SET FROM. When the last value is set, the device confirms the schedule and returns to the day’s blocks.

The strip has no labels of its own, so the screen has to say what a swipe or a tap will do. In the wireframes, I drew the strip beside every screen and marked the part a user would touch: how many steps to swipe up or down, and when to tap OK.

Working that way produced the signals on the screen. A list that continues shows arrows for scrolling up and down. The item a tap will commit is outlined. On the editing screens, a small indicator beside the value stays open while the value can still change and fills once it is committed.

On the mirror, the interface sits over whatever the room reflects: a window, a plant, a lamp. The app and the device do not share the same green. I used a brighter #3DFF00 on the device to keep the selected item legible against the changing reflections. Text stays white, menu labels are uppercase, and large numerals establish the primary information at a glance.

I built the design system as Figma variables in two layers. Primitive ramps hold every color: green, gray, blue, red, and yellow. Component tokens sit on top and name what a color is for, such as the primary button, the selected tab, or secondary text. Each component token has a Light and a Dark value, so the same components work on a light app screen and a dark one.

Type follows the same logic. Product Sans runs in six sizes and four weights, from the 128 pixel numerals on the device to 12 pixel labels in the app.

Four modes carry their own color across both surfaces. Eco is green, Auto is yellow, Cool is blue, and Heat is red. The color is on the dial, the schedule card, the mode button, and the device screen, so the current mode can be read before any text.

The device green is the one color I split from the app on purpose. When legibility on the mirror and consistency with the app pulled apart, legibility won, and the device got its own token.

I planned the test: one task on both surfaces, adding a schedule by setting a temperature range. Our wireframes had no interaction yet, so I proposed a paper prototype. Participants arranged printed screens in the order they expected to use them. Five participants tested both the device and the app, with each team member moderating one participant.

Everyone finished the task. The difference was how often they got lost: on 2.2 screens on average on the device, and 1.2 in the app. Most of the device confusion clustered around editing. Participants struggled with different parts of the feedback: whether the indicator would move, how values were changing, which direction to press, and what each step meant.

The wireframe indicator already separated an open value from a committed one. What it could not show was movement. I rebuilt it as an arc that communicates both direction and state. While a value is being adjusted, segmented ticks show the direction of change, up or down with the swipe. For temperature, the green deepens subtly as the value increases. A tap commits the value and turns the arc solid, so adjusting and confirming each have their own visual feedback. The number stays the primary signal. The arc’s direction, state, and color support it.

After testing and design feedback, I also renamed the steps. STARTING TIME and LOWEST TEMP became STARTS AT and SET FROM, so each label reads as part of one sentence about the schedule.

In the app, the team clarified where to add and finish a schedule, removed a confusing add option from the mode menu, and enlarged the text in schedule blocks.

A paper prototype could not simulate a touch strip or a mirror. Arranging printed screens showed where people got lost in the structure. It could not show how the gesture felt. I would test the device again on a phone mockup with a working swipe area, held against a real reflection.

The app components have Light and Dark modes. The device colors sit outside the primitive ramps, as fixed values. Its green is brighter than any step in the green ramp. That was a deliberate choice for the mirror, but leaving it outside the system meant it could drift. I would add a device mode to the same collection, so every surface draws from one source.

Going back to the test data, I found an error in how we had scored our custom questionnaire. Negative statements had not been reverse scored. I corrected the analysis, but chose not to publish the resulting score here. With five responses per surface and a questionnaire we created ourselves, the number suggested more certainty than the method supported.