Procedural Design: The Moment Design Became Code
There's a shift happening in the design industry that we haven't fully named yet. I want to try.
For most of my 15+ years in this field, design has been inseparable
from the tools you use — Photoshop, Illustrator, Sketch, Figma. The
artifact is the design. You open a file, you push pixels, you export.
Repeat.
But something is changing. And I think the best word for it is
procedural.
Design Has Always Been a Communication Problem
Before we get to the "procedural" part, let's step back.
There's a tension design has always carried: aesthetics versus
communication. A beautifully crafted visual with no clear message is
art — it can hang on your wall and make you feel something. That's
valid. But in UX and product design, we've made a deliberate choice:
we're not making wall art. We're building interfaces that help real
people accomplish real tasks.
That shift — from aesthetics toward communication — brought us things
like hierarchy, color contrast, layout systems, and consistent
typography. It turns out that when you strip design down to how well
does this communicate, you get something surprisingly mathematical.
Hierarchy becomes a formula. Contrast becomes a ratio. Spacing becomes
a scale.
That's the seed of what comes next.
Enter Terraform. Enter Houdini. Enter Procedural Design.
If you work in development, you know Terraform. You describe your
infrastructure in code — servers, networks, databases — and you can
spin it all up, tear it down, reproduce it exactly, anywhere. The
artifact is not a running server. The artifact is the code that
describes a running server.
If you work in 3D, you know Houdini. Instead of sculpting a mountain by hand, you write a procedural graph — noise functions, erosion parameters, height rules — and the software generates the mountain for you. Change one variable, regenerate. The geometry is an output, not a source file.
I believe design is entering the same moment.
The Four Buckets
Here's how I've started thinking about it. Any design can be described
as the intersection of four distinct layers:
- Styling — colors, typography, spacing, shadows, mood
- Content — copy, messaging, hierarchy, information architecture
- Inspiration — brand references, visual context, competitive landscape
- Technical — target device, breakpoints, component library, accessibility requirements
Right now, when a designer opens Figma, all four of these live inside
their head and inside their hands. The output is a .fig file — a
snapshot of one particular set of decisions.
What if instead, you could feed all four of these buckets into a
system — with natural language — and get a design back? Not as a
replacement for judgment, but as a starting point you can always
reproduce.
This Is Already Possible
With the Figma API and modern AI, this is not a hypothetical.
You can already write a plugin — or interact with the API directly —
to describe a layout in natural language, separate the content layer
from the styling layer, pass in a design token library, specify a
target device and breakpoint, and generate shapes, text, and layout
from those inputs.
The result is non-destructive by nature. You're not editing a file.
You're executing a spec. Change the styling bucket, re-run. Change
the target device, re-run. The design is reproducible because it's
a description, not an artifact.
This is procedural design.
What This Changes (and What It Doesn't)
Let's be honest about what gets disrupted here.
The ability to operate tools — to use Figma, Illustrator, Sketch —
has never been the actual skill. It's been a proxy for the skill. The
real skill is the critical eye: knowing whether a hierarchy is working,
whether the visual weight is off, whether the message lands. That
judgment doesn't come from the software. It comes from years of
training your eye.
Procedural design doesn't replace that. It replaces the hours you
spend translating decisions into pixels.
What it does change: volume. When the mechanical barrier goes down,
more design gets produced. Much more. Some of it will be good. A lot
of it won't be. The ability to distinguish between the two — to look
at a generated layout and say "the hierarchy is broken here, the
contrast fails here, this doesn't communicate the thing it needs to
communicate" — becomes the rare and valuable thing.
A New Opportunity for Designers
Here's the part I want you to hold onto.
Every major tool transition in design history — from physical paste-up
to desktop publishing, from print to web, from handcoding to visual
tools — felt like a threat before it became an opportunity. In every
case, the designers who came out ahead were the ones who understood
the underlying principles well enough to use the new tools
intentionally instead of reactively.
Procedural design is that next transition.
And if you're reading this, you're early. You have time to ask: what
are the inputs that produce great design? How do you describe a
strong hierarchy in words? How do you articulate a color mood before
a pixel is placed? How do you separate what a design needs to
say from how it needs to look?
These are the skills that turn a designer into a design author —
someone who can write the recipe, not just cook the meal.
The tools are arriving. The question is whether you'll be the person
who defines how they're used.
I think you will.
I'm building a lot of this thinking into real projects — design
systems, AI tooling, and a few experiments with the Figma API. If
this resonates, drop a comment or follow along. I'd love to compare
notes.
Top comments (0)