Design systems for websites with Dan Donald of Zero Height

Speaker A: Foreign.

Speaker B: Hello again. It's great to be back behind the mic. My name is Andrew Armitage and we've had a short break from the podcast

Speaker C: over the last few weeks as things in the agency have been pretty busy.

Speaker B: But I'm delighted to introduce another episode of the Client side podcast. The show is supported by the agency I founded called a Digital. And, uh, as well as podcasting, we support companies with bespoke website projects and digital marketing campaigns from our base in the uk. Now, as it happens, today is going to be our 50th episode of the Client side podcast.

Speaker C: It's taken us a few years to

Speaker B: achieve that milestone, but here we are today and we've got a fantastic back catalog of episodes covering all sorts of

Speaker C: discussions around digital marketing.

Speaker B: We talked around email campaigns, strategy and purpose, getting the Most out of YouTube

Speaker C: channel SEO, agency relationships.

Speaker B: The list goes on. And you can find all of our previous episodes by heading across to Addigital, uh, Agency Podcast, where we've got show notes and links with full transcripts for each episode. And of course I'm hugely grateful to

Speaker C: all those guests on the show who

Speaker B: have given their time to share their knowledge and experience and of course to our listeners as well for tuning in and sharing episodes on social media, leaving reviews and so on. But enough of looking backwards because we've got an amazing discussion lined up today and a fabulous guest who has lots of experience working on the web and, um, in digital projects. He is Dan Donald and I'm really excited to be speaking to him again. We've met several times in person through various events, and as this happens to be our 50th episode, I have no doubt this will be an absolute belter of a conversation to mark the occasion. So, Dan has been active on the Manchester web scene for many years, having worked at the BBC, McCann, Manchester and Autotrader in previous roles. He's a wealth of experience that is including freelance agency and in house positions, covering just about every aspect of web development, front end, back end content, user experience and most recently, design. He's founded and co organized events such as Speak the Web Upfront Conference. He's been a council member for Manchester Digital and he's now focused on design systems, which are a way of bringing all of these experiences together. That's going to be the focus of today's conversation. Dan is pretty active on Twitter, going under the handle of hereinthehive. So welcome to the show, Dan.

Speaker C: It's great to speak to you again.

Speaker A: Yeah, you too, mate. It's been ages it has, it has.

Speaker C: And uh, I think on that point, with all that's been going on in the world, it's been a long time since we found ourselves at the uh,

Speaker B: at the same event.

Speaker C: And I think it was, it was Speak the Web, which was uh, the

Speaker B: first time we met, which I think

Speaker C: was around about 10 years ago, frighteningly.

Speaker A: A very, very long time ago.

Speaker C: Yeah, I think I remember going to one in certainly one in Manchester and another in Liverpool. Um, but what was great about them, they were sort of fairly small, intimate events and, and I think, you know, it's one of those things that we've seen in our industry grow, that idea of collaboration and knowledge sharing and people have always been so willing to share their skills, their experience. And I think the other great thing about those events that you were running, you gave people a platform. It was an opportunity for them to sort of put their speaking skills to the test a bit as well, wasn't it?

Speaker A: Yeah, it just seemed like a fun idea at the time of like this gig style web conferences. So we didn't use normal proper conference venues very much. More like a pub that might have a band on or something like that and try and get a brand new speaker, someone that's maybe done a bit and end with someone you might have heard of. And so with that premise I was fairly sure we wouldn't get anyone that, you know, was a proper speaker or something. So that turned out amazingly well. Probably a lot to take on covering like, what was it, five cities in two weeks, as well as a job and having kids and stuff. But uh, it had a real buzz, it was great fun.

Speaker C: Yeah, yeah, absolutely. So, uh, yeah, remember those fondly. Um, so Dan, tell our listeners a little bit about your career because you've had a number of senior roles through your career journey. You're now working for a company called

Speaker B: Zero Height as a design advocate.

Speaker C: And we'll come on to talk a little bit more about that in a minute. Um, but what's led you from what seems to be more of a technical focus into more of a design focus?

Speaker A: Uh, I guess part of it is I've never really seen myself as a technical person. Okay. Like all of these things are just ways of solving problems and ways of expressing yourself. And so maybe I just like the idea of being able to speak your solutions in code. Just felt like a lot more immediate. So if you had an idea you could play around with some code and there it is in the browser. Whereas it felt like if you, in some places, if you're a designer, you're quite removed from that. So though I have been a designer from time to time and certainly works in a design tool first, there's always a disconnect between that and the real world. And so I think jumping to code, maybe designing in the browser was that immediacy of you playing with the material of the web. It's much more exciting and immediate.

