I don’t think Claude Fable 5 is just “better Claude” 👀

I think it changes how we should use AI.

There’s a type of AI launch that creates more noise than clarity.

Claude Fable 5 is definitely one of those.

Everyone is excited.
Demos are everywhere.
People are throwing around words like Mythos, agentic, autonomous, bigger than Opus, best model yet.

And honestly… after a while, it all starts sounding a little too shiny.

So I tried to ignore the noise for a second and ask a much simpler question:

What actually changes in real work if we use Fable 5 well?

Not in benchmark land.
Not in demo land.
In actual work.

After sitting with it, my honest take is this:

🦋 Fable 5 is not most interesting because it gives better answers.
It’s interesting because it seems able to carry more of the work END TO END.

And I know that sounds subtle.

But I think that’s kind of the whole story.

💌 Tiny pause

🎥 More of a watch/listen person?

Totally fair. Some days we read. Some days we let someone else talk while we pretend to be productive 😄

Here’s the YouTube version of this article.

That I answered these 10 questions:

1. What is Claude Fable 5?

2. Why this launch feels different

3. What people are actually using Fable 5 for

4. Why people may actually use it in real life

5. Where Fable feels different from older models

6. Is coding where Fable 5 is strongest?

7. What still feels overhyped or limited

8. How to use Fable 5 without wasting it

9. Why everyone cares about the June 22 deadline

10. Who should actually care about Fable 5?

Most people will misunderstand Fable 5 if they use it like a chatbot 🦋

This is the first thing I’d tell anyone trying it.

If you open Fable 5 and use it the same way you use a normal chat model, random questions, quick rewrites, tiny one-off prompts, you may walk away thinking:

Okay… sure. Maybe it’s better. But what’s the big deal?

And honestly, fair.

Because I don’t think that’s where this model earns its reputation.

The shift shows up when the task is bigger than one answer.

Something like:

• Build this thing.

• Improve this thing.

• Fix this properly.

• Turn this rough material into something usable.

• Keep going until the work is actually in a better state.

That’s where Fable 5 starts to make more sense.

So for me, the first practical takeaway is not “write better prompts.”

It’s simpler than that:

Give Fable a real job. Not a clever little request.

That one shift changes the whole relationship.

The real value is not “wow, it made something”

This is where I think a lot of AI conversations go a bit wrong.

People get distracted by the output type.

It made a game.
It made a dashboard.
It made an interactive website.
It made a workflow.
It made a shiny little thing with a purple gradient, because of course it did. 😅

But the better question is:

❇️ How much further did it get before I had to take over?

That’s the question that matters in real work.

Because the pain of using AI is usually not getting a first draft.

The pain is what happens after the first draft.

You know the pattern.

🌶 The output is almost right.
🌶 Then you fix one thing.
🌶 Then something else breaks.
🌶 Then the model forgets the original intention.
🌶 Then you repeat the context.
🌶 Then it confidently solves a slightly different problem.
🌶 Then you sit there wondering if you’re still the designer, or now just the AI’s exhausted project manager.

That’s where time disappears.

What seems promising about Fable 5 is that, in the stronger examples, it appears to reduce some of that drag.

Because it seems a bit better at staying with the task.

So I wouldn’t evaluate Fable 5 by asking:

Can it do X?

I would ask:

Does it let me stay in flow longer before the cleanup work begins?

That’s a much better test.

And honestly, a much more honest one.

☕ Quick note

Subscribe if you want the human side of AI tools ✨

If you want to know whether Fable 5 is worth it for you, test it in one of these three ways

This is probably the most practical thing I can offer.

If you want to understand whether Fable 5 matters for your work, don’t give it a cute little prompt and judge the whole model from that.

Test it in one of these three situations.

1. Give it something with moving parts

A task where design, logic, structure, and interaction all matter at once.

For example:

A small app.

A dashboard from real data.

A page that also needs interaction.

A workflow with multiple steps.

A feature that needs both UI and logic.

A playable game from start to finish.

A small 3D simulation where movement, physics, and visual feedback all need to work together.

This kind of task tells you much more than a simple prompt.

Because weaker models often look good at the beginning.
Then the moment the task has dependencies, they start quietly falling apart.

That is where you can actually feel the difference.

2. Give it references, not a blank page

This one is big.

Real work almost never starts from nothing.

It starts from screenshots.
Messy notes.
Old flows.
Competitor examples.
Half-finished drafts.
Stakeholder comments.
A Figma file with twelve versions of the same screen and emotional damage attached to each one.

So instead of asking Fable to invent from zero, ask it to transform something.

Recreate this.
Improve this.
Compare these.
Turn this into that.
Make this rough thing usable.

I think this is one of the most promising ways to use Fable.

Not as a magic generator.

More like a bridge between what you already have and what you need next.

And that feels much closer to actual product work.

3. Give it a task you’ve been postponing because it’s annoying

This might be my favorite test.

Not because it’s glamorous, but because it’s real.

The annoying one.

A repetitive task.
A multi-step task.
Something boring enough that you keep pushing it to “tomorrow,” which is basically the graveyard of tasks.

That kind of work reveals a lot.

Because if a model can reduce friction in the work you avoid doing, that is genuinely valuable.

More valuable, in my opinion, than making one impressive demo that you never use again.

This is where Fable starts feeling less like content…

and more like leverage.

👉 The biggest mindset shift: stop narrating every step

If I had to give one practical piece of advice for using Fable 5 better, it would be this:

Don’t over-direct it.

A lot of us are used to managing AI in tiny steps.

Do this.
Now do this.
Now change this.
No, not like that.
Try again.
Please don’t invent another button style.
Why are there three primary CTAs? 😭

That approach makes sense when models are fragile.

But with a stronger model, it can actually get in the way.

With Fable, the better move seems to be:

❇️ Explain the real goal.
❇️ Define what “good” looks like.
❇️ Give the important constraints.
❇️ Then let it work toward that.

In other words:

❇️ Be clear about the destination, not obsessive about the route.

That’s not just better prompting.

It’s a different working relationship.

Less micromanaging.
More directing.

And I think this shift is a big part of why people are reacting to Fable 5 so strongly.

👀 Small question

Are you already testing Fable 5, or are you still in “watching everyone else test it first” mode? Leave a comment, I’m genuinely curious

Leave a comment

Don’t confuse polished output with good judgment

Now, the caution part.

One thing I would be careful about with Fable 5 is assuming that stronger output means stronger taste.

Those are not the same thing.

A model can absolutely produce something cleaner, more functional, and more complete than before… while still making choices that feel generic, overly polished, or a bit obviously AI-generated.

So yes, Fable may get you further.
But no, I wouldn’t outsource judgment to it.

This matters especially for:

Design.
Messaging.
Brand tone.
Product taste.
Prioritization.

In other words: let it carry more work, but don’t let it make all the calls.

That’s a very important difference.

Where Fable 5 may save the most time

If I had to guess where Fable 5 will matter most, I wouldn’t say “the coolest demos.”

I would say:

Longer coding sessions.
Implementation-heavy tasks.
Turning references into usable outputs.
Repetitive multi-step workflows.
Messy tasks that require too much coordination.

Because these are the places where being 10–20% better at holding context and carrying work can create a very noticeable change in actual effort.

Not because it suddenly does everything perfectly.

But because it keeps you moving.

And in real work, that matters a lot.

