Here at The Scenery we’ve had the pleasure of working on multiple design systems over the years, spanning from enterprise-scale applications to simple marketing sites. We realized along the way that the systems we made all started off the same way and defined the same core libraries. They also broke the same ways, needed the same care, and worked the best under the same circumstances.
Ether is the culmination of that experience. It’s not a one-size-fits-all design framework — those are never as useful as they seem. Instead, it’s a small, simple set of core libraries that will help you design your system better.
While we wrap up the last few lines of code, we wanted to write about what we’ve learned and the problems we’re solving while building Ether for ourselves, and more importantly, for you.
This is how we think systems should be built.
Strive for Purpose Over Definition
A lot of times people conflate design systems with pattern libraries and design guides—we don’t blame them. Up to this point they’ve been very much the same. Where a lot of design systems fall short is their ability to not only define what is in the system but why it’s there in the first place.
The system should strive to give developers a clear idea of the purpose behind the application of visual style and behavior. The system’s job is to guide the design of everything it relates to the same way a human designer would. Simple color definitions and text specs don’t come nearly close enough. By mapping definition to usage we can codify the thought process of a product designer, allowing for the ultimate goal of any system: scale.
Don’t Be Everything for Everyone
Systems quickly turn into a quagmire of variables, alternates, knobs, and levers if not taken care of (we know this one from experience). The most difficult part of this concept is balancing the two sides of the spectrum—too simplistic and the system becomes inflexible, too customizable and the system becomes bloated. Both will make your system unusable.
The guiding principle when dealing with additions to our systems is this question: Can I solve the problem I’m facing with something already defined?
It’s a tough question—especially when designers are involved—but it does wonders to keep a system from taking on unnecessary cruft just to handle edge-cases or one-offs. Although it may make your system hostile towards design-snowflakes it helps achieve a far greater goal: clarity.
Build for Change
A year from now, you want to be using the same system you started with today; one that allows for growth and evolution over time. Much like a CMS or website project, the last thing you want to do in a couple years is burn down your entire project and start from scratch. We do that in multiple ways:
- By abstracting visual style definition and usage.
- By keeping our systems simple and modular.
- By not over-defining system elements.
Using these handy tricks we can create a design system that flexes gracefully over time instead of crumbling under its own weight. No one wants that.