In the before time, designers would spend countless hours tediously redlining their mockups in preparation for development. Manually calling out font sizes, weights, and styles: 60px here, 40px there, mocks for this breakpoint and that one. By the grace of what we assume was a collective interest in efficiency and things being less painful, pattern libraries began to emerge as an improvement on the practice of infinite redlining. In 2013, Brad Frost introduced a modular, repeatable approach to designing UI. He called it Atomic Design. We liked it, we loved it, and we wanted more of it. In 2014, Google introduced Material, which quickly became the poster child for the emerging concept of design systems. Robust collections of fully designed and coded components that would unlock worlds of speed for development teams.
Fast-forward roughly a decade, and here we are: design systems have become a ubiquitous tool in the software-building belt, and yet, they can still feel like an enigma (even to the people who use them). For every efficiency gained by using a design system, there’s a lurking opportunity for misunderstanding or miscommunication. If redlines are the technological equivalent of a horse and buggy, having a design system is like being handed a jet: it’s a leap in tooling that can get us where we want to go WAY faster, provided we actually understand how to fly the thing.
Design systems have tons of value to provide, so it’s no wonder they’re having such a moment in the spotlight. Here’s a taste of the three-layer value cake:
Organizational Value
Team Value
Individual Practitioner Value