Design Systems with Dan Donald of Zero Height

Andrew: 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 over the last few weeks as things in the agency have been pretty busy. But I'm delighted to introduce another episode of the Clientside podcast. The show is supported by the agency I founded called A Digital, and 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 Clientside podcast. It's taken us a few years to achieve that milestone, but here we are today and we've got a fantastic back catalogue of episodes covering all sorts of discussions around digital marketing. We've talked around email campaigns, strategy and purpose, getting the most out of your YouTube channel, SEO, agency relationships...the list goes on and you can find all of our previous episodes by heading across to adigital.agency/podcast where we've got show notes and links with full transcripts for each episode. And of course, I'm hugely grateful to all those guests on the show who have given their time and 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.

Andrew: 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 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 included 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-organised events such as Speak the Web, Up Front 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, and 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. It's great to speak to you again.

Dan: Yeah, you too mate. It's been ages.

Andrew: It has. It has. And 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 at the same event, and I think it was it was speak the web, which was the first time we met, which I think was around about ten years ago, frighteningly.

Dan: A very, very long time ago.

Andrew: Yeah, I think I remember going to one in certainly one in Manchester and another in Liverpool, but what was great about them, they were 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?

Dan: Yeah, it just seemed like a fun idea at the time of this gig style 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 then someone you might have heard of. And so with that premise, I was fairly sure we wouldn't get anyone that 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 it had a real buzz. It was great fun.

Andrew: Yeah. Yeah, absolutely. So yeah, I remember those fondly. So 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 Zero Height as a design advocate and will come on to talk a little bit more about that in a minute. But what's led to you from what seems to be more of a technical focus into more of a design focus?

Dan: Uh, I guess part of it is I've never really seen myself as a technical person.

Andrew: Okay.

Dan: 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. It's felt like a lot more immediate. So if you had an idea, you could play around with some code and various in the browser. Whereas it felt like if you in some places, if you're a designer, you're quite removed from that. So although I have been a designer from time to time and certainly worked 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 like immediacy of playing with the material of the web. It's much more exciting and immediate.

Andrew: Yeah. And I think over the years, we've seen a lot of that change. I mean, I don't know, we're probably similar ages and our sort of entry point into the web was probably a similar time where we were doing design in Photoshop and potentially Fireworks and tools that were not really designed for web, but over time, of course we've got things like Figma and were 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.

Dan: Yeah, and it still feels like it's gaps there, I think. Yeah, this whole thing about when you're using any design tool you 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. 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.

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

Dan: Yeah, completely. And I think a lot of the time it's just it tends to be the more senior levels as well, that are 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.

Andrew: Yeah.

Dan: Just get 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 external audience. So the closer you get to that and the more collaborative you are 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.

Andrew: Yeah, and I think as I was saying earlier, that idea of collaboration is so true in, in projects, the success rate. 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.

Dan: 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 if the structure doesn't allow them to be collaborative and communicate well, that's why it will fail.

Andrew: And I'm guessing then a design system is, 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 they don't seem to be anything new, design systems, they've been around for a little while now, but just tell us what you understand or what you describe a design system as.

Dan: You see this is the thing. If it was one definition you could point at. Yeah, you're right. Design systems aren't new. 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 componentisation 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 have an old school Photoshop designer, throw 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. It just makes sense. So a 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?

Andrew: We're going a lot deeper than a brand, like 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 colour scheme, choose your typefaces. But of course, there are 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 is it more about thinking about the problem? Is it more about the process or is it is it more about the efficiency? What's what tends to be the main driver behind a design system?

Dan: It's a lot of it. And I think part of it is consistency is a word you'll hear a lot, because certainly 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 will 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 or we shouldn't reinvent it. And so trying to have a structure like you're saying with Figma, you've effectively got a component library that any number of designers can share. 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?

Andrew: Yeah.

Dan: 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 their time going, I'm not sure about that form input. I mean, what about error states? Like actually you get that cumulative knowledge and you bake it into the design system, so you get the wins, like making sure it's accessible, error states and 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.