Speaker B: Yeah.

Speaker C: And I think over the years we've

Speaker B: seen a lot of that change.

Speaker C: I mean, I don't know, we're probably similar ages and uh, our sort of entry point into the web was probably at a similar time where if we were doing design in Photoshop and potentially, um, fireworks and tools that were not really designed for web. Um, but over time, of course, we've got things like Figma and we're able to do that work directly in the browser. And it does feel a lot more responsive in terms of how you're going through the process of planning, prototyping and so on.

Speaker A: Yeah. And it still feels like there's gaps there, I think. Um, yeah, there's this whole thing about when you're using any design tool, you're constrained to, you draw a box of some kind. And that kind of implies a lot. Like if you draw something roughly 320 pixels wide, you're making an assumption it's on a mobile device. It might not be like responsive design is really fluid because that's what the web is. But in a design tool, you've always got to start by drawing a box. And that innately is like, well, I'm drawing it for a desktop. It's like, maybe not because loads of tablets are exactly the same size these days. So, yeah, I just find that there's still that kind of slight disconnect between a design tool and the real world.

Speaker C: So ultimately it comes down to that idea of problem solving. Uh, and that can be done both obviously visually from a creative and a process point of view, but also from a functional point of view with code.

Speaker A: Yeah, completely. And I think a lot of the time it's just, uh, it tends to be, um, more senior levels as well. You get closer to that original problem space. So instead of having a handover process and going, right now I've got the design, I will work out and make it, yeah, let's try everyone involved earlier and go. The point of doing this, whatever it is, is to help people do this thing. And it's either going to be like an internal stakeholder or your external audience. So the closer you get to that and the More collaborative you are at that really early stage, the more fun you're going to have and the more you can properly iterate and solve a problem for people.

Speaker C: Yeah, and I think, as I was saying earlier, that idea of collaboration is so true in projects. The success rate, uh, I don't know what the actual ratio must be, but it goes through the roof when you've got effective collaboration, doesn't it?

Speaker A: Oh yeah. I mean, almost everything ends up being a people problem. You can have the greatest developers and the greatest designers, the greatest product people, but the structure doesn't allow them to be collaborative and communicate well. That's why it will fail.

Speaker C: And I'm guessing then a design system is part of a suite of tools that supports communication. That was one of the reasons why I really wanted to get you on the show. So there don't seem to be anything new. Design systems been around for a little while now. Uh uh, but just tell us what you understand or what you describe a design system as.

Speaker A: See, this is the thing, if there was one definition you could point out. Yeah, you're right, design systems aren't new. Like they've been in various industries for a very, very long time. And at one end they come all the way from brand and trying to be really consistent with how you describe and communicate brand through everything. And then more in our world, you've got more about UI and trying to get some componentization and reusability out of some design assets, which then often translate into components of some kind in code. And so a design system is almost like the bit between design and code that often gets messy. If you had an old school Photoshop design and threw it over the fence to someone, they may well make that layout exactly as you've designed it. And then the next design you throw over, they'll make that entire layout again very, very old school. And then bit by bit, as technologies change and the design tools have improved, we started to see that you can reuse stuff so much better, which just makes sense. So design system is very much a way of going. If we bring these worlds closer together and there isn't a handover as such, we build a library which isn't just in a design tool, but also in code, which should be the same thing. So a button is a button, regardless of what discipline it came from, and we document it properly and we describe what problem this thing is solving. So in the case of a button, it's for interaction for our audience to do a thing. You might have more complex components which do a form which submits and does something else. So a lot of it is taking that step back and going, all right, what problem does this solve? How do we help the next designer, the next developer, to use it properly? And then how do we make changes and keep evolving our state of digital stuff?

Speaker C: We're going a lot deeper than a brand, uh, like, uh, the equivalent to a set of brand guidelines, aren't we? Because brand guidelines will indicate how you can use certain brand assets, like a logo, choose your color scheme, choose your typefaces. But of course there's so many different ways that you can interact with digital. As you say, forms is just one example that you're given there. Search could be another, A checkout process could be another. So it's obviously closing the gap between someone doing design that's disconnected then with someone who's actually doing the code. But is it more about thinking about the problem? Is it more about the process or is it, is it more about the efficiency? What tends to be the main driver behind a design system?

