Getting Acquainted with Design Systems

A close crop of a designers working on a tablet

A Brief and Unofficial History

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.

A Layer Cake of Value

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

  • Organizations can use open-source design systems and get legit-looking apps quickly.
  • Design systems help build familiarity with consistent patterns, behaviors, and styles.
  • Design systems create a common starting point across teams and products.
  • Organizations can employ more junior folks and still get polished-looking products.

Team Value

  • Teams spend less time figuring out and/or getting stakeholder buy-in on look and feel.
  • Design systems can result in screaming fast delivery.
  • Design systems help designers and developers speak the same language.

Individual Practitioner Value

  • No more redlines.
  • Practitioners can gain relevant skills with modern tools.
  • Practitioners can spend less time designing minutiae and more time solving meaty user problems.


< Overview | Tricky Traps and Challenges >

Previous
Is a Design System Right for Your Team?
Is a Design System Right for Your Team?

Next
Develop iteratively tested and working code
Develop iteratively tested and working code