The Future of Design, Revisited
Two years ago I gave a talk called “The Future of Design.” I didn't have answers. I had a list of things that felt wrong about how design worked, and a guess at what each one should become.
I'm revisiting that list because the guesses aren't speculative anymore. Every direction on it has been answered in working tools I use every week.
Then
This is what I said design was, and what it should become:
- Siloed → Integrated
- Static → Dynamic
- Proprietary → Open-source
- Manual → Automated
- Rigid → Adaptive
- Lossy → Lossless
- Resource-intensive → Sustainable
I had no proof. I had conviction and a career spent watching design get treated as expensive, as a bottleneck, as the thing you cut when the budget gets tight.
Now
Siloed → One shared spec
Tokens, component contracts, annotated HTML. The intent travels without needing me in the room to explain it.
Static → Rebuilds with the project
The designer is still the gatekeeper of the aesthetic. But everyone can update what happened earlier and regenerate. Update the research, the design follows.
Proprietary → Open & collaborative
The tools and the formats should be open enough that design can be read, extended, and maintained by the whole team.
Manual → Evidence-backed
Design is an execution on decisions made earlier in the process. It should be obvious why something is designed this way. Not “the machine does it for me” but “you can trace every decision back to its reason.” A thousand lines of decision territory, all linked.
Rigid → Commit and regenerate
Be comfortable with partial representation. Come back, iterate, regenerate. Design doesn't have to be exhaustive upfront to be rigorous.
Lossy → Nothing lost in translation
The prototype is HTML and CSS. The tokens come from the live site. The Figma file is generated from the same data, not drawn from scratch. Three-year-old Figma libraries that nobody updates don't live there anymore.
Resource-intensive → Discover once, rebuild cheap
Make the initial discovery thorough, then make everything downstream regenerable. The cost of a wrong guess collapsed. You can afford to guess more often and learn faster.
The specification is the work
All seven of those arrows point at the same thing: design should live as a specification, not a picture.
If design lives as a spec, the visual representation follows from it. Storybook, HTML prototype, Figma, whatever you want. The format is a rendering of the data, not the data itself. You're not locked into one tool, and you're not rebuilding from scratch when you switch. The workman blames his tools. The specification doesn't care which tool renders it.
This changes what a “design deliverable” means. It's not a Figma file. It's the decisions: tokens, component contracts, content models, interaction patterns. All structured, all traceable, all regenerable. The Figma file is one output. The HTML prototype is another. They come from the same source. Change the source, both update.
The specification is the work. The visuals are what fall out of it.
Generalist to specialist
The first version of the tools I built tried to do everything. A generalist agent that pulled from everywhere and attempted to be helpful across the whole surface. Too broad, too shallow, too much noise.
What works is specialists. An audit agent that only does audits. A prototype agent that only builds prototypes. A Figma agent that only pushes to Figma. Each one does its thing well and passes structured output to the next. The orchestration holds the complexity so I don't have to.
Same lesson design teams learn. A generalist stretched across eight workstreams produces eight mediocre things. A specialist given one clear problem produces one thing you can ship.
The pipeline
People
│
discovery
extraction
taste
│
v
Audit → Analyze → Prototype → Handoff
│
visual spec
│
v
Compiler → Running Site
People in, decisions out. Discovery, extraction, taste. Then: audit the current state, analyze the findings, prototype from the analysis, hand off in a format the next system expects. The handoff becomes a visual spec, and the visual spec feeds a compiler that produces the running site.
On disk, the specification is a folder. Structured decisions, tokens, component contracts, content models. Each step writes to it, each step reads from the last. Something like this:
project/
0-context/ ← research, stakeholder notes, analytics
1-audit/ ← screenshots, component inventory, findings
2-analyze/ ← opportunity backlog, scored and prioritized
3-prototype/ ← HTML pages, token pipeline, Storybook
4-handoff/ ← visual spec (YAML, design.md, assets)
The prototype is HTML and CSS. The Figma file is generated from the same data. Storybook documents it. The handoff layer (a design.md and structured YAML) is what the next system, or the next person, reads. It's not a Figma link. It's a spec that any tool can consume.
Every step is traceable. Every decision has a number and a link. Bad decisions are learning opportunities, not things to delete. Run it again with new inputs, the whole tree regenerates.
How it feels
Two years ago, design was very tight. Fixed scope, prove your value, fight for your hours.
Now every direction on that list has a working answer. That makes me feel vindicated and powerful. Also creative. Ironically, all of this structure makes me feel more creative, not less. The mechanical parts moved to the background, and what's left is the judgment, the taste, the part of the work I got into this for.
Some designers miss the directness of working with their hands on the material: dragging, nudging, seeing the thing change under their fingers. That's not nostalgia. That intimacy is where taste lives, and losing it is how feel goes to die. The tension is real: how do you connect with your work at that level when the work is specifications and pipelines? You find new ways. The closeness moves from the pixel to the decision. And that's what design does: design our own tensions.