01The quiet problem nobody owned

Most conversations about smart glasses are about the camera, the assistant and the battery. What decides whether people keep wearing them is quieter: what the device does when two things want it at the same time.

B has one open-ear speaker, one camera and a touch strip. People reach it by voice, by the glass button and taps, and through the companion app. A dozen functions compete for those few resources, and they compete all day. A notification lands mid-song. Someone says "take a photo" while the assistant is still answering. An update is ready while a video is recording. A call comes in during an import.

Each feature team was answering these moments inside its own feature. Every answer was reasonable on its own. Together, they would have produced a device that behaved differently depending on which team happened to write the rule. On a product without a screen, that inconsistency doesn't read as a design flaw — it reads as a broken device.

So I reframed the problem for the team: on glasses, behaviour is the interface. If B was going to earn trust, it had to act like one product, with one set of priorities, everywhere.

02Choosing the harder path

The fast option was to keep fixing collisions as they surfaced as bugs. I pushed for the opposite: decide every one of them before launch.

We listed every function on the device once and crossed it with every other. The result was a single interrupt matrix: 27 running states against 29 incoming triggers, roughly 780 decisions. It spanned the AI modes (conversation, Meeting Mode, Live AI, Look & Tell, calling, translation, music search), capture by button, voice and app, calls, media import, notifications, music gestures, and each stage of a firmware update.

Every cell had to commit to two answers. What does the system do? And what does the person perceive? Most specs stop at the first question. The second is where this work earned its value, because a correct rule the user can't sense is indistinguishable from a bug.

A simplified slice — each cell shows what happens when the column's request arrives while the row's activity is running:

03From 780 decisions to one mental model

A matrix is a reference. Nobody designs from it in a meeting. The real leverage came from reading across all 780 cells until the logic underneath became visible. It collapsed into a single priority ladder with five tiers: a higher tier interrupts a lower one, and a lower tier waits or is refused.

1. Calls. An incoming call ends an AI session or a recording and moves to the glasses.
2. Work in progress. Recording, media import, firmware install. Whatever started first finishes. New requests are refused, never the running one.
3. Deliberate capture by button, voice or app. It ends a general AI chat, unless the camera is already in use.
4. AI sessions. They take over from music and announcements, one session at a time.
5. Music and announcements. They always give way. Background downloads simply run alongside.

One exception is intentional. During a firmware reboot, incoming calls fall back to the phone, because for those few seconds the glasses can't take them.

04Principles that outlive the matrix

Rules answer today's questions. Principles answer next quarter's. I wanted these five to be what a new product manager reaches for when placing a feature none of us had imagined yet.

• Never kill the user's work for the system's work. Maintenance waits. If an AI chat is running and an update is ready, the update holds with a toast and the chat carries on.
• A deliberate action beats an ambient one. Pressing a button to take a photo is clearer intent than an open conversation, so "take a photo" during a chat ends the chat and captures — unless Live AI or Look & Tell is already using the camera.
• Protect anything that is writing data. Recording and import are where an interruption costs something. During an import, captures and AI requests are refused, while calls and music continue because they never touch the data.
• Let invisible work run in parallel. Work that doesn't compete for the same resource shouldn't wait. A firmware download runs alongside AI, capture and calls. Only the install is gated.
• One voice in the ear at a time. The speaker is the scarcest resource. Announcements queue by priority, the assistant can interrupt an announcement, and notifications stay silent during music instead of cutting into it.

05Designing the "no"

Most design effort goes into the happy path. On this device, the moments that define trust are the refusals. When someone asks for something and nothing happens, they don't assume a rule. They assume the glasses are broken.

So I set one standard for every refusal in the matrix: the answer returns through the same channel the person used to ask. Someone speaking to their glasses should never have to pull out their phone to understand why nothing happened.

06The calls worth debating

A framework is only as credible as its hardest cases. These are the ones that tested it.

• A call arrives mid-recording. On paper this breaks the rule about protecting data. In practice, a missed call is a real-world cost and a shortened video is not a lost one. The call wins, and the recording is saved up to that moment — an ending tone, a "Recording stopped" card in the app, and the capture light turns off. Nothing they made is thrown away.
• A second AI request during an active session. Two sessions would mean two voices fighting for one speaker. The new request is ignored, and a wake tone confirms the glasses heard it.
• An update is ready during an import. The first draft asked the person to choose: cancel the import, or update later. We removed the question entirely. The update simply waits — the best decision for the user was the one we took off their plate.
• A notification arrives during music. It used to cut into the song. Now it stays silent, with audio ducking proposed as the next step.

07How the thinking matured

The matrix went through three versions in four weeks. The most important change wasn't a rule. It was a stance. The first draft was system-first: maintenance could interrupt the person. By the second, it was user-first: whatever the person started always finishes.

08Owning the outcome, not the document

Interaction specs often quietly die at handoff. The document is approved, the build drifts, and nobody notices until users do. I didn't want this one to end that way. Before launch, I turned the matrix into a design test plan, and my team and I tested the real build against it ourselves.

• Two rounds on Android and iOS, on 7 Sep and 10 Sep 2026, followed by a pass on the iOS pre-prod build.
• Six running states (AI features, AI conversation, capture, calling, media import, firmware update), each crossed with every trigger: about [X] scenarios per platform.
• Two checks per scenario: did the system behave as designed, and did the feedback come back through the right channel?

It caught problems that would otherwise have reached people's ears: taking a photo in Meeting Mode ended the meeting; the blocking tone for gestures was missing during capture on iOS; a firmware download moved on to install by itself; "Resume" in the notification drawer bypassed the install block; "Import now" stayed active on the gallery page; the caller's name was announced inconsistently within the same call.

By the pre-prod round, nearly every scenario passed. The one open issue — the gallery-page import button — went into launch logged and tracked. [Update if since fixed.]

09My role

I led this work end to end as design lead on B, with a team of three designers.

• Reframed the problem from fixing collisions one by one to deciding the device's behaviour as a whole.
• Defined every rule with the product manager and the glass team, covering both system behaviour and what the person hears or sees.
• Set the user-first stance that shaped versions two and three: maintenance waits, and the person's task always finishes.
• Set the standard for refusals: every "no" answers on the channel the person asked through.
• Distilled roughly 780 decisions into a five-tier ladder and five principles any team could apply without opening the matrix.
• Directed the team — the UX designer mapped edge cases; the UI designers built the refusal patterns such as toasts, tooltips and disabled controls.
• Stayed through the build, turning the matrix into a design test plan and running it on both platforms before launch.

10Impact

• One shared behaviour model adopted across AI, capture, calling, app and firmware — every team building against the same source of truth.
• About [X] behaviour and feedback issues caught in design QA before launch.
• [Add a post-launch signal: support tickets, "device not responding" complaints, review mentions.]

11What I'd tell another design leader

On a screenless device, feedback is the interface. The rules matter, but what people actually live with is the tone, the spoken reply, the disabled button. Designing the "no" deserved as much care as the "yes."

Invest in principles, not cells. Nobody remembers 780 decisions. Five principles and a ladder let every team make the right call on features that didn't exist yet.

Design isn't finished at handoff. Testing the build ourselves caught what no spec review would have. The matrix became more valuable as a test plan than as a document.

What I'd do differently: bring QA in from version one, so the matrix and the test plan are written as one artifact from the first day.