Speaker A: There's a lot of it, and I think part of it is consistency is a word you'll hear a lot because certainly, um, from a design point of view, if you only had a design system that lived in a design tool, that's fine, but that can be a conscious choice that we'll scope it so it stays within a design tool because there's lots of reasons why. And there you're just looking for, oh, actually that's interesting. You want to do the same thing. Well, we shouldn't reinvent it. And so trying to have a structure, like you were saying with figma, you've effectively got a component library that any number of designers can share. And, and so if you have stuff like a button, like form inputs, you shouldn't ever have to draw another one because why would you? Yeah, you know, you've got your look and feel for how they should be for your app or your website. And so the next designer and the next designer should both be able to quickly consume that thing they need to solve their problem. So again, if it's a complex form or a difficult user journey, you wouldn't want them wasting the time going, I'm not sure about the form input. I mean, what about aerostate? Like, actually you get that cumulative knowledge and you bake it into the design system so you get the wins, like, uh, make sure it's accessible and, you know, error stakes, all these kinds of things. You get to take it out of the context of the design you're working on now, turn it around a bit and go. Is that right? Have we got everything there? And then everyone gets the benefit.

Speaker C: So I suppose from a, uh, from a planning point of view, you're also at that point, you're asking, in some cases you're looking for a one size fits all. But you're also challenging to say, does this work in different circumstances? So in three months time we're not going to have to reinvent the wheel?

Speaker A: Yeah, exactly. And I think again, that's why I often think more about design systems being entirely end to end. So from the problem space through to solutions. So it might not necessarily be you want a huge redesign or something, but then you know that the power that the web promises can really deliver. So if you make a change in your design tool and your code saying, you know what, red buttons don't work for us, let's change them to green, that should be as trivial as it sounds. That should be like, we have a joined up conversation. We made this decision, it gets changed in the design tool and uh, shortly after, in a code format, whatever. And we know it can be released in a quite a measured way. It should be that easy. But typically it isn't always that easy and it all depends on who's working on it and this kind of thing. So certainly for larger teams, where you've got people switching in and out, it's vital.

Speaker C: Yeah. So clearly there needs to be discipline in terms of creating that design system, but then adhering to it, maintaining it, evolving it. Um, and I guess that that kind of comes into its own once you get onto a project of a certain size. So is there, is there a typical size of website, size of company size of digital estate that determines the need for a design system? Or in your view, is it just a sensible thing to have from an efficiency point of view?

Speaker A: Yeah, I'll do it, uh, at any size. I mean like you're talking about brand guidelines. You can start with whatever you use to document your design system and just capture those right at the beginning. So even before you've designed the, the app or website, it's go like, all right, what do we know? What do we need to adhere to? And effectively that's the beginning of your design system. How you then articulate it in a design tool or code, that's like the next layer. Start with some principles. So like, how can you empower your team to do code good work? That's what it comes down to.

Speaker C: Who actually owns the design system. We talked about things like Figma and for Listeners who perhaps aren't the coal face of using tools like this. Figma is a, uh, sort of a prototyping UX tool, sits uh, on, you know, it's an app that works within the browser. You can preview websites, you can prototype customer journeys and all that kind of thing. Ah, are we talking of something that sits within an app like Figma? And of course there's other uh, prototyping tools that exist out there whereby you're effectively creating this library and you're defining certain settings. Fonts are going to be font A, font B. Standard size for heading one at this point, heading two is going to be a standard size over here as you said, buttons with certain colors. So it's not like it's a document, it's not necessarily something that's coded. But it's in the tool of choice that the technical team and the creative team are perhaps going to be working with.

Speaker A: Yes, there's loads of answers to that. Um, there's loads of different models of how people run design systems, all different sizes. So I think a lot of people would assume that everyone has a centralized design system team on it, especially for larger projects. But that's not always true. So you might have a federated model where there's contributors from each product squad or whatever it might be. Uh, it might be your company's far more design weighted, so you've got way more designers than developers. So that makes sense for the design team to own it. The opposite could be true as well. You got a huge amount of developers, they've already got quite mature coded components. It kind of makes sense for them to lead the way. So whatever the starting point is just trying to make that bleed between the specialisms really work. So if you start with coded components, maybe in something like React or Angular, a JavaScript framework, how does that blur with the design and how do you make them on par with each other? It's really having those conversations. It stops being then about the components and more about how do you foster this collaborative way of working, how do you communicate properly? So it really boils down to design systems are a people problem and they can be uh, a vehicle for enabling all this, good ways of working.

Speaker C: And I guess that figures because design has been used to solve problems, as we were saying right at the outset. So it's as much about the individual components of a button or a form as it is the process that sits

Speaker B: behind it as well.

Speaker C: And that must the whole customer journey. That might be to, let's say book a train ticket online or something along those lines. Um, it's taking that into account. But how you might then also what if you need to cancel that train ticket? You've got to build in both of those journeys and therefore the components are ah, using the considerations from both of those different journeys.

