How we work

Four stages, each with a job design owns and something the squad gets back. Then what a squad owes a designer when they arrive, what has to be true when they leave, and where a disagreement goes when it doesn’t resolve.

Framing

What design does:

• Frames the problem before a spec exists, so the squad solves the right thing
• Talks to whoever is closest to the problem, before there is a brief
• Sketches a few different answers, not just the first one
• Sanity-checks scope and feasibility with product and engineering early

What you get: a problem worth solving, and a direction the whole squad can commit to.

The framing stage is not too early for a designer. It’s the only stage where changing direction is still free.

Discovery

What design does:

• Talks to customers every week, mapping the whole journey rather than one customer’s requests
• Maps jobs to be done and intent
• Builds working prototypes, wired to real intelligence
• Tests them with real customers before a line of production code exists

What you get: evidence, a validated problem, and a prototype people have already reacted to.

Discovery is where design makes the difference. It isn’t one-and-done, it’s iterative.

Shaping

What design does:

• Decides how the feature should behave, and what that means for the interaction model
• Defines the intent and the guardrails before a line of behaviour is built
• Names the risk: what a wrong answer costs, and who needs to see it
• Agrees oversight with product and engineering, not after the fact

What you get: a written intent, a risk model, and a design the squad can build with confidence.

Skip this stage, and the build ends up making decisions design should have made first.

Delivery

What design does:

• The design system (Helix), kept current
• The experience end to end: flows, states, and edge cases, not just the happy path
• Agent behaviour specs, where the product includes one: tone, confidence, when to hand back control
• Evals and accessibility conformance, checked before release

Our definition of done:

• It’s clear what’s happening, and why.
• Every action is auditable.
• A person can step in at any point, easily.
• It recovers well when something goes wrong.

It isn’t done when it ships. It’s done when the whole experience holds together.

Bringing a designer into a squad

What the squad owes them in the first week.

1. The problem, not the spec.
2. Access to customers, and the time to use it.
3. A seat in planning from day one.
4. A named PM and engineering lead to work with.
5. The tracked context: what’s been decided, what hasn’t, and why.

When a designer rolls off

Rolling off is the model working. Before it happens, four things are true.

1. Design intent is written down, so the next person inherits reasoning, not just files.
2. Patterns are contributed back into Helix.
3. The assurance state is recorded, so anyone can see where the design stands.
4. Knowledge is transferred to a repo, in markdown, in a shared workspace, not handed off in a single meeting.

Nothing lives only in someone’s head.

When design and product disagree

A normal path, not a personal one.

1. First: the designer and the PM.
2. Then: the Design Manager and the product lead.
3. Then: the Director of Digital Experience.
4. Last: the GCPO.

Most disagreements resolve at the second step.