Sometimes the biggest productivity gain is not “AI did the whole thing.”

Sometimes it is:

“I didn’t get stuck for two hours in the middle.”

That’s less viral.

But much more useful.

My honest view: Fable 5 is probably more important than it is clear

That’s the cleanest way I can say it.

I think Fable 5 is more important than a casual first impression suggests.

But also less obvious than the hype makes it sound.

Calling it “the best new model” feels too shallow to me.

The more interesting thing is that it seems to reward a more serious style of AI use.

Clearer goals.
Bigger tasks.
More trust.
Less babysitting.
More reviewing.
Less “answer this.”
More “help me move this work forward.”

And if that’s true, then Fable 5 doesn’t just improve outputs.

It changes the shape of the work.

That’s why I think it’s worth paying attention to.

Not because it wins a benchmark.
Not because it made a cool game.
Not because the internet got emotional again, although it absolutely did. 😄

But because it may quietly push more people from:

asking AI for help

to

assigning AI meaningful work

And that is a much bigger shift.

I think we’re only at the beginning of understanding what that means.

💜 Before you go

I keep seeing this sentence everywhere:

“AI will replace designers.”

And honestly… I get why people say it.

Because yes, AI can do a lot of things that used to take us hours.

It can generate ten layout ideas in a few seconds.
It can write a first draft of a product requirement document.
It can resize things.
It can create basic UI components.
It can turn a rough idea into a clickable prototype.
It can write placeholder copy.
It can clean up boring documentation.
It can even help generate code.

So if we define design as “making screens,” then yes, AI looks scary. 😆

But the more I use AI, and the more I see teams trying to bring AI into their workflows, the more I feel the opposite.

AI is not removing designers.

It is removing some of the repetitive parts of design.

But then it creates a lot of new work around the parts that are harder to automate:

judgment, context, trust, quality, systems, team workflow, and knowing what should not be automated at all.

So maybe the honest version is not:

“AI will replace designers.”

Maybe it is:

“AI will replace some design tasks, and then create five new responsibilities designers didn’t have before.”

Cute. Exhausting. Very 2026. 😅

🎥 More of a watch/listen person?

Totally fair. Some days we read. Some days we let someone else talk while we pretend to be productive 😄
Here’s the YouTube version of this article.

First, let’s be honest. AI did take some things off our plate 🍽️

I don’t want to pretend AI has changed nothing.

It has.

Some tasks are definitely easier now.

And that part is good.

I don’t think designers should be romantic about pixel-pushing forever.

If AI can help me generate first ideas, summarize messy notes, or create a quick prototype so I can test the logic earlier, I’m happy. 😊🤝

✔️ AI can generate a screen.

✖️ But does it know if this screen is solving the right problem?

✔️ AI can generate twenty variations.

✖️ But does it know which one actually supports the user?

✔️ AI can suggest a workflow.

✖️ But does it understand the team’s culture, the product constraints, the business risk, the edge cases, the design system, the legal concerns, the emotional state of the user?

Usually… no.

Or at least, not unless someone gives it the right context and checks the output carefully.

And that “someone” is often still the designer. 😎

So yes, AI washes some of the dishes.

But someone still has to decide what we are cooking, whether the food is good, who is coming to dinner, and why the kitchen is on fire. 🔥

The new responsibilities AI created for designers 🧠

So yes, AI took away some repetitive work.

But then it quietly opened a much bigger box of new responsibilities.

And I think this is the part we don’t talk about enough.

1. Context engineering: giving AI the right brain before asking it to work 🧠

This is one of the biggest new responsibilities.

AI does not magically understand your product.

It does not know

your users,

your design principles,

your business constraints,

your edge cases,

your old decisions,

or your “please never do this again” rules.

So designers now need to prepare the context before the work starts.

For example, if I ask AI to redesign an onboarding flow, I don’t just want to say:

“Make this better.”

That’s too vague.

I need to give it the product goal, user pain points, drop-off data, design system rules, accessibility needs, tone of voice, technical constraints, and maybe even examples of what “good” looks like in this product.

That is context engineering.

It is not just writing a prompt.

It is designing the information AI needs so it can actually help instead of guessing.

2. Skill writing: turning repeated team work into reusable AI instructions ✍️

This is another new responsibility that did not really exist before.

A lot of teams keep repeating the same work.

• The same product critique.

• The same UX review.

• The same design-system check.

• The same research summary.

• The same “does this flow match our patterns?” conversation.

Instead of prompting from zero every time, designers can now create reusable AI skills or Markdown instruction files.

For example:

• A UX review skill that checks clarity, friction, accessibility, and edge cases.

• A design-system skill that checks whether a screen uses the right components.

• A case-study skill that writes in your portfolio voice.

• A research synthesis skill that always looks for user needs, contradictions, and product opportunities.

This is not “nice documentation.”

This is reusable design intelligence in Markdown format.

And the important part is: these skills need to evolve.

When the team learns something new, the skill should get better too.

Thanks for reading! Subscribe for free to receive new posts and support my work.

Subscribe now

3. AI-ready design systems: teaching AI how your product should behave 🎛️

Design systems used to be mostly for designers and engineers.

Now they also need to be readable by AI.

Because if AI is generating screens, flows, or components, it needs to know the rules.

• Should it use this component here?

• Which variant should it choose?

• What content belongs inside?

• What spacing rules apply?

• When should it not use this pattern?

If we don’t answer these questions, AI guesses.

And AI guessing inside a design system is where things get messy very fast. 😅

🚨 It might invent components.
🚨 Mix patterns.
🚨Use the wrong button.
🚨 Ignore accessibility.
🚨 Create something that looks polished but does not belong to the product.

So designers now need to make design systems more than component libraries.

They need to become AI-readable governance layers.

Not just:

“Here is our button.”

But:

“Here is when this button should be used, when it should not be used, what variant belongs to which context, and what mistakes AI should avoid.”

That is a new layer of design-system work.

4. AI quality filtering: stopping “variant theater” before it wastes everyone’s time 🔍

AI can generate a lot.

Sometimes too much.

At first, it feels productive.

But then you realize many of those options are just surface-level changes.

This is what I think of as “variant theater.”

The team feels like they explored a lot, but actually they only looked at different versions of the same weak idea.

The card moved.
The color changed.
The font got bigger.
But the real user problem is still untouched.

So designers now need to become stronger quality filters. 🔎

Someone has to say:

“This looks nice, but it misses the problem.”
“This version is not worth exploring.”
“This one breaks our design system.”
“This one is visually different, but strategically the same.”
“This one is actually interesting because it changes the user decision.”

When AI makes output cheap, judgment becomes expensive.

And that judgment is still very much a designer’s job.

5. Trust and control design: helping people understand, check, and override AI 🤝

AI recommendations need trust around them.

Not blind trust.

Designed trust.

Imagine an AI says:

“This workflow will save your team three hours.”

Okay… but why?

Based on what?
How sure is it?
What did it consider?
What are the trade-offs?
Can I check it?
Can I change it?
Can I say no?

This is a new design responsibility.

Designers need to create the TRUST layer around AI decisions.

That means showing confidence levels, explanations, trade-offs, review steps, undo options, and clear “I’ll do it myself” paths.

Because users should not feel trapped inside AI decisions.

They should feel supported by AI, but still in control.

Trust does not happen just because the AI is smart.

Trust has to be designed. 🖌🖍🖋

