All work

Case 04 · How I work · 3 min

Case 04 · How I work

Not can we build it,
but should we.

With everything possible, nothing is obvious. Choosing what to build is the difference between a product that works and one people actually want, and somebody has to make that call.

Product design Service design Design systems AI-assisted build

Role  UX & service designer With  Claude Code This page  How I work across five phases, on my own and in a team

A hand-drawn illustration on warm paper of two hands reaching toward each other, one filled green and one filled terracotta, their fingertips almost touching. Between them floats a small terracotta heart. Around them are a dashed path, a few small interface marks and a cursor.

The risk

Research & design have to keep up the pace.

With AI, development teams have found a new tempo, and everybody else in the chain has to match it. A discipline or step that cannot keep up gets skipped, because standing still is not an option. That is what happens, not what might.

What often gets built then is feature driven instead of scenario driven: a list of things the product can do, decided by management rather than by a healthy mix of business and customer insights. That makes clutter and friction more likely, not less.

Working ahead is my job: defining direction for a healthy backlog, and validating afterwards. What somebody actually needs, from the situation they are in, written down in experience maps, epics and job stories. Every design afterwards has to answer to a job story, and I follow it through to the release.

A line drawing of a machine on tall legs with a hopper and a chute. Streams of ones and zeros fall into the hopper from above, and out of the chute tumble parts faster than anything can take them: cubes, cones, a cylinder and a sphere, still turning in the air. Under it a heap of what it has already made, spread wide across the ground, every piece a different shape and none of them matching. At the foot of the heap a figure in a green jacket kneels on one knee, holding a single piece up in front of him and looking at it. The ground around him is bare.

Drawn

My involvement across the process.

What I hold is the same wherever I sit: the brief, the goal, what the thing is made of, and what counts as done from a user’s standpoint. Production is where a designer normally hands over. I stay.

Click around. Choose a phase, or one of us, and the rest steps back. Switch between a team and working on my own to see what changes.

Height is involvement.

DEFINE UNDERSTAND CONCEPT PRODUCTION MEASURE

The whole picture

Two of us. At measure our involvement crosses, and the last call is mine.

Three of us, and the first half is one drawing. Define, understand and concept are the same work wherever I do it, so our involvement there is identical. It comes apart at production, where the dev team takes the building.

Define goal

What comes out
The goal in one sentence. What is non-negotiable, as a check.
What I do
Set it myself. A sentence gets reinterpreted, a check doesn’t.
Claude Code
Argues it back at me.
What comes out
The goal in one sentence. What is non-negotiable.
What I do
Set it with the PO.
Claude Code
Argues it back at me before the team does.

Understand

What comes out
Experience maps. Journey maps. A day in the life.
What I do
Validate what came back, steer at what matters and what to go after next.
Claude Code
Analyses everything, brings it back sorted.
What comes out
Experience maps. Journey maps. A day in the life.
What I do
Validate what came back, steer at what matters and what to go after next.
Claude Code
Analyses everything, brings it back sorted.

Concept

What comes out
Job stories. Flows. Priority guides. Prototypes.
What I do
Decide what I make, including the design system. Nobody catches it but Claude Code.
Claude Code
Drafts them, and pushes back on my choices.
What comes out
Job stories. Flows. Priority guides. Prototypes.
What I do
Decide what we make.
Claude Code
Drafts them, and pushes back on my choices.

Production

What comes out
Working software, sprint by sprint.
What I do
Keep it consistent. Each small decision either matches the job story or quietly breaks it.
Claude Code
Writes the features.
What comes out
Working software, sprint by sprint.
What I do
Draw a sprint ahead of the build, then check each sprint against the job story.
Claude Code
Checks with me what landed in the staging environment against what we drew.

Measure

What comes out
What the analytics or the tests said. What changes about the goal.
What I do
Add what I find by hand to what the tests say.
Claude Code
Turns the raw data into insights.
What comes out
What the analytics or the tests said. What changes about the goal.
What I do
Add what I find by hand to what the tests say.
Claude Code
Turns the raw data into insights.

My involvement

Highest at the goal, at concept and at measure. In between it drops while Claude Code analyses, with two small rises where I steer. Through production it stays level.

My involvement

My involvement stays up while the design runs ahead of the build, then falls away, because the building belongs to the dev team. The three spikes after that are me looking at what lands in the staging environment.

Claude Code’s involvement

Claude Code’s involvement is low but never nothing. It climbs through understand, eases off at concept because that part is argument rather than output, and is highest through production. At measure it falls away.

Claude Code’s involvement

Claude Code is done before the build starts, and most of that work is for the people who pick it up. The building itself belongs to the dev team. What it leaves them is the position they start from, guidelines and all, so nobody spends the first day working out where to start. It comes back when a drop lands in the staging environment.

The dev team’s involvement

The dev team is barely there, and then production is all theirs. They come in around concept, where feasibility starts to matter, and stay into measure, because what the tests turn up is theirs to fix. Their involvement only exists in a team.

The chain

From research to design.

Each step is made from the one before it.

  1. Out of the research

    Experience maps

    What happens now, across the whole journey, rather than one design at a time.

  2. Out of the maps

    Epics

    The chunks worth doing something about, picked and ordered with the team.

  3. Out of one epic

    Job stories

    Worked out per step: the situation somebody is in, what they are trying to get done, and what is non-negotiable.

  4. Out of one job story

    Designs

    Screens, components and states, each made against a job story and the design system.

Claude Code, alongside Holds each one against the one above it, across the whole set rather than a sample, and says so when a step has nothing behind it.

I was doing this long before these tools existed. The toolset changed. What steers it didn’t.

Guardrails

What keeps the work from drifting.

Working with AI has to be more methodical, not less. More intentional, not just faster. That is the part that slips first: the speed is real, and the easiest thing to do with it is take what comes back. So what is allowed gets decided up front and written down, and each of these three holds a part of it — across every phase, not at a gate at the end.

Me

What is non-negotiable is set before anything is built. I never loosen it to get something through.

Claude Code

It reads written instructions before every task. It has to show that its work holds, not say that it is done.

The standards

The design system, standardisation, accessibility and the rules of the project. Every design is checked against them.

Next

KLM — paperless maintenance.

400+ iPads for aircraft technicians who were sure they were getting something worse than paper.

Read the next case