Home Passport

(1)

I studied the apps people already use

I set up real appliances in three apps and wrote down everything that got in the way. Each app failed in its own way, and none of them gave anything back before something broke.

The used-washer test, a smudged QR code and no purchase details

(2)

I counted what it takes to book one repair: 12 steps

I walked through the real flow and wrote down every screen. Twelve steps to book a single repair, and the app starts from zero the next time you come back.

The same four questions came back every single time. That is the real finding: the app has no memory of the home, so the work never gets easier.

(3)

I looked at who already makes signing up feel like nothing

None of the appliance apps had an answer, so I looked at products people register without being asked. Three of them explained why.

The principle I designed against: the value has to arrive before the breakdown, not after it. Stop asking people to fill in forms. Make it a tap, and give something back the same second.

(4)

I designed registration around one tap

Registration had to cost nothing, so I designed it around a physical NFC tag on the appliance. Your phone touches the tag, the appliance identifies itself, and the home record updates before you open a form. Tap, confirm, done, and the record belongs to the home rather than the owner, so it survives when the house is sold.

The tag itself, tap to connect

(5)

I designed the Home Passport dashboard

Once registration is free, the app has something to give back. I built the dashboard around one question: how is my home doing right now? Health first, then age, last service, and efficiency for each device. The alerts speak in money rather than error codes, your fridge coils are dusty, save $15 a month. Manuals and receipts go into a paperless drawer you can export when you sell.

The final dashboard, appliance health at a glance

The maintenance map, repairs needed by room

(6)

I audited what the current app actually does

Before rebuilding the design system I wanted to know what the current app actually does. I captured twenty screens of the live AHS app and logged every button, colour, and label in a spreadsheet, one row per element with its colour, size, and source screen. Then I checked each colour pair against WCAG, text against its background, borders against their surface, labels against the buttons they sit on.

Seven primary buttons came back below the standard. The same primary button appears at four different widths across four screens, and values were typed screen by screen instead of coming from one source, so nothing kept them consistent.

The actual spreadsheet, every colour pair scored against WCAG

(7)

I moved the brand from orange to blue

AHS is orange, and orange reads as urgency, the feeling of something breaking. A home-care app needs the opposite, so I moved the palette to blue. I made that decision before the audit, for what the colour communicates. The audit then showed the orange was failing contrast anyway. Every new colour was checked against the surface it actually sits on rather than against white.

The blue ramp, built as Figma variables

(8)

I built it as design tokens, not hex codes

A token is a named value. Instead of typing a hex code on a screen, a button asks for action.primary.bg and gets its colour from one place. I built it in three layers: base holds the raw colours, the middle layer names them by job, and components only ever ask that middle layer. Change it once and every screen follows.

The semantic layer, one alias per role

(9)

I built components with properties, not copies

Each component is one Figma component with properties rather than a page of copies. The button carries variant, size, and state as properties, with a boolean for the icon, so every combination comes from one master. Auto layout handles the padding and constraints handle the resize, which is why the same button works full width on a form and inline in a card.

I built them in code the same way. Variants are props, and the states are real CSS states rather than separate stories, hover is :hover, focus is :focus-visible, so you can tab to the ring instead of looking at a picture of one.

Category cards, chips, search states, buttons, one master each

(10)

I made the build stop when a colour fails

Figma pushes to GitHub. One file becomes CSS, Swift, and Android XML. Before anything ships, the system checks every colour pair against the accessibility standard and stops if one fails. I put the old orange back to confirm it stops, it did, naming the exact colour and the exact ratio. It also caught two colours I had approved myself, they cleared white but failed against the page background.

FAIL  3.77:1  (needs 4.5)
purp-color-action-primary-fg #ffffff
  on purp-color-action-primary-bg #f34113

Contrast gate FAILED: 1 violation(s).

(11)

I documented every component where it's used

The components run in Storybook, one page each, with every variant and state. The controls panel lets anyone switch variant, size, or state without opening the code. Storybook is embedded in Zeroheight, where the usage rules sit next to the live component, when to use it, when not to, and the accessibility notes.

The search bar in Storybook, every variant and state from one component

Foundations documented in Zeroheight

460 icons, one outline library, recolored with text alias tokens