What This Is
I wrote the AI strategy my company is adopting
Not a deck about why AI is exciting. A staged, three-year adoption plan for an enterprise design team — naming the stages where AI genuinely compresses the work, the stages where it does not, who owns the decision about which path a given project takes, and the measurement model to prove whether any of it worked. I authored it, presented it to leadership, and MedImpact is adopting it.
Why I built it
Because “we use AI” is not a method. It is a sentence that can mean a careful hybrid workflow or somebody pasting a prompt into a tool and shipping whatever comes out. Our team had the real, unglamorous problems: requirements arriving late, designers hand-building wireframes from scratch, repeated feedback loops with subject-matter experts, and defects surfacing in user acceptance testing after engineering had already written the code. None of those is a tooling problem on its own. The question was which stages AI actually helps, and how to adopt it without losing the review discipline that keeps work correct.
What I want a hiring manager to take from this
Most designers who say they use AI are describing their own workflow. This is a different claim. I can assess a design practice, write the adoption plan, define the governance that keeps it honest, build the business case in hours and rework that leadership will actually fund, and sequence it so each year earns the next. If your team is working this out right now, I have already done it once.
The Decision Rule
The centre of the whole strategy, and the part that makes the rest defensible.
Two paths, and somebody owns the call
Standard path for planned work with full discovery time — AI assists the wireframe baseline, I refine it against the requirements, and it goes through analyst and engineering review before anything is committed.
Time-pressed path for fixed deadlines — fast throwaway comps to settle direction, then agent-generated prototypes built from our governed design system so output stays pattern-compliant, and back to full refinement once direction is confirmed.
Decision owner: the UX lead, confirmed at sprint planning. Not the designer mid-task, not the engineer under pressure. A named owner at a known moment is what stops the exception quietly becoming the default — which is how most AI adoption actually fails.
Three-Year Arc
Adoption fails when attempted all at once. Each year builds on a capability the previous year established, and each one moves UX earlier in the process.
- Year one — Augmented UX. 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.
- Year two — AI-Enabled Discovery. 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.
- Year three — Predictive UX. 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.
Making The Business Case
A strategy that cannot be argued in hours and rework will not survive its first budget review.
Built from our baseline, not a vendor’s
I took our actual feature cycle, broke it into its parts — requirements, design, development, and rework after testing — and modelled the design-stage saving per project against our real project count. Then did the same for rework avoided by testing prototypes before engineering starts.
Where the savings concentrate matters more than the headline. Not in the design stage, which is where everyone looks. In the rework: a defect caught before a line of code is written costs 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.
These are modelled projections built on measured inputs, and I present them that way. Year one is running now; the year-over-year targets are what we are measuring against, not results already banked.
Where AI Earns Its Place
Five stages, each with a specific tool and a specific reason. The point is the narrowness — naming these implies everywhere else it did not pay.
- Baseline wireframes. Requirements in, a structural baseline out in minutes rather than most of a day. I start from something to argue with instead of an empty frame. The refinement and the hierarchy judgment stay mine.
- Rapid prototypes from the design system. Figma Agents build from our established component library and approved patterns rather than generating free-hand interface, so prototypes are usable at handoff. This stage requires a governed design system to exist first — without one it produces technical debt at speed.
- Concepts and direction. Quick clickable comps that explore several directions in minutes, so the team settles on one before anybody invests in building it. Approved concepts get rebuilt in the design system — they are a conversation, not a deliverable.
- Competitive and gap analysis. Market and competitor research with cited sources, compared against our own requirements, synthesised into where the real gaps are. It decides not just the product vision but the sequence — what ships first and why. Findings get reviewed against current requirements and the requirements get updated where the evidence supports it.
- Testing before development. Clickable prototypes tested remotely with real users before engineering starts, with task success rates and timings captured rather than impressions. Design defects surface pre-development instead of post-build, which is where the rework saving comes from.
See The Presentation
The full strategy deck, as presented. Worth noting how it was made: I built it in Gamma, an AI presentation tool. Twenty slides of structured strategy, designed and laid out in a fraction of the time PowerPoint would have taken — which is the argument the deck makes, demonstrated by the deck itself.
View the Full Strategy Deck
What I Bring
Strategy, not just execution
- Assess a design practice honestly — what is actually slow, and why
- Author a staged adoption plan leadership will fund, sequenced so each year earns the next
- Define the governance that keeps it honest: decision rules, named owners, review gates
- Build the business case in hours and rework, from your baseline rather than a vendor’s
- Establish the design system the tooling needs to build against
- Present it to leadership and get it adopted — which is the part that actually counts
And know when not to use it
Elsewhere in this portfolio is a multi-year enterprise platform where I deliberately kept AI out of the shipped screens, and a seven-day conference build where AI did nearly all the execution. Same designer, same year, opposite balance. Telling those two situations apart before you start is the actual skill — and it is what a framework like this one exists to make repeatable instead of instinctive.