How to Build a Better Design System

Paul Boag

On this episode of the Boagworld Show we are joined by Aarron Walter to talk about the value design systems can provide to organizations.

This weeks show is sponsored by Balsamiq and FullStory.


Paul: On this episode of the Boagworld show we're joined by Aarron Walter from InVision to talk about the value design systems can provide to organizations.

This season of the podcast is sponsored by Balsamiq and FullStory.

Hello and welcome to the Boagworld show, the podcast about all aspects of digital design, development and strategy. My name's Paul Boag, and joining me on this week's show Marcus Lillington and Aarron Walter.

Good to have you on the show, Aarron.

Aarron: Oh, pleasure to be here.

Paul: It's been a while, hasn't it?

Aarron: It has been a while. How are you?

Paul: I am really well actually. I'm very mellow and chilled out. The weekend is almost upon me. It's a good time.

Last time I spoke to you I think you were still at MailChimp, and you've been at InVision for ages now, haven't you?

Aarron: Well, I guess "ages" in technology time, if count that. About two years at InVision. A little break in between there. But yeah, it's been a while since we've seen each other.

Paul: Yeah, absolutely.

So how is life at InVision? You guys are doing so many cool things at the moment. I've been keeping up with it and it seems like you're putting out brilliant free … I mean, how do you guys make any money? You seem to give away so much from the Craft plugin to books to all kinds of stuff. So you're busy.

Aarron: Yeah. We are very busy. And that's one of the reasons why I enjoy InVision, is there's just a lot of smart people working really hard on things that we feel passionate about, that is meaningful.

We want to try and help the design community, and just design as a discipline in general, evolve and march forward in the way that … You know, engineering has done that in the past and now design is and its own power space is becoming a really critical part of the work that companies are doing.

Getting strategic advantage and tooling is part of that. We've been using other tools … We've been using photographers tools to make interfaces for years. I mean, for goodness' sakes. Paul was just saying that he had to close out of Photoshop, and clearly that's not a tool that's built for-

Paul: Interface-

Aarron: … what we do necessarily.

Paul: No, no.

Aarron: Yeah, we've been sort of faking it.

So the work that we're doing at InVision feels very meaningful to me personally because I have been involved in product design, lead product design teams, and …

It's not just the tools part because you put a hammer in someone's hand and it doesn't make them a carpenter. It's also the practices we're trying to push forward.

And we see a lot of teams figure out how to do design better, how to, basically, communicate design out. There are a lot of people problems that are involved when design starts to scale. You mentioned the books at that we've been writing and producing. We also have a podcast, the Design Better podcast.

Paul: Oh, do you? I didn't know that.

Aarron: Yeah, we do. And we talk to fascinating, interesting people like Irene Au at Khosla Ventures; David Kelly, who founded the Stanford and co-founded IDEO.

Paul: Wow.

Aarron: Tons of interesting people.

Yeah, it's really fun work.

Paul: What I really like is you kind of hit it at the all the different levels. So yeah, you provide … I mean obviously there's the InVision tool itself but you provide kind of hands-on user interface tools like the Craft plugin and that kind of thing, which is great. And then you've also got kind of the middle layer where you're talking about design systems and some kind of the processes and things that people need to put in place.

But you're got also this design leadership thing that you've started doing as well.

Aarron: That's right.

Paul: Tell us a bit about that. That sounds very exciting.

Aarron: I guess a little bit of backstory here is that because we've got relationships with millions of designers and thousands of teams are using our products, we end up talking to people a lot in the design space. And this common theme kept coming up that designers had found themselves in a leadership position, a lot of times a little under-prepared, because they don't actually teach management and all these key leadership things in design school. And so people were going to incredible lengths. Like Stanley Wood, who's at Spotify, he took two weeks personal time off, hopped on a plane, and flew out to California and met with two dozen companies …

Paul: Wow.

Aarron: leaders at two dozen companies, on his own dime, to try to figure out, "How are you guys running your team? How do you handle leadership things? How do you communicate bigger ideas out to the company?" And he just filled up two Moleskines, on that trip, of notes.

Paul: Wow.

Aarron: That's extreme, to go to those lengths.

Paul: Good for him.

Aarron: Yeah, no kidding, no kidding.

Andy Law, who's at Netflix, found himself in a similar position. He manages the mobile team: designer and individual contributor trying to figure out, "I think I could step into this leadership thing. But how do I do it?"

He read a huge stack of books, he talked to a bunch of engineers, he talked to … you know, in leadership positions. He talked to people in other companies. He was trying to figure this out.

So we saw this as a pattern over and over again and we thought, "It shouldn't be that hard to try figure out design leadership."

So we've recently launched a new … "It's a community that we're just trying to help kickstart" is the best way to describe it. And that's called the Design Leadership Forum. You can learn more about it at Basically, it's a group of design leaders who have direct reports. They're operating at scale, producing products for lots of different types of companies, from Charles Schwab to Google and everything in between. So we get together and we have these kind of intimate gatherings, honest conversations about what's most difficult. And those conversations are moderated so you're making time to go meet with people but the conversations are productive.

