How I design with AI
I explore broadly, turn what I learn into a system, and build from it
AI can turn an idea into working software in minutes. That makes execution faster. It does not make the idea sound.
I work in three stages — explore the problem, turn what we learn into a system, build from that system. They are a loop, not a schedule. Every product is already somewhere on it, and where it sits depends on how much its design system and codebase have already decided.
A new product has decided nothing, so exploration is wide and the system gets written from what it settles. An established one has decided a great deal — some of it still true, some of it drifted, some of it never examined. There the work is narrower: find what the system already answers, find where it answers wrongly, and change it at that level rather than at the screen.
1. Explore and collect
I start by widening what the team understands. AI helps me examine source material, compare approaches, and turn early ideas into working options. Because options are cheap, the team can explore more of the problem before committing to one answer.
The point is not volume. It is evidence — the questions a specification or a static screen leaves hidden:
- Do two people understand the same requirement differently?
- Does the proposed hierarchy survive real content?
- What happens outside the default state?
- Does the interaction solve the intended problem?
- Which assumptions have not been discussed?
So I define the inquiry before generating solutions — the goal, the required behavior, the constraints, and what would make a result wrong. Without that, AI produces polished answers to an unresolved question.
In an established product the brief has one more line: what the system already claims. Much of what a team calls a new problem is a rule that exists and stopped being followed.
Running software makes findings concrete. A team can use an option and respond to what it does, not to what they imagine it might do.
In one stakeholder review I published a working application and got 48 notes across six product surfaces. It made the feedback specific, and it showed where the reviewer’s wording, the visible interface, and the right product response did not agree.
2. Turn what we learned into a system
Findings do not make a coherent product. They have to become rules that survive past the screen where they first appeared — principles, behaviors, components, content patterns, accessibility requirements — which is what turns a resolved question into a reusable constraint.
If several operational states have to stay distinguishable in dense interfaces, that gets solved once — how each state reads through language, shape, and color — not card by card. Every later component inherits it.
This is what tokens and components are for. They are not the story. They are how a decision becomes enforceable.
When a system already exists, this stage is mostly subtraction: the rules that contradict each other, the patterns nobody follows, and the decisions that were never written down and so get re-argued every quarter.
At Atheer I rebuilt an aging design system this way. Product decisions became working components with documented states: designers explored without breaking coherence, engineers received behavior as code, and brand and accessibility rules applied during implementation rather than being repaired after it.
See the operations product and component library
3. Build from the system
Once the intent is clear and the decisions are encoded, the agent can build without redefining the product along the way. Where a pattern exists it applies it. Where none exists, the gap stays visible as a design question rather than being closed with a local answer.
Then the result comes back to people. I read it against the problem we agreed to solve:
- Does the behavior support the intended outcome?
- Do the states, permissions, and failure paths make sense?
- Does the work strengthen the product’s patterns?
- Does the content explain what happened and what comes next?
- Can people perceive and operate it in real conditions?
- Is the behavior credible in the production environment?
A result can pass every check and still be the wrong thing to ship. AI can confirm that an implementation follows the instructions, not that the instructions were the right decision — and it implements an assumption with the same speed and confidence as an approved one. So I use AI to accelerate execution, never to cover unresolved judgment.
In Alucify I designed the surfaces that make that boundary visible: what the system knows, what it inferred, what a change could affect, and where a person still has to decide.
Where this leaves the work
Once people use what was built, it produces new evidence and the loop starts again with more encoded than before. This site was the greenfield case, Atheer the established one; the stages were the same, only how much was already decided and how much of it still held.
What moves is where design has leverage: less time reproducing settled decisions, more on the ones not yet made. AI widens the range and the speed. The system keeps what the team learned. I stay responsible for the meaning and quality of what ships.