6. Workflow and tool orchestration: designing how the team works with AI 🛠️

AI does not only change the product.

It changes the team workflow too.

And this creates a new responsibility for designers.

Designers now need to look at the team and ask:

• Where do we repeat work?

• Where does context get lost?

• Where do product, design, and engineering misunderstand each other?

• Where are decisions hidden in Slack, Figma, Jira, Notion, or random meetings

• Where could AI help, and where would it just create more noise?

For example, maybe the team does not need another AI design tool.

✔️ Maybe they need a shared knowledge base.
✔️ Or a reusable UX review skill.
✔️ Or a better way to connect design decisions to GitHub.
✔️ Or an AI assistant that checks whether new flows match the design system.

This is workflow orchestration.

It is not about using every shiny tool.

It is about understanding the team’s gaps and designing a workflow where AI actually fits.

7. AI tool and model evaluation: testing tools with real work, not shiny demos 🧪

This part is honestly exhausting. 😫

Every week there is a new AI tool.

A new model.
A new plugin.
A new “this changes everything” post.

But teams cannot change their workflow every two weeks.

So designers need to test tools with real scenarios.

Can this tool solve our actual problem?
Can it work with our current stack?
Does it integrate with Figma, GitHub, Jira, Storybook, or Notion?
Can the team adopt it?
Does it respect privacy and security?
Will it survive for the next two years?
Does it improve quality or just create faster noise?

Choosing AI tools is becoming part of design judgment.

Because tools shape how teams think, collaborate, communicate, and ship.

8. Designer-builder mindset: moving closer to code and real product behavior 👩🏻‍💻

AI is also blurring the gap between design and implementation.

This does not mean every designer needs to become a full engineer.

But it does mean designers can move closer to building.

They can create coded prototypes.
Test real interaction logic.
Explore edge cases earlier.
Work closer to GitHub.
Understand how a design behaves beyond the static screen.

This changes the old handoff model.

Before, it was often:

Designer designs. 😬
Engineer builds. 😬😬
Designer reviews. 😬😬😬
Engineer fixes. 😬😬😬😬
Everyone gets tired. 😬😬😬😬😅

Now, a designer can come to the conversation with something more concrete:

“I tested this interaction.”
“Here is where the logic breaks.”
“Here is the edge case I noticed.”
“Here is a working version of the idea.”
“Now I need your engineering brain to make it production-ready.”

That creates a better partnership with engineering. 🙍🏻‍♀️🤝🙎🏻‍♂️

Not because designers replace engineers.

But because designers become stronger builders.

9. Thinking infrastructure: documenting decisions so AI doesn’t undo them later 📋

Before AI, many design decisions lived in messy places.

🌶 Figma comments.
🌶 Slack threads.
🌶 Meeting notes.
🌶 Someone’s memory.
🌶 A random old ticket.

It was not perfect, but teams could survive.

With AI, this becomes riskier.

Because if the reasoning behind a decision is not written down, AI may undo it later.

For example:

Why did we choose this navigation pattern?
Why did we reject the simpler flow?
Why does this warning appear before the action?
Why do we use this component only in specific cases?

If AI does not know the reason, it may “improve” the design by removing the exact thing that made it safe, clear, or consistent.

👉 So designers now need to document decisions in a more structured way.

Not heavy documentation for the sake of documentation.

More like a living thinking layer.

A place where both humans and AI can understand why the product is the way it is.

10. Human judgment protection: knowing when not to outsource the thinking 🛡️

This might be the most important responsibility.

AI can help us think.

But it should not replace our thinking.

It is very tempting to open the tool too early.

🌶 Before reading the research.
🌶 Before noticing the contradictions.
🌶 Before forming a hypothesis.
🌶 Before understanding the user problem.
🌶 Before developing your own point of view.

Then AI gives a polished answer, and it feels convincing.

But polished does not mean true.

So designers need to protect the human parts of the work.

🤍 Research.
🤍 Empathy.
🤍 Taste.
🤍 Contradiction.
🤍 Ethics.
🤍 Judgment.
🤍 Point of view.

Use AI to sharpen your thinking, not replace it.

That is probably one of the biggest survival skills for designers in the AI age.

So what should designers invest in now? 🌱

I don’t think the answer is “learn every AI tool.”

That is impossible.

And honestly, very stressful.

I think the better answer is to invest in the abilities that make you valuable across tools.

Things like:

Context building.
Writing clear instructions.
Understanding systems.
Designing trust.
Evaluating outputs.
Asking better questions.
Knowing when AI should stop.
Working closer to code.
Documenting decisions.
Building reusable knowledge.
Understanding team workflows.
Testing tools with real scenarios.
Protecting user needs when everyone gets excited by speed.

Because the tools will change.

The models will change.

The hype will definitely change.

But these responsibilities will stay.

The future designer is not just the person who can make screens faster.

The future designer is the person who can help a team think better, work better, decide better, and use AI without losing quality.

So no, I don’t think AI is killing designers

I think AI is killing the lazy definition of design.

The version where design is only screens.
Only layout.
Only handoff.
Only making things pretty.
Only producing more options.

That version is getting weaker.

But the deeper version of design is becoming more important.

AI can generate more.

✔️ But designers still need to decide what is worth generating.

AI can make things faster.

✔️ But designers still need to ask if faster is actually better.

AI can create options.

✔️ But designers still need to know which option makes sense.

AI can support the work.

✔️ But designers still need to protect the meaning of the work.

Come & join me on LinkedIn. ☕️✨

I’ve been spending a lot of time lately in what I call the “Vibe Coding” trap.

You know the feeling? ☹️

You start a fresh AI session to prototype a new feature, and the first few components look surprisingly good.

The layout works.
The button is there.
The card looks clean.
For a moment, you think: okay, this is magic.

But by the second hour, or the next day, things start to drift.

😒 The AI chooses a slightly different blue.
😣 It guesses 12px padding where your system uses 16px.
😖 It adds a border radius that looks modern, but not quite yours.
😤 It uses a modal where the real product would usually use an inline message.

Nothing looks obviously broken.

But by session five, your prototype starts to feel like it was built by three different teams who haven’t spoken in years. 😁

The Problem: Why your current system is “invisible” to AI

AI did not break design systems.

It exposed what was already fragile.

Most design systems were built for HUMANS. And humans are very good at reading between the lines.

• We know that a primary button does not mean “use primary everywhere.”

• We understand that a modal is not always the answer.

• We remember the conversation where the team decided to stop using a certain pattern.

• We know which components are technically available but strategically discouraged.

AI agents do not have that context. For an LLM, they are a black box. ⬛️⚫️

And this is where the trouble begins. ⚠️

• LLMs don’t have memory: Every new session starts from zero. The AI doesn’t remember that yesterday it picked #2563EB for links; it just picks a “plausible” blue today.

• They can’t read “Design Intent”: An AI can see a Button component in your code, but it doesn’t know when to use a Modal vs. an Inline Message, or why you never put two primary buttons next to each other.

• Fabrication is the default: If the AI doesn’t find a token named --space-200, it will just write padding: 12px because it looks “right”.

That is the real risk of AI-generated UI.

Not bad design.

👻 Uncontrolled design. 👻

AI is guessing where our systems are still implicit.

So if we want to move toward an agentic workflow, where AI agents actually help us build complex, consistent UIs, we have to stop treating the model like a human designer reading documentation.