And we've had Bob Baxley who's … Do you know Bob Baxley, by the way?

Paul: I don't, no.

Aarron: Awesome, incredible guy. He was at Apple for eight years working under Eddie Cue and Steve Jobs. He led the team that created the Apple online store for the first time-

Paul: Oh, nice.

Aarron: … right before the iPhone launch.

Paul: Wow.

Aarron: The things that he's done in his lifetime are amazing.

And he's just got this lucid, down-to-earth way of drawing people into the conversation, getting them to ask questions and share their wisdom.

So yeah, these Design Leadership Forum events have been great. We're doing a design leadership camp in Hawaii.

Paul: I was gonna say you've made this sound all very worthy, and, "Oh, yes, we're going above and beyond." And then you turn around and say, "Oh, but we're doing it in Hawaii."

Aarron: People need to recharge their batteries, right?

Marcus: We need to go, Paul. We definitely need to go.

Paul: Oh, at the moment.

Marcus: Being leaders, you know, of design teams. Oh, you're not, are you? I am.

Paul: I'm not a leader. But also I don't think … There was a key word that Aarron used earlier which is "at scale." I don't think being a leader at Headscape counts as at scale I'm afraid. You don't-

Marcus: You know, I might learn something.

Paul: I'm sure you would. But yeah, you don't get to go to Hawaii. You're just trying to avoid the snow here is what you're trying to do.

Marcus: No, I'm not. All of this kind of chat's all very well and good but I'm just watching the heavy snow coming down outside my window. It's lovely.

Aarron: Damn.

Paul: What's it like in … Where are you? Are you New York? I can't remember.

Aarron: I'm not. I'm in Athens, Georgia.

Paul: Oh.

Aarron: The town's known for REM, the B-52's, and these days it's like Drive-By Truckers, Of Montreal. I don't know. Maybe you've heard of those guys.

Yeah, it's great town. And I've been here for 18 years.

And InVision's remote so I can work anywhere.

Paul: Oh, nice. That's nice, to be able to work remotely, because you've got family and stuff like that haven't you?

Aarron: I do, yeah.

Paul: So being around them's great and …

Aarron: You want to hear something crazy, guys?

Paul: Yeah, go on.

Marcus: Go on.

Aarron: So when I worked at MailChimp I lived in Athens and I drove about 60 to 70 miles.

Sorry, I don't know how to translate that in my head to kilometers.

Marcus: We do miles.

Paul: Oh, we don't use … We do miles in Britain.

Aarron: Okay. So yeah, it's like an hour and a half drive each way to MailChimp and I calculated that I drove the circumference of the earth six times.

Paul: Oh no, that's awful.

Aarron: It was 272 full days, full 24-hour days, in the car.

Paul: You shouldn't have calculated that.

Aarron: I know!

Paul: That's the most depressing thing you could have done.

Aarron: It is. But I'll tell you, Paul. You know what I was doing in the car?

Paul: Listening to audiobooks and podcasts.

Aarron: I was listening to Boagworld.

Paul: Oh!

Aarron: I did. I listened to you guys. I listened to every episode during that period.

Paul: Wow.

Aarron: Thank you both for getting my through.

Paul: Yeah, is it … Mind, did it … Or did it just make things worse? It's hard to tell, isn't it, sometimes?

Aarron: I loved it. I've learned so much from you two.

Marcus: That's fantastic.

Paul: Oh, I have real trouble believing that. Your track record is far more impressive than ours, I'll tell you.

And so now you're doing your own. Are you actually hosting the podcast that you were talking about or is that other people from InVision?

Aarron: I am, yes.

Paul: Oh, cool!

Aarron: It's me and my colleague Eli Woolery. He's a Stanford guy. He teaches in the, teaches the capstone product design course there.

Paul: Oh, right.

Aarron: So he and I we do the podcast together. And it's a blast. It's not news to you two, but it's just a great excuse to talk to interesting people.

Paul: Yeah, absolutely. Yeah, I need to … And you sound like you had some good guests lined up for that. I think I might have to branch out and steal some of your guests.

Aarron: Oh, all right. Do it. They're great.

Paul: One of the downsides of being here in little old England is that I don't necessarily know all of the names of all of these different people, you see, because it's a different circle of people over here. So it'd be quite interesting to steal some of your guests and some of the American figures that are doing some interesting stuff, so I might [crosstalk 00:11:58]

Aarron: Well, I'm in little old Athens, Georgia, and I just call people. I just get on the phone and talk to people and kind of get to know who's out there, and look on Linkedin. And other people say, "Oh, have you talked to this person?" So …

Paul: I can see the problem. You do research and put effort in.

Aarron: That's true, I do.

