AI Changed How I Think About Design Artifacts
May 30, 2026
As AI becomes more capable, I keep seeing the same questions surface in design circles. Should designers learn to code? Will design tools become obsolete? Will AI eventually create interfaces on its own?
Those are useful questions, but I found myself more interested in a different one: what exactly are we creating when we create design artifacts?
This question came from experimentation more than theory. I noticed that when I used AI with messy design files, the outcomes were messy. When I used AI with structured artifacts, clear components, thoughtful hierarchy, naming conventions, constraints, and systems thinking, the outcomes became significantly better.
At first, this felt obvious. Of course a better input creates a better output. But the more I observed it, the more uncomfortable the implication became. For years, our design artifacts have primarily been optimized for humans. Humans are forgiving. Developers infer intent from imperfect files. PMs understand the product story behind the work. Designers remember what a frame was supposed to mean, even when the file itself is no longer clean.
A stakeholder can look at a polished screen and understand the direction, even if the underlying file is chaotic. The visual artifact can still do its job because the human audience fills in the gaps.
AI does not work this way.
A design can look visually correct while containing very little usable structure. Detached components, broken Auto Layout, visual hacks, inconsistent spacing, and layers named Rectangle 42 may look like minor imperfections to a human reviewer. But to AI, these are not minor. They become source material.
That changed how I think about design tools and design artifacts. The question is not simply whether AI can generate a screen. The more important question is whether our artifacts describe the system clearly enough for AI to participate meaningfully.
This does not mean design disappears. It does not even mean Figma disappears. But it may mean the role of the design artifact is changing. It is no longer only a visual reference or a collaboration canvas. It is becoming a bridge between human intent, system constraints, design components, accessibility requirements, and implementation.
This changed how I think about artifacts beyond screens.
I realized that what I increasingly needed was not another static deliverable. I needed artifacts that could communicate intent, constraints, relationships, and behavior more explicitly.
That realization is partly why I started building Toybox.
Not because patterns, playbooks, prompts, and reusable artifacts are new. But because increasingly, these artifacts are consumed by both humans and machines.
A good pattern is no longer simply documentation.
It becomes input.
A reusable playbook becomes something an engineer can implement, a PM can reason about, another designer can extend, and increasingly, something AI can interpret with far more reliability. That is the intent behind pieces like the Accessibility Annotation Playbook and the Idempotent Bulk Action Pattern.
Ironically, this has made me design differently. Sometimes I start from the design system instead of drawing from scratch. Sometimes I sketch ideas before touching a design tool. Sometimes I create coded prototypes earlier because the behavior matters more than the static frame (for example, this Demo Days reference prototype). Sometimes AI generates the first pass, and my role becomes less about drawing every box and more about shaping the structure, constraints, and judgment behind the experience.
The artifact itself feels less important than the intelligence behind it.
Increasingly, our artifacts are not only documentation. They are becoming infrastructure.
The question no longer feels like, “Can AI create screens?”
The more interesting question may be, “Can our artifacts describe systems clearly enough for humans and machines to work together?”
Related writing
-
Craft notes
Three Labels, Six Surfaces
The smallest interaction rule I have, and the one I find myself repeating in every bulk-action review.
-
Craft notes
The Feature I Keep Refusing to Ship
A note on subtraction — why I write up the features a product pointedly does not have, and why the next reorg is the reason.
-
Craft notes
Notes from the Reversible Queue
Why I keep writing the same state machine into every enterprise product, and why Undo is the feature I argue hardest to keep.