From individual screens to reusable systems.
AI didn’t change my product thinking. It changed where I spend my time, moving away from manually producing screens, and towards building reusable systems that let me explore, validate and ship faster, without lowering the bar on evidence.
This isn’t a showcase of tools or prompts. It’s a working record of a shift I’ve made in how I practise product design: why it changed, how I actually work now, and where I think it’s heading next — still evolving, and grounded in real projects rather than demos.
Discovery and research were never the problem. Production was the expensive part.
Traditional product design still leans heavily on manual production: rebuilding layouts, populating dummy data, remaking common patterns, and preparing handover artefacts before engineering can even begin. None of that is thinking. It’s overhead. The diagram below isn’t about replacing Figma, replacing designers, or replacing code: it’s about where the weight of the work sits.
Discovery, research and product thinking already took up most of my time. Production was simply the most expensive part of the process.
↔ Swipe to see all stagesDiscovery and research get more time now, not less — the thinking expands into the space production used to take. Production costs a fraction as much, so prototyping and validation grow to fill what’s left.
AI didn’t change my design process. It changed the economics of it.
Zooming into how that actually gets routed:
- Problem or opportunity
- How much uncertainty exists? Understand & assess
-
High uncertainty Discovery & Research Reduce uncertainty before investing.Low uncertainty Reuse & AI-assisted exploration Reuse proven patterns. Accelerate confidently.
- Prototyping Explore, validate and refine ideas rapidly using reusable systems and AI assistance.
- Validate & refine Test with users, gather evidence and build confidence before delivery.
- Engineering Deliver developer-ready solutions with clarity and confidence.
I don’t apply the same process to every problem. Before anything else, I assess how much uncertainty exists. Genuinely uncertain problems still begin with discovery, research and synthesis. Well-understood problems can move more quickly through reusable patterns and AI-assisted exploration. Both paths reconnect in the Playground, where I rapidly prototype, validate and refine ideas before handing over to engineering with greater confidence. For the simplest, lowest-risk fixes, that same assessment can send work straight to engineering, skipping design and discovery altogether. AI hasn’t changed how I make design decisions. It’s changed how quickly I can turn those decisions into something real.
Reusable components became reusable intelligence.
Design system, code editor, prototype and documentation are one connected system, not four separate tools rebuilt by hand each time. I curate an interface from what already exists (add bar-chart-tile, not a screenshot of one), directing Claude and OpenAI Codex in VS Code, with GitHub Copilot inline, against a shared component library and a set of Markdown rules, so the output matches the system by construction. Two agents reading the same documented rules is also a working cross-check: when they disagree, it’s usually the documentation that needs sharpening, not the code.
Design system, code editor, prototype and documentation used to live in separate tools, each rebuilt by hand for every project. Inside the Playground, they’re one connected system: components, tokens, accessibility rules and interaction patterns already exist, so instead of describing an interface from scratch, I curate it — naming the exact component I want (add bar-chart-tile, not a screenshot of one), so the output matches the system by construction, not by chance.
The agents doing the composing are Claude and OpenAI Codex, both running inside VS Code and both reading the same component library and Markdown rules, with GitHub Copilot handling inline suggestions as I type. ChatGPT sits alongside for the thinking that happens outside the editor: framing a problem, working through data, drafting the documentation the agents then read. Two agents on one documented system is also a useful cross-check; when they disagree, it is usually the documentation that needs sharpening, not the code.
One shift mattered more than I expected: realistic data. Rather than filling screens with lorem ipsum, I built reusable, fictional datasets (invented retailers, products and customers, modelled on real operational patterns) that populate prototypes automatically. A promotional concept tested against a fictional World Cup campaign and invented products felt just as real to participants as a live product, without a single piece of commercial data leaving the building.
That fictional data is good enough to design and test against, not to ship. The prototype and the production feature share the same components and data shape; only the source changes, invented records swapped for a real, permissioned feed at integration, so the interface behaves identically once the data behind it is real.
There’s a commercial argument here too, not just a craft one. Guessing at an interface from scratch costs more than composing one: more generations, more correction cycles, more tokens spent arriving at the same place. Reusing a proven system gets there in fewer steps, which means a lower AI bill for the same outcome, not just a faster one.
Hygiene work and catching up with a competitor are both legitimate reasons to build something, but the version I want more of is the third one: something a user didn’t know they needed until they used it. I still weight that against effort versus reward, an old, simple scoring method, because underneath it that’s always a question of the return a piece of work is worth investing in. Once it ships, the same discipline from my CRO background applies: qualitative and quantitative testing decide whether it earned its place, not the fact that it shipped.
- Whatever starts it A data- and research-driven roadmap, aligning business and customer needs.
- What does this need? Pattern, feature, or something new — the route depends on the answer.
- Already in the design system Straight to build VS Code — Claude and OpenAI Codex as the agents (building with what already exists), GitHub Copilot suggesting inline. No design pass needed.
-
New or uncertain
Discovery & delivery, looped
Jumped between in any order, not a fixed sequence:
FigJam · Lucid — service blueprints & flows, first. Figma — a quick prototype to test, or detailed design when the pattern doesn’t exist yet. VS Code — Claude, OpenAI Codex and GitHub Copilot, delivery moving as discovery clarifies the shape.
- Sanity check UX, accessibility & content guidelines — the MD files — catching any cross-over or knock-on before it ships.
-
Ship
A GitHub repository, with a database plugged in as needed.
Vercel deploy Personal projects, shipped directly.Engineering handoff Brambles & client teams — repo, front-end code & a live prototype.
The route depends on what the work needs, not a fixed sequence: a small change using patterns already in the design system goes straight to build, no design pass required. Something genuinely new or uncertain enters a discovery and delivery loop instead — service blueprints, prototypes or detailed Figma work, jumped between VS Code and Figma in whatever order the problem demands. Both routes pass a sanity check against the same UX, accessibility and content guidelines before shipping — straight to production for my own projects, or handed to engineering with a live prototype for Brambles and client teams.
- In code Components Built once, reusable — a bar-chart-tile, a date-picker, already sitting in the library.
- In MD & tokens Rules Variants, states & spacing, plus UX, accessibility & content guidelines, written down.
- Together Claude, OpenAI Codex & GitHub Copilot Compose only from what’s named and already allowed — not a blank prompt.
Neither source is enough alone: components without rules get misused, rules without components stay theoretical. Together they’re what “Reads: MD files” means in the diagram above.
A few artefacts from inside the Playground itself — more added as the practice keeps evolving:
Where this actually happened.
Complex data, explored as something real rather than something described.
Customer dashboards began as sketches and flows, then moved into the Playground as interactive, chart-driven prototypes. Reusable chart components and design tokens meant stakeholders were reacting to something they could actually use, not a static mock.
Explore more →Two more examples, Homepage Map and Retail Promotions, are in the full story.
Scaling a mapping experience without redrawing it by hand.
A location-based homepage experience needed to work across multiple products and regions. Early exploration started in Figma; once the interaction model was proven, the Playground let me rebuild it as a working, reusable mapping pattern, so scaling it to a second product meant reusing the pattern, not redesigning it.
Explore more →Realistic enough to test, safe enough to share.
A retail promotions concept explored almost entirely inside the Playground, with very little static Figma work. Reusable components and dynamic, fictional datasets (invented retailers, invented products, a fictional World Cup promotional campaign) meant the prototype felt real in usability testing without exposing a single piece of commercial data.
Explore more →Every output becomes the next input.
None of this resets with each new task. The same working markdown files — decisions, evidence, design system rules — carry forward from one AI-assisted session to the next, so each one starts further ahead than the last, rather than re-explaining the same context from scratch. It's the same evidence-led principle behind the work itself: the more the system captures from design systems, user insights, UX patterns and research, the more it has to reason from, and the better its judgement gets over time.
The same reuse principle from the Playground. Just applied to knowledge, not components.
The same principle, someone else’s hands.
A designer I mentor, Dmytro Ivanchenko, took the same principle further: composing an AI agent directly from our design system’s existing components and documented usage rules, and separately building a plugin that converts a design between breakpoints automatically.
Composing from a proven system travels: other people can pick it up and run with it.
What I’ve learned
AI hasn’t replaced my judgement. It’s changed where I spend my time.
- Less time reproducing screens, more time understanding problems.
- Reuse compounds: every component built once pays for itself many times over.
- Realistic data matters as much as realistic interfaces.
- Prototypes that work invite sharper feedback than prototypes that merely look finished.
- The gap between “designed” and “buildable” narrows when design and engineering share the same components.
The design craft hasn’t gone anywhere: it’s moved, from producing individual screens to orchestrating the systems, evidence and reuse behind them.
Where this goes next, and how I plan to adapt.
The numbers further up this page, production down, discovery and validation up, are a rough sketch of something happening more widely: something close to 60% of the mechanical design work now falls to AI, and the 40% that’s left, refinement, judgement, knowing what a context actually calls for, is where the value moved to, not where it disappeared from. I’d rather track that ratio deliberately, and plan around where it’s heading, than notice it a year late. Here’s the honest version of that plan:
- Now · 2026 ~60% AI, 40% judgement AI drafts flows, layouts and first passes. I verify: the MD-file rules, the two-agent cross-check, the sanity check before anything ships.
- Next 12 months ~65% AI, 35% judgement Directing several AI workstreams at once, adjudicating what they produce rather than drafting it myself.
- Two years ~70% AI, 30% judgement Less reviewing everything at the same intensity. More triage: deciding upfront what actually needs heavy verification.
- Five years and beyond Compass, not forecast Less hands-on with any single tool. More defining problems precisely enough that an agent’s output can be verified against them quickly.
An honest timeline, not a sales pitch: the near stops are grounded in what’s already shifting, on this page’s own numbers; the furthest one is a compass, not a forecast — I’d rather say that plainly than fake precision I don’t have.
The reasoning behind each stop, and what stays constant even as the ratio shifts, is in the full story.
That’s also why the sanity check, the MD files, the two-agent cross-check matter to me as much as the diagrams that generate the work in the first place. As more of the mechanical layer gets handed off, what doesn’t automate away is whoever is accountable for a consequential decision being right. That’s the same discipline behind UX Governance and Design QA elsewhere on this site, applied to a faster-moving set of outputs, not a new skill I’m picking up from a standing start.
Beyond generating interfaces, I’m increasingly interested in how AI can make validated product knowledge and research easier to discover, reuse and apply throughout product development.
One area I’ve been exploring with our research team is how this could become part of the Playground itself, not replacing research, but reducing the time spent searching for evidence, so teams can build on what they already know rather than starting from scratch.
See the same evidence-led discipline applied to a validated product direction.