Paul: Yeah, that's never been my strong suit really, actually working for a living.

So you enjoy working from home after years of commuting?

Aarron: I do, I love it. It's really magical.

You know, it's interesting this whole remote culture thing, I think we're over 500 people at this point at InVision.

Paul: Wow.

Aarron: We're in roughly 28, 29 countries. And people, just, they move and they work in lots of different places. It gets a little tricky if you're in Australia and you're working with someone on the ?East Coast but we make it work.

Paul: So does InVision have no central office at all?

Aarron: None. No central office.

Paul: Wow.

Aarron: Yeah, we're totally distributed. I don't think there are too many companies that are as big as we are and as remote.

Paul: Yeah.

Marcus: [inaudible 00:13:15]

Aarron: And so I think that Automattic, the folks that bring us WordPress, they are bigger than us and there is certainly a lot we can learn from them.

But, you know, it's great. We have calls with one another, and we have the BBC moments where someone's kid comes marching in the background.

Marcus: Oh yeah.

Paul: Oh yeah, that's the best part of it.

Aarron: And it's great because … Like yesterday I was on a call with a colleague and his daughter was sitting on his lap. There was one point where I had a call with Clark. You probably know Clark from InVision, in emails.

Paul: Yes.

Aarron: And Clark was talking to me on his phone through Zoom. He was sitting on the floorboards in the backseat of his van, and he was calming his one-year old, who was in his car seat, and they were driving down to Florida to visit family. And it was a productive conversation. And I saw his father-in-law, I saw his wife, his son …

It's so human. And it's humane. I think that's the best way to describe remote work is that we're allowed to live our life and time-shift a bit and connect and get to know each other's pets. We see the insides of people's houses. It connects us. I think that's really, really cool.

Paul: I think it can work like that if you've got the company culture to support it.

Marcus: Absolutely, yeah.

Paul: It's being comfortable that it's okay to have a work call while you're trying to calm your one-year old or it's okay if your toddler walks in while you're in the middle of a call. But not every company's like that-

Aarron: That's right.

Paul: … and it's establishing that right kind of cultures that makes it acceptable I think.

Aarron: That's true.

Marcus: We have quite a lot of client calls, and it's funny to watch the younger members of our team … I'm thinking of Ian, our developer, in particular, who's got two kind of quite loud young girls. They're, I don't know, five and seven. I'm not sure exactly how old they are. And you can see him working the mute button when he's on a call. Somebody asked him a question and there's a delay. It's like, "Heads up, girls!" But it works.

Paul: It's lovely.

Marcus: And that's with clients.

Paul: Yeah.

Marcus: And they don't mind.

Paul: No.

Marcus: No one … It's great to hear kind of like kids playing around in the background.

I would miss having … Because we've got a little office that we got into a third of our time. And I love getting together with the guys two days a week and I'd miss that a lot. But then I guess if you want to be 500-people big then you can't expect everybody to live around one city.

Aarron: It gets to be really hard if you're located in one place, and real estate, parking. I mean that was a big challenge for us at MailChimp was we just couldn't find a place for all of us to fit, and we couldn't find a place for all of us to park. There's a significant logistical challenge as you start to scale.

Paul: And also finding good people as well.

Aarron: That's right.

Paul: With InVision they can select anyone from anywhere in the world-

Aarron: That's right.

Marcus: [crosstalk 00:16:27]

Paul: … and that enables you to get the people, doesn't it?

Aarron: We do have a lot of interesting people. Our illustrator is in Scotland. Yeah, people are all over the world.

Paul: I think that's brilliant.

Anyway, let's … None of that, so far, has anything to do with what we're supposed to be talking about today. This is the universal problem I have with this podcast. We get interesting people on and I go off on massive tangents.

We're supposed to be talking about design systems but before we get into that I just want to quickly mention FullStory who is one of our sponsors for this seasons.

FullStory is an amazing session recorder tool. I think it's the best one out there personally. It's the only I use all the time.

Aarron: I agree.

Paul: And I'm currently running it on my homepage.

What's great about FullStory is you can integrate it with all kinds of other tools. And that has a lot of potential to it.

For example, UserVoice is something that you might have come across, which is a tool that allows customers to raise support tickets. So if you integrate something like UserVoice and FullStory together then you start getting very interesting because every support ticket that you receive has got a link to the user's session so you can actually see the user session. What that means is you can do much faster diagnosis, so no more cumbersome back-and-forth trying to work out what it was that they had the problem with. You can actually see it.

But also, more than that, because FullStory actually records the whole DOM and the whole experience of actually what's going on, you could debug it. It's got a console for error recording and you can look and developers can pinpoint exactly what when wrong in order to be able to fix it.

And then obviously as well you've got those session URL's, which means that you can share those around with your engineering team, other people within your support team, so that they can learn, "Oh yeah, this is a problem and this is how you fix it." If it comes up again you've got that record there.