Speaker A: And that's a bit of attention as well. So if you've got something as big as like booking a train ticket, you've probably got a number of product squads working on different aspects and that might cover design and development and testing and everything of each user journey. So it's trying to work out how do you then split out bits and pieces that could be shared into a design system? Does it happen by the beginning? Do you protest a, uh, user journey out in the wild and then submit some contribution back to the system? It's trying to make sure that you learn as much as you can from things being in the wild. How you use product, uh, teams doing their work to get the best out of you of the components because otherwise it gets a bit too theoretical and like we'll just make lots of pretty components and good luck with that. So I think you've hit on a few issues there and I think contribution is one of the big ones because there's no one contribution model that works for everyone.

Speaker C: Mhm.

Speaker A: So again, if you have a centralized team, you might find in some cases that they make all the components. You might also find that they don't and their role is more to shepherd the other people submitting contributions to the system. And so a lot of it is again that facilitation role and um, being plugged into what everyone's doing. So you can go, oh, that's really interesting what you've done there. I think we'll get value out of having that shareable. So this is what we need to do to take it from your particular user journey there and make it more kind of systematized.

Speaker C: Yeah, uh, that makes sense. So on that basis then, if we're talking about a brand new website project, where does a design system come into the planning process? Because it sounds like it's something that needs a certain amount of data that feeds into a design system to help boost the understanding around what it is people are trying to do that actual behaviors. And maybe the answer is that you can still start with a basic design system and you evolve it as. And when you learn and acquire that information from something that's out in the wild.

Speaker A: Yeah, I think absolutely. Um, one of the things is again, if you look at really mature design systems, they've got amazing documentation. They've got all these variants that seem to have everything covered. It didn't start like that. It doesn't matter how big and mature they were. They started with probably nothing at all or know brand guidelines. So I'd uh, say like, be scrappy, be just learn all the time and just try and work out. Start with what you do know, start with the things that you actually need to deliver, uh, the website, the product that you need, and try and when as you can, break them down and try and capture what is the. What is this a solution to or why do we have this component? Um, because then it works really well for challenging later on if you have uh, a developer or designer saying, I know if we just tweak that it can also do this, like, is that a good thing to do? There should be some rough kind of initial guidance going. You know what, it should just do one job. It might look the same, but actually it should be a different component. Or do you establish that way of working where you go, all right, so then we'll have a quick chat and we'll make a consensus, you know, we'll somehow find out the right way of pursuing this.

Speaker C: And I guess your forms are a great example because forms are used widely on just about every website. I can't think of many sites that don't have a form. But the purpose, the application of that form can vary massively. It might be updating, uh, the checkout, it might be your address that you're changing in your account or your password. You might be doing a search. So I guess you can start with the fact that we are going to have forms on our site. That's a given. We know we're going to have forms there. And then as you go forwards, you start and challenge yourself and say, okay, well this form has got quite a specific purpose. And actually it's really common that people make mistakes here. I don't know, let's say they're putting their email address in and they mistyped their email address, which as you, um, and I know we can validate that. Um, and that perhaps has to throw up an error message or does it put a red border around the field that you've not filled in those kinds of things. Um, so I guess you can start with those sort of overall components. That is a form. But then you can start and break that down into smaller use cases based on how people need to use the site. And um, um, I suppose ultimately as a business, as an organization that owns the site, what you need people to do or how you can reduce the friction in that process.

Speaker A: Yeah, completely. And if you started off with like the pure version of a text input field or something like that, you can turn it around a bit and go, okay, how do we make it accessible? Where should an error message appear and all that sort of thing. But it's only when you use it in context where you start to maybe think, maybe that's not quite right. Or certainly when it comes to code, should some things be turned off and on, or should it then throw up an error to a higher order component so then wrap the whole thing in an error state?

Speaker C: Right.

Speaker A: And so you've got that thing of specific, uh, purity of a given component going. Yeah, this is the best possible. But only when you use it in context you're going to find out if it works and then it's trying to get that, uh, we've learned something now. How do we make the specifics better? Like the generic text input or whatever?

Speaker C: Yeah, no, that makes, uh, makes a lot of sense. And you know, the more I'm, I'm, I'm hearing from you is this is a tool that benefits everybody. This is no, this is no one size or one particular beneficiary. It benefits the developers, the designers, the organization that's putting this in place. Um, from an efficiency and as you said, that word consistency that uh, inevitably is going to keep cropping up. Um, uh, so it sounds like there's a really strong case, particularly with the tools that we now use for design, like figma. You're almost invited to create that, aren't you? Perhaps we're almost creating design systems without realizing it.

