Thinking about reading about design systems

Observations from the pre-reading for the Memorisely Design Systems course

There are some interesting similarities and differences across the literature in our course pre-reading that I thought I’d draw out.

First — most of the authors seem to identify a split between “foundations” and the components within a design system, though the things that make up “foundations” varied significantly.

Some authors drew a line from corporate mission and values through to design principles, brand identity, tone of voice. Others stuck more closely to style guide-type content like colours, typography, layout, formatting guidance. And a handful included detail on accessibility, responsive design, engineering principles. Interestingly, though they all included naming conventions in their foundations, their approaches to this differ too. Some seem to prefer a “visual metaphor” approach — believing it speaks to design intent and is more memorable for teams (e.g. “boom box” for high-impact, attention grabbing component”; others recommended contextual names connected to specific user behaviours (e.g. “discovery — details card”).

Second — all of the authors went to great lengths to outline the case for design systems, in part I believe a reflection of the relative newness of design systems as a concept. And all authors made similar recommendations for getting started — start small, deliver enough to get people excited, always be advocating, treat it like a product. The parallels with typical digital transformation work are uncanny (the strategy is delivery)- and that’s to be expected because design systems are similarly focused on enabling product and service teams. Their benefits show up only indirectly in a firm’s top and bottom lines — which makes them more vulnerable to being deprioritised or cut.

Third — the authors all held slightly different positions on how the design system fits with the rest of an org. For some, the team is cross-disciplinary team and brings together the brand and creative teams with the UX, product and technology teams — implying collective ownership. For others, the design system team is really only about digital design because digital is different to the world of print, or brand, or photography. And it’s true in many ways — design system teams have to consider different platforms and operating systems, formatting, load times, animation etc that print style guide teams don’t. That doesn’t mean there isn’t great value in bringing things together though.

Fourth, the approaches to design systems they advocated differed in the degree of connection to the codebase. Some are fully integrated and kept in sync; others are almost web versions of old-school PDF style guides. Atomic design approaches are at one extreme, with some brand-heavy systems at the other, specifying fewer constraints generally and focused more on providing material for creative re-use by designers. Perhaps the approach is determined more by the business function that initiated the creation of the design system in the first place — e.g. has it evolved from a branding style guide or is it borne of a digital team’s frustration with its workflows? Organisations that want something truly integrated really ought to work on those interdisciplinary relationships before they focus too much on the technology.

Fifth — each book and article I read emphasised the need for contextual documentation — e.g. when, how and where to use the components. Some even argued the value of showing design system users the lineage of a component — making it easier to spot potential global impacts of a component change, to plan testing. All authors were clear that building a design system is the easy bit, whether you choose to do it all at once or incrementally. The challenge is building one that a system that is useful and used across disciplines, so catalyses collaboration; and maintained and governed well, so it stays relevant and current and preferred.

Across all of these points, I can’t help but note how critical relationships appear to be in shaping everything about a design system. Whether it exists. Who it’s for. Who owns it. Who maintains it. Who contributes to it. Who uses it. What’s in it. Where and when and how it’s used. What is connects to. How it interacts with other things. Its boundaries. Its longevity. It all comes down to the social systems within which the design system is conceived, developed, used and maintained.

As ever, it’s those pesky humans who make or break a design system.