DEV Community: Luis Vargas

Procedural Design: The Moment Design Became Code

Luis Vargas — Sun, 22 Mar 2026 16:59:13 +0000

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.

I got tired of bloated React libraries, so I built two tiny ones

Luis Vargas — Sat, 21 Mar 2026 13:30:15 +0000

I've been building React apps for years, and two things kept frustrating me:

Every animation library I tried was either too heavy, caused unnecessary re-renders, or was painful to sequence. And every date picker pulled in date-fns or moment.js just to format a date.
So I stopped looking and started building. The result is ReactZero — a family of zero-dependency React primitives that are tiny, accessible, and easy to drop in.

Here's what I've shipped so far:

@reactzero/flow — animation orchestration for React

Most animation libraries in React drive animations through state, which means every frame triggers a re-render. @reactzero/flow skips all of that by running animations directly on the browser's compositor thread via the Web Animations API.

The API is built around composable primitives:

import { useSequence, animate } from "@reactzero/flow";

function Card() {
  const box = useRef(null);

  const { play } = useSequence([
    () => animate(box.current, [{ opacity: 0 }, { opacity: 1 }], { duration: 300 }),
    () => animate(box.current, [{ transform: "translateY(8px)" }, { transform: "translateY(0)" }], { duration: 200 }),
  ]);

  return <div ref={box} onClick={play}>Click me</div>;
}

A few things I haven't seen done well elsewhere:

Adaptive degradation: automatically slows or skips animations based on device capability and frame rate
True cancellation: finished always resolves, never rejects. No try/catch needed
Scroll-driven animations: uses native ScrollTimeline when available, with a clean fallback
Reduced motion: provider-level policy system (skip, reduce, crossfade, respect)

npm install @reactzero/flow

🔗 GitHub · Docs

@reactzero/datepicker — accessible date picker, no date library required

12KB gzipped. Zero dependencies. WCAG 2.1 AA.
I tried every popular React date picker and they all shared the same problems: heavy dependencies, hard to customize, and accessibility treated as an afterthought.

@reactzero/datepicker uses only native Intl and Date APIs — no date-fns, no moment, nothing extra.

import { DatePicker } from '@reactzero/datepicker';
import '@reactzero/datepicker/styles';

function App() {
  const [date, setDate] = useState(null);
  return <DatePicker value={date} onChange={setDate} placeholder="Select date..." />;
}

If you want full control over the UI, the headless hooks give you complete ARIA compliance without any of the default styles:

import { useDatePicker } from '@reactzero/datepicker';

function MyDatePicker() {
  const { state, isOpen, getGridProps, getCellProps, getTriggerProps } =
    useDatePicker({ locale: 'en-US' });

  // Build whatever UI you want
}

Ships with 10 built-in themes, 3 density modes, range picker, datetime picker, RTL support, and keyboard navigation out of the box.

npm install @reactzero/datepicker

🔗 GitHub · Live Demo

The idea behind ReactZero

Both packages share the same philosophy: zero runtime dependencies, small bundle, accessible by default, easy to style.

I'm planning to keep adding primitives to the family under that same promise.

If either of these solves a problem you've had, a ⭐ on GitHub goes a long way — it helps other developers find them.

And if you run into anything broken, unexpected, or just have feedback — issues and PRs are very welcome. This is early and I genuinely want to know how it holds up in real projects.

Thanks for reading 🙏

motiondesignlv (Luis Vargas) · GitHub

Sr .Product Designer / Ux Engineer. motiondesignlv has 34 repositories available. Follow their code on GitHub.

github.com