DU039 – Design Systems

Transcript

The Design Untangled Podcast

Episode: DU039 – Design Systems

Host: Chris Mears and Carla Lindarte

Guest: Liam Harberd

Duration: 32:08 minutes

April 29, 2019

(00:17)    Chris:  Hello and welcome to Design Untangled with me Chris Mears and Carla Lindarte. How are you?

(00:25)    Carla: I am very good. How are you?

(00:26)    Chris: I am very good. It is nice and sunny in the UK for once.

(00:28)    Carla: I know, and it is going to be a great weather on Easter weekend. So it is good.

(00:32)    Chris: Lots of melted chocolate, but this would not be going out until after Easter, so that chocolate will be long gone I think. So we have got a secret guest on the line as well. Do not worry. Someone who has been on the podcast before, on our second most popular episode.

(00:51)    Carla: Oh, is it the second?

(00:52)    Chris: Yes, second most popular. Hello, Liam.

(00:55)    Liam: Hello. Second most popular? Yes, I did not know that. Who is the first then?

(01:00)    Chris: Monzo, of course.

(01:01)    Liam: Oh, okay. Well yes, I will take that.

(01:04)    Chris: Yes, that is not bad, is it? So we have brought you on here today to help us talk about design systems, because I know that is something you are talking a lot about, at the moment. Here to give us a bit of a helping hand. So do you want to give us maybe your definition of what a design system is and how it is different to pattern libraries and style guides?

(01:28)    Liam: Yes. A lot of people talk about design systems and say, yes, we have got a design system. But the more you dig below the surface, you realize there is lots of different things that people are calling design systems. And I have been at big global companies that are saying they have a design system, but whatever they are using is, a pattern library. A pattern library is basically something that aids the UX and visual designers to be a bit more consistent in the way that they do. So for me, a full design system is something that goes beyond that. So yes, it is the pattern library, but it is also the hand off of that pattern library to the developers. So, in theory, there should be a live, living version of the pattern library that has been coded by the front end developers. But it has been built with both the UI and the front end developer, sitting next to each other and making sure that there is almost an exact replication of the two. And then once that is built, you can put that into a live URL so people can access it. And you know, people are probably very familiar with Google’s material design, which is probably the mother of all design systems. A full stack system, and hundreds and hundreds of pages of detail around the patterns they use, the shadows, the interactions, everything. But it can be a lot more simple than that as well. It can just be kind of what would have traditionally been a style guide, probably a brand guidelines, a PDF that talks about what font to use, what colors are used. It can be kind of as simple as that, but in kind of a living space, such as a coded library.

(03:34)    Chris: What do you think are the main advantages of having a design system versus just a style guide? Or is it that it does not get lost in translation once it goes to development? Is that kind of the key benefit do you think?

(03:49)    Liam: Yes, and not just development, even designers. Anyone that works in digital for five years plus, or will know first of all, the pain there is between kind of what the design looks like at a design level, and what it looks like once the developers have coded it and handed it back to you. And that is never kind of the Zionist fault nor the developers fault, but with the traditional kind of way of working, there’s a lot of room for era and ambiguity in between the design stage and the drove site. The system for me kind of joins those two areas up. It kind of forms one source of truth in between the development stage and the design stage. And it is built with both teams, at once. So you build it once, you make sure it is right, you make sure it is consistent. And then, from then on, both sector teams should be just pulling from the same source.

(04:54)    Carla: I have a question related to that point, because I have seen it when I worked at Sapient, and also at Google. That design system tells me basically, from an internal perspective, it just like a website that you can access, and then all the different information as you said, is there, for both designers and developers. But to your point about, you build it once and then everyone uses it. I wonder how, in your experience, or what are your thoughts around making sure that the design system keeps being up to date? And what I mean with that is, that you could have designed a design system that looks like four years ago, where obviously things were very different from a design perspective. So how do you make sure that that design system, it is consistent and everyone is going to the same source? But at the same time, it does not become something old and oblique. And how do you evolve it basically?

(06:07)    Liam: It is really important of any design system that someone does look after it and it is maintained. There should be someone or a group of people that are put in charge of owning that system. And yes, if someone leaves the company, they should pass that kind of responsibility onto an another person. Design is an instructive process, and very rarely now, these days we put an app out to market or website app to market and then, that is it, we just walk away from it. We continue to kind of see how it is performing, we retest it, we change bits, and the design systems made, it should fit into that overall workflow. When those things are tested, when those things change, the library should be updated, and all the people that need to know, the lead developers, the lead designers, should be an inherent part of the workflow these days of a digital product.

(07:12)    Chris: So in terms of getting that feedback loop, back into the design system, either free stuff you have learned in research, or new kind of ideas you are trying, how does that process work? Say you have found a better way to do a certain pattern. What should the workflow be to get that basically back into the design system? And then if you have used the older version of that pattern before, how do you go about bringing that up to the new standard or the new way you think it should be done?

(07:44)    Liam: If things are being done right, we should be using tools like abstract just kind of skim over the top of what that is. But, it is essentially a design tool, which it hooks all the designers up to a kind of a master, either Sketch or XD file that they all feed from. So in theory, anytime we are starting on, even new, on a project or, they have worked on a project, whenever they start their days work, they should not be pulling from a file that is local on their drive. They should be going to the cloud and pulling down the latest file, so that helps the consistency that makes sure that they using the latest stuff. They kind of create a branch and then, say they have got some user feedback that the button should be darker colors, it is too light, they should create a branch out of Abstract, which pulls down the master Sketch file, XD file and then they can make changes within that and then they push it back up to the cloud. And there should be a notification system, if the workflow is set up, right. And there is lots of different ways you can do that. And it depends on the project, the team, the amount of designers and developers and model. But there should be a notification system that then alerts the front end developer. Obviously, we can use traditional methods of just tapping them on the shoulder and telling them, but in a digital world, maybe they only find out by this kind of notification. And then they will update the front end code to replicate what is going on in the library. And then you can either push that back out to testing or if you have gone around in that loop a couple of times, you can then push that out to their kind of the live website or

(09:37)    Carla: I have a question. What would be the governance around that? If you think about, let us say a big organization which would have designers and developers in different places and they decide to change the color of the button, for example, as you just said, is there a kind of a governance model where someone approves that?

(10:01)    Liam: There should be a governance level? I have worked on projects where there is design teams in fourteen different countries, each design team with ten plus designers and they are all pulling from the same source. So, if there was not a government’s level it, maybe that is an extreme example, but if there was not a governance level there and people could just update the master file, as they wanted, it would be chaos. It would actually be a worse way of working. But yes, there should be an admin, a lead experience designer that is owning that, or it could be a number of people, but it should be at least one person that has that final approval. Also, in that situation, there is multiple designers working on multiple branches at one time. And when they tried to merge their file back into the master, there is this within, I am thinking of abstract example, there is a notification system for the admin of that group, to say, there is a conflict here. This person is trying to upload this, this person is trying to upload this. And you get to choose which method, which option you want to go forward with, or you can push it back and get them to work together to kind of merge their options and then push it back into the account. Does that make sense?

(11:33)    Carla: Yes, I just have a question, just like stepping back a little bit in the process of creating a new design system, what is the best practice about creating it from scratch? Do you think that obviously all key components, global components, and key components of pages should be designed from the beginning before you kind of roll that out? Or do you think that it is still fluid and a work in progress process where everyone kind of fits into the master design system?

(12:14)    Liam: So it depends where you start your project. Obviously, you could adopt a digital product, so you might as a team, take over the work of other design teams. So a website that is already live or an app that is already live and in the market but that has not got a design system. So in that case, you start by doing a design audit of that product. So, you pull each page apart and you kind of work out that there are six versions of the same button. They might have slightly different rounded corners, or slightly different tone of color, or the font sizes might be different. So you start to see patterns then, so that is one way of doing it, doing a design audit. If you are starting from the ground up, of a brand new product, I do not recommend just starting to design buttons and different components in isolation. I think you start by doing concept designs of key pages. Obviously, you will have the feedback loop with the client, or the internal stakeholders. Once you are at a stage where you think, okay, this is how we are going to move forward. This is the design we want move forward with, then you do an audit of the way that is done so far. And at that stage you might only have a few components that you can play with, but if you start breaking them down, you have got the start of your design library or your design system. And then as you move through your sprint, you continually add to that library and that design system. In terms of kind of creating a system, obviously you need everyone thats is involved like, the lead developers, the lead designers any kind of technical functional leads that are going to be involved as well. Sit them down on day one and say this is what we want to achieve. And I really recommend a pro tip, is just to start easy with your design system. Try by just pushing that one button through the system, design it, get it in Sketch, push that into Abstract, pass it over to developers just with one element. Do not try and do too much at once, because you will soon see the flaws and it is much easier to fix if you have only got one thing going on.

(14:44)    Chris: So obviously we have been talking a lot about design systems as they apply to digital products, like websites, snaps, and so on. Have you ever seen them used for wider purposes, like offline print advertising?

(15:06)    Liam: Personally, I have not, no. I did have a conversation in the week, actually, with someone that was talking about a team of print designers who are working for a brand and they started to talk about if they could use a design system. I do not see why that would not work. As a brand, you have still got key elements. You have still got the fonts, the colors, maybe certain kind of branding items that could live in a system that people could kind of pull from. But personally I have not worked on one.

(15:36)    Carla: I guess a lot of the branding guidelines that you normally would get, when you are doing a redesign, or a design of a new product for a particular brand that already has some branding guidance. I would say that, they are kind of the design system equivalent of that. So you have all the colors, or the way the copy, the way you should be referring to the brand. And basically, all designers in digital, we kind of do a translation of that for digital products, but they are mainly based for print, for advertising, for everything else. And they are actually quite specific, but they normally tend to be a PDF document. In my experience, that is what I have seen so far. I guess there is not a any limitation of turning that into a digital system where everyone can go and access it. But what I have seen so far is just a book, or a PDF that you could argue that is their design system. I was going to ask something around, just changing slightly the topic and going back to digital. How do you, or what is the UX element of a design system, because obviously you come from a visual design perspective more. But when you think about behaviors, or think about interaction design, or even motion design, and things like that, how do you document that into a design system? Because before, and I come from the old world of actual where you annotated wire friends and annotated things on a component library equivalent. How does it change in a system like Abstract, for example?

(17:36)    Liam: You would not necessarily document that stuff in abstract. It is probably the stage on from Abstract. So when you move into this living library, if you of a material design, or any kind of online design system that you have seen. Airbnb have got a great one, and Spotify, et cetera, there is lots out there. But if you go into that, that becomes almost you are referred to these kind of printed PDF guidelines. These new digital design systems become an online version of that. And within there you might have a page dedicated to interactions and you have seen that on a material design. If you click, you can go in and you can see all the kind of the motion design, the interactions and even talks in real detail about whether it eases in, and it bounces out, and all of those details. So that is where that information would live. Abstracts is merely a tool to version control, and maintain the design files.

(18:52)    Carla: Okay. Makes sense. Do you know what systems or things, I mean, how can you build a design system, an equivalent of a material design website, within the organization? Is it just an a CMS, or in your experience, what have you seen as being the tools that you use to build those systems? Or those internal website or external websites?

(19:25)    Liam: So again, there is kind of lots of tools out there. Invision Design System Manager or it is called DSM. It is a very good one. I think you can almost plug straight into. You can build your own, if you have got talented developers that they might prefer to, it depends on your project, but if it is very bespoke in its nature, you might want to build your own. There is a tool called Storybook, which developers use, which is something kind of an open source, off the shelf product that people, developers use, so you can plug in to. So, there is lots of different tools and ways of doing it.

