We sat down with Dan Mall of Superfriendly to explore his best practices from design systems projects with startups and corporations.
Check out the full interview recording and transcript below.
To learn more about the benefits and processes of design systems, download the free e-book Why Build a Design System?
How did you get started working on design systems? What was that progress and journey like?
I run a consulting company and we work with all sorts of different clients from mom and pop shops to Fortune 500 so all sorts of things, and the more clients we started to work with that have been in business for a long time, they started to realize that they have a ton of digital properties that they try to manage.
When I was doing work 10 years ago, it was like, “Help us get our website off the ground.” Right? But now everyone has a website and they have more than a website, they have websites, micro-sites, and apps, and all these things and they all start to get really … There’s a lot of discrepancy with a lot of them, because a lot of them are made one by one, there’s not a lot of consistency, there’s not a lot of efficiencies, and as organizations start to look across their properties and they go, “How do we manage all hundreds of the apps that we make? And why do they all look different?” They start to realize that they need some sort of system to be able to manage and update, but also just maintain all that stuff.
And I think the idea of design systems is a thing that a lot of organizations are sort of coming to rather than it like you know no one invented that idea and then people are climbing on board. It’s more like, people are realizing it pragmatically. So I think it evolved pretty naturally.
Have you seen a certain size at which a company benefits from a design system?
I don’t think so, ’cause I’ve seen companies, start-ups that have a handful of designers start to invest in that stuff. I’ve seen companies that have tens of thousands of employees or hundreds of thousands of employees do it. I think it’s more about how many digital properties do they manage? There are certainly a ton of companies that have many, many employees that are just starting to get into digital now and they may not need a design system. But then there’s let’s companies that are natively digital like Airbnb, they’ve made a bunch of things and are starting to realize before they get too deep into it, “Oh we actually need something to help us propel this forward.”
I don’t think that there’s any particular size that I can pinpoint, but I think it’s about how many digital properties they maintain or intend to maintain.
How do you sell the need for a design system?
In my experience as a consultant, I rarely have to do the selling for a design system. It’s usually somebody who works at the organization that is in charge of digital or maybe a product director or something, or a web manager, or something like that really has to do a lot of the selling. Now we can help with that but it’s that person who really needs to make the case for it. So a lot of the clients that I work with, what they do is they sell things the way that anybody sells things which is you show people the pain. You show them like, “This is the pain that we’re experiencing and here is a solution that will help alleviate that pain.” And a lot of those instances it is a design system.
So one of my clients, I wrote a blog post about this, but one of my clients walked into his boss’s office with thumbnails, hundreds of thumbnails mounted on black mounting board to say, “Here are all the websites we developed this year and look how different they are and how desperate they are. Here’s how much money we wasted on that. And I know how to fix it and here’s how much money we’re gonna save if we do it the right way if we invest in it.” And so making the good case for it was really showing and visualizing the pain, like, “Here’s what it looks like to not have a design system. And let me paint the picture of what it actually looks like to have one. And we can compare those apples to apples.”
Right. That was the Seventh Day Adventist Church project, that you were talking about?
Yeah. Exactly.
Brent Harding was the web manager there and he did a fantastic job of evangelizing that idea in the organization so that we had all the buy-in that we needed when we came in and did the work. I find the most success that we can have is ask people who come and help us consultants is when somebody internally has already done that due diligence and the level setting for everybody, the expectation setting. Like, “This is what we’re going to embark on because this is what we get out of it.”
How would you describe the benefits of a design system in 30 seconds?
My definition is evolving and I’m not sure that there is a canonical definition but I would say that the more and more I’m thinking about the idea that design systems should help you design better and faster. Or maybe just better. I’ll just stop there. And for some organizations that means faster, some organization that means to a level of higher quality. I think it should help you design better. I don’t think, and this a thing that I previously thought, I don’t think that a design system should remove design from your organization. A lot of clients think like, “Oh, if we had a design system, we don’t need to design anymore, right? ‘Cause all the decisions would be made.” And I think that I’ve never seen that actually happen. Design systems should just help you design better. So you’re still gonna have to go through the process of design, but a design system should be a good tool in your arsenal for you to be able to design better. And eliminate some of the useless decisions that you might have to make otherwise.
What are some redundant decisions that you’ve seen a design system help eliminate?
So here’s a really oversimplified example, but what color palette should we have for this app?
Well, if you’re working in an organization that has a brand guideline and style guides and typography guidelines, that’s sort of a useless exercise]. You’re gonna explore a bunch of color palettes and then it’s gonna get shot down by someone. But if your organization already had that kind of stuff, having that codified in some way so you can implement it is easier. But for you to waste time exploring a thing that doesn’t need to be explored, I think that’s where a good design system can help out. Same thing with typography. Same thing with things that you should be able to take for granted, but if you don’t have the right tools you end up having to explore those things again and again.
Kind of reinventing the wheel.
What are some common design system mistakes?
I’m not sure that I can pinpoint what mistakes clients make. I can tell you the mistakes that I’m making. One of the things is that I often have took for granted the fact that I know who the design system is for, I know how those people are going to use it. And the more I take that for granted, the more we work on stuff without talking to people, and the more we launch something and say, “Hey, this is gonna be good for you.” And then we find out that that’s very, very wrong. So it’s a fairly simple example, any good product design has that cycle in it where you gotta talk to your users, you gotta have both quantitative and qualitative data that supports the things that you’re making. Otherwise you’re just speculating.
A recent example of what we found was, we spent good bit of time designing a design system for an organization and then launching that thing and we get a ton of feedback from the people that it’s meant for saying, “We can’t use this. And here’s why.” And part of that’s just us not doing our proper due diligence in research and getting people in on the ground early, very early. Testing what we’ve got, validating it. Everything from what kind of coding standards are we gonna use all the way to where’s the rest of the colors that I can use? Every organization has different processes, so to assume like a good design system is there’s a canonical version of that, that’s a thing that I’m learning. There’s not. Every organization is a special snowflake and they have specific needs and specific people that use them.
So another example is that I’ve worked with organizations that the design systems are for purely developers. That’s it. It’s not for designers. And then in other organizations, a design system has to work equally well for designers and developers. And so just those two examples, those two design systems have to be drastically different from each other ’cause they need to support different use cases and different people. So I think that’s one of the things I constantly am reminded of and constantly making mistakes about of just taking for granted, like, “Oh, I know what this is for, I know what we need to do here.” And just forgetting to talk to people about it and really spending a lot of time interviewing and making sure we’re gonna build the right thing.
How does a design system for mostly developers versus one that is for a mixed audience of designers and developers differ?
If I could sort of sum it up, and again there’s a lot of nuance in here, but just kind of generally, the design systems that I’ve worked on that were solely for developers are ones where a lot of the developers tend to say, “Give me the one line that I could drop in and everything works. Like everything’s hooked up, I don’t need to think about this. Take away some of the thinking that I’m not comfortable with and let me focus on the thing that I am comfortable with.” So if I need to build a certain component, I don’t want all the parts, just give me the one line of Javascript that I can use to plug in this component and it all works.
Vice versa, the design system for designers or one that has to work equally well for designers and developers. Sometimes those designers are thinking like, “Give me the parts and let me figure out how to wire them together. Let me figure out what the design process needs to be for this flow, or for this particular thing. I just need the kit. I just need what all the Legos are.” For lack of a better metaphor. And so some people want the Legos, some people want the thing that the legos make. And I think that those are probably the two ends of the spectrum and then certainly all the areas in between.
How would you describe your process for creating a design system, from start to finish?
From a 1, 2, 3, 4 standpoint, 3 and 4 are almost always different for me so I’m not sure if I can codify that? But 1 and 2 tend to be constants so I can give you 1 and 2.
So 1 is, as you just said, just talking to people, just interviewing a ton, just talking to as many people as are gonna touch this. And having really a good sample size. We’ve talked to some organizations, 8 people and sometimes that’s representative enough. And then other times, like close to a hundred people and sometimes that’s representative enough. So I think it depends on the scale of the organization. 1 is just like getting the lay of the land of who’s gonna use this? How are they gonna use this? Is this person who’s very vocal, are they an exception to the rule or do they represent the median there? So I think understanding that is part 1. And spending as much time to do that as possible, I think I’m realizing more and more the value of that. So that’s part 1.
And then step number 2 is…I haven’t done a design system where we didn’t pilot it first. So what I mean by that is when a lot of people think of a design system, they generally are talking about a combination of a style guide and a component library and it’s tempted to say, “Well look, we could just build a bunch of components, we’ll build buttons and carts and tables and tabs and all that stuff.” But the way that we know that those are gonna work is through piloting and application.
So, step 2 is usually, for our work, is give us an inventory of all the apps that you use. So we walk through with people, whether on screen share or in person or we ask them to make print outs, however they can deliver that stuff, show us all the apps that you use. And just walk us through them and we’ll take screenshots and once we’ve seen 20, 50, 100 then we could start to inventory and say, “All right, of these 100 apps we just saw, or these 100 websites we just saw, all of them have some sort of left side navigation. That’s a component that maybe we should start with. All of them have a very specific kind of footer, or all of them have a special kind of dropdown.” So we’ll try to take the first 10 or 15 or 20 components that we’ve seen across 100 apps and then we’ll start to build from there. And then after the first 20, we’ll say to the people that are going to be using it, “Here’s our beta period, what do you think of these? Are these on the right track?”
And if they are, the next step after that is let’s use those things to try and build a new app, or maybe it’s rebuild one of their existing apps. Let’s try to rebuild it in the new design system and see how they work. What are we missing, what didn’t work out as well?
All of the design system projects I’ve done involve anywhere from 4 to 9 pilots of, “Kay, let’s get an inventory of this stuff. Let’s build a small component library and then let’s try to pilot building these apps with the design system and then rinse and repeat from there.”
So you start with almost a minimum viable design system in a way, right? And you test it out with the organization to make sure that, not only are the components correct but that it’s built to suit the audience. Then you can expand it.
Absolutely. Nathan Curtis wrote a great article about the fact that a design system is a product. A lot of people see it as like, “It’s a website,” or “It’s a reference site.” Absolutely not. It is a product and you have to treat it like a product. It grows like a product, it gets used like a product. And for people to think like, “Yeah we’ll just create it once and then it’ll sit there.” They’re not realizing the value of it and they may not actually get value from it if they’re not treating it like a thing that also needs to grow in time and adapt over time.
In order for a design system to be successful, does it need a dedicated team to evolve and maintain and govern the system?
I’m split on the term dedicated.
So, I think if you mean somebody working on it full-time? I’m not sure. If you mean somebody who will pay attention to it when it needs attention, then absolutely. So I think it does need care. It needs sustenance. I think it needs people to pay attention to it when it needs attention. I think there are times that it can just kind of hang out for a little while while people are using it, but I also think that it needs to be able to respond to it. So if it’s one of those things that an organization doesn’t have any resources at all to devote to doing it, then it’s just gonna sit there.
I’ve been part of a lot of organizations that as they’re creating these design systems, they don’t have people to care for it. So most of the organizations that I’ve worked with have already had a design system at one point but it just was never cared for. It’s not like this is the first design system they’ve had, it’s sometimes the second or sometimes the fifth and with all the previous versions they’re like, “Oh well it was just one person’s pet project.” And then that person left the company and then it just sat there for a while. So I do think it needs some sort of sustenance and some sort of care to go along with it, to kind of grow. It’s like a product that doesn’t have a product team, it just sits there. And it doesn’t grow and then people get upset and frustrated because nobody supports it and they’re not getting answers to their questions.
In the same way that any good product has a support team, the design system needs a support team. Whether or not it’s full-time I think is up to it’s usage. But certainly it needs people to pay attention to it.
Is the cadence of maintaining a design system similar to maintaining an external product?
I would imagine that somebody that works at some place like Salesforce that had that Lightning Design System would have maybe daily or weekly updates to that. I would imagine other organizations that maybe use it more than they grow it. Maybe it could be bi-weekly to monthly, I’m not really sure I’m just speculating at this point. Not sure that I’ve seen enough to be able to answer that well.
For a design system, is it challenging to find that balance between ensuring consistency and inhibiting creativity?
Yeah, absolutely. A lot of the times when we’re doing interviews, a lot of the resistance to a design system is well, like, “Is it taking my job away?” Essentially. And that’s why I, kind of to the question you asked earlier, that’s why I’m more and more liking the definition of a design system helps you design, it doesn’t remove design from you. It doesn’t remove the process of, “I have to create a thing.” It just helps you do it faster. I think any good design tool is that.
I could make a website without Photoshop. I could hand code it. I could make graphics in Microsoft Paint. Photoshop makes it easier for me to do that. But when Photoshop came out, a bunch of people said, “Oh, this is gonna kill my job.” So any new innovation in design, people have that worry. Any new automated thing, people have that worry and they don’t realize, “Well yeah, any design tool that could take my job is also a design tool that could actually make my job easier. Help me do my job.”
So I think the same thing is true for a design system is that if you think about it solely as a component library and all you’re doing is making and assembling components, then sure it could probably replace you. On the other hand, most designers and developers at the organizations that I know have design systems, the design system doesn’t solve their problem. They still have some sort of user experience or customer experience that they need to think about. A design system should help them to do that, it should help them build those things faster or more efficiently or more consistently. It should help them to do that, it doesn’t take away the work. That’s why more and more I like that definition that it should help you design. The creative part and the problem solving part, you’re not gonna find that in any style guide, component library, or design system out there.
How do you figure out the workflow between a design system and the products it serves?
I think it can go both ways and I hate to give the “it depends” answer too much, but I think it does. I’ll say that I’m working on a product right now and just this morning I went through with some of my team about creating our design system for it. We’re starting to create that now. One of the things that we talked about was let’s just be really scrappy about how we’re gonna build this. Let’s build one-offs as many times as we can. And then if we find that we’re building the same one-off 3, 4, 5, 10 times, then we codify that into a pattern. We’re taking that approach to how we’re doing this is like, “Let’s not worry about whether or not this rolls into the larger thing. Let’s do it on a small scale and then as we see it cropping up more and more and we get tired of repeating ourselves, then we’ll roll it into the design system.”
So we’re gonna keep the design system very, very small and it’s gonna be just the things that we know are patterns and we know, okay, we don’t need to reinvent that wheel anymore. And then as we see more and more of those things, then we’ll start rolling them into the design system. I like that approach, that’s a approach that I’ve recommended to a bunch of my clients is like, “Don’t be too aggressive on everything’s gotta go into the design system because that’s a way to bloat the thing.” So rather than bloating it, instead just be very vigilant about what things make it in and what things don’t. It’s okay to build a bunch of one-offs. And there’s gonna be a little bit of inefficiency there but that’s okay as long somebody’s noticing. As long as you notice, “You know, this is the fifth time we’ve built this thing this way. Maybe we should patternize this somehow. Maybe we should say okay, this is a common thing and we need to reuse this solution more and more so that’s when it rolls into the design system.”
How do you measure the success of a design system? Are there certain metrics you communicate to clients?
Absolutely. I think the most obvious one is time spent. Like with a lot of clients, when they say, “Hey we want to make a design system.” At that point, even if we’re not starting work together, I’ll say, “Great. Measure the time it takes you to do this thing right now.” So like how long does it take you to build an app? How long does it take you to build it? And you can generally, you can translate that into dollar amount. The amount of time a salaried employee spends on it times their salary for the amount of time they worked on it times the amount of people working on it, right? You can quantify that fairly easily, or roughly. And if you can say, “Well look, this took us 6 months before and roughly 375,00 dollars. And then after the design system it tooks us 3 months and it cost us 175,000 dollars.” You can make a very good case as to how that’s gonna work out.
So before and afters tend to work well. It’s not good for … If I’m at a company, I’m trying to convince my boss to make a design system, I don’t have numbers, so I don’t have a before and after. But I think the more other organizations start to publish that stuff and become more public about that stuff, it’ll be a lot easier to say, “Oh, look at Salesforce numbers, here’s how much they saved by having a design system. Look at Airbnb and Spotify.” These companies that have been very public about their design system work. I’m hoping that in time they start to publish some of that stuff too and in the same way that they’re publishing their code and their design style and their component libraries, I would hope that they would publish some findings about, “Here’s what it’s saved us. Here are the benefits of it from a bottom line standpoint.” And other companies can look to that and say, “Look, there’s a path here already. There’s logic to this and so we can make a good case for doing it ourselves.”
Have you worked on any design systems that created surprising results?
Almost every time. I don’t know that I can point to any specific thing or at least talk about any specific thing. But especially because we get a lot of users in before we’re done building the thing? I think part of what, I don’t know how to explain this, part of the value of a design system is to be able to point to a thing as a showcase piece. ‘Cause we could say, “Hey look at this cool design system.” But if no one can understand what you can make with it, then it doesn’t matter.
Having people come and work with it early and then when the design system launches, also launching with a gallery. Here’s a gallery of stuff that people have made already with it and you’re looking at those things going like, “Wow, I didn’t even realize you could make this.”
One of the organizations I worked with, they tended to use Material Design as their design system before they had something custom and in house. And they had a bunch of people making amazing things with Material Design. And once they had their own custom design system, people that were doing things with Material Design were creating things with their own design system and saying things like, “Wow, we couldn’t even create this with Material Design as easily as we could with our own thing.” Those are good testimonials, those are good rallying points for people to see within our organization look at what people are doing with this, look how much easier it is for us.
And the kicker of course is that it does have to be easier, you can’t fake that stuff. So it actually has to be authentic, it has to be genuine. I think the more and more examples we have of that, the easier it is to get more adoption.
Do you tend to help organizations build design systems completely from scratch or do you get brought in to improve an existing design system?
I would say that 90 percent of it has been we know we need a design system and we’ve had kind of starts and stops, but we just can’t figure out how to get this thing off the ground. And so a lot of our work tends to be how do we help organizations get to a v1? And part of that is because it’s not just making a tool, it’s different than making a website, if we were just making the website part of it it would be easy, but the reason that the design system is so hard to get off the ground is because it requires organizational change. It requires people to have different mindsets about how they’re going to work.
For example, if you have isolated design and engineering teams, a design system isn’t gonna do you very well because a design system requires collaboration between designers and engineers. If you don’t have a culture where that already exists, in order to even know that that’s gonna have adoption, you have to start to change the culture to say, “Okay now we’re going to be working together in a different way.” And that takes a lot of work.
So a lot of our work around the design system tends to be not making the tool but really coaching the teams on okay, here’s what it looks like to be more collaborative, here’s how you work on it. Here’s how you shorten your cycles from 6 weeks to 3 weeks because you’re working on pieces and you’re working on atomic parts and you’re working on collaborativeness. And you’re not building in this very waterfall, you design everything and sketch and then you throw it over the fence to this person. It’s all that organizational change that comes with it. It’s not like going away, making a website. It’s more like how do we coach people to work better together? And then once I understand that, what tool can even further facilitate that? And design system is a good example of that.
A lot of them can’t get it off the ground because they don’t know how to do that piece of it. They like help, so we tend to help with stuff like that. Very rarely have I come in to like, “All right we have a v1 already, here’s a v2.” And the reason for that I think is fairly obvious, which is that once you learn how to work collaboratively you can do anything. That’s the key. The key is being able to work together and if you can work together, you can solve any of the problems. So one you get it off the ground, you’re already along that train and then the v2 solves itself because you already know how to work on it.
At a organizational level, can a design system becomes reroute and improve your workflow?
Totally.
I’m not sure that the tool itself forces collaboration but it certainly a catalyst in encouraging that type of work. Just having a design system isn’t magically gonna make an organization work better together, but the process of making one kind of forces these situations that maybe an organization hasn’t had before. And then they go, “How do we do this? Wait what do you mean we should sit together and work? What do you mean we need to reorg the way that our organization is structured? What do you mean we need to have a design system team? Why do we need to do that?” And it kind of forces those conversation. So it’s certainly more of a catalyst for it than anything.
Do designers on a design systems team need a development background?
Certainly not a requirement. It’s funny, I just did a talk about this yesterday. I was talking about that at the O’Reilly Design Conference. It’s definitely not a requirement. You can create great digital experiences, and some of my favorite collaborators are designers who have never touched a lick of code or developers who have never, never don’t admit to being designers at all. I think it’s certainly possible to make great things without that.
I do think it helps though. I think that … And the reason is is empathy. The reason is that the more I know about what my collaborators are doing, the better I can help them, and the better I can serve them. The better I can take work away from them. The more they can take work away from me. So if I’m working with an engineer, if I could say, “Hey, you want me to write that JSON file for you? You don’t have to worry about it.” That helps that person out and they can focus on something else that’s more worthy of their skillset and their time. Vice versa, they can take work away from me.
I find that the more we can do each other’s jobs, it’s just means we can help more. If I don’t know how to do what you do, I can’t help you. I don’t think designers coding is a requirement but it’s certainly helpful because it means you can jump in.
Have the processes of creating design systems evolved over time?
It’s interesting because a lot of organizations and teams say that they’re agile. And then when you get into their nitty gritty, you’re like, “This is not agile.” What it generally tends to look like is, oh the engineering part is agile but then the design part, the graphic design, the UI design, whatever you want to call it, that part is the waterfall part. We’d design stuff first and once all the design requirements are done, then we can get agile about this. And that’s not the way to do agile.
I think that a good design system will roll everyone into the same process. Whether that process is a waterfall one or an agile one. I’ve seen it work more successfully in flavors of agile and that’s how my team tends to work, is in that way. I think that the process of sort of rolling it out, keeping it up to date, is one that needs to work like any good product design cycle and it’s not a coincidence that generally a lot of product design cycles are centered around an agile workflow. I think part of the trick is how do you get designers involved in the agile workflow? Because a lot of designers feel like they’re at the outskirts of that and don’t really know how to be involved.
UX designers is a little bit different. UX designers and engineers tend to be a good pairing. But graphic designers or people that are doing UI design don’t quite know how to fit in to that. I think part of that is how slow they move in their tools. I think they need better tools like a lot of people will take a full day to bang out a comp in Photoshop or 2 days or 4 days in Photoshop or Sketch. And that’s not conducive to a very fast moving, nimble environment.
Designers, graphic designers, need to beef up their skillsets in getting faster at the work that they do. So that they can fit into a more rolling process and need to be able to bite off smaller chunks. Which engineers have learned how to do over the years. I’ll work in a way that is modular and work in a way that is … I can break off different pieces and measure those pieces. So designers haven’t quite figured out how to do that as an industry yet. So I think that the more designers can fit into that, then they’ll fit into a cycle that fits naturally with Agile.
So how do you see design systems working with Agile?
I think the design system fits in the way that any good digital product project process works. Everybody’s seeing, everything’s transparent, you’re seeing what everybody’s doing. That’s what the agile process does, it exposes those things through rituals like daily stand ups or retrospects or things like that.
What I find is that designers don’t know how to do that generally. They don’t know how to fit with that. And I think part of it is just the chunks of work are too big. So engineers know how to chunk their work down into things that you can measure, things like velocity or work in progress limits or depending on the flavor of agile. Designers are like, “Well I have to design the product inside and out.” And how long is that gonna take? I don’t know. It takes as long as it takes. Well you don’t have to design the product. Design the header, how long is the header gonna take? Oh, 2 hours? Great, chunk it up in that way.
I think as designers are sharing more often, I think if they are exposing some of that process more often, then they start to get in that flow of, “Okay, let me show something that inspires someone else. And that person’s work is gonna inspire mine.” And kind of let them riff off of each other. Like that’s what a good agile process does, is it allows this kind of double dutch thing of somebody works on something and somebody else works on the same thing and somebody hops in there and then somebody else, like it kind of builds on each other rather than, “Let me do my part and then I’m done and then it’s your part. And then your part can’t influence mine because I’m done. Because I said I’m done.”
And so by chunking that up, I find that that’s a very useful way. It’s a very simple but useful way to figure out, “Well let me just share a little sketch of what I’m doing, let me share a piece of what I’m doing.” It’s a bit a cliché now, but I think that it works. It’s like share small pieces more often. And designers, of everyone in the process, are the most guilty of not doing that. They share larger pieces less often. ‘Cause they feel like they gotta do the big reveal thing and they’re afraid that if they reveal something too early or too late that people aren’t gonna see all the things in it. I think that if you give your team credit for being smart and being able to see through certain solutions, see to the end of it even if it’s not fully realized, I think that actually opens up the door for a lot of good value.
Does the modular nature of design systems facilitate an Agile design process?
Maybe, I’m not sure. I haven’t really thought about that too much. I think that certainly design systems help designers be more agile because it makes you faster. I could simplify it more to be like anything that makes you faster helps you fit into that process. ‘Cause the process is about speed at some point. There is a reason that Scrum measures things in velocity. It measures workflow in velocity. It is factor of speed, it’s about how quickly you can get things done. And sometimes it’s about- it’s not about fidelity quite yet, it’s really just about pace.
A design system at some level would probably help you to do things faster. It’s a good tool for speed. And I think tools for speed help designers, engineers, everyone to fit more in that process because they can make more in a shorter amount of time and then share it. And say, “Here this is done, everybody check this out.” Or, “Look at this and tell me what I need to do in the next cycle for it.”
I think that designers, maybe of all the industries so far, don’t have the tools for speed as much as other industries do. And so I think that the more we get better tools for speed, design system being one of the major ones, I think the better we’ll be able to fit in.
What design systems do you find particularly interesting or inspiring?
I’m not sure that I can name many digital ones, other than the usual suspects. I think one, I’ll say that any design system is a major feat. Launching one, creating one, maintaining one is a feat in itself so if you have a public design system out there. Congratulations, that’s an amazing thing. As I think about those, Material Design, Lightning Design System, Harmony by Intuit, Glue from Spotify, the Airbnb, the companies that have been very public about theirs are … Those are major feats at those organizations. So those are great.
I will say the ones that I learned the most from … And it’s not to knock the digital ones I just think that it’s too early in our industry, we’ve only been around for whatever 30 years, and we’re still getting our bearings on what conventions are. So a lot of these style guides, a lot of these design systems are not specifically design systems for the implementation that they’re in.
For example, Material Design isn’t just a good design system for Google products, it’s just a good design system for anyone building for the web. Same thing with Airbnb, same thing with Lightning, those are all good for general best practices. I think what those are starting to do is they’re starting to create conventions for us as an industry for the designers and the engineers as an industry. Because they’re giving us things like, “Oh this is generally what navigation should look like.” And it’s no coincidence that navigation patterns and tabs patterns across all of those design systems are pretty similar. ‘Cause they’re starting to surface these conventions.
When I read some of the design systems in the print world or specifically the NASA style guide and the MTA brand guidelines, as I look at those design systems those to me feel very mature and they feel like they help me to design. If I was designing for the MTA, I would know exactly what to design and what to design for. Because the brand guidelines are so thorough. Not only do they give me the pieces that I need but they also give me the logic and the mentality to know how to design for those things. I don’t know that I’ve seen or could recall a lot of digital design systems doing that.
So when I work on a design system I try to focus specifically on what makes for a good design system for this organization? Not generally on the web but for this organization. What are the patterns that they need that maybe others don’t? And those are the things to focus on for the design system. How many tabs can you design? How many interfaces for tabs can you design? But is there a specific way that this organization uses tabs that is custom to them, that if they had this out of the box it would actually advance their work? It would make them faster at it.
So those are the types of things that I try to focus on. I’m not sure that I’ve seen them in a lot of digital design systems, and partially because I don’t know the requirements for those organiza- I don’t know what Spotify needs, I don’t know what Airbnb needs, so I’m not sure what I would even be looking for there. I think those are the things that I try to focus on in my work.
If you could speak for a couple minutes with somebody who’s about to start creating their first design system, what would be your most important advice?
It’s a tough question. If I could only give them one piece of advice, I would say talk to people. Talk to the people that are gonna be using it, find out what they need, and then spend all of your time on that thing or on those things. I think it’s easy to get caught up on making design systems that look like the ones that are out there already, like, “Oh this is the convention, this is the guideline so let’s just make more of these.” And I don’t know that those are necessary. And I certainly get caught in that trap all the time. Like, “Well, Salesforce looks like this so ours should look like this too.”
But oftentimes you’ll find out that people in the organization, they don’t need that stuff. Sometimes they do and it’s good to know that and sometimes they don’t and it’s good to know that too. If I were to give advice to someone, I would say, “Talk to as many users are you can.
Talk to them about what they need and just build that stuff. And as soon as you build that and no sooner or no later, as soon as you build that thing see if you built the right thing.”
Talk to people and then test as early as you can to make sure like, “All right, is this what you said? Is this what you meant?” Oftentimes you’ll hear a “no” and the earlier you hear that “no”, the better chance you have of getting it closer.
