Business case · UX/UI · IoT
Smart home control panel
One user, one screen embedded in a wall, one deceptively specific task: open the living-room window at 7 a.m., at a set angle, for a set time. The whole design problem is scheduling something physical without the user ever being unsure what they just agreed to.
- Type
- Self-directed business case, a brief taken on during a design selection process and run with my own method
- Scope
- Wireflow and interface for a wall-mounted panel
- Surface
- Embedded touch screen, landscape
- Tools
- Paper, Sketch
Scenario
A 35-year-old has bought a single-family smart home, designed it in the manufacturer’s software, sent it to production, and now lives in it. Next to the entrance door there is a computer with a screen embedded in the wall, from which every fixture in the house can be seen and managed.
The user story: open the living-room window, a tilt-and-turn window, automatically at 7 a.m., for a limited time, at a specific opening angle, to air the room as they leave for work.
Why this is harder than it looks
Scheduling something in software is reversible. Scheduling a window is not. If the user misreads the panel, they leave a physical opening in their house all day. Every step of this flow has to be confirmable before it commits, and reviewable afterwards.
The process, and what was real
Empathise
Partly delivered- Scenario and user story supplied in the brief
- Home visits and contextual observation (proposed)
Define
Delivered- Task decomposition: device, days, time, angle, duration
- Design rule: minimum taps, maximum confirmation
Ideate
Delivered- Flow sketch across four screens plus dashboard
Prototype
Delivered- Interface for the full scheduling sequence
Test
Method proposed- First-use test with no instructions (proposed)
- Error test: does the user know what they scheduled? (proposed)
Flow
Delivered
I broke the task into the smallest set of decisions that cannot be inferred (which device, which days, what time, what angle, how long) and gave each one its own step with the running state visible above it. The last step is a recap: nothing is scheduled until the user has seen the whole thing written out.
Interface
Delivered
The panel is landscape and wall-mounted, so the layout keeps navigation on the left, context at the top and controls under the hand. Visual hints are built in for first use, because this is a screen somebody meets once, in a hallway, on their way out of the door.
The rules the interface follows
- Every scheduling operation is kept as simple as it can be made.
- The number of taps is reduced to the minimum the task allows.
- Each step is submitted back to the user, so it cannot be completed by accident.
- The whole schedule stays under the user’s control and in view.
- Visual hints are provided deliberately, for the first-use case.
Looking back
Method proposed written now, looking back: what I would keep and what I would do differently with the experience I have today
Treating irreversibility as the design constraint was right, and it is the habit I have carried into every product with physical or financial consequences since.
What I’d do differently: I designed the creation of a schedule and barely designed living with one. Editing, cancelling, conflicting schedules, what happens when it rains at 6.55 a.m., what the panel shows when the window failed to close: those are the screens a real household needs, and they are missing. Today I would also test the flow with somebody who has never seen it, standing up, in under thirty seconds, because that is the actual usage condition.