Communicating Design Patterns

An Introduction to Design Systems

If you’ve been reading much in the design world lately, you probably know that design systems are all the rage. If you’re not a designer but curious about what everyone is talking about, welcome! 👋 This is for you too. 😃 I thought it would be helpful to share what design systems are, why they’re useful, and a few tips for effective systems. But before we can talk about systems, we need to talk about patterns.

Design Patterns

Design is often thought of in terms of aesthetic. Color palettes, spacing, and typography come to mind. But design is much broader than that. It informs behavior and functionality as well. Design shapes how users move through a checkout process and reset their passwords. It helps users understand whether a message was sent successfully, or which direction to swipe to see more content. Design also influences and application’s voice and tone. Perhaps your weather app is personable and playful, like Poncho. Or maybe it’s precise and beautiful, like Dark Sky.

Communication Breakdown

Getting these patterns right takes a tremendous amount of effort and iteration, and effective documentation is perhaps even more of an undertaking. Beyond that, ensuring that your designers’ intentions are accurately translated into production is incredibly challenging. And while design tools have come a long way in the past few years, they still have a long way to go.

team communication diagram

Design Systems

Wait, Don’t You Mean Style Guide?

A point of clarification is probably needed. Design systems, pattern libraries, and style guides are all popular terms, and depending on who you ask, could be interchangeable or very different things. It seems the current trend is to have style guides and design systems live together which further blurs the lines between them. How you decide to define them is up to you. In this article, I’ll refer to design systems and style guides as two separate things (though a style guide is certainly a part of a design system). Against my better judgment, I’m going to make a distinction that style guides are a portion of a design system. Their focus is on describing the rules and principles that guide the system. If you’d like to see some examples, Brad Frost has a great list here.

Intent & Implementation

Design systems are a means to describe design intent and implementation, and both are equally important. Intentions without implementation are irrelevant, and implementation without proper intention will be inconsistent. This dual nature produces an interesting quality. Systems are not strict dogma etched in stone. Rather they are living documentation. The system grows and iterates with the application. Its rules are expanded, modified, and rewritten as needed. They are, at the same time, a representation of what the application is and what it strives to be.

What Makes a Good Design System?

This topic definitely deserves its own post, but I’ll briefly highlight some important aspects of our design system.

Consistency Is Baked-In

Your design principles should be clear, but it shouldn’t be essential for a developer to have a perfect map of the design rules in their mind to build a component, or for a QA tester to verify it. Baking-in consistency means creating highly reusable bits of code (whether CSS styles or reusable components) that handle a lot of the minor details. You’ll know you’re getting it right when you start getting consistent style and behavior “for free.”

Make Mistakes Difficult

This is something our team learned the hard way. At first, we wanted our implementation to be highly extensible, but providing too many options led to confusion and ultimately issues that made it to production. Because the right choices weren’t clear, the errors were non-obvious in code review and were expensive to untangle down the road. We retooled our implementation to provide few, clear options. At first this felt very restrictive, but ultimately it led to a high degree of freedom for our developers. We made the right choices easy and removed opportunities for mistakes. And when errors are made, they‘re easier to catch in code review.

Encourage Collaboration Between Designers & Developers

I’ve worked on several teams where our process involved a “design hand-off.” This usually meant that design added enough content to the mockups for the developers to implement them. This almost always ended poorly, despite well-intentioned designers and developers. Unfortunately, mockups only communicate a tiny percentage of the intended design. Our development team has an open dialog with our designers to clarify details and ask questions. This communication helps us develop our common design language, and it influences how our documentation and tickets are written.

Thanks For Reading!

I hope you enjoyed this article! Developing an effective design system has been one of the most beneficial things for our team. I hope there were some helpful ideas for you and your team as well.

design systems @workday