A practical field guide for designers working on AI products: what to decide, what to test, what to show engineers, and what to refuse before a generated answer becomes a shipped product.
Hello, friend!
It's okay if a lot of this is new to you. Take it slow. You'll be fine.
A note before you start
If you're new to design or new to AI, read this first.
This playbook teaches the job in layers. First you learn the plain words, then the daily habits, then the checks that keep AI product work from drifting.
Start hereIf you're brand new
Read the welcome, contents, and first 6 stops in order. They explain the job before the tools.
Use todayIf you need action
Jump to the Monday runbook, then use the handoff and spec pages before sharing work.
Review workIf you're checking a feature
Use the 8 states, link checks, and appendix patterns before you call the design done.
Your first-day playbook
Pick one real AI surface. A chat, summary, recommendation, search answer, or agent action.
Write the promise in one sentence. "This helps the user do ___ without ___."
List the failure states. Wrong answer, missing source, timeout, refusal, empty history, partial output.
Open the working version. If there is no working version, make a tiny fake-data prototype before polishing frames.
Share one link and one question. "Open this state. What would you not know how to build?"
If you only do three things
Open the prototype every morning. Click around. Notice what feels off.
Write down the problem before you draw a screen. One sentence. Out loud is fine.
Show your work early. A rough thing seen by three people beats a polished thing seen by none.
Words you'll use today
Prototype, a working version of the app for trying ideas.
Spec, a one-page note about how a piece works.
Tokens, the shared list of colours, spacing, and font sizes.
State, how a thing looks in a moment (loading, empty, broken).
Handoff, the moment you give your design to engineers.
Do this in the next 10 minutes
Open one AI feature and write three notes: what the user expects, what the AI might get wrong, and how the user recovers. That is enough to start.
"You are not trying to know everything. You are trying to make the next decision visible."
The AI designer playbook
Front matter
Stop 1 · Map
Here's the whole journey. Four parts, plus three short appendices at the end.
Contents
Four parts, one working method.
Read it from start to finish if you're new to this. Or jump straight to the runbook pages when you need the step-by-step "what do I actually do" version.
The 2026 reality, after a Twitter/X pass
The loud conversation is speed: agents in Figma, vibe coding, prompt-to-product demos. The useful move is evidence: show the source, expose the state, preserve the trace, and give humans a way to contest the result.
Part I · the job
01The designer's role in AIHow the job changes when the screen doesn't sit still.003
02Range and AI tasteCode, pull requests, planning docs, and restraint.005
Part II · the day-to-day craft
03Prototype the moving partsWhy a working screen reveals what a picture hides.008
04Use AI as a thinking partnerSmall tools that push back before you commit.009
05A design system with rulesShared blocks the computer checks.010
Part III · working with engineers
06The working app is the handoffSend a link people can click, test, and resize.013
07Specs as a real agreementShort docs that act like contracts.014
08Shareable links and the "why"Every state gets a link. Every choice gets a reason.015
Part IV · the impact
0917 weeks, measured honestly554 saved changes · 250 AI chats · the receipts and caveats.017
Appendices
AAI screen patternsThe new shapes AI brings into UI.022
BHelpful places to learn moreResources for when you're stuck.023
CThe quality checklistQuestions before you call it done.024
Part I · the job
Chapter 01
Stop 2 · Part I begins
We're starting with what the job actually is now. Don't worry, no code yet.
Chapter 01, the job
The designer's role in AI.
Old design controlled every pixel of a fixed screen. AI broke that. The screen now changes based on what the model says, and you can never know exactly what.
Own Model boundariesCheck States others missCut Weak ideas early
01
In this chapter
From pixel control to setting limits
From drawing screens to building systems
From specialist to generalist
From visual taste to AI taste
Things to avoid
Your week, day by day
You're doing it right if
For anything you ship, you can answer:
What did I decide the AI is allowed to do? What screen state did I cover that someone else would forget? What did I say no to?
Field move
Before review, write one Allowed / Not Allowed / Unknown note for the AI behavior. If the unknowns are risky, the design is not ready.
map
Three sides of the same job.
Side I
The taste-keeper
You decide what the AI is allowed to say, what it looks like when it refuses, and how it shows where its answers came from.
Side II
The system builder
You don't just hand over screens. You hand over a working set of parts that fit together, and the rules that keep them tidy.
Side III
The hands-on maker
You write a bit of code, you read pull requests, you set up small tools. Not because you're an engineer, because the design only feels real once it runs.
Part I · the job
Chapter 01 · sections 1–2
Stop 3 · The shift
First we'll compare the old way with the new way. Then look at all 8 screen states.
From pixel control to setting limits
You don't draw every screen anymore. You decide what's allowed to show up.
An AI screen has no single "correct" version. The model can return text, sources, suggestions, a polite "no", a wrong answer, or a timeout. Your job is to decide what's allowed to land, and what each situation should look like.
In plain words: instead of choosing the colour of a button, you're choosing the rules the AI plays by.
Old way
One screen, drawn in Figma. You picked the spacing, the colour, the hover state. Engineers rebuilt it to match exactly. The work was done when the picture was done.
New way
A set of rules and shapes. You decide the AI's voice, what a refusal looks like, how sources show up, what to do when the model is unsure, plus five new states the old role barely thought about.
What you actually own now
Limit
Action to take
Voice
Write 3 example answers: helpful, too much, and not allowed.
Refusal
Design the polite "no" before the happy answer.
Sources
Put the citation next to the claim it supports.
Confidence
Decide when to label, hold back, or ask the user to verify.
The five AI states
Make empty, error, loading, half-loaded, and streaming reachable by URL.
A neat trick
Make every state a link
Instead of describing a "loading state" in a doc, build the prototype so you can type a web address that opens that exact state. If the state can't be reached by a link, you haven't really designed it.
?persona=new-user
&scenario=error
&volume=high
From drawing screens to building systems
Coverage is the deliverable, not pretty pictures.
The old job was: “deliver this flow.” The new job is: “deliver every state in this flow, plus the way we'll know it's done.” If you only designed the happy path, you only did a third of the work.
The 8 states every component needs
01 · defaultresting
Save
02 · hovermouse over
Save
03 · focuskeyboard
Save
04 · activeclicked
Save
05 · disabledrequired
Save
06 · loadingrequired
07 · errorrequired
! Save failed
08 · emptyrequired
nothing here yet
If you haven't designed all eight, you haven't finished designing.
Part I · the job
Chapter 01 · sections 3–5
Stop 4 · Range & taste
Two sides of the job, then the traps.
From specialist to generalist
Use Figma to think. Use code when the screen needs to move.
You don't need to become an engineer. You need enough working code to see the parts a picture hides: streaming text, loading steps, source links, errors, and empty states.
In plain words: Figma helps you sketch the idea. A prototype helps you test whether the idea survives real behavior.
What that looks like in practice
You write some code. Not full features, small bits. Enough to make the prototype feel real.
You review pull requests with a designer's eye. If a screen flashes the wrong thing for a split second, that's a design bug, even though it lives in code.
You write planning docs. The way the project is organised changes what the product can become.
You set up small tools. Anything that saves time becomes part of the deliverable.
The boundary
Range is useful only when it leaves receipts.
Doing many things badly is worse than doing one thing well. The way to stay honest is to make every new skill produce a trace someone else can inspect.
Prototype shows the state running.Spec names the rule.Review catches the gap.
From visual taste to AI taste
Your taste shifts from "what looks good" to "what to throw away."
Old portfolios showed the final picture. New portfolios should show the ten ideas you rejected and why. AI is happy to give you ten convincing answers in a minute. Most of them are wrong. Your job is to spot which ones.
Asking taste
Knowing what to ask the AI so you get a real answer instead of confident nonsense.
Spotting taste
Knowing when the AI is wrong but sounds right. Smooth-sounding answers can still be wrong.
Restraint taste
Knowing when "let's add AI to this" is a bad idea. Sometimes the same simple box, in the same place, is the right answer.
Taste script: "Give me 5 reasons this may be wrong, 3 failure cases, and the smallest safer version." Keep only what you can verify.
Things to avoid
Just shipping the AI's first answer
Ships generated output as design. No system, no rules, no checks behind it.
Long plans, no real work
Lots of docs, but the actual product is empty.
Refusing to test the moving parts
Hands engineers a design that's never been seen running. Every gap they hit is a design gap.
Letting AI do all the thinking
Tools that push back don't replace your job to push back on yourself.
Part I · the job
Chapter 01 · runbook
Stop 5 · Your week
Last stop in Part I, the simple Monday-to-Friday rhythm.
Your week, day by day
Monday morning.
A simple rhythm for the week. Three speeds, every day, every feature, every week.
Every dayKeep the product honest.
Every featureMake all 8 states real.
Every weekPromote what earned its place.
Monday first move
Pick one live AI flow and make a risk list: 1 wrong answer, 1 missing source, 1 slow response, 1 empty state, 1 handoff question. Work the list before new polish.
EVERY DAY
Open the prototype. Read one pull request. Run the checks.
Open
Start the prototype on your machine. If it won't run, that's the first design problem of the day, fix it before anything else.
Read
Look at one engineer's pull request through a designer's eye. Watch for screens that flash the wrong thing, missing skeletons, broken empty states.
Check
Run the small "is everything tidy?" checks on whatever you touched. They're fast and they catch silly mistakes.
EVERY FEATURE
The 8 steps when you're building something new.
01Name the real problem
02Sketch a few directions
03Write the spec first
04Build it, all 8 states
05Try to break it
06Compare to reference
07Run the checks
08Share a preview link
Don't start designing until step 1 is honest. Spec first, code second.
EVERY WEEK
Tidy up. Promote the good stuff. Watch for bad habits.
Look for old docs
If a doc is out of date, fix it or delete it. Don't keep zombie docs around, they confuse everyone.
Promote good parts
If you built a small component locally and it earned its keep, move it to the shared kit so everyone can use it.
Check yourself
Review the bad habits above. The role quietly slips into one of them if you don't watch.
Part II · the craft
Chapters 02–04
Stop 6 · Part II begins
Now the day-to-day craft. Three big habits coming up.
Part II, The Craft
Working as an AI Designer.
These are habits, not personality traits. You can learn them one by one: prototype the moving parts, use AI to challenge your thinking, and protect the system with rules.
Build In the working appArgue With AI before committingGuard The system with checks
02
In this part
Prototype the moving parts
Use AI as a thinking partner
A design system with rules
Common AI screen patterns
Things to avoid
One feature, start to finish
setup
Where the work happens.
Where the prototype lives
Inside the bigger project, in a folder called design-prototype/. It's a separate space, a sandbox.
Nothing in the real product depends on it, so you're free to break things and try ideas.
What it's built with
The same tools the production app uses. So when something works here, engineers can copy the shape over without rebuilding it from scratch.
The deal
The prototype is throw-away on purpose. Engineers borrow the idea, not the file. That's what keeps it fast.
Idea 1
Prototype the moving parts
Use a working app when timing, loading, errors, or AI responses change what the design means.
Idea 2
Use AI as a partner
Set up small tools that ask hard questions back at you. Then you don't have to be the only one slowing yourself down.
Idea 3
A system with rules
Write the rules into the code. The system isn't a Notion page nobody reads, it's checks the computer runs.
Part II · the craft
Chapter 02
Stop 7 · Habit 1
Why the working app, not the picture, is the real design.
Chapter 02
Prototype the moving parts.
The working prototype shows timing, uncertainty, and failure. A still picture can only suggest them.
AI screens move. Text streams in word by word. The model takes a few steps to get to an answer. Sources show up. None of that can be honestly shown in a still picture.
In plain words: a chat is alive. A picture of a chat is dead. Until you see the real thing moving, you don't know if it works.
What "prototype the moving parts" actually looks like
Use fake data, no real server
The prototype uses made-up people, files, and integrations from a small data folder. No login, no real server. Speed of trying ideas matters more than realistic data.
Every state has a link
The web address itself decides what shows on screen, who the user is, what's loading, what flags are on. If a state can't be opened by typing a link, you haven't really designed it.
All 8 states for every component
Default, hover, focus, active, disabled, loading, error, empty. Skipping any of them means you only shipped a draft.
Coverage is the deliverable
You make a list of every state your design covers. The computer checks the list is up to date. It's a real artifact, not just a checklist in your head.
It's allowed to be throw-away
The prototype is never used by the real app. If something here earns its way into production, an engineer copies the shape across, not the file. That means you're free to delete anything that didn't work out. Burning ideas that didn't earn their keep is part of the craft, not a failure.
How much truth a still picture loses, by content type
Streaming text
96%
AI's step-by-step
92%
Source links inline
78%
Polite refusals
70%
Half-loaded answers
88%
Plain old buttons
12%
Higher number = harder to design honestly without a working prototype.
Part II · the craft
Chapter 03
Stop 8 · Habit 2
Meet the small AI tools that push back when you'd rather skip the hard part.
Chapter 03
Use AI as a thinking partner.
Set things up so AI pushes back on you, then you don't have to do all the pushing on yourself in real time.
It's hard to be your own toughest critic at the same time as being the maker. So I keep a set of small helpers, each with one clear job. Stacked together, they become a workflow.
Use AI for pressure, not permission
Do not ask "is this good?" Ask: "What am I missing? Where does this fail? What would engineering have to guess? What should we cut?"
Done when
You can name the decision AI changed, or you can say it changed nothing and why.
A typical feature, in order
01/explore what's the problem?
02/grill-me am I solving the right one?
03/diverge three real options
04/debate safe vs. bold
05Build in code
06/expect try to break it
07/agent- browser compare
08/handoff checklist
Skip the deep questions for small tweaks. Slow down only for new shapes.
Surfaces structural issues across the codebase, suggests refactors before they ossify.
The "no-shortcut" rule
Before AI gives me an answer, it has to ask itself: am I helping the designer skip the messy thinking? Am I making something sound like understanding when it isn't? Am I helping win an argument the designer shouldn't win?
That rule is itself part of the design. AI pushes back on me because I set it up to.
Part II · the craft
Chapter 04
Stop 9 · Habit 3
The design system. Shared parts plus rules the computer enforces.
Chapter 04
A design system with rules.
Design tokens live in one place. Local exceptions are tracked. The computer checks the rules.
A design system is only useful if people actually follow it. The trick is to make the rules easy to check: a small script warns you when a screen uses the wrong colour, spacing, or state.
Design tokens are shared values like colours, font sizes, and spacing, saved in one place so every screen uses the same set.
Turn taste into a check
When you catch the same issue twice, write it down as a rule. When you catch it three times, make the computer check it.
Where everything lives
Layer
Owns
Rule
Shared tokens
Colours, spacing, type scale
If a value you need doesn't exist, ask for it in the shared set. Never invent one locally.
Shared kit
Buttons, inputs, basic blocks
Use as-is. Don't edit the source from this prototype.
Local prototype CSS
One-off tweaks for this app
Tweaks only. Never new tokens.
Local components
Things only this prototype needs (yet)
Tracked in a small list with a deadline to either move them up or delete them.
The 10 rules the computer checks
Each rule is a small "no" that saves a long argument later. Beginners can use this as a checklist before asking for review.
Token hygiene
01No raw colour codes.
02No brand-name colours like emerald-600.
03No random font sizes.
Interaction states
04Hover and focus come from the approved set.
07Empty states are real components.
08Small text has a fixed line height.
No local hacks
05No inline colour styles in code.
06No raw widths. Use shared width tokens.
Clear actions
09The more-options menu uses three vertical dots, bold.
10No trash-can-only delete. Use a clear word.
Specs as agreements, folder shape
specs/
├── components/
│ ├── ui/# local building blocks
│ ├── ai-elements/# chat-style components
│ └── domain/# product-specific things
└── patterns/
├── <name>.md # layouts and combinations
└── review-gotchas.md# list of mistakes we've already made
If you edit a component, you update its spec. If you delete one, the spec goes too. The computer treats stale specs the same as a failing build.
Part II · the craft
Chapter 04
Stop 10 · Quality & routine
The quality checklist, traps to dodge, and a real example.
The quality checklist
The list every change gets checked against.
The computer catches some of these. A human catches the rest. Either way, every pull request gets read against this list.
Computer catches
SpacingShared spacing scale. No random pixels.
ColoursNamed colours only.
CSSOne place for app styles. No inline overrides.
StatesAll 8 states are reachable.
Human reviews
ThemingDark and light mode both work.
IconsRight size; icon-only buttons have screen-reader labels.
ComponentsShared kit parts. No source edits from this app.
Things to avoid in the craft
Drawing in Figma when code would be faster
Streaming, sequences, sources, half-loaded states, all lie in still pictures.
Skipping the hard questions on new shapes
Tweaks can be fast. New ideas can't. Don't rush a fresh shape.
Adding tokens locally
Every local token is a future bug. Ask for it in the shared place instead.
Treating specs as docs
Specs are agreements. Docs decay; agreements get checked.
Local components without a deadline
Without a tracked deadline to move them up, "temporary" turns permanent.
Shipping the AI's first answer
AI sounds confident. The taste is in the rejections, not the first draft.
runbook
One feature, start to finish, designing a new "empty" screen.
Start with this sentence
"This screen is empty because ___, so the user needs ___, and the product must not imply ___." If you cannot fill the blanks, do not design the empty state yet.
Frame the real question. Not "design empty state for this tab", "what does someone with zero data actually need to see, and what would mislead them if I show it wrong?"
Read what's already known. Look at design knowledge. Look at how other products do it. Read the list of past mistakes.
Sketch a few directions. Three real options. Throw away two and write down why.
Pressure-test the choice. If the debate flips your mind, take the flip seriously.
Write the spec first. All eight states. Props. Copy.
Build it. Make sure each state opens via a link with the right settings.
Run the checks. Type checks, lint checks, state map, spec freshness.
Try to break it. Adversarial test. Compare with any reference picture.
Hand it off. Run the handoff checklist. Share a preview link with the right settings in your pull request.
Step 1 is the most important. If you skip it, nothing else matters.
Part III · the handoff
Chapters 05–07
Stop 11 · Part III begins
Last big section: how to work with engineers without losing the design.
Part III, The Handoff
Working with Engineers.
The old handoff was Figma red lines plus a Slack thread. The new handoff is a working prototype, a short written agreement, and the back-and-forth that produced both.
The handoff test
If an engineer cannot verify the state, read the agreement, and understand the reason without a meeting, you have not handed it off yet.
Show A running previewWrite The shared agreementExplain The load-bearing why
03
In this part
The working app is the handoff
Specs as a real agreement
Shareable links for every state
The "why" of the design
Things to avoid
Shipping a feature, top to bottom
the transfer
Three things replace red lines.
Thing 1
The working app
Engineers borrow the shape, not the file. Same building blocks, same tokens. A real link, not a still picture.
Thing 2
The spec
A short written agreement that survives pull requests. Versioned, reviewable, freshness-checked.
Thing 3
The "why"
A short, curated note about how the design landed where it did. Just the load-bearing decisions.
The handoff flow, end to end
ABuild in prototype
BWrite the spec
CCurate the "why"
DCheck all 8 states
EDeploy a preview
FShare links for review
GEng copies the shape
HWatch for regressions
Part III · the handoff
Chapter 05
Stop 12 · The shipped link
Why the working preview link is the actual handoff, not the file.
Chapter 05
The working app is the handoff.
Engineers don't translate from a design tool. They open a running app.
The prototype lives near the real product, but it is not the real product. It uses the same building blocks and fake data, so engineers can understand the shape without waiting for server work.
What this gives engineers
A running link, not a still picture
They can click around. Hover. Press Tab. Resize the window. Switch to dark mode. Real, not imagined.
The same building blocks
Every class name and component already exists in production. Copying is mechanical, not creative.
States they can verify
Every state is reachable by link. They don't have to trust me, they can open it.
A clear path to production
A small bridge tool helps move the prototype piece into the real app, updates imports, and checks that shared tokens still match.
The deploy is the handoff
Commits are noisy. Local pushes are private pressure. The real moment is when the preview is live and I can share a link. That's the handoff. Before that, the work is still private. After that, people can review the same thing.
What the prototype is NOT
Not a replacement for the spec.
Not production code. Engineers rewrite it for real data.
Not permanent. I delete things often.
Not the only handoff layer, the "why" matters too.
PR comment to paste
Please review these links, not the screenshots: default, loading, error, empty, high-volume, mobile. The spec is here. The one open question is here.
How small the gap gets
Spec + prototype together~6%
Running prototype only~12%
Figma + Slack thread~38%
"Gap" = bugs born in translation. Lower is better.
Part III · the handoff
Chapter 06
Stop 13 · The agreement
Short written agreements that act like contracts, checked by the computer.
Chapter 06
Specs as a real agreement.
Specs are agreements that get checked, not docs that get ignored. Docs decay; agreements get enforced.
A spec, here, is a one-page Markdown file that describes a component: what it's for, what inputs it accepts, what its 8 states look like, and what NOT to do with it. Engineers and designers read the same file.
Minimum useful spec
A spec is ready when it answers four things: when to use this, what states exist, what can break, and what engineers must not guess.
What goes in a spec
01Purpose
What problem it solves and when to use it.
02API
The inputs, examples, and how engineers call it.
03States
All 8: default, hover, focus, active, disabled, loading, error, empty.
04Quality
Tokens, dark and light mode, accessibility.
05Don'ts
What not to do with this component.
06Review date
A date the computer can check for freshness.
Why agreements, not docs
Freshness is checked.A command fails if specs are stale.
Versioned.Review covers the spec like code.
Same file.Designers and engineers read one agreement.
Survives turnover.The next person inherits the decision, not a rumor.
That link is the spec. It survives a refresh. It works in a deploy preview. Engineers paste it into review comments, open it, and see exactly what I designed.
What each setting controls
Setting
Values
persona
new-user · returning · power
scenario
default · error · loading · empty
flags
hasMeetings · hasTraining · …
volume
low · medium · high (data density)
annotations
on · off (designer notes overlay)
The hidden risk
Links only work if engineers actually open them. If I'm the only one clicking, the system is theatre. Fix: I drop links into review comments and ask people to review against them.
Chapter 07
The "why" behind the design.
The conversation that produced the design is part of the reason. Curate it. Don't dump it.
Worth keeping
The "name the real problem" chat, the exchange that actually clarified what we were solving.
The argument, the back-and-forth that flipped (or held) the safe choice.
The pressure-test, the trade-offs made plain right before commit.
The handoff gap-check, what was missing right before ship.
Worth throwing away
Tweak chatter ("add 8px below").
Pixel-pushing.
Dead ends that didn't change direction.
Anything that wasn't actually load-bearing.
Why this matters for AI features: with normal screens, the design choice is often obvious from the result. With AI features, the choice is invisible. Without the "why," nobody (including future-me) can tell whether a small tweak respects the original intent.
Why note template: We chose ___ because ___. We rejected ___ because ___. If this changes, re-check ___ state first.
Part III · the handoff
Chapter 07
Stop 15 · Ship checklist
The full top-to-bottom checklist for handing a feature off to engineering.
Things to avoid in the handoff
Where the handoff falls apart.
Red-line handoffs in 2026
Translation cost = bug surface. A Figma frame plus a Slack thread is a guessing game.
Specs that document existing code
Specs should describe future code. Documenting after the fact is useful exactly once and then it rots.
Links that only you click
If engineers never open the link, the system is theatre. Put them directly into review comments.
Pasting raw chat logs as "rationale"
Curate or skip. Raw logs are noise; curated notes are gold.
Treating the deploy preview as a courtesy ping
The deploy is the handoff. Treat it like a deliverable, not a notification.
Local components without a deadline
Local pieces without a path to the shared kit fragment the system permanently.
runbook
Shipping a feature to engineering. Top to bottom.
01 · Before code
Real problem named.
Prior art read. Knowledge + patterns + past mistakes.
Decision made. Pressure-tested if needed.
Spec drafted.
02 · Build
Code written. All 8 states reachable by link.
Tokens upstream. No new local tokens.
Lint clean.
Types clean.
State map fresh.
Specs in sync.
03 · Try to break
Adversarial tests pass.
Visual diff vs. reference.
Front-end review run.
04 · Before handoff
Handoff checklist.
Dark + light verified.
All 8 states reachable.
Spec date current.
“Why” curated if load-bearing.
05 · Handoff
Deploy preview live.
PR opened.
Description has links + spec link + “why”.
Engineer tagged. Migration path noted.
After ship: watch for regressions.
The handoff worked if engineers can answer:
What state did I want them to verify?
→ The link.
What was the agreement for this component?
→ The spec.
Why did the design land where it did?
→ The curated "why."
If those answers need a Slack search or a meeting, the handoff failed. If the link, the spec, and the "why" make the answers obvious, the handoff worked.
Part IV · the impact
The work, in numbers
Stop 16 · Show your work
Now the receipts. 17 weeks of work, with the real numbers.
Part IV · the impact
17 weeks. Real numbers.
A solo product designer working with AI. 5 big features shipped fast. 554 saved code changes. 250 AI chats. 10 design rules the computer checks. 43 written specs. Here's what we can count, and what we honestly can't.
The headline numbers
554
Saved code changes
17 weeks of work
250
AI chats
All saved on disk
1,163
AI helper actions
Screenshots, deploys, checks
12
Pull requests
10 merged
43
Specs written
33 components · 10 patterns
10
Design rules
Checked by computer
~2,600
Files changed
Across the project
59
Pages shipped
In the prototype
Lines added
+302,266
Big number, but includes auto-generated files. Activity, not value.
Lines deleted
−53,017
Cutting is part of the job. Knowing what to throw away matters.
My most-used skill isn't autocomplete. It's the one that argues back before I lock in a plan.
How to measure your own work
Track fewer numbers, but track them honestly: preview links shared, states covered, specs updated, reviews that changed the design, and bugs caught before engineering.
Part IV · the impact
Velocity
Stop 17 · Idea → ship
Five hard features. Months on paper. Shipped in days.
Velocity
Five features that should have taken months.
The speed isn't from typing faster. It comes from a workflow that won't ship without checking 8 different states, won't plan without an AI argument first, and won't commit to the safe choice without debating it.
Idea → ship vs industry baseline
Orange = how long it actually took. Grey = how long a typical 5-person team would plan for. Same 30-day scale across every row.
Feature
Time to ship
Shipped
Industry
External CollabPR #6038
14d
4–6w
Mascot avatarsApr 30
1d
1–2w
Connected appsApr 28
hrs
3–5d
Train wizardMay 2
4d
2–3w
Shipped (actual)Industry typicalSpeed comes from removing handoffs, not from rushing.
The tricky part: how do you share a "twin" across different companies when permissions are tied to the company? Took several rounds of arguing with AI before a clean answer appeared.
~2–3×
2
URL state system for personas, scenarios, volumes
101 chats · Feb → ongoing
Forces every screen to handle 8 states (default, hover, focus, active, disabled, loading, error, empty) without manual checklists. State coverage is now automatic, not a designer's plea.
system
3
Mascot avatars for AI agents
PR #5914 · Apr 30 (single day)
Small surface, big stakes, show AI agents as friendly without making them feel like fake people. Designer-led call. Opened and merged in 4 hours.
~5–10×
4
Connected apps · text labels instead of icons
PR #5879 · Apr 29
Debate showed that icons get unreadable at 16px once you have more than 4 of them. Restraint won, fewer icons, easier to read.
~3–5×
5
Train wizard + feed cards
PR #5926 · Apr 30 → May 4
Three different visual styles compared side-by-side before picking one. Throwing things away is the default, not the exception.
~3–6×
Part IV · the impact
Cadence
Stop 18 · The shape of the work
A daily activity grid, plus the shape of two distinct phases.
Cadence
Activity, day by day.
Each square is one day. Color = how busy that day was. Two clear phases show up: the rebuild grind (Jan–Mar, all coding) and the new prototype phase (Apr 13 onward, where AI chats appear).
MonWedFri
JAN
FEB
MAR
APR
MAY
What to notice
Two different kinds of work.
Jan-Mar is sustained rebuild activity. Apr-May is shorter, sharper prototype work with AI chats doing more of the thinking.
Peak week87 saves
Prototype phase250 chats
LessMore
Commits per month, the rebuild grind
27
Jan
128
Feb
219
Mar
75
Apr
3
May
March peak, the big project rebuild. May tail, AI chats take over from coding. Time to think, not just type.
Two phases, one timeline
Phase 1 · RebuildJan 12 → Apr 12
471 saved code changes on the old project. Heads-down coding. No AI chats saved from this time.
Phase 2 · PrototypeApr 13 → May 7
250 AI chats. Lots of thinking, less typing. Design takes the lead.
Older AI chats were rotated off disk, so we only have full data from Apr 13 onward.
Most-active week
Mar 17 → Mar 23
87
saved code changes in seven days. The week the project split in two, clean, no merge problems left behind.
Longest streak
Feb 17 → Mar 19
23 days
in a row with at least one save. The rebuild didn't pause for weekends.
AI chats per workday
Apr 13 → May 7
~13.9
AI chats per workday. Each one is a thinking step, not just typing.
Part IV · the impact
AI leverage
Stop 19 · How AI multiplied the work
My most-used skill argues with me. That's the whole point.
AI leverage
1,163 AI helper actions across 250 chats.
A helper action is when AI uses a tool for me: deploy a preview, take a screenshot, run a test, inspect code, or challenge a plan. The value is not autocomplete. The value is a workflow that checks the work from multiple angles.
Blue bars = skills that push back on my thinking. The other 10 skills add up to 137 helper actions (11.8%).
What this tells us
Deploy beats save
Deploy preview is my #1 skill. A live link is the handoff.
Look first, test second
Browser screenshots (169) beat test expectations (107). Eyes before edge cases.
Question before plan
Grill-my-plan runs once every few chats. The default safety check on big decisions.
Argue against the easy choice
Debate-me runs in only 6% of chats. When I notice I'm picking the safe answer, I force myself to argue against it.
Reversals
When pressure-testing changed my mind.
250 chats · 9 changed direction · 6 came from arguing first
Plain chat (190)Pressure-tested (60)Changed direction (9)
The numbers
250
Total chats
9
Times I changed my mind
66%
Came from arguing first
6 of 9
~10–13%
Argued plans that flipped
Most arguments confirm I was right. The few that flip me are gold, those are the calls I would have shipped wrong without pushing back on myself first.
Part IV · the impact
System & journey
Stop 20 · Health & honesty
Speed is one number. How well things hold up is another.
System health
What got better around me.
10 design rules
Computer-checked taste
no hardcoded colors
no raw color values
no random font sizes
only approved hover styles
no inline color styles
no raw container widths
no inline empty states
matched line-heights for small text
no triple-dot icons
no trash-can icons
43 specs
Living contract
Component specs
33
Pattern specs
10
Decision records
2
Owned modules
10
Specs are checked automatically. We log every recurring failure as a pattern, so we don't fix the same problem twice.
Every holdout has a plan: move into the shared library or delete by a fixed date. No permanent mess.
JOURNEY
17 weeks, end to end.
Jan 12
Rebuild begins
Old project. 471 saved code changes ahead of us. Start the rebuild.
Mar 16
Peak day
35 saved code changes in 24 hours. The grind hits its peak.
Apr 13
New phase
First AI chat lands. The prototype era begins.
Apr 30
Five-feature week
Mascots, connected apps, train wizard. Days, not weeks.
May 6
External Collab ships
PR #6038 in 14 days. Industry estimate: 4–6 weeks.
Honest caveats
A few honest notes about the data.
01Older AI chats are missing. Only the last 25 days are saved on disk.
02Lines of code is a fuzzy number. Includes auto-generated files.
03Files-touched counts moved files too. 2,600 is a high estimate.
04"Industry typical" is my estimate. Treat it as a rough guess.
05Some explorations didn't ship. But the thinking still mattered.
06Prototype work is meant to be thrown away. Saves don't translate one-to-one to production.
Appendix A · AI screen patterns
Reference
Stop 21 · Patterns
A short list of the new screen shapes AI brings, keep this nearby.
Appendix A
AI screen patterns.
A short reference list. The full treatment lives in the design knowledge folder. For new components in this space, use the small AI element library.
How to use this page
Pick the pattern your feature depends on, then design the bad version first: slow stream, missing source, wrong answer, refusal, or empty prompt.
Pattern 01
Streaming text
Show progress without picking a layout that breaks when only half the text has arrived. The container shape matters more than the final string.
Pattern 02
Sources (citations)
Show sources right next to the claim. Trust needs source-at-the-claim. A source someone has to scroll to find isn't a source, it's a footnote.
Pattern 03
Polite refusal
When the model declines, that's a state, not an error. Different copy, different shape. Design it on purpose.
Pattern 04
Confidence (hallucination gate)
When the AI is unsure, label it or hold it back. A screen that hides uncertainty teaches users to trust uncertainty.
Pattern 05
Step-by-step helper actions
Show what the AI is doing, not just the final result: searching, reading, checking, or asking another tool for help. The "doing" is where trust is built.
Pattern 06
Empty AI screens
The hardest one. A blank chat is not an empty state, it's a prompt to the user.
Pattern 07
Persona-aware copy
A new user and a returning power user need different words, not just different layouts. Words are the smallest design surface, and the most often skipped.
Which pattern owns which state
Pattern
Default
Loading
Streaming
Half-loaded
Error
Empty
Refusal
Streaming text
●
●
●
●
●
-
-
Sources
●
●
●
●
-
-
-
Refusal
-
-
-
-
-
-
●
Confidence
●
-
●
●
-
-
-
Step-by-step
●
●
●
●
●
-
-
Empty AI screens
-
-
-
-
-
●
-
Persona-aware copy
●
●
●
●
●
●
●
Orange ● = main state for the pattern. Black ● = it still applies but in a smaller way. - = not relevant.
Appendix B · helpful resources
For new designers
Stop 22 · Keep going
Places to learn more when you're stuck or just curious.
Appendix B
Where to learn more.
A small list. You don't need to read all of these. Pick one or two when you're stuck and come back later.
Current learning path
Learn in this order: AI failure modes, basic frontend states, agent/eval vocabulary, then design-system rules. Tools change fast. These habits hold longer.
Evergreen foundations
The Design of Everyday Things for affordances and feedback.
Refactoring UI for visual decisions that do not require art-school language.
Designing Interfaces for stable patterns when AI makes the surface feel new.
Web references
Nielsen Norman Group for research-backed usability habits.
Smashing Magazine for long-form interaction case studies.
Large design systems for how mature teams describe reusable parts.
Reusable agent skills point to the same pattern: spec first, browser check, review gate, then ship.
Habits that quietly make you better
Keep a "things I noticed" file
Save screenshots of empty states, refusal copy, loading steps, and broken flows.
Watch one user every week
Hand them the prototype and do not help. Note where silence starts.
Copy on purpose
Rebuild one good screen to feel the spacing, states, and tradeoffs.
When you feel lost
Use the small list: open the prototype, read one spec, talk to one teammate, write the problem in one sentence. One of those four usually unsticks you.
Appendix C · quality & closing
End of journey
Stop 23 · Last stop!
You made it. The final quality checklist and a short closing thought.
Appendix C
The quality checklist.
The list every shipped piece gets checked against, plus the three honest questions that decide whether the role itself is still working.
Proof 01 · Role
Good AI design has boundaries.
What did I decide the AI is allowed to do? What state did I cover that someone else would have missed? What did I refuse to ship?
Voice limitsRefusal shapeSource behavior
Proof 02 · Craft
Good AI design survives bad states.
Did I name the real problem before the plan? Are all 8 states reachable? Did I throw away what didn't earn its place?
8 statesNamed tokensNo inline hacks
Proof 03 · Handoff
Good AI design can be verified.
What state did engineers need to verify? What was the agreement for this component? Why did the design land where it did?
Open the preview, force one failure state, press Tab through the page, resize to mobile, and paste the exact state link into the handoff. Then call it ready.
The work, in numbers
3
Big ideas in the craft
8
States, every component
10
Rules the computer checks
14
Small AI helpers in the rack
Closing
The work is making three things honest enough to stand on their own.
The handoff works only if engineers can answer: what state did I want verified, what was the agreement for this component, and why did the design land here. If those answers need a Slack search or a meeting, the handoff failed.
If the link, the spec, and the "why" make those answers obvious, the handoff worked.
/ end of playbook · Pip out.v1.0 · Internal print · 2026