The Clearleft Podcast

Today on the Clearleft podcast: do you know what a design system is?

So I think a design system is ...

Oh, the biggie. Oh!

I mean there's different definitions. I'm not sure if mine is right right now.

Maybe it's wrong to sort of try and pin down a design system as one particular thing.

Yeah, it is a hard thing to pin down.

I guess this isn't such a straightforward question, but I'm going to try and get some answers.

I'll be talking to a few designers here at Clearleft, Jon Aizlewood and James Gilyead.

You'll also hear from some people who used to work at Clearleft: Charlotte Jackson and Paul Lloyd .

My name's Charlotte and I'm a product manager for a company called BCG digital ventures in Sydney.

I'm Paul. I'm an interaction designer, a front end developer, occasional speaker.

And you'll hear from Amy Hupe who worked with the Government Digital Services team, GDS, on the design system for gov.uk.

I'm Amy and I am primarily a sort of content designer. But I have also in the last few years moved into being quite specialized in design systems and right now I'm actually not working as a content designer. I'm working as a product manager on a contract basis, product-managing a design system.

Alright, seriously, what is a design system?

A design system is an ongoing discussion. Maybe it's an audit log of discussions.

In every case that I'm aware of, a design system is a library of documentation, which documents the kind of standards and conventions for your outputs.

It's basically a repository of often used patterns and behaviors that are consolidated in a singular place.

There's a library of components with guidelines for their usage but then there's a full system or piece that can naturally include so many other parts like brand and design and things like that. So I think there's probably a discussion that I haven't had for a while around what the different parts of called or what what you name your system, whether it's a design system or component library. I think they probably are different things .

I think when we talk about a design system, that's the thing that most people will picture: very discreet bits of interface or big kind of flows and user interactions, and while I believe that there are some very important aspects of a design system that don't fall into that image or that definition, like contribution, like operations, like distribution and all that sort of thing, I think being realistic, a design system does mostly come back to that kind of that thing that you picture when you say the word design system.

We as an industry, we seem to be quite willing to just let terms become meaningless quite quickly.

Design systems aren't a new thing. You know, these things have been around for a long, long time. But then on the web and in the web industry, it's like, Oh wow, there's these design systems. Ooh, these are new things. And it's like, these have been around for centuries, but you know, on the web they're like these new discoveries.

Okay. I'm hearing two things here. On the one hand, we're using the term design system to talk about a thing, a collection of interface patterns and their documentation, you know, buttons, headings, form fields, all that stuff.

But it also sounds like a design system can be even more than that.

It's a mindset

Yeah, people get very conceptual about design systems. There is a very sort of prevalent statement at the moment, which is that, you know, a design system is just systematizing your design.

I prefer to talk about systematic design.

So what I mean by systematic design is designing only the things you need, but in a systematic way so that anything you need in future can build on the system you are building. So it's not a finished thing. I think a design system to me sounds like a product which is finished, and that you hand over to somebody for them to kind of take on.

I think a design system sounds like quite an intimidating product, whereas systematic design is something that anybody can get involved with at any point.

I do support that view. But I also think if you look at the reality there isn't that much variation in terms of what that looks like in practice. Yes, it is a method of systematizing your design, but the method itself is quite specific.

You could, I think, have a design system that is simply just tone of voice and language with no components whatsoever.

I think as long as the system itself addresses a problem and makes addressing that problem every time you see it faster, I think that's a successful design system. So it doesn't have to be full of these components that are all shiny and new and et cetera. I think it's, as long as it makes it easier to get the job done, I think that's a success personally.

I think in digital design, there's probably an element of a kind of systematized thinking, but I think it moves up a level when you make it explicit.

And I think if everybody agrees in an organization that a systematic approach is worthwhile, then it's hard to argue against.

As I said, like design systems aren't a new thing and you know, design and design on the web, especially, I've always thought this, you know, it should be systematic. It should have, you know, logic to it.

Well, even if we can't all agree on exactly what a design system is, there seems to be broad consensus around what a design system is for.

It's supposed to save time and bring consistency.

Efficiency and consistency.