Andrew: So I suppose from a 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?

Dan: 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 solution. So it might not necessarily be on a huge redesign or something, but then you know that the power that it 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 shortly after in a code format, whatever, and we know it can be released in 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 we've got people switching in and out, it's vital.

Andrew: Yeah, so clearly there needs to be discipline in terms of creating that design system, but then adhering to it, maintaining it, evolving it. 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?

Dan: Yeah, I'd do it 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 app or website, it's like, 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 good work? That's what it comes down to.

Andrew: Who actually owns the design system? We talked about things like Figma and for for listeners who perhaps aren't at the the coalface of of using tools like this, Figma is a sort of a prototyping UX tool, sits 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. Are we talking of something that sits within an app like Figma? Of course there's other prototyping tools that exist out there whereby you're effectively creating this library and you're you're defining certain settings. Fonts are going to be font A, font B, standard size for heading 1 at this, this point, heading 2 is going to be a standard size over here, as you said, buttons will be certain colours. So it's it's not like it's a document. It's not necessarily something that's coded, but it's it's in the tool of choice that the technical team and the creative team are perhaps going to be working with.

Dan: So there's loads of answers to that. 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 centralised 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. 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 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 people problem and they can be a vehicle for enabling all this good ways of working.

Andrew: And I guess that figures because design has been used to solve problems, as we're saying right at the outset. So so it's it's as much about the, the individual components of a button or a form as it is the process that sits behind it as well. And that must, you know, the whole customer journey that might be to, let's say, book a train ticket online or something along those lines. 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, are been, sort of their using the considerations from both of those different journeys.

Dan: And that's where there's a bit of the tension as well. So if you've got something as big as 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 road test a 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 teams doing their work to get the best out of each 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 contributions is one of the big ones, because there's no one contribution model that works for everyone. So again, if you have a centralised 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, the people submitting contributions to the system. And so a lot of it is, again, that facilitation role 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 systematised.

Andrew: Yeah, 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, their actual behaviours. 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, from something that's out in the wild.

Dan: Yeah, yeah I think absolutely. One of the things is that 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. Doesn't matter how big and mature they were. They started with probably nothing at all or brand guidelines. So I'd 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 the website, the product that you need and try and, as you can break them down and try and capture what is the what is this a solution to? Why do we have this component? Because then it works really well for challenging later on. If you have 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. They 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, we'll somehow find out the right way of pursuing this.

Andrew: And I guess 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 can vary massively. It might be updating the checkout, it might be your address that you're changing in in your account or your 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've mistyped their email address, which as you and I know we can validate that. 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? And so so I guess you can start with those 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 I suppose ultimately as a business, there is an organisation that owns the site, what you need people to do or how you can reduce the friction in their process.

Dan: 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 and 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 stage.

Andrew: Right.

Dan: And so you've got that thing of specific 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 we've learned something. Now, how do we make the specifics better, like the generic text input or whatever?

Andrew: Yeah, no, that makes it makes a lot of sense. And the more 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 organisation that's putting this in place from an efficiency and as you said, that word consistency that inevitably is going to keep cropping up. So so it sounds like there's 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. Perhaps we're always creating design systems without realising it.

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

Andrew: Okay.

Dan: 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 colour palette or whatever it might be between different design tools and between code that 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 plug in. It's that abstraction, which is a word you come across a lot in design systems where it's not being bound to, we're working in 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've 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 secondary brand colour, boom! And it's literally everywhere.

Andrew: And if it's connected to things like GitHub, 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. Then you've got that opportunity as well.

Dan: Completely. And same as what you're saying with disciplines, like if you have content designers who care about the micro copy 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 a 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 maybe a product owner or product manager, you should be able to go to your design system and not only see all the components that 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.

