People first. Information first.


Design Systems and Design Problems

At my organization, the ways we talk and think about our nascent design system are increasingly causing pain. In team conversations and meetings, the terms “design system” and “pattern library” swirl. Are they interchangeable? What belongs in our “digital brand manual,” and where does that fit in? What’s the difference between a component, a pattern, an element, a widget … if anything? What names do we agree to within our tenuous taxonomy of buttons, accordions, cards, tiles, dropdowns, and the like?

I want to see our design system framed and focused on problems. After all, a design pattern is a reusable answer to a recurring problem. Vastly different products and places within our digital ecosystem share many problems, and isn’t that the crux of a contemporary design system?

A radio button, for instance, answers a basic information problem — how might you make a mutually exclusive choice from a set of options? Visual styles as patterns are more than aesthetics; they address problems of distinguishing and representing a brand. Meanwhile, does our design system need a modal dialog pattern? Well, what’s the problem we’re solving for? Maybe we need to alert users to critical information, or convey that a new preference was saved successfully.

These problems are things that every designer, engineer, product manager, business owner, and stakeholder can understand. Framing this way is more approachable than trying to educate about tokens and CSS frameworks. Not only that, it spotlights what issues are actually shared or not between product teams. “I need a date picker!” can become a dialogue that illuminates the real need and empowers us to prioritize and decide.

At least, this is all an idea that has intrigued me as I prepare to take potential stewardship of our design system for the next couple months. And likely these thoughts aren’t wholly unique. I see Shopify’s Polaris design system, as an example, providing some problem focus and structuring their components in a way that isn’t just a list of UI. Still, I want to see more. I want to see a design system framed fundamentally on the problems. What might such a framing look like? And can it help make a system make sense?

Jeremy BurtonComment