But once you take this everything is unique philosophy really seriously into consideration, it starts getting a bit more complex and not really tree-like. A tree-like structure is looking at everything from only one perspective but with design systems there could be millions of them.

In an environment where everything is unique and where basically any world can use almost any world, you need to have all of them ready and accessible from any position. You need to have a list of all the worlds and what you end up using will be based on your perspective.

To describe any design system (or system in general) you need a list of all possible unique worlds, heavily referencing each other.

You also can’t really remove a world that’s being referenced to by another world — otherwise things might break. You can’t remove a #ccc colour if you are using it in Rectangle, or remove Button if you are using it in Frame. You need to replace it with another world — this is what you usually do when you remove a Colour Style from an object in Figma.

Perspective Matters

There is no hierarchy, unless you decide to observe one of the worlds. Since the list of all possible worlds in not a renderable tree, to actually render or show something, you need to pick one of the worlds — app, colour, size, number, button, anything. This world becomes an observer and you can render the view from the perspective of this world — either looking in or out.

This world will become the centre of your perspective. In a way, you and your observer are one. This means you could observe and control the view from the point of any of those worlds (colour, number, opacity, etc.) and achieve almost impossible level of overview in your design.

The God Mode

A design system (or any system in general) could be described as a network of relationships where every node exists just once. Every world, every world’s dimension and every world’s state is unique.

Now, if you kept track of every world as an unique document, you could change any rule just once by either changing any unique document or changing any relationship between them. No more manually adjusting of 1000+ screens after the font of list item size has been changed.

This will allow you to look at your design system from a perspective of anything: all the colours,

a specific colour,

or a colour swatch/style,

and change any one of those things just once. Boom. You can create your own world structure to create whatever kind of structure and dependency you need — worlds will act as relayers, effectively changing the traffic of information and allowing you to change any kind of rule just once everywhere at the same time.

Additionally to some elementary worlds like a Frame, Text or Image, you should be able to create your own worlds, pointing to other worlds — something like what we call variables in code or Colour Styles in Figma. But this should be applied to any rule, not only colour or text styles. You should be able to sync anything, for instance strings,

percentages,

or sizes,

and do all of this manipulation in a highly visual way, with no coding required.

Exploring vs. Consistency

Just like in Figma, Framer X or Sketch, with this approach you can either explore with no rules set or set a strict set of rules in the form of symbols, components, variables or styles to build your stuff with.

But what is really nice about this approach is that you could start exploring freely with no strings attached and then, at any given point, you can make it more strict and organised by finding the emerging patterns and encapsulating them as single individual rules. Go crazy, use any font sizes, colours or naming conventions you wish, you can always clean it up and organise at any given point. You could also do it vice versa: sprinkle a little bit of chaos into your strict design system rules.

This could be the answer for the everlasting conflict between free exploration and strict non-allowing rules of a design system — an ability to find emerging patterns and pin them down at any given point of the process.

Design Assistant

I don’t think we need to build robots that will do all of our work for us. I think that what we need more are assistants, that will help us being better at what we do — all of us, including people with limited knowledge of design principles. And keeping track of every node, every rule and relationship in a design system would allow to make amazing assistive algorithms.

You could make algorithms that will analyse your design system and suggest to you what the program predicts that you will use. It would nudge you to use the stuff that’s already been used to create more consistency. In the most simple way, it could suggest a colour or a size based on how many times it was already used:

As a more complex example, it might suggest a colour based on much more contextual metadata than how many times it is used — i. e. an object the colour is usually used on, the overall hue of all the colours, fill vs. stroke colour usage…

Or — when properly trained with metadata — give even more sophisticated suggestions based on various attributes:

You might be able to analyse any design system (like Google’s Material Design) or a personal designer’s style and nudge the user to make choices that align with the defined “style”. This could help people that have no knowledge of design principles to learn by doing.

Our tools should nudge us into making not only more consistent choices, but also choices that contribute to accessibility and legibility. Imagine a design tool not allowing you to use an ineligible font colour — an accessibility baked right into the core of the design tool.

ABC… Testing

Testing different versions and picking the best one is another part of the design process that could benefit from systematisation. Imagine having an option to literally split the whole design system in two or more parallel universes so that you can see the difference between those and test which one is better. Something like git, built right into the core of our design tools, but better.

Splitting design system into multiverses based on choices to be made