Speaker A: I think, um, as well, if you get into the nerdy detail, which I do enjoy. If you look at uh, design tokens as a way of underpinning a design system, if you've not come across them before, it's a way of storing essentially design decisions in a JSON file.

Speaker C: Okay.

Speaker A: Uh, so it's completely abstracted. It's not bound to any way of consuming it or generating it. The direction of travel is. There's now a W3C community group working on making a standard for this. The point would be then you could move your tokens, your decisions like color palette or whatever it might be, between different design tools and between code. They'd all read the same format and have this shared understanding. So you could, I don't know, start in sketch, move to figma, consume it in code and it would be the same basic file. So when you get down to the nerdy detail. So we have these things called design tokens, and you can do them in figma today using the figma tokens plugin. Um, it's that abstraction which is a word you come across a lot in design systems where you stop being bound to. We're working with figma and we need to hand it over. You store it as a token, you use it in figma, and then you can directly consume it in code. And it completely blurs those lines between the disciplines. And certainly with Figma tokens, where they got integration with GitHub or whatever, you can make that workflow really tight. And all of a sudden that power is, you know what, we've just changed our, uh, secondary brand color. Boom. It's literally everywhere.

Speaker C: And if it's connected to things like GitHub, uh, obviously that gives you a version history that you can roll back to if you later decide, actually, we didn't like that shade of purple. We've gone for a different one, or we want to go back to where we were sort of three weeks ago, then you've got that opportunity as well.

Speaker A: Completely. And same as what you're saying with disciplines like if you have content designers, um, who care about the microcopy and helping people to understand what they're reading and get the most out of it, or if you've got manual or automated testers on the tech side, all of these disciplines can be part of a design system, depending on how you scope it. So again, it's that weighting of teams and what structure of management works for you. So if you can do it end to end and you start off with something in design, how do you get it safely out to your site? Maybe you've got lots of different pipelines and ways of working on the tech side, how do you have the right test coverage there to guarantee it? And shouldn't that be in the docs too? So then as a, maybe a product owner or product manager, you should be able to go to your design system and not only see all the components you've got and understand their purpose, but realize that you can speak to developers about how to consume it. Here's your actual design and here's the test coverage or whatever it might be. It's a really good way to bring everyone together.

Speaker C: Yeah, yeah, no, I can, uh, see the benefits, uh, across the board. So, I mean, you talk about product managers and product squads, who, who would lead that process? Again, I suppose it really comes down to the individual project. Does it tend to sit more Comfortably with a designer or developer to begin with. Ah, and then does it need. Do you have to generally get someone in a senior role that ah, says, right, this is how we're going to adopt? I suppose it needs leadership.

Speaker A: Ultimately, yeah. And again, it depends on the shape of your organization. If you're a relatively small agency, you could do this right at the beginning and say, as we make stuff, we'll just do it together. It could be as simple as that. And a guiding principle of as we make stuff, we'll try and look at the design system first. If it's already in there, brilliant, we'll use that. If it isn't, then try and work out. Does it make sense to roll it out first and then put it back in, or do we save ourselves some time by building it straight into the design system? If you're a multinational bank, you'll have very different structures to work with and different characters and time zones and all sorts. So I don't think it necessarily has to come from any one discipline. Clearly at some point you need design and whatever flavor of tech, you've got to be a massive, massive part of it. But because there's a huge amount of leadership and that, uh, bringing people together again, if you've got an existing product, you might want to do a huge audit and look at what's currently live on your site or app, even screenshot it, and just go, that's the same as that. It's the same as that. Or it should be, but it's not. And um, I think most people could probably have a decent start at that without having any experience, and go, these are not the same. These should be the same. And you know, cut them out, stick them on the wall, whatever needs to be done to try and work out this is the state of what we've got. So therefore that's why a design system might help us.

Speaker C: And Dan, I'm sure you've been involved with projects as well where the scope changes, uh, time goes on, people come into the project, people leave the project and things can get messy, can't they? And I suppose this is one of the great tools that you can use to reduce that messiness and introduce the consistency. And you know, it's easy to see on, on many corporate sites where, you know, clearly there isn't a, uh, or at least there isn't a robust design system in place. You know, clearly there's, there's common things around their branding, like their fonts or the color palette, but actually you can observe differences. Uh, I Mean even something like HMRC is probably a good example at the moment. You know, it's gone through massive transition so it's not, it's not so much criticism but clearly you've got uh, some sections of the site which are very new. You've got some sections which clearly aren't. It's a bit like being in an old building and all of a sudden you walk into this extension. It's got a different feel to it. Um, but I guess, you know, an organization like that, they will have a design system in place. It's just a case of how they utilize that and how they, they prioritize their work to make sure that it spreads out across the, the whole estate.