Efficiency and consistency are definitely things that the Gov UK design system has in common with pretty much every other design system out there.

I think for government services in particular, it's very important that they are uniform, and that they feel recognizably like government. Because it's important. It's important that they sound official. It's important that they all do the same job and they will treat you in the same way when you move through them as a user.

So consistency was definitely a consideration for us. I would say we were aiming more for uniformity than complete consistency.

Consistency is the watchword with design systems. And that has never sat well with me. Because one, I don't think there's actually a user need for it at all. Unless the user is the designer. Consistency is entirely driven by designers own needs. Like they want, and again maybe I'm just speaking for myself but I see this in others, like they want consistency.

Designers want consistency. This is what drives them. But I've seen in testing, I remember we were doing some user testing on the Guardian website and we had this journey and it went from the old design to the new design and back to the old design. And like, we're like, Oh, will this test well? You know, this is gonna probably disrupt the user journey. And nobody noticed that the pages were totally different. And we were like really worried about it. I mean, we were fretting over all these different bits of like, they were just focused on the task in hand and hadn't noticed anything else. And I think ultimately, if you're using the same font, same colors, you know, broadly the same, that's consistent enough for most people.

So the whole idea of design systems being this, you know, being done to make things consistent. I just feel like there's, there's actually very little evidence that that serves much need.

I guess the true benefit of a design system is that it increases efficiencies and it increases process, but for the better.

It's there to be a process that people can basically just do their work faster. And I hate to say it, but design systems can ultimately be kind of brought back to capitalism because basically they just mean industrialism at its core. Right? You're just, you're, you're getting the workers to do their work faster so that you can get more out there.

But what if you built a design system and no one came?

I don't think very many design systems tend to hire a dedicated community manager or engagement manager.

I think more are starting to now, but historically, like that hasn't been a role that's been part of a core design system team. And so often when you look around at design systems across the industry and you have people who are performing that kind of role, it's often done alongside their main job.

And it's often people who have this kind of natural tendency towards wanting to collaborate, wanting to work with other people, being quite strong communicators, and being able to build relationships.

I went to Ansarada. I went to work on their design system

Seeing how long it was taking to get the design system really embedded into the company was was really interesting 'cause I've never seen that before.

I was building a lot of components but I kind of knew that a lot of the teams weren't really using it. And that kind of started to bug me a bit. Feel a bit flat if you're just building something that people aren't really using.

So I did a bit of research on that. I went around to various people I went to I spoke to all of the developers to find out what was the reason they weren't using it. What was what was their like daily role? And where did the design system fit into their work? And how come they would just create brand new components and bypass the design system? 'cause that's obviously completely defeats the point of having it. Like it's supposed to save time and bring consistency.

Once I had spoken to everybody I put together a bit of a case and I listed out the challenges I'd found and what I thought we needed to do in order to increase adoption. And I spoke to the CTO and the CPO at Ansarada. And basically just shared this plan and said like this is what I think we need to do. And they gave me permission to give it a try.

So that was... that was fun. It was it was tough. It wasn't an easy easy thing to do. There were lots of people that I guess resisted. A lot of people resisted the idea.

I think people get so enraptured with the design system as it is in their product team that they can't necessarily any longer see it objectively. And I think it's then really, really useful for a third party agency who has the street cred and the ability to understand design systems and what they should and should not do, to kind of come in and say, look, do you know what? It's either a) working really well. There's no issues. Or b) there are some kind of concerns here and we can recommend how you might want to fix those things.

And what we do is basically just do a bit of a design and dev spike to kind of look at what they're doing, shadow them, look at their processes, look at kind of how they use the design system and what it's actually doing, and then start to provide kind of some insights and recommendations on what they should be doing next.

I don't think a system should ever stop you from being expressive or being creative. I think it should guide you. And the moment that you feel like you're working against the system I think it highlights the fact that there's probably something wrong with the system.

Naming things is hard. It's hard because you have so many pieces and you need to find like a consistent structure, a system, and something that makes sense but also it needs to be a shared language that everybody is adopting and on board with. So it was just as hard to come up with the right names that felt like they made sense as it was to get everybody to continue to like use that .

