HomeBase - Smart Home App
HomeBase is a concept smart home app for Android tablet and mobile, built on Material Design 3 and the Matter standard. It is designed around two people in the same home who want opposite things: Anna, who opens the app many times a day for a few seconds, and Marek, who opens it a few times a day to set things up and fix them. The challenge was to give Anna instant control without hiding the depth Marek needs. I designed ten screens plus edge-case states, each in tablet and mobile, light and dark, and linked them into a clickable prototype in Figma. The design tokens are built into code in a public repository, and an expert-review audit of the components has already led to one fix.
Fast or powerful, rarely both
Reviews and UX write-ups on Google Home, SmartThings and vendor apps keep repeating the same complaints: a slow reconnect every time you open the app, unclear errors when adding a Matter device, no control at all when Wi-Fi drops, and automations that fire with no explanation of why.
Honest about the research
This is desk research: app store reviews, published UX studies and a comparison of four platforms. I did not interview users or run usability tests. The personas are assumptions built from that research, and the case study treats them that way.
Anna, the daily user
Checks the app all day in short glances. She needs an instant “all clear” and one-tap scenes.
Marek, the configurator
Manages 28 devices and 9 rules. He needs to see why something happened and what depends on what.
Six principles before any pixel
Written before wireframing, so layout choices could be checked against them instead of decided on taste:
Status at a glance, details on demand
Colour means one thing everywhere
Adapt density, not identity
Show direction, not just value
Accessible, and checked against WCAG 2.2
Earn every notification
Anna’s morning: has to be instant
Open the app from bed and see the home state at once. Trigger the Morning scene without digging through a list. Nudge the kitchen temperature from the room card. Answer the door when it rings. Each step became a rule for the dashboard: status first, scenes always visible, temperature on the card, door call as a takeover.
Marek adds a smart plug
Scan the code, commission through Google Home, assign a room and name, add it to a scene. Reviews describe this as a multi-app struggle with unclear errors. It became the three-step Add device flow, with the optional scene step kept inside setup so he does not have to leave and edit the scene separately.
One design, two densities
A Standard / Advanced switch changes the density of the same dashboard. Advanced adds a health strip, protocol and activity chips per room, and recent automation activity. One design system, no parallel set of screens.
Status you can read without colour
Status is designed to use colour, shape and text together. Colour blindness, glare on a wall tablet and quick glances all make colour alone unreliable, and a wrong reading of “door locked” has a real cost. An audit of the room card found where this still falls short: the “on” state of some device chips is carried by green alone, and the status icons are below 3:1 contrast on their tint. Both are logged under Audit, fix, verify.
Facts stay neutral
The actual room temperature is always neutral text. It is a fact, not a judgement. The target, the dial arc and the subtitle carry the meaning.
Door communication is always dark
A deliberate exception to the theme switch, like a video call screen. Doorway light, night use and unpredictable camera images make a light theme a poor fit.
Offline still says what works
When the internet drops, the offline screen shows which devices still respond (wired) and which do not (Wi-Fi), instead of a blank error.
Adding a device is three steps
Scan, Connect, Setup. If pairing fails, the screen names the likely reason and offers Try again. Pairing goes through Google Home commissioning, so there is no second app to open.
Activity explains why
A log of what happened and what triggered it: Anna, a rule or a schedule. This answers the “why did that happen?” complaint directly.
Rethink, do not shrink
The room grid becomes a single column. The Quick Scenes row becomes a horizontal scroll so each card stays large enough to tap. Status chips wrap onto extra lines on most mobile cards instead of shrinking. 12 of the 144 room cards in the file still overflow, which is logged as an open audit finding. The same five tabs stay in the same order on both, so the app feels like one product.
Extend Material 3, do not fork it
I copied the Material 3 kit into the file and added a small second token layer for smart-home meaning: status, status text, energy and gradient colours (16 variables on top of the 427 from Material 3, shape, type and font). Custom HB/ components such as the room card, scene card and temperature dial are built on those tokens, so they stay native to Android.
Light and dark from variables
Dark mode comes from switching variable modes, not from redrawing screens. Energy cost is shown in PLN, not kWh, because people think in their bill.
Tokens in code
The variables are exported from Figma to JSON, converted to W3C design tokens and built with Style Dictionary into CSS variables (light, dark, base and an alternative font theme), Android colour resources and JSON. A contrast check runs on 16 text and background pairs, in light and dark mode, on every pull request in GitHub Actions. Changes to tokens go in by pull request and are then pushed back into Figma.
Repository: github.com/marcinpociask/homebase-tokens
What the audit found
I reviewed the room card component with a heuristic and WCAG 2.2 AA checklist: 13 findings, 4 major, 5 minor and 4 cosmetic. The most serious was a contrast failure. The label text on the status chips used the status colour on its own tinted background, which is below the 4.5:1 requirement.
The fix
I added darker Status Text tokens. Each light value keeps its hue; in dark mode they point at the original status colours, which already passed. The change went in as a pull request to the tokens repository, where the contrast check had been flagging the four failing pairs as known issues until they were fixed. I then pushed the new variables into the Figma file and rebound the chip labels in all 16 variants. The 666 chip instances in the file follow the component, and none overrides it.
The result
Chip label contrast, light mode
Before
After
Operational
2.98 : 1
4.72 : 1
Warning
1.97 : 1
4.66 : 1
Critical
3.41 : 1
4.70 : 1
Neutral
3.02 : 1
4.69 : 1
The requirement is 4.5:1. In dark mode every pair is 5.2:1 or better.
Product Designer (concept project)
Research, personas, information architecture, design system, all screens, edge cases and the prototype. After the first pass: an expert-review audit of the room card, the token fix, and the tokens built into code.
Figma
Variables, component sets, prototype flows with light/dark, tablet/mobile and Standard/Advanced switches.
Material Theme Builder
Colour scheme from the seed colour #1B6B5A.
Token Pusher (custom plugin, personal project)
Moves Figma variables to and from JSON through the Figma API; used to push the new status text tokens back into the file.
Style Dictionary
Builds the variables into CSS custom properties, Android colour resources and JSON.
GitHub and GitHub Actions
Pull requests for token changes, with a build and a contrast check on every pull request.
ucd-toolkit (my own)
Open-source Claude skills for the UX process; ucd-audit ran the audit.
Claude Code
Connected to Figma over MCP (Model Context Protocol, using Figma Console MCP), so it could read and edit the file's variables, components and prototype links from a running session, not just generate text or images. I used it for documentation, repetitive component work (dark-mode variants, rewiring prototype links, spacing audits), the token pipeline and the audit. The decisions on this page, and every trade-off they involved, are mine.
Not tested with users
The prototype has not been through usability testing. A test plan is ready and has not been run: five participants and four tasks, each with a success criterion set before testing. For example, four of five people should activate the Morning scene unaided, in two taps and under ten seconds; four of five should complete adding a device and name the right next step when pairing fails; four of five should answer a doorbell within five seconds; and four of five should find out why a light came on within thirty seconds. Results will be added here.
Open audit findings
Besides the three major findings above, the room card still has two minor accessibility gaps and several naming and consistency items. They are logged in the audit.
Known gaps
No scene or automation editor, no notification list and no settings screen. Rule conflict detection in the automation builder is the part I would explore next.
