RepairOS

Turning a crowded repair day into clear, safe next actions.

Product strategy · Information architecture · Interaction design · Visual design · Front-end implementation · Workflow-safety design

Discuss a similar project
RepairOS Today view, with fictional sample records redacted, showing role-aware repair-shop triage.

The challenge

A repair can move through booking, diagnosis, parts, quotes, payment, collection and warranty. Staff need current truth and one clear next action, not another broad ticket list to decode.

Built around the real constraint.

I designed three deliberate modes of work: Today for role-aware triage, Work Queue for high-density execution, and Repair Card for focused decisions. The system keeps the next action, physical location, owner, customer position and money attention visible without exposing unnecessary commercial detail.

Role

One connected product responsibility.

I held the thread from product direction and interaction design through delivery and evidence.

  • Product strategy
  • Information architecture
  • Interaction design
  • Visual design
  • Front-end implementation
  • Workflow-safety design

What was built

  • Role-aware Today, Work Queue and Repair Card workspaces
  • A dense queue with filters, action groups and return-to-context behaviour
  • Chapter-based repair work with next action, location, owner, contact and money truth together
  • Quote, approval, deposit and payment journeys shaped around written evidence and progressive disclosure
  • A desktop-first, local-first React experience with focused feature modules

Verification

  • Vitest coverage for application and domain behaviour
  • Playwright journeys through the rendered interface
  • SQL migration and contract tests for capability checks, idempotency and denied reasons
  • Local health, recovery and restart checks for the desktop workflow

Lessons carried forward

What the work taught me.

  1. The fastest interface is the one that makes the next safe decision obvious.
  2. Information density works when changing state, stable context and decision-making are visually distinct.
  3. Failure and recovery states are part of the product experience, not an afterthought.

Have an idea worth building?

You do not need a finished brief. Tell me what you are trying to make—or what is getting in the way—and we can work out the right next step.