Hublix

Designing a smart home app for people who did not ask for a smart home

Status: design exploration. Four interface screens exist and are published. No code repository, no deployed application, no users. This document describes design work and reasoning, and it does not describe a shipped product. Anything that reads like an outcome in what follows is a design intention, not a measured result.

One claim previously attached to this project on my site said the UX prototype had secured seed funding. I cannot name a round, an investor or an entity, so that claim is removed and it is queued for deletion at source. Asserting a financing event is the most serious kind of unverifiable claim, and it is worse than a metric because it implicates other people.

---

01 · Context

The recurring scene that started this: someone in their sixties standing in a room with a light on, holding a phone, scrolling a list that says Living Room Bulb 2, TP-Link_A47F, Smart Plug (3), and giving up. The light stays on. There is a switch on the wall that would have worked.

That is the actual state of consumer smart home software for a large share of the people who own it. Most of these systems were not chosen by everyone who has to use them. One person in the household installs them, and everyone else inherits an interface built around the installer's mental model, which is a list of devices.

Hublix was an exploration of a different starting assumption: design for the person who did not buy it. Organise the interface around what the household understands, which is rooms and things they want to happen, rather than around what the network understands, which is addressable endpoints.

The primary user in that framing is not the enthusiast. It is the fifty-plus household member who wants the kitchen lights on and has no interest whatsoever in which hub they are paired to.

02 · Problem

Device-centric information architecture leaks the network topology into the interface. A list of devices is an accurate model of the system and a poor model of a home. Nobody thinks "I will actuate the third bulb on the living room circuit". They think "make it brighter in here". Every layer of translation between those two sentences is a place a user gives up.

Naming is unfixable at the interface layer and it is where most systems fail first. Device names arrive from manufacturers as model numbers and MAC fragments. The installer is prompted to rename them and does so inconsistently, under time pressure, once. Six months later nobody remembers whether Lamp 2 is the floor lamp or the reading light. The interface is then permanently unreliable, and no amount of visual design repairs a broken naming layer.

Permissions are absent, so the household has no model of who can do what. Most consumer systems are effectively all-or-nothing: you are on the account or you are locked out. That produces two failure modes at once. Guests cannot turn on a light, which is absurd. And a child or a visitor can potentially unlock a door, which is worse than absurd.

Feedback is ambiguous in a way that destroys trust quickly. You tap. Something happens in the cloud, then over a local radio, then at a device, then a state report travels back. Somewhere in that chain the interface has to decide what to tell you. Most systems either lie optimistically or freeze. Both teach the user that the app cannot be believed, and once that lesson is learned they go back to the wall switch.

Onboarding is where most households stop. Pairing is the hardest technical moment in the product and it happens before the user has any reason to persist. Anyone who has set up consumer IoT knows the loop: hold the button until it blinks, join a temporary network, wait, fail, factory reset, try again.

03 · Why the problem mattered

Because a smart home that only one household member can operate has failed at being a home product. It is a hobby installation. The value of automating a shared space is only realised if the space stays usable for everyone in it, and the fallback for everyone else is the wall switch, which means the software is decorative.

Because the accessibility gap here is demographic and predictable. Presbyopia and reduced contrast sensitivity are ordinary features of ageing eyes, and reduced fine motor precision is ordinary too. A product whose users skew older is a product with known, well-documented interface requirements: larger targets, higher contrast, larger type, forgiving hit areas. The WCAG guidance on contrast and target size is not an accommodation in this category, it is the specification.

Because trust in a physical-consequence product is structurally different from trust in software. If a note-taking app shows stale state you are mildly annoyed. If a smart lock shows stale state you do not know whether your front door is locked. The stakes of an ambiguous status indicator scale with the physicality of what it controls, and locks, thermostats and appliances sit at the top of that scale.

Because the switching cost is zero in the wrong direction. Every smart device has a manual fallback. The competitor is not another app, it is the wall. That is an unusually harsh competitive position: the alternative is free, instant, universally understood and already installed.

04 · Research

Method: usability observation with household members aged fifty and over, plus a competitive benchmark against Google Home and Tuya. That is what happened and I want to state its limits clearly.

What that means concretely. Watching people attempt real tasks in existing smart home apps and recording where they stopped. Not a moderated protocol with a script and a recruited panel. Not a sample size I am going to quote, because I do not have a participant log, and a number without a log is decoration. The observation was real and it was informal.

