From Faster Copy to Building the Thing
I started using AI to write faster. Now I use it to build an idea and test it before I commit to it. This is how that happened, and where I still draw the line.
Photo: Florian Klauer on Unsplash
AI helps me write, synthesise research, build ideas and check decisions against the real system.
The design system, documentation and code are the inputs. Working prototypes help me check a call before I commit to it.
AI writes, builds, extracts and audits. Domain logic, naming, principles and trade-offs stay with me.
It started as a faster pen
I started with ChatGPT the way most designers did: cleaner writing, sharper wording, more ideas, and unfamiliar concepts explained when I needed them.
The mental model was simple. I knew what I wanted to do, and AI helped me do it faster. Faster copy, more options, a mockup by lunchtime. Useful, but nothing another designer wasn’t also doing.
Then it started organising my thinking
The shift was small at first. Instead of asking it to rewrite something, I gave it the mess: my notes, a stakeholder conversation, and one question. What’s actually happening here?
That grew into research synthesis on a complex financial product: support interviews, call recordings and funding rules. What are the patterns? Does this match the research? Am I solving the wrong problem?
That last question did the most work. It’s how a redesign brief turned into a trust problem. See it in Expenses & Utilisation
“It’s hard to imagine”
I heard that in every demo, and for about a year I treated it as a comprehension problem. It was actually three problems with one cause:
- Stakeholders were arguing with my wireframes instead of my ideas.
- A mockup could show a figure that could never occur, and nothing about it looked wrong.
- The design kit for a staff platform had fallen behind what was actually built.
Each one was a picture that wasn’t attached to the thing it described. A picture can be discussed, but it can’t be tested. So I stopped drawing pictures and started building the thing.
Building the thing
By then I was mostly using Claude. It started with screenshots: show it a screen, get feedback on what wasn’t working. Then I began loading the real material into the conversation, research, handover docs and code, and having it build prototypes of what I meant.
That changed two things.
What I showed the rest of the business. At town halls and senior demos, an unfinished artefact reads as an unsettled decision, so people not equipped to steer direction felt free to. A version close enough to real changes the question from “should it be something else?” to “is this right?”
Working prototypes
Obviously provisional, and reads that way
Reads as a decision not yet made
“Should it be something else?”Direction — from people not equipped to set it
Close enough to real to react to
Reads as the thing itself
“Is this right?”The idea itself — from people who will live with it
Product and engineering still get low fidelity. They can argue with an idea rather than a drawing, and cheap is the point. My mistake was matching the artefact to the wrong room, and I got that wrong for a year.
When I found out I was wrong. I built working versions of how the calculations drive a page, and ran generated data through them: positive, negative, warning, variant after variant. Over and over, the design made sense and the data under it didn’t. A static mockup can’t fail that way, because nothing in it computes. Two of the hardest funding rules were worked out by watching the numbers move. See the four layers
The prototypes weren’t the deliverable. I used them to test my own research coverage, then moved straight to strategy.
Then I stopped repeating myself
In May I moved to Claude Code, connected it to Figma, and turned the work I kept doing by hand, like audits and handovers, into reusable skills.
On an SAP-based staff platform, the Figma kit trailed production. So I pulled real components from the repo and designed against what was built, sometimes live in meetings.
When the design kit is behind the codebase, the codebase is the design kit.
By July I was using several tools, each with one job: chat for discovery and checking, Claude Design for building, a Figma agent for the file. And one AI audits another against the real source, because the output that looks finished is the one nobody questions.
Building inside the system
Today the design system, the docs and the code are my inputs. I’m one of the custodians of a company-wide design system built on shadcn/ui, and I generate the Figma files from the repo, so the kit can’t fall behind the code the way it used to.
I run several workstreams in parallel, with clear ownership of each source of truth. And when a new system is still being built, I build only the new pages on it and leave the old shell alone, rather than redesigning a lot of things at once. See how the releases staged the change
Where I draw the line
The risk isn’t bad copy or a clumsy screen. Those get caught. The risk is a plausible wrong answer where the judgement is the work, like deciding what a number means. It arrives looking like evidence, and nothing downstream questions it again.
So AI checks AI against the code, the data and the source of truth. Questions only frontline staff or stakeholders can answer go to them, not into a guess.
What I’d do differently
- Give iterations a home. Early on I shared Claude Design prototypes straight for feedback. It had no version history, so those iterations are gone. I now prototype in Claude Code, whose canvas keeps every one. See why the Funding page became an explanation in context.
- Don’t let building outrun the room. A working version feels settled before the people who need to agree have agreed.
- Scope before asking. Brief instructions let AI guess. A quick scoping question first works better than a fast answer to the wrong question.
Two years in, AI hasn’t changed who makes the call. It’s changed how cheaply I can check a call before I commit to it.
The case studies
Selected work across aged care, FinTech and two-sided marketplaces.