Process

Four moves, repeated honestly.

Process is a tool, not a deliverable. Here's the loop I use on complex product surfaces.

  1. 01

    Understand the mess

    I sit with the actual workflow — the spreadsheets, the support tickets, the screenshots in Slack. I'm looking for the shape of the problem as it lives, not as it's been described. Most clarity work begins by refusing to flatten this stage.

    Typical moves
    • User interviews with current and former operators
    • Workflow shadowing where possible
    • Audit of every existing artifact — forms, exports, emails
  2. 02

    Frame the decision

    I name what's actually being decided on each screen, by whom, with what information, and against what cost of being wrong. This is where most of the leverage lives — a well‑framed decision designs itself.

    Typical moves
    • Decision inventory per surface
    • Information‑on‑hand audit
    • Failure mode mapping
  3. 03

    Design the system

    I look for a small set of patterns — table, form, summary, status — that can carry the whole product. Bespoke screens are a tax later; a shared grammar pays back across every release.

    Typical moves
    • Pattern library tied to real surfaces
    • Defaults that encode product knowledge
    • Permissions and edge cases as first‑class citizens
  4. 04

    Ship and watch

    Release in a way that's reversible. Watch real use, not analytics theatre. The honest, slow loop after launch is where complex workflows actually improve.

    Typical moves
    • Phased rollout with named bailout points
    • Direct user feedback channels
    • Quarterly review of patterns against new use
Principles

The six rules I keep coming back to.

Respect the depth

Never simplify by removing what the user actually needs. Simplify by hiding it correctly.

Defaults are design

A good default does more work than ten options. Choose them with care.

Plain language

If the screen needs a tooltip to explain a label, the label is the bug.

One canonical surface

Two screens that show the same thing slightly differently are two bugs.

Make the rule visible

When the system says no, the screen should say why, and what's allowed instead.

The interesting work is after launch

Design that doesn't survive contact with use isn't finished yet.

Want to see this process applied to real work?

See selected work →