After many years mostly on the fringes, “design systems” (which were more commonly known as “living style guides” for a while, until “design systems” made them sound much cooler and legit) started really gaining more mainstream popularity and traction over the last 24 months. Many companies have made public announcements and displays of their internal design systems; sometimes based in code, sometimes not.

However, while there are elements of this that are really positive (encouraging re-useability and modularity for design), in some ways, the “design systems” marching band has been something of a big distraction. With the conversation so narrowly focused on climbing the mountain of creating a design system as a goal in and of itself, far less thought has been given to the endgame.

Your design file is not a design system.

First - for some much needed context to what I’m going to talk about next - just to address the elephant in the room, there still seems to be a wide misconception that a design file that contains some hand drawn (literally) pieces of a website or application - no matter how neatly or organised they might be - constitutes a design system. I don’t agree with this idea, because at best, it’s still just an emulation of the real medium (code running in a browser or native app) that your customers and users are actually looking at and using.

It’s disheartening to see companies spending many months or even years all working towards meticulously creating really big component libraries in screen design tools, only to realise later that this big design system project becomes very unstable alongside a “mirrored” development environment which will always be ahead of it. It is difficult to maintain at a small scale with few people, and near impossible to maintain at scale with many people. Indeed, if your company has multiple brands or products that all branch off the same underlying design system, this problem continues to compound with every additional property.

I personally know companies and teams who tried doing this approach back in 2013-2014, and less than a year after “completing” the design system creation (in design tools), the problems of how that relationship with front-end development (and the production environment) might work together begins to rapidly break down.

If you haven’t seen this happen before, it’s understandable for it to be a blind spot - especially as many design/development teams are disturbingly disconnected from each other - but on a long enough timeline, anyone who embarks on this approach to the “design system project” will ultimately realise that we can (and must) do better.

Design has not reacted to “React”

As I’ve written and talked about a number of times before: after 20 years, the way we design things still has much more in common with front end development in 1999 than it does with the front end development in 2020.

Despite being more than half a decade old and forcing us to completely re-think and change the way we think about front end development, designers and design tools have yet to catch up with the ideas that “React” (the JavaScript library for building user interfaces) and those like it (Vue, Svelte etc) have brought to the table.

Before we had the “React” way of thinking about working with “state” and events in development for the front end, we were living in a much different “jQuery” reality that makes little sense with the benefit of hindsight (which is likely how we will view design today when we look back on it with similar hindsight in the future).

The three key concepts featured on React’s website are:

Declarative

React makes it painless to create interactive UIs. Design simple views for each state in your application, and React will efficiently update and render just the right components when your data changes. Declarative views make your code more predictable, simpler to understand, and easier to debug.

Component-Based

Build encapsulated components that manage their own state, then compose them to make complex UIs. Since component logic is written in JavaScript instead of templates, you can easily pass rich data through your app and keep state out of the DOM.

Learn Once, Write Anywhere

We don’t make assumptions about the rest of your technology stack, so you can develop new features in React without rewriting existing code. React can also render on the server using Node and power mobile apps using React Native.

All we have are static components with no souls states.

If we use the React concepts and try to pair them up with the way we currently approach design, we would (in the best case) score ~0.5/3 - we have something resembling components, but they don’t really do anything. Our front end environments are operating on a totally different paradigm to the way that design is still generally being approached; the two are completely incompatible. There is no sane way to approach state driven design in our current design tools.

Having personally worked on projects that have hundreds of possible “states” within a single view - it doesn’t matter how good or well organized/named your components are inside of a design tool - you cannot possibly create robust designs that account for the interplay of all these possible combinations of future states by approaching it the way we have for the last 20 years.

This is a huge deal, because (again, as I’ve experienced on many, many projects), if you are not considering the “states” of an application, you’re going to have blind spots as a designer, which might not be front of mind while trying to design a handful of “pages” that give an example of some states which might be encountered.

When you compound this problem with the fact that many designers are not even using real data or content from the production environment (often favouring “fake real content” or just using lorem ipsum for imaginary content), you end up in a weird place where you are literally designing based on delusion rather than data or anything based on reality.

If you’re designing fake static “pages”, with fake content, using fake components and creating fake “states” by stringing a dozen static “pages” (modified versions of the same view) together in order to emulate something comparable to the production environment, you’re flirting with a time bomb that will eventually explode once this design makes its way to development and nothing makes sense.

Extrapolating the “hover states on buttons” problem

It’s very telling when a common request for prototypes is being able to show “hover states” on buttons. This might sound funny, especially since the joke that “all conversations about design systems eventually just lead to talking about buttons” (somewhat true, as this paragraph confirms), but this concern is basically “patient zero” for the massive amounts of headaches it will cause going beyond just wondering about the state of a single button.

The “button component” is often used because it’s an example of one of the most atomic things you could design - you can’t break a button up into anything smaller than itself. If that’s true for the component itself, then the same is true for the “states” of the button - a button can have visual interaction states (hover, focus, active, disabled, loading etc) and it can have different text, but it doesn’t really many other properties that change.