So far this season we've talked a lot about how FullStory is great for improving usability and things like that, but it's a really good customer support tool as well.

So you can sign up for it and get a free month of their pro account for free, which will give you a chance to really try it out and put it through its … Yeah, you know what I mean. But if you get to the end of that, and you might want to use it a low level, maybe with some of your customer support queries, to be able to judge certain ones, you can continue using it for free for up to a thousand sessions per month. So it's certainly a very useful tool to have. Just go to

Okay, so design systems.

Aarron: Well I gotta say FullStory is awesome. I gotta put in a little plug, and also tell you something crazy, which was I was present when the idea for FullStory was conceived.

Paul: Oh, were you indeed?

Aarron: Yeah, that team sued to work out of an office inside of MailChimp.

Paul: Right.

Aarron: It's just genius the way it works, the way it records. You can do things like search for any time a CSS class, like the class "error," shows up, and then go watch that session. It's just … Those guys are brilliant.

Paul: You know, the trouble I always find whenever I talk about FullStory, and I tend to gush about it a lot, is people go, "Oh yeah, we've got a session recorder already." No, you-

Aarron: It's not like this.

Paul: Not like this. It's totally … It just is mind-blowing. How it works … I mean they must be from a technological point of view … There are some smart cookies in that company.

Aarron: That's right. Former Googlers that left and got together.

So yeah, it just records the whole DOM of a page and all the deltas. So the capture the DOM and then they look at every delta in the DOM as it changes, and they just play it back like a video.

Paul: Unbelievable. Really is.

Aarron: Yeah.

Paul: Anyway, let's talk about design systems.

Now the reason I've got you on to talk about design systems is you were the person that I knew within InVision, and you guys have written some really great stuff on design systems recently. Now that wasn't actually you, was it? That was someone else within the company, is that right?

Aarron: The book … It was my team that produced that book, and we worked with some really great folks. People like Jina Anne. She led the team that created Salesforce Lightning system. Also Roy Stanfield from Airbnb; Diana Mounter from GitHub; Katie Sylor-Miller, who's at Etsy. All the contributors are working on design systems on the front lines in one capacity or another.

Paul: Excellent. So just for people listening to this show, and probably for Marcus, let's be honest.

Marcus: Hey.

Paul: How would you define design systems? What is it as far as you're concerned?

Aarron: Design systems … Not so long ago it was just about creating some standardized components. So we could reduce tech debt by having the same blocks of code, reduce design debt by having the same button styles, typographic styles, grid structure, form elements, etc. And some people call that a "component library."

And then that kind of evolved into something bigger, which … That's what we call a "design system." And that contains things like the voice and tone, so how we write, design principles. It might also have animation.

IBM's design system, for example. I love their examples where they've got … They show the tape reels from the 60's that were data tapes, and how they would move with this momentum, and that is how their loader animation, what it's drawn from, that exact same movement, which is brilliant. It's bringing that history of "Here who we are, here's what we've made," and bringing that into the design today.

So a system is deeper. It's more than just the components. It's a broader philosophy about the design.

Paul: So that's how it's different from, say, Brad Frost's Atomic Design or a pattern library or something like that. It looks at design in the broadest sense.

Aarron: That's right. And I think Brad's Atomic design approach is … It's a great framework to help us just understand how do we break things down into smaller pieces, and then how do those pieces, once they're in their smallest units … they're atoms … how do we combine them together into something bigger, into pages, into interaction, products, etc.

Paul: Creating a design system is not a trivial undertaking. You know, there's-

Aarron: No, it's not.

Paul: … quite a lot of work involved with it.

So what value does it bring? If there are people out here, they're listening to this who know that it's a worthwhile thing to do, maybe they work in a fairly large organization, say a university or a reasonable-sized business or whatever else, that are managing a big broad range of sites, a design system makes a lot of sense.

But they're gonna have to carve out time to produce this which means they're gonna have to persuade someone of the value. How do you go about doing that? What is the value of a design system?

Aarron: The values are myriad. There's a bunch of values.

And I think the easiest way to visualize that and get a sense for it and communicate it to skeptics, who may not work to stop the presses on the things that you're making and invest a bunch of time in this design system, is to do a UI inventory.

So you go through your product or your set of products. If you're in a big company that's acquired a lot of products and other companies, and just screenshot every element. Start with buttons. Screenshot every type of button that's in your product line; screenshot every form element; screenshot every typographic … type header; all these different elements, and put those in a big deck, like a Keynote deck, PowerPoint deck, and flip through those. And look at all the variation of all of these elements.

It's such a brutal punch-in-the-face way to show the cost that you're paying by not having a design system because you can see … Think about, "Okay, how much time would it take someone to create a new product or a new feature if this is the Lego set they're working with? How much time and effort does it take our engineering team to support code for all of these things? How much time does it take for pages to load? How does that influence the customer experience? How much confusion and time does our support customer team invest in talking people through how to use the product because it's so inconsistent and confusing?"

