In a recent podcast, Elizabeth Stone said Netflix needs more systems thinkers, especially in design.
Her point was that designers increasingly need to define the templates, design language, and shared paths that help many people build coherent experiences. As more people and agents create product work, the system around that work matters more.
I have been working through what that could mean for design systems, and I'm starting to think we need a new kind of system. For now, I am calling it a frontier design system. The idea is still a theory. I want to describe it clearly enough that other people can test it, challenge it, or help build it. Perhaps you are thinking about it too or, even better, have started to build it. So please, read on and let me know what you think.
A context model for the whole product
Most design systems describe tokens and components. Some include templates, motion rules, content guidance, and usage examples. A frontier design system would go further. It would contain a living description of the entire product. At the bottom are tokens. Above them are components and their behavior, including motion and transition standards. Components combine into interactive templates such as lists, searchable lists, dashboards, product pages, and navigation structures. Those templates combine into screens. Screens combine into flows such as onboarding, product discovery, acquisition, servicing, and support. The model also describes the states those screens and flows can enter.
Then the context gets deeper.
It includes the rules for information architecture and information design. It includes localization rules for language length, asset formats, image dimensions, and market-specific content. It also includes business logic for different customer segments, products, and regulatory environments.
Take the Amazon homepage as an example. It has a stable underlying pattern. But the details change across countries. Product selection differs. Purchase flows differ. Specific regulations apply. The context model needs to understand both the shared structure and the conditions that change the experience.
This is larger than a DESIGN.md file. It's a versioned model of how the product works, how it behaves, what it knows, and where variation is allowed. The model will never be perfectly complete. It needs to be complete enough to produce reliable outputs and explicit enough to expose what it does not know.
One context, several artifacts
Once the product has a sufficiently accurate context model, the design artifacts become views of that context.
The first output is a static map. Figma or Paper can show every screen, flow, and navigation path. The map helps people understand the territory, review the system, and explain a concept. It remains valuable, but it is a representation.
The second output is a lightweight prototype. It uses the real components and behavior but is disconnected from some backend services. The team can explore an experience quickly, test assumptions, and debate something that feels close to the product. This prototype is generated by an LLM, which uses the context to output reliably accurate outputs.
The third output is a data-bound prototype. At that point the prototype is the app. It uses live code, real services, production components, and the same underlying context.
Today there is a meaningful gap between these outputs. The map, the prototype, and the production experience can drift apart. My theory is that a shared context model can progressively close that gap.
Figma then becomes one way to inspect or communicate the system. The prototype becomes the main surface for debate. Over time, the production app becomes another output from the same source.
Intent becomes the input
Imagine declaring an intent such as: increase engagement with notifications among minimally engaged customers by 10 percent.
The context model already understands the notification experience, the relevant components, the navigation model, the customer segment, the content rules, and the available data. It can use that context to produce several prototypes that explore the intent.
The designer judges those prototypes. They test the assumptions, make the tradeoffs, and decide whether any direction deserves to move forward. Each decision can then improve the context model, which gives the next exploration a better starting point.
In the nearer term, those prototypes will stay lighter than production. They will use real patterns and behavior with simulated data. As the system matures, more prototypes can bind directly to the required data and services. The distance between exploring an idea and building it should continue to shrink.
This works best in bounded product spaces
I think this model is most credible for products with a stable underlying grammar.
Media, banking, e-commerce, travel, delivery, and transportation products have well-understood patterns. Netflix, Nubank, Airbnb, DoorDash, and Uber continue to invent, but each product also has a base model that changes slowly. Dashboards, listings, product pages, acquisition flows, transaction histories, and account states can be described with reasonable precision.
The theory becomes weaker in more open-ended product spaces that have no established pattern. For example in Claude Desktop app the search space is less bounded, and the prototype often exists to find the product's grammar.
A frontier design system can still help those teams with components, behavior, and shared context. It will have less power to predict the shape of the final experience.
That boundary is meaningful. A context model built for a stable system can generate useful variations. A context model applied too early to an emerging product can harden today's assumptions and narrow tomorrow's ideas.
The difficult part is maintaining truth
The technical output is only half of the problem. The harder part is keeping the context accurate.
Every component change, new market rule, revised flow, exception, and product decision has to update the model. The context needs versioning, ownership, sources, tests, and clear confidence levels. A stale model will generate consistent work that is consistently wrong. There is another risk. A system this complete can reward repetition and discourage invention. The context needs explicit room for exceptions, experiments, and new patterns. Designers still need the authority to challenge the model and change it when the product needs a better answer.
So the frontier design system cannot become a frozen specification. It has to behave like a living product model, with a continuous loop between intent, generation, judgment, and learning.
The designer builds the context
This changes the designer's work.
Designers will still make screens and flows. They will also codify why those screens work, where a pattern applies, how it behaves, and which conditions should produce a different answer. They will work in prototypes close enough to the product that the team can debate the real experience.
The design system becomes a model of the product. The static canvas becomes a map generated from that model. The prototype becomes an executable expression of it. Production becomes the highest-fidelity output.
I am still working through whether this is the right model and how far it can go. The direction feels plausible for products with a stable grammar, and the unresolved questions are substantial.
What belongs in the context? How should it be structured? Who keeps it current? How do we protect exploration when the system can generate a coherent answer so quickly?
If you are building something like this, or think the premise is wrong, I would like to compare notes. Please drop a comment and let's explore together.