(20:06)    Chris: So if I was someone saying we have got a pretty good style guides and I have not had any issues with it so far, how would I be convinced to move to this? I guess more elaborate design system, which covers a lot more basis than just kind of components. What would be the benefit for me, one, as a UX designer and two, as an organization?

(20:32)    Liam: I think design systems have risen out of the fact that these PDF guidelines just have not been working. And for years, as digital designers, we have been aligning ourselves to what was happening in the print world as Carla mentioned earlier. But there is lots of room for error if you have just been handed a PDF guidelines which talks about the font sizes and the colors, and this is what buttons should like look like. There is lots of kind of holes in between that information, and lots of room for designers to kind of get it slightly wrong. And the more designers that are getting it slightly wrong, the more design debt you end up with. So as I mentioned earlier, you might end up with six versions of the same button. A primary call to action, even though it is a red button with white text on it with rounded corners. If that tone of red is slightly different, if that font size is just one point out, it is a different version. Which, it does not matter necessarily until you need to make an update. If two years down the line, and lots of big companies do this. They go for a brand refresh and they say, oh, now our brand colour is changing from red to magenta. That is when you see the problems. Now, just to quickly update the colors becomes a big job. And I was working at a huge company last year, kind of a global company. The one I mentioned earlier, kind of about 40 different countries. They went for a brand refresh, and it created months of work to go back and update all the existing digital assets. If it is zoned systems done well, and done properly, changing the colour of the button between the design files, between the live code design system, it should be, an hour tops. And you go from weeks or months of work, to an hour of work. That is when you can really start selling the business benefits back to the client.

(22:47)    Carla: I think my last question was more around you mentioned that there are different tools to have these websites build and also all the tools to make sure that those quick updates are connected to the code of the website on the CSS or the CMS. So how often do you see that design system being changed? Obviously, it is when you do a rebrand. But is it as you add more features, or more pages, or what is the best practice? Should you be changing that design system frequently?

(23:34)    Liam: It depends on the stage of the project. I am working on a project now. It is a brand new product. We are just setting up the design system. We are just going through the early stages of sprints and designing new kind of elements, components every day. So the design system is updating on a daily or hourly basis. Obviously, that project will get to the point where it levels out and it is out in the market and it would slow right down. But then, as I said, you start looking at the performance of that and you might go back and start changing elements. So it really depends on the stage of the project. But it should be something that is maintained. Absolutely. Even if you push it live and you do not make any changes for two years. When you do make those changes in two years time, the design system, the library is where you should start. And go back into that workflow you are using.

(24:36)    Chris: If you had to marry one design system, what would it be?

(24:39)    Liam: I do not really have an answer for that. Again, it really depends on the project itself. If you have only got two designers, two developers, you might not need a design system at all. If you have got a slightly bigger team, you just need a very light touch version. If you have got teams around the world working on it, you need a much bigger one. All I would say is, that an end-to-end design system is not just a pattern library, but an end to end design system, however big or small it is. Or whatever product you are using to pull it all together. You should use that because it is really that collaboration between front end development and designers in the middle that really makes design systems work or fail. If the communication, or the way that is set up, is not right the pattern library is going to break down, the front end assembly teams, the guys that are building the pages, that is all going to break down, and not work. And you are left where you were originally, anyway. So just having a very tight team in the middle of it, collaboration design and developers. That is my favorite bit, getting that right.

(25:58)    Carla: Yes, because, I was going to ask a controversial question, but I think you already answered it. Which is who is between the UX and UI designer, who has the responsibility of designing and creating that design system? But I guess, you answer is collaboration. There is not a UI or UX role, is it?

