Every studio says it uses AI. Far fewer can tell you when they decide not to. This is the adoption framework our practice runs on — written for an enterprise design team, adopted there, and the reason our AI claims come with a decision rule attached.
Because “we use AI” is not a method. It is a sentence that can mean a careful hybrid workflow or someone pasting a prompt into a tool and shipping whatever comes out.
This framework was written for an enterprise design team facing a specific, unglamorous problem: requirements arriving late, designers hand-building wireframes from scratch, repeated feedback loops with subject-matter experts, and defects surfacing in user acceptance testing after development had already written the code. Every one of those is expensive, and none of them is a tooling problem on its own.
The answer was not “add AI.” It was deciding which stages of the process AI genuinely compresses, which it does not, and — the part most people skip — who decides which path a given piece of work takes, and when.
The centre of the whole framework, and the part that makes the rest defensible. Two paths. Somebody owns the call. It gets made at a known moment rather than drifting.
Planned work with full discovery time. AI assists the wireframe baseline, then the designer refines it to higher fidelity against the requirements, and it goes through analyst and engineering review before anything is committed.
Fixed deadline, compressed discovery. Fast throwaway comps to settle a direction, then agent-generated prototypes built from the governed component library so output stays pattern-compliant — and a move back to full refinement once the direction is confirmed.
Five stages, each with a specific tool and a specific reason. The point is the narrowness — these are the places it was found to pay, which implies everywhere else it did not.
The first draft, not the final one.
Fast, and still pattern-compliant.
Throwaway on purpose.
The most underrated stage of the five.
Where the money actually is.
Adoption fails when it is attempted all at once. Each year builds on a capability the previous year established, and each one moves UX earlier in the process.
AI-assisted wireframing, prototype testing before development, and AI-supported requirement review. UX still enters the process late, but produces better work faster. This year buys credibility and the data to argue for the next one.
UX moves upstream. AI-generated journey maps, workflow diagrams and task flows let design participate in requirements rather than receive them, and an AI-assisted design system reduces inconsistency and design debt across active projects.
Product analytics feed back in. Behaviour, click patterns and workflow inefficiencies get analysed continuously, so design moves from reacting to reported problems to identifying them before they are reported.
A framework that cannot be argued in hours and rework will not survive its first budget review. This one was built to be.
The model is simple and auditable. Take your current baseline feature cycle and break it into its parts — requirements, design, development, and rework after testing. Measure the design stage before and after. Multiply the per-project saving by projects per year. Then do the same for rework avoided by testing prototypes before engineering starts.
Where the savings concentrate. Not in the design stage, which is the part everyone focuses on. In the rework: defects caught before a line of code is written cost a fraction of the same defect caught in user acceptance testing. The design speedup is the visible win; the rework reduction is the larger one.
We will run the numbers against your baseline, not ours. The figures that matter are yours — your cycle length, your project count, your rework rate. A model built on somebody else’s inputs is a brochure.
Two ways this shows up, depending on what you need.
This is the process running underneath the work. It is why the AI claims on this site come with limits attached, and why you can ask at any point which path a piece of work is on and get a straight answer.
We will write you one. Current-state assessment, a staged adoption plan your leadership can fund, the decision rules that keep it honest, and the measurement model to prove it worked. Built around your tools and your constraints.
Usually one of three things: no design system for the tooling to build against, no decision owner so the fast path became the only path, or no baseline measured at the start so nobody can prove it helped. We can tell you which.