Design Thesis: What makes an "effective" Design Sytem?

There are a million articles out there about what a design system is, but many don't dive into what makes a design system effective for an organization. I want to talk about how I define effectiveness in a design system.

To preface this: I'm obsessed with design systems. The smell of freshly reviewed components, newly filled out checklists, polished documentation, and thoroughly documented states. There's nothing not to love.

So, what is a design system?

Well, it varies from company to company. It's everything from a component library, to a set of tenants and tests for components, to design documentation. 

To me, a design system is an explorer's guide to designing and developing in an organization. The design system lays down the laws of the area (the tenants and tests), explains the geography and wildlife (the components and layouts), and offers advice for navigating the wild (the tribal knowledge contained within its binding).

A design system can take many forms, and that's because of the unique relationship between design, engineering, and the design systems org (team, department, ...). The more flexible the design system, the fewer rules it has (relying on guidelines and review processes). The less flexible the design system, the more the existing components become "the law," and the design systems team begins to control contributions.

I personally believe in a design system that has authority in its design and engineering org (with buy-in at all levels), being the source of truth while still allowing free contribution from the design teams. The design systems team is there to be advisors, collaborators, and reviewers rather than the dictators or controllers of the design system. They don't erect large barricades to block contributions; they welcome contributions and creative solutions while creating a framework for helping review the work.

The role of a product designer is to create experiences, both through flows and components. When a system becomes so rigid that contributing is extremely hard or impossible, then designers become blocked and can't do the work they should be doing. To create experiences, you need to be able to create new flows, new components, new layouts. I believe a system should enable them to be creative while ensuring quality; creating guidelines for clarity and accessibility (enabling designers to focus on the problems they're solving).

To set those guidelines, a system should have clear contribution guidelines (checklists, component tests, a well laid out system in your tool of choice), a flexible review process, and hard rules around meeting accessibility and usability guidelines. When a new component or layout is inducted, the problems and goals behind it should become part of the system as well. Your component library is a collection of pieces that make up different experiences, which go beyond just empty states and form fields.

When we design, it's important to consider who we're designing for. It's essential to understand what they're trying to achieve and what we want them to be able to take away from any screen or flow. In the end, we're expected to serve the user and their goals. Whatever we hope to gain from them (money, time, activity) needs to align with their goals somehow. In our design system, we should document these goals and intents as much as we document states. Engineers and designers need to be able to understand the current and historical goals and intents behind the system's work.

How would you create a design system like this?

Well, set some strict rules and set a horrible consequence for breaking them, like, singing karaoke in a team standup.

Just kidding. 

I think it's about buy-in and setting the goals and mission for your design system early enough. It's hard to pivot a design system that's already entrenched in a particular workflow, although not impossible. 

I'd say the hardest challenge is in deciding what guidelines and review systems your design system should put into place. It's important to meet some base guidelines, like WCAG and mobile/desktop click target sizing for buttons/action text, but there's more to it than that. You don't want to just ensure you meet guidelines around color, text sizing, and foreground colors; it also matters how consistent the work and behaviors in the work are with the rest of the platform. How these review processes integrate into team reviews and stakeholder reviews is another, potentially greater, challenge for a design team to overcome.

It's hard to be on the team with "ownership" over the system while being separate from the teams designing the product, which is why working with them and collaborating on components can foster a healthier culture around the design system. Typically your job on that team is to help ensure quality and accuracy in the system and maintain the systems documentation. That's usually what the business pays you for, which can quickly turn you into the target of annoyance when reviews turn up too many changes needing to be made. The main thing to remember is we're designing for people; art belongs to the brand team. We're here to build a product, and if it doesn't do a good enough job of serving the user, we need to make adjustments.

Thanks for reading through until the end! I hope you enjoyed a look into my mind, and if you want to discuss any of this, please reach out to me on Twitter!