Dayro Smart Home

The original plan was a single app for both setup and daily use. Then I actually mapped the onboarding.

To set up the system, the app first has to be connected to the local Wi-Fi so the radar activates and finds the switches. Then, for every single switch, someone has to go to that switchboard, toggle it to see which device responds, register that device, and name it. When we calculated it for a typical 3BHK, that came to around 1.5 to 2 hours of technical installation work. And there was no design trick to shrink it, the length comes from how the physical product works, not from the flow.

Dayro’s customer is a premium homeowner. Their first experience of the brand could not be a two-hour chore. So in a client meeting, instead of arguing the point, I walked them through the journey switch by switch, room by room. Toggle, connect, name. Toggle, connect, name. Somewhere around the third imaginary room, the alternative became obvious to everyone at the table.

Their reference design put everything on one screen: every device, sensor readings, curtains, fan dials, all rendered like a physical remote. The instinct behind it was actually right, they wanted the app to feel like holding the controls. But as a screen it was organised around how the system is structured, and nobody lives their life according to their switchboard layout. Everything competing for attention at once.

How I knew habit beats hierarchy? One of my teammates had a Google Home setup at his place, and watching how he actually used it settled the question he controlled the same few switches every single day and rarely touched the rest. It matches how anyone lives. I’m not walking into the kitchen turning appliances on every morning, I’m using my own room’s switches. But the pattern is different per person: for my mom it would be her room, the kitchen, and the living room. So the design conclusion wasn’t “show fewer devices,” it was “let each person’s app reflect their own routine.” Everything pins: your rooms, your individual switches, the scenes you want on top. My app and my mom’s app would look completely different, and both would be right.

The client liked the direction, it aligned with where his head was too. His sharpest note: the room card was too small. He was right. At that size we couldn’t showcase enough switches, and the room is the thing people came for. So in the final UI the room card grew to roughly 70 to 80% of the first viewport: room name, its live temperature, humidity and AQI, device filters, and the controls themselves, with the card swipeable sideways to move between rooms and pinned switches one scroll away. The first fold now answers the question the user actually opened the app with: what’s happening in my room, and what do I want to switch.

Dayro’s switches have a deliberate, tactile feel, and the client wanted the app to be an extension of that hardware rather than a remote control for it. The hardware itself gave us the vocabulary: the physical knob is customizable, with as many breakpoints as we choose to define, and it ships in two behaviours, a stepped one with haptic ticks at each breakpoint and a smooth one with none.

So the app’s dial mirrors the physical knob’s behaviour. A fan gets stepped control with a haptic tick at each of its levels, 0 through 6, the way the physical regulator notches between speeds. A dimmer can run smooth for a continuous glide. And because the hardware lets breakpoints be defined per device, the app exposes that: interval sensitivity is configurable, tight steps for someone who wants precision, wide or none for smooth control, with sound feedback for people who prefer audio. The app doesn’t imitate the hardware, it inherits its logic.

The client’s brief was that a smart home needs safety and child lock features. Safety Mode was straightforward: he described it, we designed it, when temperature or electrical load crosses a user-defined threshold, every switch turns off automatically except CCTV, so security stays live while a potential overload is prevented.

Child Mode is where we shaped the use case. The scenario we designed around: a child playing on the floor near the switchboard. With Child Mode on, the physical switches carry no current, so the child can’t operate anything from the wall, and every covered device responds only through the app. Which switches it covers is configurable, a refrigerator socket mounted high on the wall can be excluded because it’s already out of a child’s reach. The protection targets exactly what needs protecting, nothing more.

The breakdown surfaces the highest and lowest consuming devices immediately, with total and average monthly usage and comparable time filters. Knowing the AC averages 95 Wh/m while the bed lamp averages 16 Wh/m gives a user one specific place to focus, which is far more useful than staring at a graph of everything.