And then also think about the ideas that you have of "This is where we wanna go this year, this is our roadmap, what we're excited about. How much time will it take you to execute on that?" I guarantee if you have a design system, executing is going to be a lot faster.

So to be able to produce new things faster, reduce tech debt, design debt, reduce customer support volume … I mean, the value is very deep, which is why this is the topic that …

Doesn't matter if you're the chief design officer. I just had a call yesterday with Meriah Garrett, who's the chief design officer at USAA. She was talking about design systems. Or you're talking to an individual contributor. And everybody in between, they're talking about design systems, because the value is so concrete and palpable.

Paul: And also it never hurts when you're talking with skeptics to through around names of organizations that are adopting design systems because it adds credibility to it.

You mentioned IBM already who have released their design system. Are there other companies that really have got standout design systems that are worth referencing?

Aarron: Shopify has released a really great one in the past year. It's called Polaris. And theirs is great because it's so well fleshed out that it's not only component library but it's also a writing style guide, talks about their design philosophy.

And they've got, if I remember correctly, five, maybe six locations, design studios, in each of those. And how do you unify those teams across all those locations? You use a design system, that's how you do it.

Paul: Yeah, yeah.

Marcus: I always thought BBC GEL is an excellent example of a design system.

Paul: Yes.

Aarron: Yep, they do have a great design system as well, and it's something they're still working on and refining. But yeah, it's a good one as well.

Spotify, not to be confused with Shopify, but Spotify, has a design system as well called GLUE. And I think everybody knows Salesforce Lightning. That's a really big one that's familiar.

At this point you'd be hard-pressed to find too many companies without a design system at all, but they're in various states.

So the first state is usually that they live inside of Sketch or Illustrator and the designers are just sharing a file in Dropbox, which is kind of the … Yeah, it's a pretty clunky, clunky way of doing that. There are a lot of problems. If you change something does everybody get the same thing? Overwriting people's work … There's all Kinds of issues with that. And also, how do you communicate that out to a developer?

So the high-level version is that you've produced a website where there's components and there's code and all these different things.

But yeah, design systems are popular in lots of different types of markets.

Paul: So you've talked about the kind of basic design system and how these things evolve over time. Where do they go after that basic level? What's the next stage up or where are they heading in terms of improving them?

Aarron: Well in my experience we started with some sort of a design file with the components and then that gets coded.

So this is another thing that's very interesting to me about design systems is that it's one of the few topics where designers and developers are on equal footing, and they get each other because they're talking about design debt and tech debt. It's the same thing. They've got a common cause that bring them together, and so it's a great way to build relationships between different teams.

But that next step is to involve a developer to actually code these components out using CSS or Sass and various other things to make that efficient and easy to maintain. So that's usually the next step.

And then beyond that, if you've got it coded and designed how are people gonna use it? They're gotta learn about it so you need some sort of documentation.

And if they start using it, now what? What if they misuse it or they start to abuse it and modify it? Well then there's governance.

And a lot of times we see that when companies get sufficiently far along with their design system it affects the org chart. So they'll have a central team … And this is a phrase that you'll hear in a number of companies is that you staff your design system like a product, not a project. And so you've got people dedicated to that product, which is the design system, supporting it, maintaining it, evolving it, governing it. That is like a central team that other remote teams can kind of come back to for design conversations and discussions.

Paul: Yeah, absolutely. And that idea of having to evolving your design system over time, I imagine is a very important one, because your product's gonna evolve over time, your brand is gonna evolve over time, and so as a result your design system's gonna have to do that too.

So what mistakes do you see people making a lot when it comes to design systems? Where do things typically go wrong?

Aarron: Things go wrong around communication about the design system and getting people involved. I think that the easy part … As hard as it is to create a design system that's actually the easiest part.

The hardest people is getting to adopt it. Just think for a minute, "What does it mean to adopt a design system?" It means redesigning your product or a whole portfolio of products. How does that work? Can you do it piecemeal? There are some ways to do that but it's kind of hard. Also, how does that translate across platform? That becomes technical and tricky, and Nathan Curtis has written a bit about this and talked about this. If you go to Medium and you look for Nathan Curtis you're gonna find a lot of great articles about what he's done. And he's been involved with design systems and helping companies create them for probably longer than anybody else that I know of.

But he often creates like a middle layer, like an XML file that will translate Sass into iOS and Android code so that design system can be deployed across different places.

One mistake that I have heard that people make a lot is not versioning. Versioning the design system allows you to carefully roll into something without breaking a ton of stuff across the company. We were mentioning the Design Systems Handbook on earlier. Katie Sylor-Miller at Etsy, she talks about that a lot, and she knows from experience that not using versioning creates just a hairy, crazy mess.

Paul: I think that's generally true in most situations, isn't it?

Aarron: That's right, that's right.

