Hi there, Matt here.
Last year I published an essay on a new paradigm of design systems I called a Design API. The gist is this: let’s structure our design system more like software APIs, so that getting information into and out of them is fully automated and extremely flexible.
Since then, the concept has been on a constant simmer on the back burner of my brain. The longer it cooks, the more excited I get. I think this really is the future of design systems. And like any new frontier, it certainly doesn’t explore itself.
So today I’m sharing my first attempt at actually building a design API. You can skip straight to the good part and play with the API here; the essay goes into detail on how (and why) it works (and doesn’t).
First, a song. Bing and Ruth has been one of my favorite neo-classical groups for ages. Their upcoming album is shaping up to be another stellar entry in their catalog: Species is an homage to that staple of 1970s new wave, the Farfisa organ. You can check out a track from the new record on Bandcamp.
Now, on to the essay.
A few months ago I wrote an essay titled “Design APIs: the evolution of design systems”. The API model for design systems resonated with design systems practitioners. The response blew me away.
Since then, I’ve had lots of conversations (and one podcast) about the concept of a design API. One question comes up almost every time: what does a design API actually look like? Good question.
So I built one. It’s up and running at https://matthewstrom.com/api. It’s very rudimentary, but it makes an excellent proof of concept. In this essay I’ll describe how it works, how I built it, and what it can (and can’t yet) do.
How it works
My design API consists of a few libraries and frameworks, connected by pieces of my own code:
- The foundation of the API is an Express.js application, running as a serverless function via Netlify Functions.
- The API accepts and responds to JSON queries, using GraphQL to interpret requests and compose responses.
- The application uses Theo to read and compose design tokens on the fly.
I won’t go through the technical implementation of those libraries and frameworks in this essay, and after this point they’re not that important. I wrote a companion piece for this essay, and CSS-Tricks was kind enough to publish; check out that article if you’re interested in the nuts and bolts. If you’ve never written a line of code, keep reading — let’s take a more abstract look.