Why the competitive benchmark was useful. Google Home and Tuya sit at two ends of the consumer market. Google Home is the polished first-party experience with strong voice integration and an opinionated model. Tuya is the white-label platform behind an enormous number of unbranded devices, which means it is the interface a large share of budget smart home owners actually encounter. Comparing them isolates which problems are execution failures and which are category properties. Naming and pairing are category properties: both fail at them, in the same places, for the same structural reasons.

What I did not do. No quantified before-and-after usability testing. No longitudinal study. No accessibility audit with assistive technology. The two figures previously attached to this project, an onboarding time cut from fifteen minutes to under three, and twenty households beta-testing the design, have no study document behind them and are excluded from this case study.

What the observation did produce, and it is worth more than a number. A consistent map of where people stop. They stop at the device list, at ambiguous names, at the absence of feedback after a tap, and at pairing. Four failure points, observed repeatedly, in every app examined.

05 · Insights

People navigate homes spatially and functionally, never by device. "Upstairs", "the kitchen", "when we go to bed". These are the two axes that exist in a household's actual language: where, and what for. A device list matches neither.

The most valuable interface element is the one that answers "is anything on that should not be". Observed repeatedly: people open a smart home app not to control something but to check something. Did I leave the lights on. Is the door locked. That is a status query, and it is arguably the primary use case, which means a home screen optimised for control is optimised for the second most common task.

Everyone in a household needs a different amount of the product. The installer wants configuration. The other adults want control. Guests want the lights. A child should have almost nothing. A single permission level cannot serve four intents, and the absence of levels is why households end up sharing one account and one password.

Automation is trusted only when it is inspectable and reversible. A routine that fires unexpectedly is alarming rather than delightful. People accepted automation readily when they could see what it would do, see that it had happened, and undo it. The requirement is not fewer automations, it is legible ones.

The wall switch is the benchmark for every interaction. Instant, unambiguous, zero learning. Any interaction slower or less certain than the switch will lose to it. That comparison sets the design budget for everything else in the product.

06 · Product thinking

The core reframe: this is not a control product, it is a state-of-the-home product. Control follows from state. Once the primary job is understood as answering "what is happening in my home right now", the home screen stops being a grid of toggles and becomes a summary with controls attached to it. That single reframe drives most of the design decisions in section 09.

Scope discipline: no device management on the primary surface. Pairing, network settings, firmware, hub configuration are installer tasks performed rarely by one person. They belong in a separate area, reached deliberately. Putting them on the main screen means every household member navigates around functionality that is irrelevant to them, permanently, to serve a task that happens once.

Rooms over devices, routines over automations. "Rooms" is spatial and matches how people describe their homes. "Routines" is intentional and matches how people describe what they want. "Automations" is a word about the system; "routines" is a word about the day, and the vocabulary choice is a product decision rather than a copy decision.

Three permission tiers, chosen because four is too many and two is not enough. Admin configures. Member controls. Guest gets a deliberately narrow slice. Consumer software that offers granular per-device permission matrices produces a configuration burden nobody completes, and the result is that everyone is an admin. Three coarse tiers that people actually set beat twenty fine ones they never touch.

What this product should not attempt. Energy analytics, security monitoring, voice assistant replacement. Each is a separate product with separate expectations. A smart home app that tries to be a dashboard is a smart home app whose lights are three taps deep.

07 · Strategy

Design for the least willing user in the household. Not the buyer, not the enthusiast. If the fifty-plus household member can operate it confidently, everyone can. This is the whole strategy and everything else is downstream of it.

Compete against the wall switch, not against Google Home. The design target for a control action is the certainty and immediacy of a physical switch. Feature comparison with other apps is the wrong axis, because a household that finds the app slow does not switch apps, it stops using the app.

Solve naming at onboarding, because it cannot be solved later. Guided, room-first naming during setup, with plain-language suggestions. This is the highest-leverage moment in the entire product, and every consumer system I examined wastes it.

Make status the front door. The home screen answers the status question first and offers control second.

What the strategy did not include, and should have: a distribution answer. A smart home interface has to reach devices, which means either a hardware partnership, an existing platform integration, or a bring-your-own-devices story built on an interoperability standard. None of these was resolved, which is a substantial part of why Hublix remained a design exploration rather than becoming a product.

08 · Information architecture