Speaker A: Yeah, and there's got to be a huge amount of pragmatism in there too. Right. Um, if you've got, it might just be a different tech and you think, well actually see the same result, we've got to implement it twice. You got a really good reason to do that because then you're doubling the workload or maybe the older code base is really, really hard to work in. So it's more than doubled it and at some point, maybe a year down the line, you know you're going to get rid of that. So there's always trade offs you need to try and get your head around. And the output from your design system might not be a shiny react component. It could be CSS in some way too. Multiple ways you can address it depending what output suits your context. I think something as big as HMRC or if you go into a uh, brownfield site and it's something that's been around for quite a long time, is trying to find out where's the win for your end users and for your developers or your designers. Like be quite clear on what our uh, problem is here. Why do we think our design system is going to help it? And actually Dan Moll is a great speaker and tutor for design system stuff. Uh, Conference Converge he said really clearly. Like the, the thing is lots of people would try and start with a button with a design system, but he flicks on his head and so pick the most complicated, most well used components. Start with that because then you've got value. Right from the beginning you've had to unpick a load of challenges about, well, how do you make the thing together, how do you break it down into smaller bits and you've got value right there. The most used component is now new, shiny and powered by the design system.

Speaker C: You've taken that point of friction away from the end users, probably from the developers as well. And um, people have seen the benefit straight away. They're more likely to then stick with it going forward.

Speaker A: Yeah, exactly. Because adoption is really a huge challenge for a lot of people. And again that's the communication thing, that's talking to people early and taking them on the journey. Which is a very different skill set to just delivering a thing for a product.

Speaker C: Yeah, sure.

Speaker A: I think it's just trying to find that value. What's the value story behind having a design system?

Speaker C: Okay, yeah, Loads of real positives I'm hearing down around uh, how companies can benefit. They might not necessarily see a design system, they might not implement it directly themselves, but if they're working with development teams, product teams, um, you know from, from a leadership point of view and ultimately an efficiency point of view, it sounds like uh, a design system is well worth having and uh, sort of recommending that the teams embrace uh, the concept and uh, follow it through.

Speaker A: And I think it's one of those things where you can start small like don't look at the big mature ones and think you need that tomorrow.

Speaker C: Right.

Speaker A: Clearly it's an investment of time which means you are paying for this thing. But um, it's one of those things where if you get it right it becomes a real asset to your company. So you do have that ah, bit uh, of maybe trying some stuff out, maybe getting it wrong at the beginning. It's fine, you can follow it up and change it because you're learning every time and that makes everything better. So if you have it and it works properly and maturely and everyone's working well, that will pay off multiple times.

Speaker C: Like a lot of things, progress beats perfection completely. And uh, just make a start with it, start using some components and uh, look where you can iterate. Which of course is what we're often recommending with websites anyway. Roam wasn't built in a day. You're probably never going to get uh, 100% picture of how people are going to use your site until it's out there with the masses. For all the testing that you can do, uh, you're probably still going to find edge cases that people do things that you didn't expect, uh, or you hadn't allowed for. And uh, that's where the iteration on the website itself can come in. But of course the design system has to iterate with that completely.

Speaker A: And if you start off with nothing more than a simple purpose statement, what is the point of this component? What does it do that's already better than what you had before. And then if you can layer on overwards like, um, something on accessibility or you've got some research insights, bit by bit it will grow and become really, really valuable. And like you were talking about a little while ago, it actually works really well as an onboarding tool. So you get a new developer or designer. It's like in that time where you're finding your feet, go check out the design system, uh, start a new project, whatever, and start playing with it. And you'll be on brand and feeling like it's a real thing really quickly.

Speaker C: That's, that's a really good point. As, as we said, people will come and go and uh, you know, as, as, as generally, projects are expected to sc. Uh, visitor numbers grow or the scope of the project opens up inevitably. You want people to be able to join the team and hit the ground running and maintain that consistency as well.

Speaker A: Exactly.

Speaker C: Great. Okay, Dan, that's really interesting hearing all about design, uh, systems there. Um, so I'm conscious that we don't have a huge amount of time, so I'm going to go into our, uh, final set of questions which we've been asking everybody on the podcast through this year. Um, so just quick answers just to help our listeners get to know you a little better. Uh, so first question, what's the one app, website or piece of software, personal or professional, that you couldn't live without?