Paul: Going back to what you were saying about multiple devices or across devices, how do companies typically deal with that in their design system? From a kind of visual design perspective rather than necessarily a coding side, are they trying to create almost separate design systems for each of these different platforms, or are they trying to create a consistent design language, and how do they do that?

Aarron: Well it's a little tricky because if you're trying to create a design system that works for a web app product how does that translate into iOS where components are very different? And in fact every few years Apple does a major iOS rewrite and a lot of times those components change. And then of course Android has a different style as well where certain menus and interactions happen, are different than iOS.

With a design system we want to create a unified experience but it doesn't mean that everything is the same. So there are places where you need to bend and think about, "Okay, we're gonna do this different for Android than we would for iOS, and we're gonna do this differently on iOS than we would for the web app itself." Paying attention to those differences are and not trying to make those conform exactly across the board is key. You can keep the spirit of a design pretty well, like typography, hierarchy, color, general … Like, form can be consistent. But there are some details that have to shift.

Paul: I mean that's actually a really interesting area, that whole area of flexibility versus consistency.

For example, I mentioned universities earlier. We work a lot of in the higher education sector. And one of the things that inevitably happens there is that different projects that come up for a digital team within the university may have very different branding. The business schools in universities always seem to want their own branding and … There's a particular research project that is being done collaboratively across many different universities and that's got its own branding. And all of these things need to be built. And when you're building with a design system it can feel potentially quite constraining in terms of forcing consistency across that. And that's actually one of the reasons I quite like BBC GEL because that kind of demonstrates how you have flexible, different visual appearances while still keeping consistency in certain areas.

Have you seen other examples of that or is that a relatively unusual problem?

Aarron: No, it is a common problem and it definitely makes things a lot more difficult.

I mean that's essentially what Material Design is trying to do, is sort of like the mothership of design systems, is trying to be consistent and provide some really good building blocks that can be tweaked. I mean if you look at the color palette for Material, it's huge. It's just massive. It doesn't look like some very concise branding guideline of narrow set of colors for consistency. It's really broad because they're trying to create flexibility in that system.

But you're right that when you get to a certain scale, if you have a big portfolio of products, you want the things to feel like they are of the same family but they're not exactly the same system altogether.

Paul: Yeah.

One last question I wanted to ask you I think at this stage was around what point does a design system become valuable? So what I mean by that is it very much depends on the size of your organization. You can understand if you are the scale of the BBC for example or the UK government or whoever that else that absolutely a design system makes sense because of the enormity of what they're trying to cover.

But a lot of the people listening to this won't working at organizations of that size. They'll be working at much smaller organizations. Having a design system, does that still make sense at that kind of scale? And when does it kick in, and is it a suddenly a kind of line from one or other if that makes … Is there a way of maybe trying it a little bit? You get what I'm … It's a really poor question.

Aarron: No, it's not.

Marcus: But I kind of want to add to that, because "Is there a design system lite?" I suppose is what I'm trying to say. Because as you said earlier Aarron, to get this thing to work properly you need to have a team looking after it. And it's kind of like quite a lot of our clients are just getting into the idea of having their own digital team.

Aarron: That's right.

Marcus: So to have another team to look after something like this is way beyond them. But these are quite successful companies. So where is the line where it's worth doing or is it not a kind of … there is a design system or there's not a design system. Is there kind of somewhere in between?

Aarron: Yeah, I think that's a really good question.

In my experience the need for a design system is connected to iteration. If you are working on something and iterating on it on a regular basis a design system is gonna pay huge dividends. If you are not iterating on it so much you're gonna optimize for … in a pretty extreme way and probably not the maximum amount of value.

Here, engineers, they talk about premature optimization. So if you're a startup and you are iterating, and this sort of contradicts what I'm saying here, but if you're a startup and you're working on a product and you're just trying to get the thing off the ground and get people using it and understanding it and you're learning so much, you don't quite know what that core component needs to be just yet. You probably know some of them, but there are some things that are still being figured out. And if you invest a ton of time in creating a design system when you're just trying to get the product right, your priorities are mixed up. But when you get the product to … It starts to be a bit more mature and you start to refine that product and you're gonna continue to iterate and add new features, new things. Perhaps there's new product lines coming. That's when a design system is really gonna have a lot of value.

I can tell you I know exactly when a design system became clearly a need at MailChimp, and this is an embarrassing story to share, but we had been working on this product on MailChimp as basically me and one engineer. I think maybe we had a couple engineers by that time, but the head engineer. And some new CSS stuff had come out. We could drop shadows, we could do gradients, all kinds of stuff. And I continued to add to and refine, try to make the product look like the future. Not like a 37signals app … at Basecamp at the time. And I got to the point where we deployed the code and we went to look at it in Internet Explorer and half the pages were unstyled. And we were like, "What the hell is causing this?" Well it turns out Internet Explorer at the time truncated … it was something like 255K of CSS. Anything after it would truncate, or if you had a certain threshold of selectors.

