Approach
The first stage is spent trying to disprove your brief.
Nearly every engagement we have watched go wrong went wrong before anything was designed. So the argument is front-loaded and the making is deliberately boring.
Interrogate
We spend this stage trying to disprove the brief. Most briefs describe a symptom accurately and a cause badly, and the gap between the two is where the project actually is.
What we do
- Long interviews with the five or six people who decide things
- Desk review of everything already written internally
- Field observation where the work is used, not where it is approved
- A competitive reading, once, so we can stop looking at it
What we need from you
- Access to people, not summaries of people
- The documents you would rather not send
- One named decision-maker for the whole engagement
What you get
A written position: the problem as we now understand it, the argument we propose, and what we would not do.
Frame
The argument becomes a set of constraints. Not moodboards — constraints. What the work must always do, what it must never do, and the measure everything will be judged against.
What we do
- Write the single claim the project has to survive
- Set the constraints: measure, tone, materials, budgets
- Agree the definition of done for every deliverable
- Set accessibility and performance budgets where digital is in scope
What we need from you
- A decision on the claim, in writing
- Realistic dates for the things we do not control
What you get
A one-page frame and a scope document that says what is out as clearly as what is in.
Make
Three-week cycles. At the end of each you see real work at real size in its real context — printed, on a screen at 360 px, mocked at the actual signage scale. Never a rendering of a rendering.
What we do
- Design and build in three-week cycles
- Review at full size, in context, every cycle
- Prototype the hard applications first, not the flattering ones
- Keep one route alive until it is genuinely beaten
What we need from you
- Consolidated feedback within four working days
- The same people in the room each cycle
What you get
Working artefacts every three weeks: files, builds, proofs, samples.
Prove
Before handover, the system is tested where it will fail: the worst reproduction, the longest name, the smallest screen, the least-trained user. We fix what breaks and document what we could not.
What we do
- Stress the system against its worst applications
- Accessibility review against WCAG 2.2 AA and manual keyboard testing
- Print and fabrication trials with the actual supplier
- Write down the known limits honestly
What we need from you
- Access to the suppliers who will produce it
- Time for one proper round of trials
What you get
A tested system, with its failure modes written down rather than discovered later.
Hand over
The work belongs to you, in formats your team can open, with the reasoning attached. We would rather be un-needed than retained by obscurity.
What we do
- Source files, repositories and artwork templates transferred
- Guidelines written for the people who will use them
- Two training sessions, recorded
- A ninety-day check-in booked before we leave
What we need from you
- The names of the people who will own it
What you get
Everything, including the working files and the reasoning. No licence to your own identity.
Ninety days later
We book the check-in before we leave.
Three months after handover we sit down with whoever now owns the work and go through what has broken, what nobody understood and what we got wrong. It is included, it is not a sales meeting, and it is the single most useful hour in the whole engagement.