Home                        state summary first, controls second
  Rooms
    Kitchen                 devices grouped spatially
    Living Room
    Bedroom
  Routines
    Morning                 named by intent
    Away
    Night
  Household                 people and permissions
    Admin   Member   Guest
  Settings                  installer surface, deliberately separate
    Devices  Hubs  Network  Firmware

Three deliberate structural decisions.

Devices do not appear at the top level. They exist inside rooms, because that is where they exist in the world. The only place a flat device list is correct is the installer surface, where the user genuinely is thinking about endpoints.

Routines are peers of rooms, not a setting. If automation is buried in configuration, it is used by the installer and nobody else. Promoting it to a top-level destination is what makes it a household feature instead of a power-user one.

Household is a first-class section. People and permissions are not settings. They are part of what the home is. Making the roster visible also makes the permission model visible, which is what allows a household to reason about it at all.

The one hard problem this architecture does not solve: devices that belong to no room and rooms that overlap. A hallway sensor, a whole-home thermostat, an outdoor camera. Every spatial architecture eventually needs an escape hatch, and designing that escape hatch badly is how spatial models degrade back into lists.

09 · UX and design

Four Hublix interface screens are published. This is the section the exploration was really about.

Hierarchy. State, then room, then device. The home screen leads with what is happening: anything on, anything unlocked, anything unusual. Rooms come next as the primary navigation. Individual device controls sit one level in. This inverts the conventional smart home app, which leads with a device grid, and the inversion follows directly from the insight that people mostly open these apps to check rather than to act.

Mapping, which is the oldest problem in this category. Norman's canonical example of poor mapping in The Design of Everyday Things is a bank of light switches that bears no relation to the lights it controls. Smart home software has faithfully reproduced that failure in a new medium. Spatial grouping is the fix: the relationship between a control and the thing it controls has to be inferable from where it sits, not from what it is called.

Touch targets and type, specified rather than eyeballed. WCAG 2.5.5 sets a 44 by 44 CSS pixel minimum for target size, and for a primary user with reduced motor precision the design floor should be higher than the accessibility floor, not equal to it. Contrast at or above the WCAG 1.4.3 ratio of 4.5 to 1 for body text, with larger type than a general-audience app would use. These are not accommodations bolted on at the end; in a product for this audience they are the baseline dimensions everything else is composed around.

Feedback, and the specific choice that matters most. Tap produces an immediate visual state change, because Nielsen's 0.1 second threshold is where an interaction stops feeling like a request and starts feeling like direct manipulation, and no cloud round trip meets it. So the interface commits optimistically. The essential part is the second half of that decision: if confirmation does not arrive, the state must visibly revert and say so. Optimistic feedback without rollback is a lie, and one lie about a lock is enough to lose the household permanently. This pattern is the single most important interaction decision in a physical-consequence product.

Three states, not two. Off, on, and unknown. Consumer smart home apps overwhelmingly show two, which forces them to guess when a device is unreachable, and guessing wrong about a lock is the worst failure the product can produce. An explicit unknown state is less tidy and much more trustworthy.

Progressive disclosure, applied selectively. Correct here, unlike in a professional tool: a lamp shows on and off, with colour temperature and scheduling one level deeper. The common case is one tap. The rare case is available. The failure mode to avoid is hiding the common case to make the screen look calm.

Guest Mode as a designed experience rather than a restriction. A guest gets lights and the temperature in the room they are in. Not a locked-down version of the full app, which reads as distrust, but a small complete interface that does not mention what is missing.

Empty and error states, which is where this category is weakest. No devices yet should teach rather than apologise. A device offline should say which device, since when, and what to try, because "connection error" is the least useful string in consumer IoT. Pairing failure needs a real recovery path, since it is the most common failure in the product and the one that happens when the user's patience is lowest.

Visual system. Restrained, high contrast, generous spacing, minimal chrome. Colour reserved for state, and specifically for the difference between on, off and unknown. Iconography plus text labels rather than icons alone, because icon-only interfaces assume a shared visual vocabulary that this audience has no reason to have.

Tradeoffs I would defend. Spatial organisation costs power users speed, since an enthusiast with forty devices wants search and I would give them search rather than reorganising for them. Three permission tiers cost granularity, and I think the completion rate is worth more. Optimistic feedback risks a visible correction, which is the right risk to take as long as the correction is honest.

10 · Technology

I did not build this. No repository, no deployment, no implementation. This section describes the platform constraints the design had to respect, and every one of them is a property of consumer smart home systems, not a claim about a Hublix system.