And it was so heavy. I had so much tech debt from this and so much design debt from overindulging that we had to roll back and just strip out a bunch of stuff. And so clearly at that moment I was like, "Okay, we need to …" We didn't call them design systems back then. We called it a "component library." "We need to reduce the weight here." Hopefully none of your listeners ever experience that embarrassing moment. It was crystal clear.

Paul: Well that is one way to make the decision, isn't it? Hit a crisis point. That can often … Especially when it comes to management as well, to persuade them. Hit a crisis point. Let it go horribly wrong and then they'll suddenly be on board.

That's terrible advice. Absolutely [inaudible 00:44:13]

Aarron: It is terrible advice.

Marcus: [crosstalk 00:44:12] awful advice.

Paul: Yeah, yeah. Don't do that.

All right. [crosstalk 00:44:17]-

Marcus: I've got one more question.

Paul: Okay, yeah, go for it.

Marcus: It just occurred to me when I was thinking about sort of how you can sell this into a smaller company, a company that doesn't have tons and tons of designers and developers within their ranks. Obviously a lot of their design work involves print as well, so can a design system involve print elements and can it deal with an entire company's design aspects, if you like?

Paul: Oh, yeah.

Aarron: Sure, yeah. Before there were design systems on digital products there were brand books. In fact, when we go back and we look at inspiration for design systems. Apple HIG, NASA's brand guidelines-

Paul: Oh yeah!

Aarron: … Mass Vignelli's brand guidelines for the New York subway system. So that's all a design system.

You know, it's interesting. As people in the web space … It's a lot of navel gazing, where we think, "Oh, we're tackling a brand new problem no one else has seen." Yeah, it's actually been done quite a few times before in different capacities.

Marcus: I guess where I was coming from was how can you kind of merge the two that they're looked after in a single place. I'm just spouting this off the top of my head.

Paul: No, it's good. Yeah.

Aarron: Yeah. I think that's interesting. And you could have a website where your design system lives and it also has branding guidelines, print guidelines, the whole lot.

Paul: It's interesting. One of the clients … I'm writing an ebook for a client at the moment that they want to give away. The client is a company called Frontify. I think they've sponsored this show actually in the past. And their product is very interesting from this point of view because they do exactly that, Marcus.

Marcus: Okay.

Paul: You could easily host a design system on Frontify because you can put pattern library information, components in there, all of that kind of stuff. But they don't stop there. You can also add your style guide into that, which is both your web-based material but also your style guide for print as well. It's got a brand portal where you can put up all the brand information and media libraries and all of that kind of stuff. So they're trying to do exactly that, create a kind of one-stop shop for all of this kind of information, which makes a lot of sense to me.

Marcus: There it is.

Paul: And they just-

Marcus: And my question is answered.

Aarron: And of course InVision is doing that with Design Systems Manager.

Paul: Yes, of course you are. I forgot that. Oops, sorry.

Aarron: And it ties into your design environment, your prototyping environment. You've got design systems managed. And we acquired last year and folded them into our products. And so you can deploy your design systems to a website as well for everyone to see, and there's version control. All of those problems I was describing earlier, we have seen those firsthand, and that's built in to the product.

Paul: And it's just so beautiful done as well the way that with the Design System Manager you've got the code and the design, it's all sitting side-by-side. It's all managed and versioned and all of that kind of stuff. It's very impressive and I feel really embarrassed that I got to mentioned it.

Aarron: Oh, that's all right. That's okay.

Paul: Not as embarrassed as what I've got to do now.

Actually, it's fine, because I've got to talk about my second sponsor, which from a certain point of view could be perceived as a competitor for InVision. But I maintain that they're not.

So the second sponsor for today is Balsamiq, which is a wireframing tool, and you could argue that so is InVision.

But actually I think there's a fundamental difference between the two, that InVision is very much aimed at digital professionals. It's aimed that people that are creating working prototypes and are managing design systems and creating more complete user interfaces.

While what is really interesting about Balsamiq is that they're not trying to reach that audience at all. They're not interested in appealing to people like me, for example. They're more interested appealing to our clients, our managers, our stakeholders. It's a tool for non-digital-professionals to express their ideas, so that you've got a better understanding of what they're thinking, what they're trying to achieve, so that as you go into a project and you start working with a tool like InVision, you've got a set of ideas from the various stakeholders about what their expectations are.

Now I know they're not design experts, they're not, hopefully, gonna be the people making the final design decision. But it is useful to know what's going on in their heads.

Now, sure, they could use pen and paper to do that, and pen and paper is an excellent tool for getting down those initial ideas. And Balsamiq has very much tried to recreate that simplicity of pen and paper and in some ways I think they've succeeded, because you can literally just drag and drop components into pages in a way that's actually simpler than having to draw it all out yourself. And of course you can move things around and place things in different places and try out different stuff.