This would be all possible thanks to us keeping track of every building block, every rule in the design system. You could continue making changes to any of the multiverses and they would all update, just because this difference is also an unique rule (or a collection of rules) acting independently of others. For instance, you could test as many different visual themes of an app totally independent from the whole UX process of setting up screen flows.

What Are Screens?

There is this clash between designers and programmers. When talking about flows, designers talk about screens or pages but programmers talk about views or routes. But we’re all just trying to do the same thing, right? So it should be probably one and the same. Or something in the middle. I do think there is a place in between where they meet and can coexist. I am convinced that screens are snapshots of states of observed worlds, created with intention — for instance to tell a story or to show an overview.

By snapshot of a state of the whole environment I mean that there could be as many screens as there are possible states of the app. It’s just that some of those states are more “interesting” and “main” than the others — you don’t show every possible combination of a calendar picker in a booking screen, you just show the default one, or another one that you want to communicate something with.

A snapshot means that they are generated with intent. They are picked from all possible combinations to communicate a particular story. This means you are not designing screens — you are designing dynamic worlds and from those worlds you can generate stories or overviews by arranging a few selected snapshots next to each other. Screens are secondary, they are a byproduct of dynamic systems.

A Small Note On Interactivity

Maybe you’ve already noticed I didn’t mention interactivity yet. So far all that I have described is a world of possibilities, where an observer can see an overview from any point of perspective but can’t really interact with it. This whole article is about defining design systems, not using them.

I have chosen not to talk about this because: a) I haven’t got my thoughts on interactivity sorted out yet, and b) it would be a huge and long undertaking to talk about it so it’s for another article. Stay tuned.

But what I am sure about — and this may seem like a “really?” moment — is that interactivity is emerging on a higher level out of all these discrete building blocks of design systems by adding time as another dimension. I would dare to define interaction as being an observer that can travel through these allowed states in time-flows — for example interacting with an app instance, testing how a particular button works, or just inspecting the blue colour swatch:

Just like when 2D games were morphing into a 3D world, game developers initially thought it would be fairly easy to make games, given it’s just one more dimension added. This proved to be untrue, as making games in 3 dimensions brought so many new nuances into it, that it became much, much more difficult.

How to Actually Build This Different Kind of a Design Tool

I have spent a huge amount of time trying to put this theory into practice and I made countless number of prototypes. This work-in-progress version I am going to show you is the closest I came to my vision. It doesn’t really matter what programming language is used to make this tool real. Or if this is a plugin for an already existing design tool. These ideas should be universal and applicable for use in any programming language or a design tool. This is my version of it.

The Architecture

In order to build a design tool based on these ideas, I started thinking about what systems I need to have in place. This is what I came up with:

Possibilities — a place where you will set up what can exist and how. A place where all the masters and rules are. Think of this as a place where you create your design system — pick colours, font sizes, make buttons or switches, etc.

— a place where you will set up what can exist and how. A place where all the masters and rules are. Think of this as a place where you create your design system — pick colours, font sizes, make buttons or switches, etc. Instances — a place where you manage what really exists. A place where you can create instances out of masters based on rules allowed in the Design System. Think of this as a place where you actually use the design system you are creating — for instance by making an app or a website, just like in any other design tool out there.

a place where you manage what really exists. A place where you can create instances out of masters based on rules allowed in the Design System. Think of this as a place where you actually use the design system you are creating — for instance by making an app or a website, just like in any other design tool out there. Renderer — algorithms that render what exists into a dynamic result in a real time.

algorithms that render what exists into a dynamic result in a real time. (Dynamic) Result — a place where you can interact with what you have made out of any perspective — see/manage a Button, a specific colour or the whole App.

Alternatively, Possibilities and Instances are mixed together in the tool’s interface so you can manage your design system by using it — just like you add a colour style straight in Figma’s toolbar without going into a separate screen. But what interface is this having is not really important — all I am saying is you need to have these systems in place. How will these systems manifest in UI is a thing of an opinion.

Storing The Truth in Unique Documents

Another thing you need is a database with a list of documents for every world, dimension or state. It’s quite easy: all you need is lots and lots of documents with keys and values, where most of the keys and values are just references to other documents. In a way, any design system (or system in general) could be seen as metadata about metadata.

You don’t really want to design things from scratch. You need some elementary documents to build your own worlds from, for instance:

The same goes for dimensions, for instance:

And these elementary worlds will become documents :

Here’s a more detailed example for those who want to look closer: