I do the job before I design it.

Putting a repair technician's judgment into a triage tool

Problem

Appliance repair techs were arriving on site with the wrong diagnosis, the wrong parts, or no reason to be there at all. Each miss costs a truck roll.

Approach

I interviewed Geek Squad agents and their customers to find what the strong technicians actually do differently, then encoded that judgment into a guided triage Q&A that recommends the next action rather than just recording symptoms.

Result

Errors in assessments, part orders, and wasted repair trips dropped by more than 35%.

The thing I'd carry forward: technicians didn't want the tool to be confident. They wanted it to be legible. Showing why a recommendation was made mattered more to adoption than the recommendation being right every time.

MVP walkthrough — AI-enabled repair triage and service app.

Triage, quote, and booking without pulling a mechanic off a bike

Problem

A mobile bike repair business with no storefront still has to answer the phone. Customers arrive with a photo and a vague description, at all hours, and most of them don't yet know whether they need a mechanic at all.

Approach

I designed and built a four-persona agent system on FastAPI and the Anthropic API. Intake routes to a mechanical, electrical, or pricing specialist. The system runs in DIY mode when the customer can fix it themselves and triage mode when it needs a visit — and any mention of a real mechanic's name hands the thread to that person over an authenticated join link.

Result

Quote and ETA in minutes from a photo. 24-hour repair turnaround through a season when local shops were quoting two to four weeks.

The wear tracker is the part I'm proudest of. Membership visits are triggered by actual part condition rather than a calendar, so the system is deciding when to dispatch a human — a judgment call I had to earn the right to automate by doing the repairs myself first.

Expand

Expand

The service desk on the left, one bike's wear tracker on the right. Both link out to the running product.

Deleting the translation step between design and production

Problem

New Coverage Map features were being drawn in a design file, then rebuilt from scratch by engineers — two rounds of review, two chances to drift.

Approach

T-Mobile's design system already existed as CSS, so I delivered the work as HTML, CSS, and JS instead. Visual review and code review became one review, and the deliverable merged straight into production.

Result

Cut production time in half. I then built a no-code prototyping tool so the rest of the design team could work the same way without writing any.

This one predates the current wave by years, but it's the same instinct that shows up in my agent work now: the highest-leverage thing a designer can build is usually the tool the team uses, not the screen the customer sees.

Two weeks in a high school, because offices had taught us the wrong lessons

Problem

The Whiteboard Owl is a computer vision camera that finds and shares a whiteboard during a video call. We understood setup in conference rooms and almost nothing about setup in classrooms.

Approach

I ran a two-week study in a New Hampshire public high school as sole researcher — 7 participants, 8 observed classes, 9 observed setups, 10 products — then redesigned setup around what the environment, network, and teachers actually did.

Result

Adoption rose an estimated 30–50% over previously tested solutions. One clutch finding was that our button states didn't match common camera conventions, and fixing that alone moved usability more than anything else we shipped.

Expand

Button states, audited against the conventions teachers already knew.

The research surfaced far more than that. The full report is under NDA, but I'm happy to talk through it. What I can show is what it produced: a setup guide written from nine observed setups in a working high school rather than from lab runs and engineering guesses, so it answers the questions teachers actually hit, in the order they hit them.

Click to expand

Whiteboard Owl quick start guide — the six-panel accordion that shipped in the box.

The barrier to buying a hearing aid was never the price

Problem

Research found people weren't stalling on cost. They were stalling because they didn't know whether they needed one.

Approach

I ran a two-week competitive analysis of the audiologist path — including getting my own hearing tested — then designed an online flow that mirrors that assessment, removes the appointment, and recommends products from your own test results.

Result

A best-in-class assessment-to-purchase experience, still live and still doing the job.

Onboarding for a product you can only understand by wearing it

Problem

Bose Frames put psychoacoustic 3D audio in a pair of sunglasses. Nothing on a screen can explain that. The onboarding had to demonstrate it in the first sixty seconds or the product read as ordinary.

Approach

I ran sprints and workshops with the app and marketing teams to find the right scenario, then wrote the iOS app for it myself — reading the head-tracking IMU, driving in-app feedback, handling connectivity.

Result

An onboarding that taught the product and sold it at the same time.

Bose AR onboarding, as it ran on the phone — press play, and use headphones.