Contribution was a really important aspect of making sure that the design system was representative and that it actually kind of did the things that it set out to do.

Everything would go through our team before getting published. And there wasn't, you couldn't pretend that wasn't the case. So it was never kind of, anybody can just throw anything in there.

And I think that's quite important, for like the users of the system. But yeah, for the most part, we always really tried to encourage contribution from outside of the team and from across government because ultimately those are the teams that are working much more closely with users than we were. So they were going to know much more about how to solve users problems in the services that we're working on.

I think I'd had such a passion for design systems before getting to Ansarada. I spent all that time at Clearleft working so closely with them and getting really into them and speaking about them that I just couldn't really …I just couldn't really sit at my screen and keep building without finding out what was going on.

I guess you know it's the same with anything really. If you're building a website then no one visits or you're building a product that no one uses. No one ever downloads your app, you know, you feel, like, what's the point? I need to find out why.

So it was it was like that really. Yeah I wanted to speak to everybody and understand what was the barrier? And it turned out you know there were various various things. But I didn't just speak to developers. I spoke to many different stakeholders.

Like product managers. Because product managers were prioritizing work and also very keen to get their I guess features and and whatever else was in their roadmap out as soon as possible to their deadlines and hit their quarterly goals. So if anything was slowing down the engineers then that was not not great. So they would be encouraging them not to use the design system if it was slowing them down. So I spoke to them. That was really key.

Spoke to designers who were obviously supposed to be designing for it. But yeah that, you know, there was no consistency. I mean there was consistency but it was not a hundred percent there because designers weren't using it sometimes as well or they weren't contributing to it. So it was, you know, it was it was an interesting challenge.

I remember once hearing a thought experiment about Coca-Cola, it went like this.

If tomorrow all of Coca-Cola's factories, trucks and infrastructure disappeared, the company would still be able to rebuild. But if tomorrow everyone in the world would undergo a form of collective amnesia and forgot that Coca Cola existed, the company would go out of business.

I think it's meant to be a story about the importance of branding, but perhaps it could be applied to design systems too.

Let's say your company has a design system manifested in the designs code and documentation for all your product's interface elements. Now, what would be worse: if everyone in your company suffered collective amnesia about your company's processes and priorities, but your design system remained intact?

Or would it be worse if everyone retained that knowledge but your library of components disappeared in a puff of smoke?

The answer to this hypothetical thought experiment might just tell you what a design system is for you and your company.

I think design systems personally are becoming a bit fetishized in this industry. I think people now are at risk of potentially making design systems in order to make them public.

And in order to kind of say, look at my new shiny, without potentially realizing, understanding the true need of them. Right? Which is ultimately, it's there to be a system.

I think clearly different companies require different things of their design systems, and you know, when you, if you're thinking about building one, you should be thinking about the needs of a particular organization rather than sort of trying to look around at what another company's done and trying to replicate that. It needs to come from, what needs to be achieved within the company or within your particular team.

I think we all think of something like Material Design, which is excellent and probably necessary for an organization like Google. I think a lot of people feel like they're important enough to have something similar, but actually you can end up creating loads of overhead, lots of complexity, which doesn't actually serve your own requirements.

Where design systems are useful and what they end up being about, is about communication. Between designers and developers, between designers and stakeholders. And that's when they work best. And if approached in that way, then I think they can be really useful.

The best design systems also bring in user research insights as well. And the less narrow they are, potentially, the better they can be.

Thank you to Jon, James, Charlotte, Paul and Amy. You've been listening to the Clearleft podcast.

And clearly we're going to have to return to the topic of design systems in a future episode. There's a lot more to discuss. I feel like we've just scratched the surface in this episode.

In the meantime, if you need a partner to help you with a design system, get in touch. Whether you need strategic advice or you want to work with experienced experts in the area of design systems, Clearleft can help you. Send an email to info@clearleft.com and we can take it from there.

If you have any feedback about the podcast, send an email to me, jeremy@clearleft.com. I'd love to hear from you. If you're enjoying the podcast, pass it on. Tell your friends and share your recommendations on social media.

Thanks for listening.