Andrew: Yeah, Yeah. Now I can see see the benefits across the board, really. So I mean, you talk about product managers and product squads who who would, who would lead that process? Again, I suppose it really comes down to the individual project. Does it does it tend to sit more comfortably with a designer or a developer to begin with? And then does it need do you have to generally get some? Someone in a senior role that says, Right, this is how we're going to adopt, does it need to...I suppose it needs leadership ultimately.

Dan: Yeah. And again, it depends on the shape of your organisation. 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 the 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 in time by building it straight to the design system? If you're a multinational bank, you'll have very different structures to work with and a 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 flavour of tech you've got to be a massive, massive part of it. But because there's a huge amount of leadership and 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, that's the same as that. Or it should be, but it's not. And I think most people could probably have a decent start at that without having any prior experience and go these are not the same. These should be the same. And you 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 this system might help us.

Andrew: Dan, I'm sure you've been involved with projects as well where the scope changes as time goes on, people come into the project, people leave the project and 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 it's easy to see on, on, on, on many corporate sites where clearly there isn't a, or at least there isn't a robust design system in place. Clearly, there's there's common things around their branding, like their fonts or the colour palette, but actually you can observe differences. I mean, even something like HMRC is probably a good example at the moment and it's gone through massive transition. So it's not it's not so much criticism, but clearly you've got 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 a, you know, an old building and all of a sudden you walk into this new extension. It's got a different feel to it. But I guess, you know, an organisation like that, they will have a design system in place, it's just a case of how they utilise that and how they they prioritise their work to make sure that it spreads out across the whole estate.

Dan: Yeah. And there's got to be a huge amount of pragmatism in there too, right? If you've got, it might just be a different tech? And you think, well, actually to see the same result, we've got to implement it twice. You've got have a really good reason to do that because then you're doubling the workload or maybe that all the 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 on what output suits your context and I think something as big as HMRC, or if you're going to a brownfield site, something that's been around for quite a long time, it's trying to find out where's the win for your end users, and for your developers or your designers. Be quite clear on what our problem is here. Why do we think our design system is going to help it? And actually Dan Mall, great speaker and tutor for design systems stuff; 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 flipped on his head and said, 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.

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

Dan: 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. Yeah, sure. I think it's just trying to find that value. What's the value story behind having a design system?

Andrew: Okay. Yeah, loads of real positives I'm hearing Dan around 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 from a from a leadership point of view and ultimately an efficiency point of view, it sounds like a design system is is well worth having and sort of recommending that the teams embrace that the concept and and follow it through.

Dan: 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. Clearly it's an investment of time, which means you are paying for this thing. But it's one of those things where if you get it right, it becomes a real asset to your company. So you do have a bit 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 if it's working well, that will pay off multiple times.

Andrew: Like a lot of things, progress beats perfection.

Dan: Completely.

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

Dan: Completely. 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 afterwards like something about accessibility or you've got some research insights, bit by bit, it will grow and become really, really valuable. And like you're 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, 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.

Andrew: That's that's a really good point is, as we said, people will come and go and, you know, as as generally projects are expected to scale up, 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.

Dan: Exactly.

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

Dan: 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. But no, it's end up like, oh, just finished that meeting or something. It's Candy Crush time!

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

Dan: Oh, that's a good one. There's loads. Jhey Tompkins at Google has done some amazing, amazing examples of what you can do with CSS today and it never stops blowing my mind just how simple details added to CSS gives you so many creative possibilities and I just always love 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.

Andrew: Yeah, yeah.

Dan: Like when you see someone tinkering, you know, relatively soon, you can do that yourself in production.

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

Dan: It's that playful nature of the web that I love.

Andrew: 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 CD's dropping through the letterbox, which...

Dan: Oh yeah!

Andrew: ...which was probably about 1997. But yeah, it felt like Lego blocks that you could just sort of have play around with try something. 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. You'd go off and 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.

Dan: Yeah, absolutely.

Andrew: So it's quite timely. We had daylight saving time change yesterday, but if you did have an hour, an extra hour every day, how would you spend that time?