Interoperability is the whole strategic problem. A device-agnostic smart home interface either integrates per-vendor, which does not scale, or builds on a common standard. Matter, developed under the Connectivity Standards Alliance, exists to make that second option viable, running over IP and typically over Thread for low-power devices or Wi-Fi for the rest. Any serious version of this product is a Matter product, and that decision determines what it can control before any interface work matters.

Local control is a design requirement disguised as an infrastructure choice. A cloud round trip cannot meet the immediacy budget set in section 09, and it means the lights stop working when the internet does, which is the failure that ends a household's trust in the entire installation. Local-first control with cloud used for remote access and coordination is the only architecture consistent with the design intent here. This is exactly the kind of case where a design constraint should drive the architecture rather than accommodate it.

The state model is the hard engineering problem. Devices report asynchronously, unreliably, and sometimes not at all. The interface needs a state store that distinguishes confirmed, pending and stale, with per-device timeouts, and that distinction is what makes the three-state display in section 09 possible. An interface cannot honestly show "unknown" unless the layer beneath it tracks confidence.

Pairing is a protocol-level problem that design can only partly mitigate. Matter's commissioning flow with QR codes and numeric setup codes is a genuine improvement over the previous generation of vendor-specific pairing. Design can make the flow forgiving and the errors legible. It cannot make radio commissioning reliable.

Privacy, which deserves more weight than it usually gets. Occupancy, sleep and absence patterns are inferable from smart home telemetry, and that is sensitive data about a household by any reasonable standard. A local-first architecture is a privacy posture as much as a latency decision, and a product for a cautious audience should be able to state plainly what leaves the house.

11 · Marketing and GTM

No go-to-market work was done. There was no launch, no positioning exercise, no channel plan, and no distribution answer, which section 07 names as a gap rather than an omission.

The one commercially relevant observation from the exploration: the underserved segment is visible and specific. Households where one person installed the system and everyone else avoids it. That is a real positioning wedge, and "the smart home app the rest of your household will actually use" is a proposition that names a problem people recognise. It was never tested.

Removed from this section. A claim that this design work secured seed funding. No round, no investor, no entity. It is not repeated here and it should be deleted from the live site.

12 · Execution

What exists:

• Four published interface screens covering the smart home interface concept
• An information architecture organised around rooms, routines and household roles
• A three-tier permission model with a designed Guest Mode
• Usability observation with household members aged fifty and over, informal and unquantified
• A competitive benchmark against Google Home and Tuya

What does not exist:

• Any code
• Any deployment
• Any users
• Any usability testing with measured outcomes
• A hardware or platform partnership

13 · Results

No outcome metrics exist for this project. Nothing was built, so nothing was measured. What exists is the artifact listed in section 12.

Removed and recorded so the omission is traceable:

Previously claimed	Why it is not here
Onboarding time cut from 15 minutes to under 3	No study, no protocol, no timing data, and nothing was implemented to time.
20 households beta-tested the design	No participant log or recruitment record. Informal observation happened; a household count is not evidenced.
Secured seed funding on the strength of the UX prototype	No round, investor or entity can be named. Queued for deletion at source.

What the design work does demonstrate, without any of that: an information architecture that follows from an observed failure pattern, a permission model designed for a real household rather than an account holder, and a specific position on the optimistic-feedback problem that has consequences for anything controlling physical hardware. Four screens and a coherent argument. That is a legitimate design exploration and it is stronger described accurately than inflated into a product.

14 · What went wrong

I designed an interface for a platform problem. The reason smart home apps are bad is only partly interface design. It is mostly interoperability, naming, unreliable radios and vendor fragmentation. A better information architecture on top of an unsolved integration problem is a mockup, and I spent my effort where I was most comfortable rather than where the problem was hardest.

I never resolved how it would control anything. No Matter integration plan, no vendor partnership, no bring-your-own-device story. That gap is the difference between a design exploration and a product, and it was knowable on day one.

I did not build even the smallest working version. A single device, controlled locally, with the three-state feedback model and the rollback behaviour from section 09, would have tested the one genuinely novel design claim in the whole project. That is a weekend of work. Not doing it means the most interesting idea here is untested.

I published outcome numbers for design work that was never implemented. An onboarding time reduction for software that does not exist cannot be true. This is the worst item in this document, and it is worse than an inflated metric because there was no system that could have produced it. It was invented to fill a section.

