mydlink Smart Home

One app had to hold cameras, smart plugs and sensors, and each category had arrived carrying its own logic. A plug is a state: on or off. A sensor is an event: something happened, at a time. A camera is neither — it's a live view, a recording history, a storage plan, a permission set and a motion sensitivity, all current at once and all wanting to be on screen.

Cameras were the hard case and it wasn't close. The others could be pushed into a shared shape without losing much. Cameras resisted, because everything a camera has to say is either happening right now or is evidence about something that already happened, and those two want different amounts of room.

The failure mode was already visible in the product line. The more device types shipped, the more the app became several products sharing a login: every new category brought another set of screens, and anyone who owned three kinds of device had to learn three different ways of reading whether something was working.

We looked at the three platforms people actually compare us against: Google Home, Apple Home and TP-Link Tapo. Four things came out of it — dashboard-first management that puts the important state on the opening screen; neutral greys plus a technical blue; device identity carried by iconography rather than names; and flows built for few steps and immediate feedback.

Read together, those four are one observation. The competition had stopped being about the feature list and moved to the first few seconds after opening the app — whether you can tell what's going on at home before you've tapped anything.

So each one turned into a decision rather than a mood board. Dashboard-first meant the home screen stopped being a device list. Neutral plus technical blue meant status colour became the only saturated thing on screen and everything else stepped back. Icon-led identity meant every device category had to be recognisable without reading its name. Few steps and immediate feedback meant setup had to go find the device over BLE, instead of sending the user off to find a network.

Testing was task-based with non-technical people who live with this kind of product: check a device's current state, switch something on or off quickly, then notice something abnormal and react to it. No prompting on where to tap.

What it produced was qualitative, not a completion-rate table — I'd run it differently now. But three things came back often enough to design against: people lean on colour and icon to judge state, before labels and before layout; clear device grouping visibly cuts the time spent hunting; and immediate feedback — the small animation when a state flips — makes people trust that the tap worked.

The three changes that came out of it were not new features. They made what was already on screen easier to read.

The obvious move is to draw one device card and make everything sit in it. That gets you visual consistency and not much else — the moment a camera needs to say something a plug can't, the card either grows a special case or the camera gets its own screen, and you're back where you started.

What actually carried the weight was agreeing on what states a device can be in, independently of what kind of device it is: found, connecting, named, active, unreachable. Once every product speaks that set, a new device type doesn't need a new interface — it needs to declare which state it's in, and the interface already knows how to say it.

Setup is where the same idea pays out most visibly. Traditional hardware setup asks the user to go and find the device's own network, which is exactly the step where people get stranded. Here the app searches over BLE and finds the device itself, then walks through connecting it to Wi-Fi, naming it, and switching it on as one guided sequence. The user never has to know that a network handover happened. That's not a convenience feature — it's the difference between a product that installs itself and one the buyer has to be qualified to install.

The web side had a different routing problem, one about hardware generations rather than device types. Two web systems were live at the same time — older models could only run the old one, newer models went to the new one, and the user has no idea which group they're in. They just know they own a D-Link camera. The worst possible handling is to let them guess and then fail to sign in on the wrong site.

So each portal carries a door to the other one: the new site asks «want the old version?», the old site asks «want the new one?», and the button sits in the top bar. Running two systems side by side isn't a transitional exception — for that stretch of time it is the normal state, and normal states belong in the layout, not in a notice on a help page.

The hardest person to bring round was the boss, and the subject was the palette. The ask was to line mydlink up with AQUILA — one company, one colour direction. On its face that's just brand discipline, and hard to argue with in the abstract.

So I stopped arguing in the abstract. The two products aren't sold to the same person. AQUILA is bought by someone who chose their own router; mydlink is a consumer product, bought by a household that wants a camera in the hallway and doesn't think of itself as running a network. Unifying the palette across them doesn't unify the brand — it borrows the more technical product's posture and puts it in front of the less technical audience.

That's the move worth keeping from this project, and I used it again later on a different argument: when a decision is stated as a preference, it can only be answered with a preference. Restate it as a question about who the product is for, and it becomes something two people can actually settle.

Six cloud recording plans exist. The first screen shows one.

Opening cloud recording gives you a single price — $4.99 a month — and one primary button: Try It. «See All Plans» sits underneath in secondary weight. That is a stronger recommendation than putting a «recommended» badge on one of six cards. A badge says of these six, I suggest this one, which still leaves you comparing six things. This says use this one, unless you actually want to compare — and most people don't want to.

Two more decisions sit in the same flow. Which plan and how you pay for it are separate questions, so the billing period comes after you've chosen, on its own screen, where Yearly carries the only «save more than 15%» label in the entire flow. One decision at a time, and the nudge arrives at the moment it's relevant rather than competing with five other prices.

And the plan list inside the app has no free tier at all — the web pricing page does. Someone who opened this screen in the app is already considering paying; putting the free plan in front of them there mostly hands them a reason to stop. The web page is for people still evaluating, the app is for people already using the product, and the same six plans are arranged differently in each place.

The visual system had one job: carry a lot of information without competing with it. Neutral greys hold the layout, the technical blue carries identity, and status colour stays the only saturated thing on screen — which is what makes a red dot mean something.

Status never rides on colour alone. Every state is colour plus icon plus label, which is both an accessibility requirement and the thing that stops «green» from having to mean two different things on two different device types. I ran the contrast pass against WCAG AA and reworked the swatches that didn't clear it.

The part I'm actually proud of is downstream: engineering, product and the other designers started pulling these components into their own work. A component library gets adopted when it's faster to use than to avoid, and that happened here — which makes what I didn't do next more annoying (see below).

What changed, in the terms I can actually stand behind: support questions about the app dropped noticeably — the ones that stayed were hardware problems, which is the right kind to be left with. Sales demos got smoother, because you can now show the whole home in one screen instead of narrating your way through a device list. And engineering, product and other designers started building with my components.

No before-and-after numbers. I didn't set up a way to measure it, and I'm not going to reverse-engineer percentages now to make this page look better.

The real lesson is the thing I stopped short of. I shipped a Figma library and treated that as done. I never wrote the rules down, and I never sat with engineering to agree on tokens — so the library lived exactly as long as the people who remembered how it worked. When they moved on, it came apart, and the same states started being rebuilt slightly differently in different places.

A component library is an artefact. What makes it a system is the written rule and the shared token, and those are the parts that survive a handover. That's the first thing I set up now, before drawing a single component.