Dan: Making music.

Andrew: Right. Okay.

Dan: Like I seem to run out of time to do, and I love doing it, but I think when we first started working from home during the pandemic, I was pretty good and maybe a bit at lunchtime or something to carve it out? I got myself an electric drum kit, so that was right next to where I was sat at our dining table during lockdowns and stuff. And it was the best thing. I've just finished a call, I'm on lunch, quickly bash out something really hard and loud on drums and, ah, it just felt amazing. I've fallen out of the habit, I think.

Andrew: Yeah, it's difficult, isn't it? It's it's the discipline and life. Life gets in the way, doesn't it? And I mean you in your current role now with with Zero Height, you're a design advocate and you 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 your job.

Dan: As someone who doesn't like anything complimentary 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 sized organisations and just listening and going, oh, actually I've come across that before I think I can help. And yeah, I just love helping people. And so being in a role where that is literally my job, it feels pretty good.

Andrew: Yeah, that's great. And final question, what advice would you give to to someone at the start of their career in digital?

Dan: 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 stroking your own ego sometimes.

Andrew: Yeah. Yeah.

Dan: 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.

Andrew: Yeah, so many of the things that we do, I mean, that's, that's ultimately what we create a website for. People have a problem. There's a task they want to, to, to solve. And for, for all the niceties of making it look pretty, it's got to be functional. And and of course, again, the context of 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. But but yeah, I think that's 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 being about bringing people together and and that collaborative collegiate nature almost, of, of solving problems.

Dan: 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.

Andrew: Yeah, Yeah. Great stuff. So, Dan, we'll we'll wrap up there. But before we finish up, but just tell us a little bit about Zero Height and where does that fit in with design systems?

Dan: So Zero Height itself is a design system documentation tool. And however you make documentation, it's really important. So that again, like whether it's design led or code led, you need to know what you've got in terms of components and how to use them. So essentially it's things up with your design tool, like a 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 customise it, go crazy with it, have multiple different style guides. And I think that's why I wanted to work there, is the fact it's such an interesting space. It really helps bring people together.

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

Dan: Yeah, hoping it's going to be every month.

Andrew: Right.

Dan: I kind of viewed it as being a really simple little intimate thing where people can share stories and help each other out. 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 that people can share things properly and hopefully share any themes or topics that come out of it so everyone can learn from each other really.

Andrew: Yeah, Yeah. Back to creating that forum for people to learn again.

Dan: Completely.

Andrew: Brilliant. It's been an absolute pleasure to speak to you. It's been a long time since we've met, but hopefully that opportunity will will return soon. Tell people where they can follow up with you, where they can find you online.

Dan: Yes, I'm pretty much on everything. I'm hereinthehive - all one word. Don't ask me why. And likewise, know there's loads of content, we write about design systems on the Zero Height blog, so going through design tokens, accessibility, the workflow stuff, there's a few of us design advocates always writing stuff on there.

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

Dan: Brilliant. Thanks for having me mate!

Andrew: So thank you, Dan, for joining me on the podcast today and celebrating our 50th episode. Do check Dan out; hereinthehive on most channels; he's particularly active on Twitter and as we talked about a few events that he's hosting, 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. It was a really good conversation and as he was saying, the name is a design system; it's actually a people system, and 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 the design system. But of course, as 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.

Andrew: Do check out Zero Height as well. That's the design system documentation platform that Dan works for. He obviously has a real passion around design systems and helping people and I'm sure if you were to reach out with him, he would be more than happy to answer any questions that have come out from today's show. So I hope you've enjoyed that. 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 or if you're interested in what A Digital does as an agency, then you can find out more on our website at adigital.agency. You can also find the podcast there with the back catalogue of all 50 episodes and transcripts, adigital.agency/podcast. And if you want to get in touch, then do reach out on social media or drop me an email to hello@theclientside.show. We'd be really grateful if you could spread the word about this series of the Clientside 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.