I claimed a funding event. Restating this on purpose, because it is the most serious claim in my portfolio, and unlike an internal metric it implicates other parties.

The research was real and I recorded none of it properly. Observation happened. No notes structured well enough to cite, no participant record, no task list, no timings. The insights in section 05 are trustworthy as pattern recognition and unusable as evidence, and that is entirely a documentation failure. Twenty minutes of note-taking per session would have made section 04 a genuine asset.

15 · What I learned

Design for the least willing user and the willing ones are served automatically. This generalises well beyond smart homes. In any shared product, the constraint is set by whoever has the least motivation to learn it.

Accessibility requirements for an older audience are specifications, not accommodations. Target size, contrast and type scale are input parameters to the design, and treating them as a late compliance pass produces a product that technically passes and still fails the person it was for.

Optimistic feedback obligates you to honest rollback. You cannot take the responsiveness benefit without accepting the duty to visibly correct. This is the most transferable interaction lesson I took from the project and it applies to anything with a network between the tap and the effect.

"Unknown" is a state and hiding it is a lie. Two-state displays force the system to guess, and in a product controlling locks and appliances, a confident wrong answer is worse than an admitted uncertainty.

Vocabulary is product design. "Routines" and "automations" describe the same mechanism and invite different relationships to it. The words on the tab are part of the information architecture.

A design exploration that admits it is one is more useful than a fake product. The four screens and the reasoning stand up. The invented metrics were doing no work except damage.

16 · What I would do differently

Build the thinnest possible working version before drawing a fifth screen. One Matter device, local control, three states, optimistic update with visible rollback. It tests the only claim in this project that could be wrong in an interesting way.

Solve the distribution question first. Which devices, via which standard, reached how. Without an answer this is a portfolio piece and it should be labelled as one from the start, which is what this document now does.

Instrument the research even when it is informal. A task list, a sheet per session, timings where they matter. Informal research with records is citable. Informal research without records is intuition, and intuition cannot be handed to anyone else.

Test the naming flow specifically, because it is the highest-leverage screen in the product. Guided room-first naming during setup determines whether the interface is comprehensible for the following five years. It deserved more design attention than the home screen got.

Design the escape hatch for things that live in no room. The hallway sensor and the whole-home thermostat are where spatial models break, and I left that unresolved.

Delete the funding claim and the invented metrics from the live site, and describe this as what it is. A design exploration, honestly labelled, that argues something specific about feedback in physical-consequence products.

17 · Current status

Design exploration. Not built. Four screens published.

Item	Status
Interface screens	4, published
Information architecture	Designed: rooms, routines, household
Permission model	Designed: Admin, Member, Guest
Code	None
Deployment	None
Users	None
Usability testing with measured outcomes	None
Device integration path	Unresolved
Outcome metrics	None. Three previously published claims removed, including a funding claim.

---

Related reading in this archive

• Cognitive load is the real SaaS design problem: progressive disclosure, and when hiding things is wrong
• Designing under uncertainty: designing before the platform question is answered
• Designing for latency and trust in real-time products: the optimistic-update-and-rollback pattern in general
• Designing trust in AI interfaces: the same three-state honesty problem, in a different domain

Sources

1. Hublix interface design screens, 4 published. https://devchopra.life/gallery
2. devchopra.life /projects/smart-home: research approach, interface strategy, permission model. Also the source of the three excluded claims. https://devchopra.life/projects/smart-home
3. Don Norman, The Design of Everyday Things, revised edition, Basic Books, 2013: mapping, affordances, and the gulf of evaluation.
4. Jakob Nielsen, "Response Times: The 3 Important Limits", Nielsen Norman Group, 1993. https://www.nngroup.com/articles/response-times-3-important-limits/
5. W3C, Web Content Accessibility Guidelines 2.2, Success Criterion 1.4.3 Contrast (Minimum). https://www.w3.org/TR/WCAG22/#contrast-minimum
6. W3C, Web Content Accessibility Guidelines 2.2, Success Criterion 2.5.5 Target Size (Enhanced). https://www.w3.org/TR/WCAG22/#target-size-enhanced
7. Connectivity Standards Alliance, Matter specification and commissioning model. https://csa-iot.org/all-solutions/matter/
8. Thread Group, Thread network specification for low-power IP mesh. https://www.threadgroup.org/
9. Google Home and Tuya consumer applications, reviewed as competitive benchmarks.