So it's a really good tool if you're running a workshop and you wanna engage the people in the room. Many people find it quite difficult to draw their ideas, while something like Balsamiq is just drag-and-drop. And of course with pen and paper if you're in a workshop environment it's quite hard to change what you're doing and trying something different, while Balsamiq can be instantly updated.

And then of course if you're remote like we discussing earlier … Pen and paper already really works when you're in the room together. If you're working remotely then Balsamiq is a great collaboration tool.

So don't think of it as a tool for professional designers and developers, like many of the people that are listening to this show. Really it's a tool for the stakeholders that we're interacting and dealing with.

So anyway, you can give it a go yourself. It comes with a 30 day trail anyway, but actually, if you decide that you want to sign up, when you sign up and you enter all your billing information, if you enter the code "BALSAMIQBOAG," you'll actually get your first three months are free, which is even better. And you can do that by going to

So there we go.

We've talked about design systems and Aarron has already shared a load of great resources. There are a couple that I also wanted to point you at as well just so you've got a bit of further reading that you can do if you want get into this a little bit more. I wrote a post on this myself quite a long time ago that I have updated a little bit more recently that you might want to check out, which is How to create a pattern library and why you should bother. I'm still a little bit out of date. I don't use the cool, trendy words of "design systems." I'm still talking about pattern library because I'm stuck in the past. So you can find that by going to … I've forgotten what the URL is.

Marcus: "patternlibrary."

Paul: patternlibrary, yep. So that's a good starting point.

Then of course, there is the design handbook that has been created over … the Design System Handbook that Aarron was talking about earlier. You can get to that by going to

We also talked, didn't we, about Brad Frost's Atomic Design, if that's interesting to you and that's something that you want to find out about then you can find out about that by going to

I would really encourage you to check out the InVision Design System Manger that we talked about earlier, which is now a part of Craft.

So if you haven't used Craft you really need a slap round the head, because … There's two reasons to that. Either you're using Sketch … Although, actually, no, Craft is in Photoshop as well, isn't it, Aarron?

Aarron: Sorry, I was muted there.

Yes, it is. It's in Photoshop and in Sketch.

Paul: I always thought … I had it my head it was just a Sketch thing but it's not. It's in Photoshop as well. So I can't … You just get a slap round the head for not knowing about Craft. I was gonna give you a slap round the head for not using Sketch as well, but maybe I'm slightly biased over these things.

The final thing that I wanted to mention is a tool that I came across recently which looked quite good. I haven't used it myself but I stumbled across it but I wanted to share it, which is a tool called Lucid.Style, which is very much like the Frontify tool I mentioned earlier but it's designed specifically just for creating good design systems. So it's not quite as broad as Frontify, but enables you to organize all your design systems there as well.

So lots of choices available for you there, and lots of things to check out.

In terms of where to start with this it was really interesting that Aarron talked earlier by start by creating a UI audit. I've said exactly the same things in my notes. You start by reviewing and identifying all the various elements that you've got on the site and then also start to identify common elements that are reoccurring multiple times. And start just looking at ways of combining those similar elements together into a consistent library of stuff.

Stuff. I'm so eloquent aren't I? It's unbelievable.

And then start documenting that and the various variations that you need, just start having a look at what's there. Give this a go. It is definitely worth your attention.

Marcus, do you have a joke to wrap us up with?

Marcus: I do. And with the snow still coming down outside my window I thought to do a snow joke. I looked up snow jokes before the show started and they're really bad, but so … Even by my standards they're really bad.

Paul: Why? That's never stopped you before.

Marcus: Anyway, this is the best of a bad bunch.

What's an "ig"?

Paul: [crosstalk 00:55:43]

Marcus: It's a snow house without a loo.

Aarron: Oh.

Paul: Oh.

Now, Aarron, please tell me that you weren't so traumatized by Marcus's joke all those years when you were commuting.

Aarron: I love Marcus's jokes. They're great. They're great.

Paul: Please tell me you haven't started doing them on your own podcast.

Aarron: I couldn't do them justice.

Paul: [inaudible 00:56:14] so much [inaudible 00:56:16]. You're such a suck-up.

Marcus: Thank you, Aarron.

Aarron: You're most welcome.

Paul: I'm gonna talk over the top of the two of you now.

If you want to carry on talking about design systems, if this is something you're interested in and you'd like to bounce ideas around with other people, then by all means come and join us in the Boagworld Slack channel, and we can talk about it a little bit further there. You can join that by going to … sorry, … Forgotten my own domain name after 13 years., and you can sign up there.

Next week we're gonna be talking about how to test your user interface the right way.

But for now thank you very much for listening. Aarron, thank you for being on the show again. It's great to talk to you.

Aarron: My pleasure.

Paul: And hopefully it won't be quite so long before we talk to you again.

Aarron: I hope not. I hope to see you in person soon.

Paul: Yeah, that'd be nice. It's been a while.

All right. Thank you very much, guys. And good-bye.

Aarron: Bye!