Speaker A: See, I should say something really highbrow or important, but I've been sucked back into Candy Crush. I really wish I could say something more profound. Um, but no, I end up like, I've just finished that meeting or something. Oh, it's a bit of Candy Crush time.

Speaker C: I've got to confess, that's not something that, uh, I've ever got into. So I can't even say anything in response to that. But, uh, fair enough. Um, and beyond Candy Crush and of course design systems, what's exciting you in digital at the moment? What are you sort of keeping a close eye on?

Speaker A: That's a good one. There's loads. Um, Jay Tompkins. Um, uh, Google has done some amazing, amazing examples of what you can do with CSS today. And, uh, it never stops blowing my mind just how a simple detail added to CSS gives you so many creative possibilities. I've, uh, just always loved seeing people just tinker and play with the new stuff and being like, it's not like the old days. We have to wait years and years for other browsers to catch up. Yeah, yeah, like when you see someone tinkering, you know, relatively soon, you can do that yourself in production.

Speaker C: Interesting. Yeah, I mean, I'm, I'm not into code as much these days, but, uh, certainly what you can achieve with CSS now is, is pretty incredible, um, with, uh, all of these little playgrounds as well, that you can, uh, sort of create your own little blocks of code and experiment. Uh, yeah, it looks pretty cool.

Speaker A: It's just that playful nature of the web that I love.

Speaker C: Yeah, exactly. And that's very much how I got into it. It felt like Lego blocks. Okay, we're going back. We still had CompuServe CDs dropping through the letterbox, which was probably about 1997. Um, but, yeah, it felt like Lego blocks that you could just sort of have a play around with, try something. Uh, and if you didn't like it, if you wanted to extend it as often you did because you thought, oh, well, if that works, I can now do that. Uh, you'd go off and sort of get into the code. And that's, that's ultimately how I learned, which I suspect you're probably in the same camp.

Speaker A: Yeah, absolutely.

Speaker C: Uh, so it's quite, ah, timely. We had, uh, daylight saving time change yesterday. But if you did have an hour, an extra hour every day, how would

Speaker B: you spend that time?

Speaker A: Uh, making music. Right.

Speaker C: Okay.

Speaker A: Like, um, I just seem to run out of time to. And I love doing it. But, uh, I think when we first started working from home during the pandemic, I was pretty good and, you know, maybe a bit of lunch time or something, just carve it out. Got myself electric drum kit. So that was right next to where I was sat at the dining table during, um, lockdowns and stuff. And it was the best thing of. I've just finished a call, I'm on lunch. Quickly bash out something really hard and loud on drums and just. I felt amazing. Other habit, I think.

Speaker C: Yeah, it's difficult, isn't it? It's, uh, it's the discipline and, and life. Life gets in the way, doesn't it?

Speaker A: Completely.

Speaker C: And, uh, I mean, you in your current role now with, with zero height, you're, you're a design advocate. Um, and we'll probably mention zero height in a minute. But what's, what's the most important personal attribute that you feel you bring to

Speaker A: your job as someone that doesn't like, uh, anything complimentary or, or anything positive like that? I find it hard to explain, but I think I just love listening to people. I think one thing I've loved about this role so far is like all the conversations I'm having with people, all different size organizations, and just listening and going, oh, actually I've come across that before. I think I can help. And um, yeah, I just love helping people. And so being in a role where that is literally my job, it feels pretty good.

Speaker C: Yeah, that's great. Um, and final question. What advice would you give to someone at the start of their career in digital?

Speaker A: I think it goes back to what we're saying with design systems. It's all about people. So you can get excited by tech, you can love details in design, but until it's real and people are actually using it, then it's all kind of theoretical or a bit stroking your own ego sometimes. Yeah, you can do all of that stuff and hone your craft at the same time as going like, yeah, it's how we work together and it's how well we do for whatever your audience might be. It's just about people.

Speaker C: Yeah, so many of the things that we do, I mean, that's ultimately what we create a website for. People have a problem, there's a task they want to solve, and uh, for all the niceties of making it look pretty, uh, it's got to be functional. And of course again, the context of where that site is going to be used, what type of problem people are trying to solve and how quickly they need to solve it, if they're booking a train ticket versus going to a design exhibition, then clearly the environments are very different. Um, but, uh, yeah, I think, uh, that's something that ultimately rings true throughout all of the work that we do. That it is fundamentally all about people. You've talked about design systems, been about bringing people together, uh, and that collaborative collegiate nature almost of, uh, solving problems.

