Why context systems
Field notes from the future of design and AI tooling
The spark
About a week ago I wrote my most impactful Linkedin post – a random thought about context systems, which caught a roaring 180 reactions and 18 comments, some from actual humans!
On the heels of this success, I’ve decided to launch this publication that explores giving context to agents for the purpose of product design and development.
Let’s get started.
The hunch
Context systems are not an abstraction above or inclusive of design systems, they’re a notion to replace them.
Smarter people than me are already thinking about context-based design systems, but my gut tells me that design systems as a concept do not seem to make sense for the LLM context layer. At the very least not in their current form.
Before we get too ambitious with hot takes and bold predictions, let’s paddle-back a decade or so ago to reassure you that I am one of you.
Before
I first heard the term design systems at Smashing Conf Barcelona in 2015.
There, Jina A. talked about how Salesforce’s design team had component pairs synced up in both Sketch (I think) and code, how their designers and devs worked together and how it was all interwoven with this CI/CD magic. They called it the Lightning Design System and I could see why. It was nothing short of amazing – all of these were very novel concepts.
Back then, most of us worked with tools and tactics that now feel like something from the dark ages.
Ten years later I taught a course on the subject. Looking at my course material now, design systems have become a precious tool that permeates most layers of design work. They solve important systematic problems and serve as an interface with our programmer peers. The better ones also guide us through the maze of interaction patterns and establish useful constraints.
After
A few weeks ago, I tried Claude Design when it came out and I was initially pleased to see the first step was “upload your design system” – a promising start.
However, it quickly became apparent that sourcing your design system from a Figma library is an absurd thing to do. It was not only technically complex and expensive (combing through 10,000 layers of semi-semantic geometry via an MCP server is not very efficient or easy to do) but also felt oddly pointless in terms of purpose.
Our design system in Figma carried a lot of dead weight and presentation that wasn’t meaningful to the context window of a chat session. Figma libraries often include a lot of meta info, WIP and future work, annotation – all optional context or irrelevant for the LLM. You might say that this is a housekeeping issue – why not just optimize the library? Why carry this dead weight in the first place?
Ultimately the things people need will always be fundamentally different from what the machine needs in order to infer the necessary context, guidelines and building blocks to produce good design.
Curating a second Library set for Claude quickly became a chore and concerns around drift and maintenance naturally popped up.
This can’t be the way to do it.
The changing problem
The heart of the issue is that design systems evolved as a tool for humans to manage bits of abstractions inside design software and development frameworks, as well as serving as a collaboration layer between the two. None of this seems to be inherently useful for the problem of “building software with AI”.
If we started anew today with all of these new tools and practices at our disposal, without knowing what design systems are, would we end up with them again? From first principles, I don’t think the answer to the question “how can we give design context to a model so that the output is better” sounds much like “design systems”.
The most useful bits for the model are patterns, guidelines and examples. Those usually live inside Figma pages that showcase how to do these things or at best reside inside the design system’s web page. The problem then becomes how to bring this data to the agent efficiently, at the right time, in a structured format.
This situation also reveals an interesting perspective – we may have separated concerns a bit too far. A “Select” component for example carries only its base semantics – you use it when you want to select something – but it does not carry with it best practices like how many options to contain, where in the product it is best suited for and where in the layout exactly does it usually appear. This knowledge (hopefully) lives inside a Figma annotation or a designer’s head. Maybe this makes a lot of sense for traditional development practices, but does this model still make sense in the context of agentic development – where a broader audience of people actually produce code?
What if
My hypothesis currently is that design systems should collapse back into something like component libraries and we need to formalise some sort of governance layer for them, delivered just in time to agents so that they can output the right thing.
Behaviour and use cases should be informed by patterns. Components are like tools – a saw can cut through different things, and for a specific type of cut, you may need a specific type of saw, but the saw shouldn’t come first or inform what you are building.
Maybe this is a collection of structured pattern markdown files with some sort of router? Or a simple DESIGN.md?
What now
I don’t know where any of this is going. What I do know is that it is time for experiments closer to the fringe, because the way we did things yesterday is starting to look incoherent for the things we need to do tomorrow.
See you next time!
– Todor