(26:24)    Liam: It is a design and developer role, and design can be UX or UI or other things. But it is that collaboration between design and developer, which is really important. That is the difference. And that is for years, or my whole career, the most painful bit of a project, is handing your designs over to the developer and seeing what they come back with, a month or two later.

(26:57)    Carla: And it looks horrible.

(26:57)    Liam: Yes. But that is neither the developer’s fault, or the designer’s fault, it is just the way we were working. So we were quite aligned to the print industry where you just throw things over the wall. But now for the first time, yeah, we have design systems. It really create one team, which includes developers and designers. And the handoff process is a lot more streamlined. There is far less room for error. The consistency is better. And as a result, of the back of that, the user experience is better, because there is far less in consistencies in your experience.

(27:39)    Carla: Definitely. I totally agree with you. I think there is still a lot of big clients who still practice print being applied to digital. Hours of hours of time refining files in Photoshop to make them look absolutely perfect. Knowing that perfection of a desktop looking design is going change so much in a responsive design environment. So I think yes, you said it is just an evolution of designing for digital and doing everything digitally first, rather than print first, and then send it over to digital to try and make it work. So I think it makes a lot of sense.

(28:21)    Chris: Yes, and it is something I think has been quite popularized by startups, because of the necessity to be able to kind of produce and roll out features very quickly. But not features that look completely different to one another. So I think that kind of rise of startups, and fast working, but still producing kind of consistent UX and UI, I think that has driven this way of working, quite a lot.

(28:48)    Liam: Definitely. And it just allows you to scale a lot better as well. If you have got a solid foundation, a solid system in place you can quit the days of spending hours laying out individual pages in Photoshop, kind of gone. It depends on the maturity of your design system and your pattern library. Anyone should be able to pull those components out and create a page quite quickly, and even do that in a live environment. So you are presenting almost live designs to a client, as opposed to pixel perfect Photoshop files, which is what we did. Just printed out and stuck on the wall.

(29:34)    Carla: Yes. Well, we used to do it, right, but it is not to same anymore.

(29:37)    Liam: Yes. And not that long ago, and we were talking a couple of years ago, we were still doing that. But yes, I think things have moved on a lot, in that time. I mean, design systems are not necessarily a new thing, but they have become very popular in the last couple of years.

(29:55)    Carla: It is more like they have, isn’t it?

(29:57)    Liam: Yes. Developers have been using systems in their work, for decades, and it is only really the design industry. Again, because we have been very aligned to kind of the legacy of the print wowed and where we have come from. But we have only just kind of recently, starting to realizing the benefit of using the system ourselves.

(30:18)    Carla: If people want to learn more about designing systems what kind of books or resources you think they could get to try and go deeper into this?

(30:33)    Liam: There are loads of stuff online. You just have to type in design systems in Google, or search engine of your choice. And there is loads of stuff, loads of videos. For me, the place I keep ending up back is InVision and doing loads of stuff around it. There are loads of tutorials. They have got books and digital books, and they have obviously got their own tools to help manage it as well. So yes, for me they have been a really good source to kind of learn and get up to speed.

(31:08)    Chris: Carla, do you want to plug your judging thing again? I think this episode will go out, just before that.

(31:12)    Carla: Yes. So I have been fortunate to be invited to be a judge for the D&AD New Blood of Works on the 29th of April. So I hopefully will be able to interview people there, and ask questions about trends, in types of creativity, et cetera. So if you want to know something about how the D&AD works, just contact me, ping me, and let me know what you want to know. And I will tried to find answers and I will try to interview people there as well. Which should be fun.

(31:44)    Chris: Cool. Well thanks for joining us, Liam.

(31:47)    Liam: No worries. Thanks for having me.

(31:49)    Carla: See ya.

(31:49)    Chris: See you next time.

(31:50)    Liam: Bye.

Narrator:  Search and subscribe to Design Untangled using your favourite podcast app and leave us a review. Follow us on the web at designuntangled.co.uk or on Twitter @designuntangled. Become a better designer with online mentoring at uxmentor.me.