Speaker A: Yeah, exactly. And I think it's one of those things where if you get it right, then hopefully you've got great working relationships with people around you and you know, you've put something out that's good. And not only that, but you've got the desire to listen and learn more from your audience to make it even better.

Speaker C: Yeah, yeah, great stuff. Um, so Dan, we'll, we'll wrap up there, but before we finish up, just tell us a little bit about Zero height and where does that fit in with design systems?

Speaker A: So zero height itself is a design system documentation tool. And however you make, uh, documentation, it's really important so that again, like with design LED or code led, you need to know what you've got in terms of components and how it's using. So essentially it syncs up with your design tool like, uh, Figma, Sketch, xd, whatever, and you can link it up with your code so you can start describing all these things in a really simple, quite fun cms and you can customize it, go crazy with it, have multiple different style guides. And I think that's why I wanted to work there. It's just the fact it's such an interesting space. It really helps bring people together.

Speaker C: And I see we're not going to get this podcast out, uh, in time for this event, but you've got an event coming up this week and it's uh, an online event, uh, which you've posted on, uh, uh, Twitter. But it sounds like you've had a really positive response to this thing that you've called a design system Triage. So, uh, are there going to be more of those that people can look out for?

Speaker A: Yeah, hoping it's going to be every month. I kind of viewed it as being a really simple little intimate thing where people can share stories and help each other out. Um, now we've got like 350 plus people so signed up for the first one, so we might have to change the format. If it goes down well, we'll do something every month and we're not going to record it so people can share things properly and just hopefully share any themes or topics that come out of it so everyone can learn from each other. Really.

Speaker C: Yeah, yeah. Back to creating that forum for people to learn again.

Speaker A: Completely.

Speaker C: Dan, brilliant. It's been, uh, an absolute pleasure to speak to you. Uh, it's been a long time since we've, uh, met, but hopefully that opportunity will, uh, return soon. Uh, tell people where they can follow up with you, where they can find you online.

Speaker A: Uh, yeah. So pretty much on everything I'm here in the hive, or one word, don't ask me why. And likewise, you know, there's loads of content we write about design systems on the Zero Hype blog. Um, so going through design tokens, accessibility, the workflow stuff, there's a few of us design advocates always writing stuff on there.

Speaker C: Sounds great. So we'll definitely link up those, um, uh, put those links that you've mentioned there into the show notes. Uh, Dan, thank you so much for your time. It's been an absolute pleasure. Hope it's been useful to listeners. Really appreciate you joining me today.

Speaker A: Brilliant. Thanks for having me, mate.

Speaker B: So, thank you, Dan, for joining me on the podcast today and celebrating our first 50th episode. Uh, do check Dan out here in the Hive on most channels. Uh, he's particularly active on Twitter and as we talked about a few events that he's hosting, uh, details of where you can find those events. Go check him out on Twitter as well as links to the Zero Height blog where he's mentioned a few articles going into the details, all about design systems. A really good conversation. And uh, as he was saying, the

Speaker C: name is a design design system.

Speaker B: It's actually a people system. And uh, design is there to solve problems for people. Design gets fed into code that in itself can create its own problems. So a system that helps to solve that problem is really valuable and clearly something that companies of all sizes can benefit from. Any website of almost any size will have certain reusable components, navigation, for example, the header which has your logo in it, perhaps the footer as well. So I guess those are just simple ways to start with a design system. But of course as uh, your site scales as things get bigger and more complicated, more people working on the project then having something more robust is clearly going to be very useful. Introduce a lot of efficiency, consistency as well as Dan was talking about and just make it easier for people to work together. Do check out Zero Height as well. That's the design system documentation platform that Dan works for.

Speaker C: He obviously has uh, a real passion

Speaker B: around design systems and helping people. And I'm sure if you were to reach out with him, uh, would be more than happy to answer any questions that have come out from today's show.

Speaker C: So I hope you've enjoyed that.

Speaker B: I'd love to hear any comments or feedback. So do get in touch with me, you can find me over on LinkedIn or Twitter. Uh, or if you're interested in what a digital does as an agency then you can find out more on our website at a digital uh, agency. You can also find the podcast there with the back catalog of all 50 episodes and transcripts. A digital uh, agency forward slash podcast. And if you want to get in touch then do reach out on social media or drop me an email to hello at uh, the clientside show. We'd be really grateful if you could spread the word about this series of the client side podcast as well. So please do tell your friends and colleagues we've had some fabulous guests on the show and if you can leave a rating and a review then that would be massively appreciated. So I'll be back in a few weeks time with another episode so I hope you'll be able to join me then. Take care. I'll see you next time.