From artifacts to instruments

For as long as I've been a designer, the object has been the endpoint. You shaped an artifact (a poster, a product, an identity) and its value was fixed the moment it left your hands. The craft was in the resolution of the final thing.

That assumption is quietly breaking. What's worth designing now is often not the artifact but the instrument that makes it: the set of rules that keeps producing outputs long after you've stopped touching them.

Which feels new, and isn't. We have been building our own instruments for centuries.

We've been here before

Gutenberg's invention wasn't the press. Screw presses were ancient. It was what sat upstream of the page: a letter cut into a steel punch, struck into copper to make a matrix, set into a mould that could cast that letter without limit. What followed is the part that gets left out. Punchcutters organized into houses whose only product was the matrix. They sold to typefounders, who cast type and sold to printers. Three trades, three steps removed from the printed page, and the houses that held the instruments held the trade.

It happened again in 1964, when Karl Gerstner published Designing Programmes: instead of solutions for problems, programmes for solutions. A designer-defined rule set that determined the outcomes rather than the outcomes themselves.

What's different now

So instruments built for the sake of producing artifacts is a tale as old as time. We've been commercializing them forever. What's different now is the fusion: the tools are being built by the same people responsible for the object. That configuration is rare. Knuth is the clearest case: he was writing a book, hated how it printed, and spent ten years building the typesetting system and then the typefaces to set it.

The deliverables we're responsible for are moving up a level of abstraction. Historically that happens when the volume required exceeds what hands can serve, or when building the abstraction costs less than producing the deliverable itself. Right now it's the latter.

Designers who relied on Figma, Illustrator, and After Effects are building their own tools instead: narrow ones, aimed at a single problem they actually have.

Earlier this year I designed a brand for a company with no design team and no budget for ongoing production. I knew that going in, so I built part of the visual identity as a formula: fixed rules, a small set of variables. When they came back needing launch assets, I didn't open Figma. I built them a tool. Background, color, text, grid, format. Every control mapped to something that actually needed to move. If a variable didn't need to move, it didn't become a control. That's what keeps the output on-brand no matter who's driving it. The brand system stopped being a document. It became the product.

What constraint costs

This comes with implications on how we design. I'm most interested in what it means for brand systems. In order for this to work, or better yet work at scale, constraint is needed. However, good branding doesn't always follow strict requirements. So as designers we now have to consider whether our visual ideas can be built as systems, ones that translate cleanly into requirements for a specialized tool. And if they can, are we compromising too much of what makes the brand special in the process? Are we creating guardrails as a scapegoat, rather than as a tasteful and systemic solution to a brand problem?

I believe there are still ways to build these specialized tools without losing ambition. I think it starts by recognizing it's even a possibility from the very beginning of the brand building exercise, rather than retrofitting one at the end. After all, as designers, part of our domain is understanding what a medium can and can't do, then working within those constraints to deliver the best output we can. Now that boundary has moved. A year ago most of us would have put a tool like this well outside it.

Still early

I believe we're still early. The LLM models are only now becoming robust enough that this can be done consistently, without much time spent debugging or QAing the instrument. I'm seeing a wave of designers adapting to this quickly. I'm not sure we've named the shift yet, but they certainly see its potential. Justin built a Figma plugin from scratch to make layout creation faster. Jarek built a web tool from scratch to experiment with dithering and other shaders.

Justin@jayrizpopView on X

Jarek@jarekceborskiView on X

Neither is an instrument made for a client. But they show designers starting to build their own tooling, and I wouldn't be surprised if, once this becomes obvious, designers start adding tooling to their client deliverables.

The price

Ultimately what makes this possible is the price. Building an instrument used to require a decade, a foundry, or a computer science degree. Now it costs a weekend and a subscription. That's the shift: not that designers can build their own tools, but that it stopped being a specialization.

The instrument layer has never stayed distributed for long, though. It gets standardized, sold, and leased back to the people who briefly owned it. We know how this ends. We just don't know when.