Designers Chat Part 1: What Makes a Great Design System?

A design system is more than a pattern library or a collection of bits of reusable code. That’s a great place to start — but the system does so much more. It’s your ticket to designing and building a digital product in a scalable way that maintains consistency across the multitudes of ways a user will experience your product. 

In part one of Designers Chat, Patrick, Isar, Ryn, Sam, and Grace gathered around a virtual roundtable to discuss what makes a design system great. Curious about when it’s time to kick off a design system for your product or overhaul what you have? Check out part two.

---

So, what are the key qualities that make a good design system?

Isar: Organization is a really big one — being able to easily identify groups of components so that you can find them quickly. Different states being placed in their proper spots. The ability to utilize components across different contexts and the general flexibility of the components within the design system. Everything about the system should serve the overall product.

Patrick: Yeah, organization is huge. Another is guardrails — knowing when and how to communicate what you’re guard-railing and what is open for iteration. There are certain things that aren’t really on the table for a quick change, but there are other things we haven’t really explored. So a big part of the system — and, like, a real challenge for designers — is communicating within the system what is flexible and what is not.

Ryn: Add to that documentation, whether that be extremely formal, more of a Confluence, or even a Storybook, or as minimal as notes and Figma to make sure that there’s language for other people to use the system. Design systems, in my perspective, are for shared use. The system needs to be designed so that people can read it and understand it from a first download. 

Patrick: 100%. Documentation is mandatory. It’s like half of the entire endeavor. 

Who do you think the documentation is for?

Grace: Designers, developers, and product managers, really anyone on the product team. 

Patrick: Documentation is also insurance. It’s for the people who don’t intuitively understand the system, or they’re not designers — which is totally okay — or they’re in a rush. That’s all right. There’s nothing wrong with not understanding a design system. Most people should not have to understand a design system. Like, the onus is on us as designers to make it great and explain it through documentation. It’s making sure no one has to guess about the important stuff.

Ryn: There’s always going to be that buy-in piece, too. People have to be on board, and they have to agree to it, and not everyone will. Making it accessible and easy to use helps, but it could be the best documentation, and people will still not follow it for whatever reason. The troubleshooting after that is that secondary follow-up.

What design systems do you look at as great design systems?

Isar: One of the classics is Material Design. I think that’s probably one of the big players that made design systems visible among not just like very-deep-in-it designers. They talked about it in their tech reveals (Google IO). They really made it more of a mainstream topic and brought awareness to what a design system can mean for a product. 

Also, just looking at their actual documentation, there’s a page for everything, and they provide very good examples of what to do and what not to do. Personally, I love looking at what-not-to-do examples. It’s a good way of illustrating the guardrails and rules they’ve created, and they communicate their design system very effectively because of that.

Ryn: One that I’m a fan of — in terms of the interactive nature of it and hinting at what to do and what not to do — is Stripe. I think that is one of the most playful, fun, well-designed experiences for me personally as a designer who really wonders, “What are the error states, and how do they show up?” Rather than just giving that still shot of what it looks like, you get to actually experience that as a user. It’s a teaching moment, an interactive moment, and a best practice all at the same time.

And they write out what was wrong with it and give you three options like, “How do you want to fail this task? Do you want it to succeed? Do you want it to hit an error, or do you want it to decline?” Ugh, beautiful. So you could replay it. You could feel it. I thought it was really well done. 

Grace: That’s awesome.

Isar: From a developer’s perspective, when I was working on Goldman Sachs, our task was to redesign their design system website. Very meta. As part of that, we looked at a bunch of different examples of various design system websites out there. One of the big things that developers really liked was the code snippets, being able to inline edit those code snippets for a particular component to see how that all plays out and being able to experiment with that and copy-paste it into their own editors.

I think back to the question of who documentation is for. And developers greatly appreciate good documentation for design systems, because if you have the world’s best design system and the people building it don’t understand how to implement it correctly, it’s just not going to work out. Everyone wants it to work out.

Sam: The Human Interface Guidelines talks about the philosophy of why certain choices were made. When designing Apple things, you can always go back to their system principles and ask, for example, “Is this delightful?” It’s nice to know why these corners are rounded at four pixels. I think a lot of design systems don’t do that. They set the rules; they show you all the different states of things but not the reason behind it. Carbon does this a little bit. They talk about the color palette. Everything, like, makes this philosophical sense, which I think makes it easier to use the system in a really intentional way where you’re not just using components — you’re creating part of an ecosystem that has meaning behind it. I think that’s an important piece of a design system. 

How does brand fit into a good design system?

Sam: I think it should absolutely fit, but a lot of companies don’t do that. I think it should be an omnichannel experience where everything is making sense together. That’s what Postlight is trying to do right now. That’s sweet. That’s really cool. There’s not really a need to have different design systems for everything. We can have this one voice with different themes to it. 

Isar: I think something that might necessitate different sorts of aesthetics is, going back to that Goldman Sachs example, they have so many different sub-products and sub-branches and departments, and they have vastly different use cases and products that require designs in very different contexts. They have an overarching design system; it’s very robust. But there’s a certain amount of flexibility that’s needed within those particular components. 

Isar: The colors, for example, in the design system basically span a rainbow because they have various tables and charts that require a lot of different color coding. There are guidelines around their usage, but it’s actually quite broad at the end of the day. And that is specifically to be able to fit into any one of the millions of different products that they create. That could be one of the reasons why it becomes a little bit more divorced from the core Goldman Sachs branding. Just because of how differently it gets used. 

Should your design system be open source?

Sam: How many are truly open source? Is Airbnb’s design system open source, I think?

Isar: I’m also curious about the usage of these. I see a lot of open source design systems — they have the full documentation, and you can download their components, but how many people are actually using them?

Sam: An old coworker of mine sent me a website of a company that basically copied all of IBM’s library — a totally open source thing — and so their homepage, their entire website, looks identical to IBM’s homepage. It’s weird. It’s an open source design system. They’re using all the components. They didn’t alter them at all, though.

Isar: That’s so funny to me because if you don’t change anything, if you follow the design system to a tee, it just looks like a carbon copy (ha!) of something else. So I don’t know what the point is. 

Sam: Sometimes Apple says if you do anything in Swift or whatever, they want you to use those components. 

Isar: I guess in terms of a specific brand or company that’s not so all-encompassing like Bootstrap or Apple, the benefit is general knowledge of how design systems work and how people have it set up. But in terms of actual usage or adoption, that’s where it gets murky for me. 

Sam: Some companies are just benevolent. WordPress allows you to use all its terms and conditions for free. They’re like, “Hey, if you’re starting a startup, you can totally use these. And you’re welcome. Because we love you.” I think it says that at the bottom of the privacy statement.

Sam: We’re all designers here. Should we not share our things? Kind of like scientists, right? Scientists publish their works, and everyone can use them.

Grace: It’s competitive analysis, right? I would not know how to make a design system if I hadn’t looked at other design systems. But I do think that copying is very interesting.

Ryn: I’m definitely in support of design systems being public. Share the knowledge so everyone can get better all the time. I look at these semi-public ones at least, and I take from it because I want more products to be better. I think if it were all private, we’d still be in, like, 2001. It’d be rough.

Want to keep reading about design systems? Check out part two in our series.

---

Want to talk about your product? Reach out at hello@postlight.com.

Work for Postlight! Love making exceptional digital products? We’re hiring engineers, PMs, designers, and strategists. Let’s grow together. See openings.