If we can’t even do something like change the “state” of a button under certain conditions without duplicating that button 5 times for the interaction states, then duplicating all those 3 more times for “primary/secondary/tertiary” variants, then duplicating those 3 more times for “dark mode versions”, to give us 45 instances of a button, then I don’t even want to imagine what designing anything even slightly more complicated would be like.

The question remains, even after you’ve got these 45 button instances in a design tool, what can you do with them? You cannot make the text on any button(s) “react” to use someone’s name when the state of the application changes to “logged in”, this needs to be compounded by designing that possible state of those buttons, with the 5 other possible states of that view - because there are dozens of other components that might also do something different when somebody is logged in, or if that customer has new “notifications”, or dozens of other combinations that come along for the ride… who knows what might be happening in the state of your application at any given time.

Design in the “Abstract”

If we are to look at Silicon Valley as the epicenter of the bleeding edge, as many designers tend to (eg. blindly adopting “underlined text inputs” from “Material Design”, only to find out 2 years later from the Material Design team’s data that they aren’t actually very good), then one could imagine that the problems I’m describing would be coming ever closer to being solved in these bigger tech companies with huge design teams.

However, in season 2 of the Netflix design series, “Abstract”, there is an episode that looks at a design team inside of the company “Instagram”. There is one short part of the episode where one of the designers is showing off a prototype on the screen which looks like the visual source code for The Matrix or something - it seemed crazy to me, but then I realized that this is “the best of the best”, and I felt very sad and confused.

On a more personal version of this: one of the lead design system designers/developers that I know (who works at a well known startup here in Melbourne), recently went to Silicon Valley and had a tour of some very well known tech companies to see how their design teams were doing things. After they returned back home to Melbourne, I somewhat excitedly asked: “So, tell me… what are they doing that we don’t know about?” and the answer was disturbingly: “Well… nothing. They’re not really doing anything different than most of the bigger design teams at the design-driven companies around here.”

It became clear that nobody has figured it out; and while everyone claims they have some answers (or even the answer), we are still all essentially operating within a very similar set of mostly accepted parameters, mainstream tooling and narrow ranges of thinking about these problems related to problems such as (but certainly not limited to) the need for state driven design.

“You must study the endgame before everything else”

With such a heavy and narrow focus on just creating design systems, it seems like many have lost sight of why they are doing so in the first place. The moment you have completed your design system project (knowing it is never “done” in some sense, let’s define “completed” as something that can be 10x more materially useful to the way you design products), the question becomes something like: “what can we do now that we couldn’t before?”, with all eyes on your brand new design system, the promised savior to all your problems.

If we take a quote from world chess champion José Raúl Capablanca:

“In order to improve your game, you must study the endgame before everything else, for whereas the endings can be studied and mastered by themselves, the middle game and the opening must be studied in relation to the endgame.”

To me, it seems like we are spending more time distracted by studying everyone’s “opening move” (of creating a design system), that we haven’t given enough thought to the rest of the game.

Weirdly, I do get the sense that everyone is almost kind of “happy” being distracted with the project of “creating design systems” as the goal itself, because it means we don’t have to think about what comes next; and maybe if nobody talks about it too much, then nobody will get in too much trouble because “we were just copying each other, after all”.

If the poorly defined endgame on our current trajectory is simply having a neatly organized and shared set of hand drawn pictures that look like components (from a real website or app) in a design file that makes it easier (but not fundamentally different) to continue designing very complicated things that aren’t interoperable with front end development and the production environment; I would be very pessimistic about that future.

However, to me, it seems that we both acknowledge and ignore our “secret” endgame; the way we are acting indicates that we are trying to emulate the front-end environment in design tools on some level (albeit one very slow and incremental step at a time), but seemingly without ever considering that we could just going “all-in” on actually using the front-end code itself to accomplish the same outcome instead.

I sort of understand why this isn’t a very popular idea (even today, after talking about it for half a decade, most people I talk to still disagree with me on it), especially since the tooling has not caught up to this idea, but if we really don’t want to use code, then we still need to come up with a sane way to design things without pixel pushing 100+ possible “fraudulent states” (using fake data) of an application manually across artboards (just the name “artboard” is a tell that something has gone a bit wrong) and dragging arrows between them to create some crazy prototype that has no value beyond an artifact sitting somewhere in the cloud (once it has served its limited purpose).

On a long enough timeline (which is still far too long) of trying to trudge our way through this current paradigm (which has already run out of track), I’m still optimistic that enough people will start recognizing the way we’re thinking about design systems, prototyping and the far bigger fundamental problem of design and development not being interoperable are things that we really need to think about seriously and solve with greater urgency.

The future is not set - new ideas (“state driven design” is only one of many that we need now and in the future), positive progress and innovation are not automatic - it’s up to us to change it; no one is going to save you.