Clarity and flexibility in design systems
Insights on a recurring theme from speakers at the 2022 Clarity design system conference
Last week, I took my first flight in years to New Orleans for Clarity 2022, a design system conference founded by Jina Anne, for two days listening and talking about all things new, evolving, and exciting in design systems.
While talks ranged in subject from auditing for accessibility to scaling teams, and included references to everything from the MCU to Kant, there was a—ahem—clear theme of flexibility throughout.
Speaker after speaker spoke to the importance of being flexible in our ways of working, the systems we build, and the most basic notions we hold about design systems.
Amy Hupe took on rigid design system thinking in her talk “Down with Design Systems Dogma,” calling out sweeping statements about what is or is not a legitimate design system.
She even challenged the most basic assumptions about what a design system should do: efficiency, consistency, and scale. To paraphrase, if your design system consistently encourages crap output, is being able to quickly generate a lot of it a benefit?
Amy used salmon swimming upstream. Chasing preconceived definitions of success can burn design system teams out when they’re moving against the current of business needs, resources, tech stacks, and team ways of working.
Amy Hupe’s “The Salmon of Design Systems Knowledge” Illustration: Nicole Amy
Instead Amy encouraged attendees to interrogate their design system’s purpose before deciding what shape their output should take. And use that insight to decide where to put your effort and when to “go with the flow.”
Dan Mall echoed that sentiment in his talk, “Your Next Component,” in which he shared strategies from his workbook, Design System in 90 Days.
You might have a pretty set idea about where you should start a new design system (admit it, it’s a button). But Dan suggests you take on the biggest, meanest-looking component around to show everyone you mean business.
Instead of working off a checklist of what a comprehensive design system should have, ask yourself where your design system has the most potential to help realize your organization’s vision.
Dan used the example of Uber, where if your mission is to “reimagine the way the world moves for the better,” a button will not get you nearly as far as a map component.
I know from my own experience leading the design system at Stitch Fix how daunting taking on mission critical components can be. When we finally added the card used to display shoppable products to clients, three-quarters of the work was spent aligning stakeholders outside of the design system team on design and implementation decisions. These conversations were tough, and to land the final component, we made some compromises; but the benefits to the team and experience were worth it.
As Dan said in his talk, ”It doesn’t matter what you agree on, it just matters that you agree.”
If your design system consistently encourages crap output, is being able to quickly generate a lot of it a benefit?— Paraphrasing Amy Hupe
Agreement can be hard to reach when you’re rigid in your approach. Your system needs to flex with the needs of the product you’re building and the people building it.
While speaking to the ability of design system leaders to make important connections across their product and business, Hayley Hughes of Nike cautioned against narrowly defining your design system by its component pieces.
Instead, Hayley described a design system as the relationships between its pieces and how they all come together.
Like all relationships, your design system must change over time. Otherwise, your consumers will abandon it, leaving you with what Dan Mall called a “design system ghost town.”
In their “Real-time Retro,” the design system team from Spotify opened up about how they’ve changed their approach to the Encore design system since its splashy unveling.
Launched as a system of systems, Encore grew to represent the company’s internal structure more than the cohesive experience everyone was working to create for their customers. (Damn you, Conway.)
Now, they are using what they’ve learned to evolve the system to reinforce Spotify’s design goals instead of its org chart. If they’d held too firmly to their original vision for the system, that wouldn’t be possible.
A vintage page from the HIG, grabbed from Linda’s slides, extolling the virtues of carity.
Linda Dong shared Apple’s Human Interface Guidelines (HIG) have evolved over decades, since its first draft in 1977.
Apple published the HIG, believing the app ecosystem would feel more cohesive, familiar, and usable if it was built on a shared understanding of what makes a good experience.
While many of the HIG’s founding principles (consistency, metaphor, forgiveness, clarity, to name a few) have remained the same, the recommendations for how to achieve them aren’t set in stone.
For example, in earlier decades, Apple recommended avoiding blue, “the most illegible color.” Other earlier color guidelines ignored cultural differences in color meaning. And many of us remember the days of skeuomorphism.
Imagine if Apple clung to those rules instead of adapting to new technology, design approaches, and consumer needs.
It doesn’t matter what you agree on, it just matters that you agree.
— Dan Mall, Clarity 2022
As Amy Hupe cautioned earlier in the conference, if we define our design practice by the shape of our design system instead of the other way around, we’ll become obsolete.
Being flexible in the systems we build is essential to our future success. It may also be a moral imperative.
In her talk, “Good Design is Anti-Capitalist,” Natalie Weizenbaum defined the goal of design as giving people agency, enabling the people who use our products to achieve something they desire.
In contrast, capitalism restricts agency through the threat of scarcity, houselessness, and illness if what people desire to achieve runs counter to its rules.
To fuel its constant drive for growth, capitalism also commodifies what people already possess and sells it back to them at greater expense. (Consider how software you could once own outright now needs to be licensed monthly on the cloud. How you have to pay Pantone for the colors in designs you created years ago.)
As Natalie pointed out, “We’re not going to be able to design our way out of [capitalism].” But these critiques provide a valuable lens through which to look at the way the systems we build grant or restrict agency.
For example, Sass, which Natalie created and continues to lead, chooses to stay as compatible with vanilla CSS as possible.
To what extent are teams adopting your design system locked into its design and tech conventions?
When you bring another team’s component into the design system, are you turning it into something of greater value? Or are you simply licensing a more restrictive version of it back to them?
Are you creating structures that help people more effectively meet the problems they face, as Natalie encouraged the audience to?
Our design systems need to be flexible to adapt to new challenges and visions of success; but, as talks kept reiterating, there’s no one-size-fits-all approach to design systems.
What level or types of flexibility should your system allow? I think Anna Cook said it best in response to a question about the best way for orgs to approach accessibility:
It depends.
In one of the final talks of the conference, “Design Systems Culture,” Ben Callahan of Sparkbox put flexibility on a scale. Teams can be on the more controlling or more permissive ends and still find themselves within a healthy range of flexibility.
Ben shared how culture can be key to determining the right types and levels of flexibility for your design system. Using the Competing Values Framework, you can make sure your design system team’s approach aligns with your company’s larger culture.
The four types of organizational culture from the Competing Values Framework, as presented by Ben Callahan at Clarity. (Cropped for legibility. Sorry, Ben!)
With flexibility on one axis and an internal or external focus on the other, the framework identifies four main types of team culture and the outcomes they’re best suited to.
For example, a team that values autonomy and interpersonal relationships likely has a collaborative culture and will be most effective at driving long-term change. They’re not going to be as effective at driving quick change. A team that’s looking inward at process and efficiency is less likely to generate disruptive innovations.
Design system teams will be better off, Ben suggested, when they share—or at least overlap with—the orientation of the business’s culture.
If you’re working on a mature product that needs to maintain a set pace of change to protect its market share, it may make sense for the design system to exert more control. But novel problems may require your team to be more open to exploration outside the system.
When your teams’ values are at total odds with the culture in which you’re working (diagonally opposed on this graph), you’re going to find yourself swimming upstream. (Hey, callback!)
In the nascency of our discipline, design system practitioners have had to define and advocate for the value of what we do. This year’s focus on ways of working, influence, and culture reflect the ways in which what we do is continuing to evolve to meet the dynamic challenges we face across diverse systems.
For me, Clarity 2022 illustrated how important it is for us to think critically about what is right for our unique context and just how much there is left in our space to explore and define together.
If you feel like wearing your renewed commitment to flexibility on your sleeve, I was inspired to create this It depends t-shirt during a break.
See you next year in Oakland, Clarity!
