From Design Systems to Design Ecologies

TL;DR Growing organizations must accept growing complexity. When one "design system" is not enough, sometimes collections of systems are used, in what could be called a design ecology.

I wrote nearly two years ago about Design Systems, while I was at my peak obsession with the concept and the term. Since that time I worked on quite a few projects that all, to at least some extent, incorporated those ideals and the process. I simply cannot imagine that changing anytime soon.

However, as perhaps the article above may indicate, I try to take a critical approach to any methodology that seemingly claims to be a blanket solution to all problems. Looking back at what I wrote nearly two years ago about systems in the real world, I remain critical, though my thinking has evolved.

When I first wrote about this, I defined design systems almost exclusively in terms of UI and visual design patterns, and gave Mailchimp's as an example. I'm glad I used them as example, because that organization's recent work reflects what I believe is the real value of systems thinking, and what can be referred to as Design Ecologies.

Mailchimp has not only has a robust library of components and patterns, above, but also a Content Style Guide that serves as the foundation for anyone writing copy throughout the brand experience. They even built an interactive tool called Voice & Tone that goes through examples and digs into more detail on what kind of language to use when, and most impressively of all, why.

One more example of what I see as a growing Design Ecology. WeWork is one of the shiny jewels of the tech world at the time of this writing, opening up new spaces across the world for freelancers and small businesses to come and go. They recently wrote about a design system called Plasma, which is not fully open sourced, but has a great case study. It looks similar to some other popular systems, however I believe there is a greater emphasis on communication – both to designers who need to pick up sketch and get started, as well for designers to spec work for developers.

But what makes WeWork a great example of a design ecology, and not just a system, is the recent addition of the research tool they call Polaris. This system is also not open-sourced, though interestingly there is a version made for Airtable. The system is about collating and communicating research insights by boiling insights into digestible "nuggets" that can be sorted and filtered by a variety of relevant facets.

Every organization is its own ecosystem and therefore will have its own Design Ecology. Like any complex environment, problems in the ecosystem arise, and it will be up to us decide to fix those problems. While any good elementary school student could tell you that those problems are probably interrelated, there might still be some obvious places to start. For most organizations, a growing design team and design-developer communications become hurdles to growth and consistency, and so style guides and pattern libraries emerged. After that, I believe the problems quickly become specific to the organization and its circumstances. Mailchimp relies so heavily on clear unique communications, that a content style guide is a logical problem to tackle. For WeWork, a distributed map of physical locations with both universal and local concerns makes research both critical and challenging.


As you can probably guess, I get excited by this kind of systems problem solving. But from my own experience I still think it is worth reiterating that seeing the beautifully packaged solutions above and deciding that's what your organization needs can be risky. Every situation is different. We should take inspiration from the above, and even use them as stepping stones. But the best solution for you will almost certainly be the one created by and for you.