We need to treat it like what it is:

👉 a machine that needs structured scaffolding, clear rules, reusable context, and guardrails.

The problem is not vibe coding. The problem is vibe coding without infrastructure.

I actually like vibe coding. 😇

💜 I like the speed.
💜🩷 I like the experimentation.
💜🩷❤️ I like being able to move from idea to working prototype without waiting for the perfect handoff moment.

🫨 But the more the agent has to invent, the more hidden judgment turns into hallucination. 🫨

The future of AI-native design work is not “better prompts.”

It is better context.

The question is not:

How do we ask AI to design better?

The better question is:

How do we make our design system explicit enough that AI does not have to guess?

That is the shift.

From prompt engineering to context engineering.

Come & join me on LinkedIn. ☕️✨

So What I mean by an agentic design system?

My practical definition:

An agentic design system is a design system that AI agents can read, use, generate from, and be checked against.

It is not just documentation.

It is a structured environment made of:

• machine-readable specs,

• semantic tokens,

• component metadata,

• usage rules,

• anti-patterns,

• templates,

• recipes,

• guardrails,

• audits,

• and feedback loops.

A normal design system says:

Here is our Button component.

An agentic design system says:

Use Button for actions that submit, save, confirm, or move a workflow forward. Use only one primary button per decision area. Do not use Button for navigation links. Use Danger only for destructive actions. Icon-only buttons require accessible labels. If you need a new variant, stop and ask.

That is the level of clarity AI needs.

Not because AI is stupid.

Because ambiguity at machine speed becomes inconsistency at product scale.

The 7 practical layers that make your design system machine-readable

The layers below are the practical pieces that make it happen.

Layer 1: Create a spec layer agents can actually read

The first thing I would create is a specs/ layer.

A structured set of Markdown files that tells the agent how the system works before it starts generating UI.

This is already starting to happen in public design systems.

• 🔗 Atlassian publishes an llms.txt for its design system.

• 🔗 CMS does too.

• 🔗 Carbon does too.

• 🔗 Nord Design System does too.

What I find interesting is that they are not only pointing to components. They expose foundations, tokens, packages, patterns, accessibility guidance, and documentation in a way an LLM can navigate.

That is the shift.

The design system becomes something the agent can look up.

I like the hierarchy Hardik Pandya uses in Expose your design system to LLMs:

specs/
  foundations/
  tokens/
  atoms/
  molecules/
  organisms/
  patterns/

Each part answers a different kind of question.

• Foundations define the primitives: color, spacing, typography, radius, motion, accessibility.

• Tokens map every CSS variable and when to use it.

• Atoms cover single-purpose components like Button, Input, Link, Badge.

• Molecules and organisms cover composed components and product-specific assemblies.

• Patterns cover layout rules, content flow, spacing between sections, and composition decisions.

Every spec file should follow the same structure. ✍️

Something like:

# Button

## Metadata
Name: Button
Category: Atom
Status: Stable

## Overview
Use for actions that submit, save, confirm, or progress a workflow.

Do not use for navigation. Use Link instead.

## Anatomy
- Container
- Label
- Optional icon
- Loading indicator

## Tokens
- --color-action-primary-bg
- --color-action-primary-text
- --space-200
- --radius-medium

## Props / API
- appearance: primary | secondary | ghost | danger
- size: sm | md | lg
- state: default | hover | focus | disabled | loading

## States
Default, hover, focus, disabled, loading.

## Code example

<Button appearance="primary" size="md">
  Save changes
</Button>

## Cross-references
Uses:
- tokens/color-tokens.md
- tokens/spacing-tokens.md

Related:
- atoms/link.md
- molecules/form.md
- molecules/modal-dialog.md

This is where the hidden design logic becomes visible.

When should the agent use a button?
When should it use a link instead?
Which tokens belong to it?
Which components does it relate to?
Which state should it support?

Source code shows what was built.

Specs explain how to build the next thing correctly.

That is the gap we need to close. 🙅‍♀️

Layer 2: Create named tokens for every visual value

The next layer is the token system.

This is where I would stop AI from inventing visual decisions that only look correct.

A blue that is close enough.
A spacing value that feels normal.
A border radius that looks modern.

None of that is enough.

The product does not need a reasonable blue.

It needs your blue. 🫵

So the agent should NOT write raw values.

I would use a closed token layer with three levels:

1️⃣ First, upstream tokens define the raw source of truth from the design system:

--ds-text: #292A2E;
--ds-link: #1868DB;
--ds-space-100: 8px;
--ds-space-200: 12px;
--ds-radius-200: 8px;

2️⃣ Then the product creates aliases. This is the semantic layer. It translates raw design system values into product meaning:

