Notes from building an AI design collaborator · part 2
I gave the AI my design process, not my design decisions
· 5 min read
Every AI design tool I see is racing to do the work for me. Describe a screen, get a screen. I want the opposite. I want something that does everything around the work so I can keep doing the work.
That sounds like a mug slogan, so let me back it up with the thing that was actually slowing me down.
The re-explaining tax
Every session with an AI started from zero. I'd re-explain the product, the persona, the constraints, and worst of all the history. Why we killed the obvious layout last quarter. Why the empty state says what it says. Why this one flow has an extra confirmation step that looks pointless until you know what a wrong cross-border payment costs.
At Xflow that stuff lived in three places. The code, which knew what shipped. A few people's heads, which knew why. And Slack, where it scrolled off into the void. None of it was anywhere an AI could reach. Honestly, none of it was anywhere the next designer could reach either.
Our repo is a great record of what we built. It's a terrible record of how we got there. The dead ends, the "we tried that and here's why it broke," the reason a button sits where it sits, none of that survives a merged pull request. So every time we came back to a feature months later, we rebuilt the context from memory. And paid the tax again.
What the engineers had already done
Our engineers had quietly solved a version of this for themselves, and I only found it because I went looking for how they onboard a new backend dev.
Sitting inside the app repo is a .context/ folder, kept per persona, and it's the thing I wish
design had built years ago. A screen index. A navigation map of how the product is actually
structured. A glossary of our domain terms, because "receivable" and "deposit" and "partner" all
mean something specific here and getting them wrong makes you sound like a tourist. The lifecycle
states an entity can be in, which is the single most useful document in the building, because half
of design is drawing screens for states. Relationships between entities. Then flow docs for the
individual journeys.
None of it is glamorous. All of it is the answer to a question a newcomer would otherwise ask a senior engineer, twice. Design had nothing like it. Our process just evaporated the moment the Figma tab closed.
What I decided it should not do
So I started building an AI collaborator for the team. And the first real call turned out to be the most important one, which was deciding what it should not do.
It should not design. Design is the judgment part. Taste, trade-offs, knowing which user you're willing to annoy. That's the part I actually enjoy, and the part I'm paid for. What I wanted gone was everything crowded around it. The drafting, the cross-referencing, the formatting, the logging, and most of all the remembering. So I wrote it down as a rule and stuck to it.
The AI drafts, cross-references, formats, and remembers. The human decides.
Every feature I've built since gets held against that line. If it quietly makes a design decision for the designer, it's the wrong feature, no matter how good the demo looks.
The one idea underneath all of it
Everything hangs off a single choice. Two sources of truth.
| The code repo | The design workspace |
|---|---|
| What was built | How we got there |
| The final, shipped state | Iterations, alternatives, rationale |
| Engineering owns it | Design owns it |
| Design reads it, never writes | Design writes here |
Keep them apart and both stay honest. The repo doesn't fill up with process noise, and the process doesn't disappear into a merge.
That's the whole foundation. Capturing the real product so the AI stops inventing screens, the step-by-step workflow, teaching it the team's taste, all of it is just those two ideas wearing different clothes. Augment, don't automate. And record the why, not just the what.
Start with one sentence
You don't need any of the machinery I built to get value out of this. Start by writing down the one thing your code will never tell the next designer. The why.
Next time you make a real call, you kill a direction, you add the extra step, you overrule the obvious pattern, write it down where the team can find it. It doesn't need a format, but the ones that stay useful six months later all seem to carry four things:
2026-07-11. Payout confirmation keeps its second step. We tried collapsing it into one screen and the flow got faster and worse. A wrong cross-border payout is not recoverable the way a wrong invoice is, so the friction is the feature. Rejected: single-step with an undo window. Undo doesn't exist once the money has left.
The date, the call, the reason, and the option you killed. That last line is the one everybody skips and the one that stops the same argument happening again next quarter, because "we already tried that" is worthless without "and here's what broke."
Do that for a month and you'll have something no repo has ever held. A record of your team's judgment. The AI can build on that. So can the next designer. So can you, six months from now, when you've completely forgotten.
Part of a series on building an AI collaborator for our design team at Xflow. Each post stands on its own, and I'll link the rest as they go up.
Next: I turned my design process into a dozen small skills, not one giant prompt.
- ai
- design-process
- design-leadership
The work behind the series
Designing the Instructions
This post is one thread out of a three-month project: an AI design collaborator for a payments team. The case study is the whole of it: what worked, what broke, and what is still unproven.
Read the case study →