--color-text: var(--ds-text, #292A2E);
--color-link: var(--ds-link, #1868DB);
--space-100: var(--ds-space-100, 8px);
--space-200: var(--ds-space-200, 12px);
--radius-medium: var(--ds-radius-200, 8px);

3️⃣ Components only reference the alias:

.button {
  color: var(--color-text);
  padding: var(--space-200);
  border-radius: var(--radius-medium);
}

That alias layer is what protects the system.

The upstream token says: “This is the value.”

The alias says: “This is what the value means.”

The component says: “This is where I use it.”

If the design system changes later, you update the alias once. Components do not need to be rewritten.

And the agent does not get to choose a new blue because it felt plausible.

It has to use the named value.

That is why semantic tokens matter.

The agent should not be deciding:

“What color looks right here?”

It should be deciding:

“Is this a link, a warning, a disabled state, a muted surface, or an emphasized action?”

Then the token system handles the visual decision.

Layer 3: Add metadata to components, not just props

Specs give the agent the system map.

Tokens give it the allowed visual values.

The next step is to put component intent close to the actual component.

For important components, I would add a small metadata file next to the implementation:

button/
  Button.tsx
  Button.meta.ts
  Button.stories.tsx
  Button.test.tsx

The metadata should be boring and explicit.

That is the point.

export const buttonMeta = {
  name: "Button",
  category: "atom",
  status: "stable",

  purpose: "Trigger actions that submit, save, confirm, or progress a workflow.",

  useFor: [
    "submit form",
    "save changes",
    "confirm step",
    "apply settings"
  ],

  avoidFor: [
    "navigation between routes",
    "low-emphasis text links",
    "destructive actions without confirmation"
  ],

  variants: {
    appearance: ["primary", "secondary", "ghost", "danger"],
    size: ["sm", "md", "lg"],
    state: ["default", "hover", "focus", "disabled", "loading"]
  },

  rules: [
    "Use only one primary button per decision area",
    "Use Link for navigation",
    "Use danger only for destructive actions"
  ],

  accessibility: [
    "Must have a visible label",
    "Must include focus state",
    "Icon-only buttons need accessible labels",
    "Loading state should prevent duplicate submission"
  ],

};

Props tell the agent what is possible.

This tells it what is appropriate.

That matters because most AI mistakes are not syntax mistakes.

They are judgment mistakes.

A modal exists, so the agent uses a modal.

A danger button exists, so the agent uses it too freely.

A table exists, so the agent turns every dataset into a table.

The component metadata should make those decisions less open-ended.

This is the part humans often infer.

Agents need it written down.

Layer 4: Document patterns, not only components

A lot of product quality does not live inside components.

It lives between them.

Spacing between sections.
Hierarchy on dense pages.
How filters relate to tables.
How errors recover.
How empty states guide action.
How assistant panels sit beside core workflows.
How complex dashboards reveal information gradually.

This is especially important in B2B and enterprise products. 👀

AI can generate a table.

But can it understand when the table should be dense, when actions should be visible, when filtering should be persistent, or when the user needs decision support instead of more data?

Not unless the pattern is documented.

A pattern spec could look like this:

# Filterable table pattern

## Use when
The user needs to compare, scan, filter, and act on multiple records.

## Structure
- Page header
- Optional summary metrics
- Filter bar
- Table
- Pagination
- Empty state
- Error state

## Rules
- Keep filters visible after results update.
- Do not hide primary row actions only on hover.
- Use bulk actions only when multi-select is enabled.
- Show active filters clearly.
- Empty states should explain how to recover.

## Do not use when
- The user is completing a linear task.
- The content has fewer than three comparable items.

This is where design systems become more than UI kits.

They become product thinking infrastructure.

Layer 5: Use templates where AI should not improvise

Some parts of the interface should not be regenerated every time.

Top navigation.
Side navigation.
Brand assets.
App shell.
Theme setup.
Permission-sensitive areas.
Product-level layout.

These are not places where we need AI creativity.

We need consistency.

👉 The practical solution is to pre-build these parts as reusable templates in your codebase.

Think of them as production-ready starting points that AI can reuse instead of recreating from scratch every time.

For example:

templates/
  dashboard-shell/
  settings-layout/
  admin-layout/
  analytics-page/

These templates should live in your repository and be documented in your AI tooling structure so agents know they exist and when to use them.

And each template should have a short spec explaining:

# Dashboard Shell

## Purpose
Standard dashboard structure for authenticated users.

## Includes
- Top navigation
- Side navigation
- Theme setup
- Responsive layout
- Notification area

## AI instructions
- Do not modify navigation structure.
- Do not replace theme tokens.
- Generate only page-specific content.
- Use approved dashboard patterns.

This is important because many teams currently ask AI to regenerate the same dashboard, settings page, or application shell over and over again. 😬

That creates unnecessary variation.

Instead, pre-code the stable parts once, document them, and tell the agent to build on top of them.

So instead of asking:

Generate a dashboard using our design system.

A better instruction is:

Use the existing dashboard template. Do not modify navigation, logo, theme, or shell. Generate only the main content area using the table, filter, and empty-state specs.

This changes the agent’s job.

It no longer has to invent the whole product environment.

It works inside a stable frame that already exists in code.

My rule:

Pre-code what should stay stable. Let AI explore where flexibility is useful.

Layer 6: Turn repeated prompts into recipes

If a team keeps asking AI to do the same thing, that should become a recipe.

Not everyone should have to remember the perfect prompt.

Recipes are reusable instructions for common tasks, such as:

• add an assistant panel,

• create an empty state,

• generate a filterable table,

• switch to dark mode,

• create a settings page,

• convert a screenshot into a prototype,

• add responsive behavior.

Example:

# Recipe: Add assistant panel

## Use when
The user needs contextual AI help beside an existing workflow.

## Rules
- Do not replace the main workflow.
- Place the panel on the right side on desktop.
- Collapse into a drawer on smaller screens.
- Show uncertainty when the assistant makes recommendations.
- Keep the primary product action outside the assistant panel.

## Do not
- Do not auto-submit user input.
- Do not hide core workflow actions.
- Do not present AI output as final when confidence is low.

This is small but powerful.

It reduces prompt variability.

It also makes AI workflows easier for non-technical teammates.

Good AI adoption is not just about tools.

It is about making the right behavior easy. 😎💪

Layer 7: Add guardrails and audits

This is the layer that turns AI from “helpful but unpredictable” into something teams can actually trust. 🫶

I think about it in two parts:

👉 Guardrails happen before AI generates.
They tell the agent what it is allowed to do.

👉 Audits happen after AI generates.
They check whether the output respected the system.

Both are needed.

Guardrails: tell the agent where the boundaries are

Guardrails should live in places the agent reads before touching UI, like:

design.md
CLAUDE.md
.cursorrules
llms.txt
component specs
pattern specs
recipes

They should be direct and practical.

For example:

Before modifying UI:
- Read the relevant component and pattern specs.
- Use existing components before creating anything new.
- Use only tokens from token-reference.md.
- Do not create new variants unless explicitly asked.
- Do not modify global navigation, theme, or brand assets.
- Ask for human review if the flow involves payment, privacy, permissions, or destructive actions.

This gives the agent a working frame.

Not just “make it nice.”

More like:

Here is what you can touch.
Here is what you cannot touch.
Here is when you need to stop.

That is much safer.

Audits: check the boring mistakes automatically

Audits are the system’s safety net.

They catch the things humans should not have to manually inspect every time.

For example:

• Did the agent use raw hex colors?

• Did it add random spacing values?

• Did it invent a component variant?

• Did it break accessibility rules?

• Did it change the app shell?

• Did it ignore the documented pattern?

• Did it introduce a new UI pattern without adding a spec?

A simple token audit could scan the code and flag:

src/components/Card.css
x Line 42: Hardcoded color #2563EB. Use var(--color-link).
x Line 57: Raw spacing 12px. Use var(--space-150).
x Line 73: Raw border-radius 10px. Use an approved radius token.

This is the point where the design system stops being passive documentation.

It becomes enforceable.

A simple setup can be enough

You do not need a huge governance machine to start.

A practical first version could include:

scripts/
  token-audit.js
  accessibility-check.js

checklists/
  ai-generated-ui-review.md

And your AI instruction file could say:

Before completing the task:
- Run token-audit.
- Run accessibility checks.
- Confirm no new components or variants were created.
- List which specs were used.
- List any assumptions.
- Flag any missing design system guidance.

The goal is not to remove human review

The goal is to make human review more valuable.

I do not want designers spending their review time catching random px values, broken focus states, or invented colors.

The system should catch those.

Designers should spend their attention on judgment:

• Is this the right pattern?

• Does this support the user’s task?

• Is the hierarchy clear?

• Is this interaction appropriate for the risk level?

• Does this feel like our product?

❇️ That is the real value of guardrails and audits.

They do not make AI perfect.

They make AI output easier to trust, easier to review, and easier to improve. 😎

Where these layers actually sit in a real repo?

At some point, all of this has to become more than a nice diagram.

🏠 The specs need a home.
🏠 The tokens need a home.
🏠 The agent instructions need a home.
🏠 The templates and recipes need a home too.

A structure I really like comes from Hardik Pandya’s article. He tested this setup with Atlassian’s design system and organized the documentation around a very clear hierarchy.

I would use that as the backbone.

Then I would add the few layers I think are missing for agentic workflows: templates, recipes, tool-specific guidelines, and agent instruction files.

So the ideal final structure could look like this:

your-project/
├── specs/
│   ├── foundations/              # Tier 1: Visual primitives
│   │   ├── color.md
│   │   ├── typography.md
│   │   ├── spacing.md
│   │   ├── radius.md
│   │   ├── elevation.md
│   │   ├── motion.md
│   │   ├── z-index.md
│   │   ├── iconography.md
│   │   ├── accessibility.md
│   │   ├── breakpoints.md
│   │   ├── grid.md
│   │   ├── borders.md
│   │   └── opacity.md
│   │
│   ├── tokens/                   # Tier 1: CSS variable reference
│   │   ├── token-reference.md
│   │   ├── color-tokens.md
│   │   ├── spacing-tokens.md
│   │   ├── typography-tokens.md
│   │   ├── elevation-tokens.md
│   │   └── motion-tokens.md
│   │
│   ├── atoms/                    # Tier 2: Single-purpose components
│   │   ├── button.md
│   │   ├── icon-button.md
│   │   ├── input.md
│   │   ├── textarea.md
│   │   ├── checkbox.md
│   │   ├── radio.md
│   │   ├── toggle.md
│   │   ├── avatar.md
│   │   ├── badge.md
│   │   ├── lozenge.md
│   │   ├── tag.md
│   │   ├── spinner.md
│   │   └── link.md
│   │
│   ├── molecules/                # Tier 2: Composed components
│   │   ├── tabs.md
│   │   ├── breadcrumbs.md
│   │   ├── dropdown-menu.md
│   │   ├── modal-dialog.md
│   │   ├── banner.md
│   │   ├── flag.md
│   │   ├── inline-message.md
│   │   ├── tooltip.md
│   │   ├── form.md
│   │   ├── select.md
│   │   ├── date-picker.md
│   │   ├── pagination.md
│   │   ├── inline-edit.md
│   │   ├── search.md
│   │   ├── popup.md
│   │   ├── progress-bar.md
│   │   ├── side-navigation.md
│   │   └── empty-state.md
│   │
│   ├── organisms/                # Tier 2: Product-specific assemblies
│   │   ├── table.md
│   │   ├── navigation.md
│   │   ├── page-header.md
│   │   ├── content-panel.md
│   │   ├── chat-panel.md
│   │   ├── dashboard-card.md
│   │   └── work-item-header.md
│   │
│   └── patterns/                 # Tier 3: Layout and composition rules
│       ├── canvas-content-flow.md
│       ├── three-column-layout.md
│       ├── responsive-grid.md
│       ├── panel-expand-collapse.md
│       ├── form-layout.md
│       ├── list-detail.md
│       └── error-handling.md
│
├── tokens.css                    # Every CSS variable, with layered token logic
│
├── checks/
│   ├── token-audit.js             # Catches hardcoded visual values
│   └── design-system-drift.js     # Flags stale specs when the system changes
│
├── ai-tooling/
│   ├── templates/                 # Things AI should not invent from scratch
│   │   ├── base-template/
│   │   ├── figma-make-template/
│   │   └── replit-template/
│   │
│   ├── guidelines/                # Short guidance for AI prototyping
│   │   ├── prototyping-guidelines.md
│   │   ├── figma-make-guidelines.md
│   │   └── replit-guidelines.md
│   │
│   └── recipes/                   # Repeatable safe actions
│       ├── dark-mode.md
│       ├── chat-panel.md
│       ├── logo-swap.md
│       └── side-panel.md
│
├── CLAUDE.md                      # Claude reads this before touching UI
└── AGENTS.md                      # Optional shared rules for other agents

❇️ This is the ideal direction.

⭕️ Not the day-one checklist.

I would not expect a team to create all of this in one sprint. Actually, I would be suspicious if they tried.

The point is to let the structure grow with the product.

• When a new component becomes important, write its spec.

• When a pattern keeps showing up in reviews, document it.

• When AI keeps breaking the same shell, create a template.

• When people keep asking for the same change, turn it into a recipe.

• When raw values keep slipping into code, add a check.

That is how the system becomes agentic over time.

Not through one big documentation marathon. 😅

Through repeated decisions becoming reusable infrastructure.

Start small. Please do not turn this into a six-month initiative. 🤨

Small does not mean weak.

And it definitely does not mean giving the agent half of the foundation and hoping it figures out the rest.

For the first version, I would still make the foundation layer complete enough to be useful.

That is the part AI needs before it can make even basic UI decisions.

Where I would stay small is the component and pattern coverage.

So the first shippable version could look like this:

your-project/
├── specs/
│   ├── foundations/
│   │   ├── color.md
│   │   ├── typography.md
│   │   ├── spacing.md
│   │   ├── radius.md
│   │   ├── elevation.md
│   │   ├── motion.md
│   │   ├── z-index.md
│   │   ├── iconography.md
│   │   ├── accessibility.md
│   │   ├── breakpoints.md
│   │   ├── grid.md
│   │   ├── borders.md
│   │   └── opacity.md
│   │
│   ├── tokens/
│   │   ├── token-reference.md
│   │   ├── color-tokens.md
│   │   ├── spacing-tokens.md
│   │   ├── typography-tokens.md
│   │   ├── elevation-tokens.md
│   │   └── motion-tokens.md
│   │
│   ├── atoms/
│   │   └── button.md
│   │
│   └── patterns/
│       └── form-layout.md
│
├── tokens.css
│
├── checks/
│   └── token-audit.js
│
├── ai-tooling/
│   ├── templates/
│   │   └── base-template/
│   │
│   ├── guidelines/
│   │   └── prototyping-guidelines.md
│   │
│   └── recipes/
│       └── dark-mode.md
│
└── CLAUDE.md

This is small, but not fragile.

That is the version I would ship first.

Not a complete agentic design system.

But a complete-enough foundation with a narrow, testable slice of real usage.

A starter prompt to get moving

If you already have a product repo, you do not need to start from zero.

I would use a prompt close to the one Hardik Pandya shared.

Paste this into Claude Code, Cursor, or another AI coding agent at the root of your project:

Audit this project and make the design system LLM-readable.

Step 1: Audit
Scan every CSS/SCSS file. List every hardcoded visual value:
hex colors, rgb/rgba colors, pixel spacing, raw font sizes,
font weights, border radii, z-index values, box shadows,
and transition durations. Group them by category. Count totals.
Report which files have the most hardcoded values.

Step 2: Token layer
Create a tokens.css file with three layers:
- Layer 1: upstream design system tokens (use existing ones
  if the project already uses a design system, otherwise
  derive sensible primitives from the audit)
- Layer 2: project aliases that reference Layer 1 with
  fallbacks, e.g. --color-text: var(--ds-text, #292A2E)
- Layer 3 is the components themselves — they only ever
  reference Layer 2 aliases, never raw values

Include tokens for: colors (text, background, link, border,
interactive states), spacing (at least 8 steps), typography
(font families, sizes, weights, line heights), border radius,
elevation/shadow, z-index, and motion/transitions.

Step 3: Spec files
Create a specs/ directory. Write structured markdown specs:
- specs/foundations/ — color.md, spacing.md, typography.md,
  radius.md, elevation.md, motion.md, accessibility.md
- specs/tokens/ — token-reference.md (master map of every
  CSS variable, its value, and when to use it)
- specs/atoms/ — one file per single-purpose component
  such as button, input, link, badge
- specs/molecules/ — one file per composed component
  such as form, modal-dialog, dropdown-menu, empty-state
- specs/organisms/ — one file per product-specific assembly
  such as navigation, table, page-header, content-panel
- specs/patterns/ — layout and composition rules
  such as form-layout, responsive-grid, error-handling

Each spec follows this template:
1. Metadata (name, category, status)
2. Overview (when to use, when not to use)
3. Anatomy (parts of the component or pattern)
4. Tokens used (which CSS variables it references)
5. Props/API (if applicable)
6. States (default, hover, active, focus, disabled, error)
7. Code example
8. Cross-references (related components or patterns)

Only spec components and patterns that actually exist in this project.

Step 4: Audit script
Create checks/token-audit.js (or .sh) that:
- Scans all CSS files for hardcoded values
- Suggests the correct token for each violation
- Prints file, line number, violation, and suggestion
- Returns exit code 1 if any errors are found (CI-ready)
- Distinguishes errors (hardcoded colors, spacing) from
  warnings (raw durations, uncommon values)

Step 5: Replace hardcoded values
Go through every CSS file and replace hardcoded values with
the tokens from Step 2. Every color:, background:, padding:,
margin:, gap:, border-radius:, font-size:, font-weight:,
box-shadow:, z-index:, and transition: should reference a
var(--token). No raw values should remain.

Step 6: Project instructions
Add a section to the project's AI instruction file (CLAUDE.md,
AGENTS.md, .cursorrules, or equivalent) that says:

"Before writing or modifying any UI code, read the relevant
spec file in specs/. Use only tokens from tokens.css. Run the
token audit script before committing. Zero errors required."

Run the audit script at the end and confirm zero violations.

What I like about this prompt is that it does not ask AI to magically “make the design system better.”

It asks for specific outputs:

a token layer,
structured specs,
an audit script,
cleaned-up hardcoded values,
and project instructions for future AI sessions.

That is a much better starting point than another abstract design system discussion.

The real team habit: capture decisions when they happen

The best AI-ready design systems will not be built by one big documentation sprint.

They will be built through better habits.

• When a designer says, “We do not use modals for this,” add it to the pattern spec.

• When an engineer says, “This generated layout breaks our shell,” update the template.

• When accessibility feedback repeats, add it to the component metadata.

• When AI invents a token, add an audit rule.

• When a product team introduces a new recurring workflow, create a recipe.

This is the practice:

Every repeated correction is missing system knowledge.

Capture it once.

Then let the system reuse it.

The goal is not to make AI more creative

This might sound strange, but I do not want AI to be creative everywhere.

🔺 I do not want AI inventing new spacing.
🔺 I do not want AI improvising button hierarchy.
🔺 I do not want AI creating a new modal pattern because it “looks modern.”
🔺 I do not want AI guessing brand colors from memory.

I want AI to be constrained where consistency matters.

And useful where exploration matters.

✖️ Strict with tokens.
✖️ Strict with accessibility.
✖️ Strict with core components.
✖️ Strict with product shell.
✔️ Flexible with concepts.
✔️ Flexible with layout exploration.
✔️ Flexible with content alternatives.
✔️ Flexible with early prototypes.

That balance is the work.

Not full control.

Not full freedom.

Designed freedom.

Why this matters now

AI is pushing design systems into a new role.

They are no longer only a place to store reusable UI.

That means design system work becomes more strategic.

🔸 Less about documenting what already exists.

🔶 More about encoding how the product should be built.

🔸 Less “Here are our components.”

🔶 More “Here is how our product thinks.”

And for me, that is the interesting part.

Because the teams that benefit most from AI will not be the ones who generate the most screens.

They will be the ones who build the strongest context.

So maybe the real question is not:

Is our design system ready for AI?

Maybe it is:

How much of our design judgment is still trapped in people’s heads? 🧠

That is where I would start.

Start by writing down the decisions AI keeps guessing.

• Turn them into specs.

• Connect them to tokens.

• Package repeated tasks into recipes.

• Use templates for stable structure.

• Add audits where consistency matters.

• Teach the team how to use it.

That is how a design system becomes ready for the agentic age.

Not by becoming bigger.

By becoming clearer.

Come & join me on LinkedIn. ☕️✨

A few weeks ago, I kept thinking about a strange gap in how we design AI products.

Not only the big “ChatGPT-style” products.
I mean the smaller AI moments that are now showing up inside everyday tools:

a smart suggestion,
an AI-powered workflow,
a generated summary,
an agentic action,
or simply one moment where a human and AI need to work together.

And this is where I started seeing the problem. ⚠️⁉️

Currently, when teams design an AI-native feature, they often move from:

1️⃣ AI-native design need
A new feature, or a specific moment where human–AI collaboration needs to happen.

to:

2️⃣ Visual design system
Components, tokens, layouts, UI states, accessibility, and all the interface rules we already know how to reuse.

to:

3️⃣ Product experience
The final AI-powered feature people actually use.

But something is missing in the middle. 👀

The missing step was not visual. It was behavioral.

Before we decide how the interface should look, we need to decide how the AI and the human should work together.

Should the AI suggest, ask, or act?
When should a human approve something?
How should uncertainty be shown?
What happens when the AI gets something wrong?
How much control should the user have?
Who is responsible for the final decision?

These are not visual design system questions.

They are behavior questions.🤖👩

That’s where messy AI experiences quietly start

If every team answers them from scratch, feature by feature, things can quietly become messy.

• 🔺🔺🔺

• One AI feature asks for confirmation.
  Another acts automatically.

• One explains uncertainty.
  Another hides it.

• One gives users a way to recover.
  Another leaves them stuck.

So this became the question for me. 👇👇👇

What if AI products need a behavior layer before the visual design layer?

That was the starting point for my Behavioral Design System. 🤖✨

A source of truth for designing, documenting, and reusing human–AI interaction patterns before UI decisions.

The visual above is the simplest way I currently explain it:

The Behavioral Design System does not replace the visual design system.

It sits before it.

It helps teams define the collaboration first, so the final product is not only visually consistent, but behaviorally consistent too.

What I mean by a Behavioral Design System

🎨 A traditional design system helps teams reuse interface decisions.

❇️A Behavioral Design System helps teams reuse human–AI collaboration decisions.

🎨 In a visual design system, the reusable unit is often a component.

❇️In a Behavioral Design System, the reusable unit is an interaction pattern.

Not just:

What should this look like?

But:

How should this moment work?

For example, if an AI assistant is about to take an action:

• Should it ask first?

• Should it show a preview?

• Should it explain why it chose that action?

• Should the user be able to edit before confirming?

• Should there be an undo path?

These are not just interface details.

They are behavior decisions.✔️

And if those decisions repeat across the product, they deserve to be documented as patterns.

Not a component library.
Not another AI UX checklist.
More like a shared place for the moments where humans and AI need to coordinate.

Then I gave each interaction pattern its own DNA

One thing I wanted to avoid was turning this into a random list of AI UX ideas.

Because AI interaction patterns can get messy very quickly.

A pattern can support trust.
It can happen before an AI output.
It can appear inside a chat interface.
It can belong to an assistive AI model.

So each pattern is classified in four lenses.

1. The first lens: Behavior Principle

This describes the experience quality the pattern supports.

This helps teams understand the purpose behind the pattern.

2. The second lens: AI Collaboration Model

This describes the relationship between the human and the AI in that moment.

This matters because the same pattern may behave differently depending on how much agency the AI has.

3. The third lens: Task Moment

This describes where the pattern sits in the interaction timeline.

Timing matters a lot in AI interaction. A clarification before output feels very different from a recovery option after a wrong result.

4. The fourth lens: Surface

This describes the product context where the pattern appears.

This structure makes the library easier to browse, but also more honest.

Because the same AI pattern can behave very differently depending on where it appears, how much control the user has, and what risk is attached to the task.

Together, these classifications help people browse the library, but also think more clearly when documenting new patterns.

Then I turned it into something people can actually use | a Notion system

I’m building this as a Notion-based Behavioral Design System.

The goal is not to make a huge academic library.
The goal is to create something practical enough that designers, PMs, engineers, and AI builders can actually use it.

I kept the Notion structure simple on purpose

The system currently has four main areas.

👋 Start Here

This is the onboarding layer.

It explains how the system works, how patterns are organized, and how someone can add a new pattern.

Because if a system needs a long explanation before people can use it, it is already too heavy.

🎲 Pattern Playground

This is the more exploratory way into the library.

Instead of starting from a big database, you can begin from what you are designing:

a behavior principle,
a task moment,
an AI collaboration model,
or a product surface.

It is meant to help people find relevant patterns faster, especially when they do not yet know the exact pattern name.

💎 Interaction Pattern Library

This is the main database.

It is where all the human–AI interaction patterns live.

Each pattern has metadata, status, documentation, examples, and implementation notes. The idea is to make patterns easy to filter, compare, reuse, and evolve.

🧠 Governance

This is the maintenance layer.

Because a pattern library should not just grow forever.

Some patterns should be reviewed.
Some should be improved.
Some should be merged.
Some should be retired.

The goal is not to make the system bigger.
The goal is to keep it useful.

Then I started adding real patterns

I started by documenting patterns from existing AI products and AI UX references, then translating them into my own structure.

Not as final “rules.”
More like reusable starting points.

Each pattern can be opened as its own documentation page with examples, notes, and implementation references.

And this is where the Notion system becomes useful: the patterns are not just floating ideas. They are organized, searchable, and ready to connect back to design work.

And just to be clear, this is not a rulebook

I do not see this as a fixed framework.

It is not meant to be the final answer to AI interaction design.

It is also not meant to replace judgment.

A pattern can guide a team, but it cannot decide everything for them. Context still matters. Risk still matters. The product’s role still matters. The user’s mental model still matters.

For me, the value of this system is not that it removes thinking.

It creates a better starting point for thinking.

Instead of asking every team to begin from a blank page, it gives them a shared language. ✔️

Here is the pattern.
Here is when it helps.
Here is what can go wrong.
Here is how we usually handle it.
Here is the design reference.
Now let’s decide if it fits this product moment.

That is the kind of design system I want for AI.

Why I’m sharing it

I’m sharing this because I think many teams are about to face the same problem.

👫👬😫😰😱😓🧑‍🤝‍🧑👭

AI features are moving fast.
Teams are experimenting.
Patterns are emerging.
But the way we document and reuse those patterns is still immature.

A lot of AI design knowledge is scattered across articles, product teardowns, internal decisions, and individual designer judgment.

I wanted to start turning that scattered knowledge into something more structured.

👫👬🤗😇😊🥲🧑‍🤝‍🧑👭

Something teams can browse.
Question.
Reuse.
Improve.
Connect to design files.
And eventually govern.

It is still early.
It will evolve.

But I believe this kind of behavioral layer will become more important as AI products become more agentic, more embedded, and more capable of acting on behalf of users.

The more agency AI has, the more carefully we need to design the moments around it.

Not just the interface.
The behavior.

For me, the bigger idea is this

For years, design systems helped us create visual consistency.

Now AI products need behavioral consistency too.

🔴 Because the experience is no longer only about what users see on the screen.

🟢 It is also about what the system does, when it acts, how it explains itself, how it asks for permission, how it handles uncertainty, and how it gives control back to the human.

There’s a moment every product designer knows but nobody really talks about.

You’ve spent weeks on a feature. The Figma file is clean. The components are organised. The flows make sense. You feel good about it. You hand it off.

And then — sometimes hours later, sometimes days — an engineer sends you a message.

And you sit there, staring at your design, realising you never thought about that. Not because you’re a bad designer. But because nobody ever gave you a structured moment to think about it before the build started.

That moment — that quiet, slightly embarrassing pause — is what Edgely is about.

The problem nobody admits

I’ve been a product designer long enough to know that edge cases are the part of the job that falls through the cracks most consistently.

Not because designers are lazy. Not because engineers are unreasonable. But because the tools we use — Figma, Notion, Jira — are built around the happy path. They’re optimised for showing what should happen, not for systematically thinking through what could go wrong.

So the edge case thinking happens in the worst possible moments:

• In the middle of a design review,

• when someone asks a question you haven’t prepared for.

• During a sprint,

• when an engineer is halfway through building and discovers a state you haven’t designed.

• After launch, when a real user hits a scenario nobody anticipated.

I kept watching this pattern repeat. In my own work. In teams I worked with. The same conversation, the same awkward pause, the same scramble to design something quickly that should have been thought through weeks earlier.

And I kept thinking — there should be a tool for this. A small one. Focused. That forces you to think about edge cases before you hand off, not after.

Why I built it myself

I looked for that tool. It didn’t really exist.

There are frameworks and checklists scattered across design blogs. There are sections in some design systems documentation. But there was no dedicated, focused place to actually do this thinking — visually, quickly, before a handoff.

So I built it.🤓👩‍💻

Not because I’m a developer — I’m not, really. But because I’ve started to believe that designers who can ship small tools have a kind of superpower. You stop waiting for someone else to solve your problem. You just solve it.

Edgely is what came out of that belief.

What it actually is

It’s a single-page web app. No account. No backend. No price.

You get a two-axis canvas — likelihood on one axis, impact on the other — and you drag your edge cases into four quadrants:

• Ship now — critical and likely. Must be designed before handoff.

• Next release — critical but unlikely. Plan it soon.

• Nice to have — low impact but common. Address when you can.

• Backlog — low impact and rare. Documented, but deferred.

You can click anywhere on the canvas to add a card. You can upload a markdown file and it parses your existing notes into draggable cards. When you’re done, you copy a structured markdown output — ready to paste into a Figma annotation, a Jira ticket, or a PR description.

👉edgely👈

The whole interaction takes about three minutes for a component you might have been designing for days.

That’s the point. Not a big process. Not a workshop. Just a quiet, structured moment of honest thinking before you say “it’s ready.”

What I learned building it

I designed and built Edgely entirely with the help of AI — specifically Claude, which I used as a development partner throughout the process.

I want to be honest about that, because I think there’s still a weird stigma around it.

Using AI to build didn’t make this less mine. Every product decision — the interaction model, the naming, the colour system, the animation timing, the way cards snap into quadrants — those were all deliberate choices I made, iterated on, and changed my mind about dozens of times.

What AI did was collapse the distance between having an idea and having a working version of it. For a designer who thinks in products but doesn’t think in code, that distance used to be enormous. Now it isn’t.

That changes something fundamental about what designers can build. And I think we’re only at the very beginning of understanding what that means.

Try it

Edgely is free. Open source. No account. No cookies.

👉 edgely-teal.vercel.app

🔗 github.com/KhoshnazKazemian/edgely

If you’re a designer or engineer who’s ever been caught off-guard by an edge case you should have caught earlier — this is for you.

And if you use it and have thoughts, I’d genuinely love to hear them. This is the first of what I hope are many small tools. Each one designed to solve one real problem in product work, extremely well.

— KK

Subscribe now

👋 Come and say Hi in LinkedIn

Edgely is part of a series of focused product tools built by KK. Design for what hasn’t happened yet.