Design Systems with David Darnes

Notes

• Dave is looking forward to working on Lit framework/library.
• Nordhealth Design System:
• Other design systems: Adobe Spectrum, Lion, Stack Overflow Stacks, MDN, OpenUI
• Dave's article on tabs

Transcript

Mike: Hello, welcome to episode one of Behind the Source podcast. my name is Mike street. I'm a CTO and lead developer at a web agency in Brighton called Liquid Light.

With the behind the source podcast the idea being that we're gonna introduce a topic or a project or a tool, or maybe a person each episode and we'll invite someone on who knows quite a bit about it to talk in very high level terms.

We won't get too techy, but it's just a case of, if you wanna know more about a subject. This is the kind of podcast for you.

I am joined today by David Darnes Who's gonna talk to me about design systems, Dave. Hello! How are you?

Dave: Hi, I'm doing all right. Thanks. How are you doing?

Mike: Yeah, not too bad. Little bit warm. Cuz the suns come out in my garden cabin and it's heating it up, but I'll do I manage

Dave: Oh, I feel the same. I've closed the window to stop the audio like interference, and now it's pretty warm.

Mike: The sacrifices we do for podcast. Dave, for those that don't know about you if you could please introduce yourself, tell us a bit about where you work, what you do, and there's an opportunity for you to plug any side projects or anything that you're working on.

Dave: Yeah, my name's Dave you'll find me on the internet as David Darnes on all over the things, I tweet too much. And, my main job is a senior front end developer at Nordhealth. And I work on design systems.

Mike: And what do Nordhealth do?

Dave: Nordhealth is a health company that kind of has. As an array of products that provide for the holistic healthcare and veterinary and stuff like that. So we have kind of a, a roster of applications, one of the most high level ones that we've got is private cloud. And that's used for vets like large scale, like vet surgeries Mostly in Europe, but we're kind of extending into the UK and like wider than that.

So yeah.

Mike: Great. So before we start talking about design systems every episode I'm gonna ask the guest what they're looking forward to working on. So not what they know about, but what they're looking forward to learning about working on, developing.

And, knowing more about, so Dave, what are you what's coming up on the horizon that you are looking forward to learning about?

Dave: We use lit a library at work for building our web components, and there's actually an aspect of that, that I wanna like dig into more and it's server side rendering. Now, I, I know the concept, you know, it's rendered on the server means that it just comes down as is, but as you can tell, I know it quite high level, quite trivially.

I need to know more about it and understand how stuff is built and like how that might play to, certain frameworks and tooling and stuff like that.

Mike: So is that, is that lit or

Dave: Lit lit. So it's, it is kind of, it's kind of down with the kids, like it's, it's lit, I think that's what they were going for. Like the icon is a, is a blue flame. So I, I think they've kind of and it's very short, so I think they've kind of like the, the brevity of it.

Mike: Great. And I'm assuming that's a JavaScript framework?

Dave: Yes. Yeah. I want, I keep wanting to call it a framework, but I think they just call it like a, a library or a package or something. Don't think they, they would regard it as a framework, but it may be

Mike: All right. Great. I'll put a I'll put a link in the, in the show notes

Mike: this episode, we're talking about design systems. So Dave, what is a design system?

Dave: Ah, so design system would be a source of truth a place where everything kind. Resides to do with like design front end, maybe like even copywriting and stuff like that. It kind of leaks into other areas as well as just design. But for us, like the focal point is the design, like a center of truth for all the colors for sizing spacing and all that kind of stuff. And then that kind of gets mirrored in the front end and because we're building applications for the, for the web mostly that means that all the stuff that we use for design system that's in our design system is Code for like CSS and JavaScript, possibly, and like bits of HTML and things like that and how to use that stuff.

So, so developers on a team or in, in a company can, can use that as a reference point and as well as designers use that as a reference point.

Mike: And how does a design system differ to a style guide?

Dave: So a style guide, I would regard that as part of a design system, much in the same way as a component library is part of a design system or a list of color tokens is part of a design system.

Mike: Right. So design system is kind of the umbrella term that contains all of these different aspects.

Dave: That's what, that's what I would regard it as I'm, I'm sure there'll be people that will kind of have a more accurate answer to that. But from my experience of using our design system, that's kind of what it encompasses.

Mike: Great. So when would slash should someone use a design system?

Dave: Whoa. Great question. I I think. I think it, it works really well in large teams. When the design work starts kind of stretching across multiple teams or like the scale kind of gets quite large. I mean, like what you've just talked about before with like a style guide or a component library, those kind of pieces of a design system, you could still use that stuff at a smaller scale on a smaller team.

I mean, In theory, when you have a, a main CSS file for your website or websites, that's kind of you systemizing design by saying, right. All the answers are in here for how something should look. We could use that CSS file, on a few websites and then that's your source of truth. And then you could expand from there and say, right, this is how we do components, this is how we do HTML structure for inputs and things like that. So you could kind of grow from there, but I think it works best when you are working across design and development teams. That need to refer to a again, source of truth, where colors have been agreed upon design and, and, and development like structure, HTML structure, for example, has been kind of agreed upon and can evolve. So when I say agreed upon, it's kind of like, not only has it been agreed upon for like a first iteration, but it's continuously improved by the team, not just by one person having like the answer of this should be how it's done.

It's collaborative.

Mike: So do design systems always have to include the like HTML snippet. Like, could you use a design system with a Wix or you know, a WordPress online site where you don't actually control the HTML?

Dave: Wow. That's a, that's a good, that's a good question. I think you could. I think you could, you, could you, you know, for, for web flow and things like that, there is a lot of toggles and switches and controls. And if you can template things and reuse stuff consistently, or even refer to like the same piece of code where every time the right answer comes out and they, they always get updated.

Then in theory, you are creating like a library. That is partly what a design system is a library of tools or a library of pieces that you regularly reuse. And if you are building multiple applications for the same company, like Nordhealth, we want everything to look like our design system, which is Nord.

And then variate on top of that, then, you know, if you were using it, if you're using it in the context of web flow, then of course you could reuse that and you could reuse that. Web flow sites, you know, if you're building them for different things. And again, like just, just for HTML, the one that popped into mind is like gov, gov, UK are really good at having a design system and they're very consistent and they just use HTML.

Well, they have template files as well, but they have just HTML that you can copy and paste and reuse and. That's like really stretching what a design system needs to do, which is across, you know, different councils and different departments of like services within the UK. Like it's, it's quite widespread.

Mike: Yeah. And so you mentioned that design systems are generally geared towards. Larger websites or places where you're gonna have your styles in more than one application. Is there one of those scenarios where you wouldn't need a design system or is it just a kind of best practice? We recommend this.

Dave: It's not, it's not necessarily like, it's not that it's like not necessary. It's that whether it will return on investment now, like I, I I've thought I've thought in many occasions without actually knowing is that. I, I tend to build stuff with the hope that it becomes a problem to like, like clean up and, and work on better later.

Like I think it's, I think that's when you start seeing what the, what the value would be for us at a large scale, it's like a, almost a no brainer. It's like, we, we should do it from the stocks. We're so large that we need to. Plan for it. But if you were small or like you were quite a nimble team and you.

You could plan ahead and you could create a design system out of the gate, but you could kind of see how the chips fall and you go, well, actually we're reusing this so many times we might as well kind of create a central place for this. Maybe we just create some kind of rudimentary dock site, like statically and, and reside everything there and note down things, or I don't know, have just a Google drive with, you know, consistent like answers in there and solutions.

So I think. I think it's really good to have a have systems in place. And then when your design kind of gets to that scale, then it's like extending where you, where you need to create a source of truth. I keep using the phrase source of truth, but I, I think, I

Mike: I mean, it's a great phrase.

Dave: yeah,

Mike: And so at Nordhealth, now that you've got to that scale where your apps and your website's quite big, and you've got this design system, if a new component needs to be built, does it get built on the design system first or does it get built in situ first and then added to the design system?

Dave: So it tends to be built into our design system first. But there are cases where people might take the initiative and, and, and build something from our kind of other options. So it is our design system. Isn't so tight that you have to use a component every time or a web component. You can use a combination of web components, normal elements, and our CSS framework, or even our color tokens.

You can use all of that in the web, just as it's. So. For example, we'll be talking about today, like a button group where it's just multiple buttons, kind of wrapped together in one big section. And there are ways to like, build that custom, like just do it yourself and kind of make some adjustments and make it look good.

But what we would like to do is build it as an official component. So then we can kind of provide some consistency and help people get to that point without having to invent stuff or make stuff up on the fly. So to your, to your original point is kind of a combination of it, but mostly we try and do it inside the design system first, but it's, it's all collaborative.

So whenever stuff comes up, it's tends to come up in discussion of people using the design system and using the components and us kind of feeding that back in and, and working together to get those to get the desired, like results that everybody wants.

Mike: Yeah. I mean, you can have the best design system in the world and there's always gonna be an edge case. Isn't there. There's always gonna be that one, that one page where it just doesn't quite do what it needs to do. So the Nordhealth design system is very comprehensive. It's very thorough. It's really good.

I've had a, had a click through a few times, maybe stolen a couple of ideas. Is there any other like. Excellent design systems that you would recommend that people go and check out for inspiration or to even use. Cause you can use Nordhealth design system. I could go and use it, couldn't I, for my website?

Dave: I mean, you, you could, it's not designed to do that, but all the answers are there where you could just use it. I, in fact, when I, when I did the the talk the other week at Bristol JS someone said, could I just use this? And I was like, well, Yeah. like you, you can just go and use it if you want to.

But I would, I wouldn't recommend it because you would be when you would be using a design that kind of, that that's ours. And you wouldn't be able to really deviate from it. And, and the other thing is. Once we make changes, your stuff would change as well. Like and ours is kind of built for our use case.

So we've got like date pickers and things like that. But absolutely we, we, we like to, to be as open as possible because we, we benefit from the community so much and and to that effect, like there are a few design systems that we look at as inspiration. So for example, the folks over at Adobe, they're doing like a I think it's spectrum that the, that the design system's called.

Maybe you have to, I might be wrong on that, but that's a great design system. That's very comprehensive. And we use that as a kind of reference points in, in some cases. And I think the folks there look at ours as well and kind of were inadvertently kind of inspiring each other. And there is another design system called lion, I think.

And that's very open that has all the source code, like available one GitHub to like play around with. And that's a lot more not basic, but like simplified. Like they haven't gone too far with the design aspect, which means that it's it's, it's quite, it lends itself to just like regular web type presentation, a lot better.

And then there's Stack overflows design system. I, I can't think of what it's called. It's got a clever name and I can't remember now. I think it's called stacks. I think it's called stacks. That's another great one. And then other things we just look at like MDN and open UI and stuff like that for like reference points for,

for example, components and UI.

Mike: Great. And so is your, I suppose you, your design system feeds a few different websites and apps, so is your design system a standalone website?

Dave: So, yeah, so the, the, the main, like design system, like center is nordhealth.design. That is all built with 11ty that's. It's quite static. Most of it actually isn't the design system itself. I mean, we use the CSS and the token colors from it, but we don't use the web components themselves because they are designed for application use.

And we want the docs to be able to load like, you know, without JavaScript or, or as much without JavaScript as possible and to be fast and not kind of struggling to like build itself or load on the page. People need to get the answers quite quickly. So the that's where all the like answers are, but yeah, you're right.

We, we use the, we use the design system in private cloud, or we are using it if this is kind of early days for like actually using it inside of the product. And then it will extend into other products as well when we have we have different like themes for different use cases inside of the inside of those applications, like light and dark and high contrast stuff.

Mike: Yeah. So say I've got, I'm building a website, it's got a hundred different components. And the designer says to me, I think we should, you know, I think we really need a design system. How would I go about starting? Is it like just starting with some HTML pages copying and pasting and including the CSS?

Or is there sort of a, a good convention to follow or yeah. How would I, how would I make a design system?

Dave: So, so our work workflow tends to be like a lot of research up front, a lot of discussion, a lot of talking about what is in the current application and a lot about like what we want, where we wanna be. And then kind of investigating stuff and trying things out. So it starts in the design files in, in, and we use Figma a lot for our designs.

So the design team will like develop components in there and, and work on like how the, the look and feel and the, the interaction and the accessibility and things like that. And then. At the same time, we tend to experiment with code as well. But what tends to happen is the design is ready to go.

They've agreed upon like that component even existing. That's one of the kind of early days as well, where it's like, does, does it even need to exist as a component? Like, do we need that? Or do we wanna like have tabs instead of just buttons? And do we want it to be this complicated or this simple

Mike: Do you have a general, do you have a general rule as to like, cause I know I've worked on a lot of websites and often you are, you'll build a component and you'll be like, this is what tabs look like. And then someone will be like, I want tabs, but I want, it sounds horrible, but like a form inside of the tabs.

And it's like, is that. Our tab component with our form component, or is it our sort of like a, a new tab form component. So do you have like a rule as to whether something is a amalgamation of existing components or if it's a new one or do you just kind of take it as it is and review it and judge that way

Dave: So we, we, we we are, we're fairly like, not strict, but we, we like to have our, our components used in a, in a particular way. And we, we are quite heavily documenting each component as we make them. So funny you bring up tabs is the, the tabs. One is what I talked about in, in, in one of my articles. And I did a talk about it last week. Our tabs. When, when I first did them, I, I created one, where is an example, where is inside a card. So there was tabs across the top bar of the tab of the, of the card. And then the content main content of the card kind of changed. And when I talked to Viljami , our, our, our team lead and, and CDO they said, right, we don't want to do this.

We don't wanna have. Like it can be done, but we don't want to present this as an option. Really. If anything, the tabs go on the outside and then cards go inside of it because that's how we've kind of planned to have the structure. So if somebody starts kind of using our components in a slightly like exotic way, we, we tend to suggest trying to.

Come back into what, what we, what what's best. Another example is we, we, we spoke to somebody who was using tables inside of a card, and they again, were putting stuff that was designed for the main content into the header section. And what that creates is like a segregation in, in like accessibility, but also cognitive load of like, oh, this is a heading, but then you've got like, it's split into the, into the content area and the table's already come.

With a head heading anyway, so they should be using that. But in addition, they were using it using the tables for key value pairs. And it's like, well, really you should use a DL, a description list to like present that, that those details and, and values because it, it, you don't need the complexity of a table.

So we try to like, Bring not reign people in, but bring into like something that's gonna be a, a lot better to use in the future and a lot more appropriate for that case. Cuz not only will that be an example of like deviation, but slightly like inspiration, but for somebody else to kind of deviate even more and that's how, you know, stuff kind of really goes off track.

And when a design system is kind of failing is when stuff has gone. So off track. We aren't able to reign it back in because someone's built on top of like deviations too far in, in an undesired way. That's where inspiration comes in some cases, but that's like where it can really kind of go a bit astray.

Mike: And do you have a sort of going back to the sometimes there's edge cases that aren't, that don't fit in? Do you have a general rule of it's like use it once and it's. Sort of bespoke use it twice and it starts to get folded in as a component or is it just, is it again, are you kind of fluid on that in terms of whether you think it should be added or not?

Dave: It's it's very, it's very much fluid. We talk a lot on, on slack about how, how we wanna, like how components might want to be used, like where, where we would like them to be. Like, people are asking all the time, even when a component might not be needed, like somebody asked for like a button and input pairing that are like connected, as opposed to just.

Next to each other. And while we were saying that, like, maybe that we wouldn't wanna do that, it it's cool that people are able to bring that up comfortably and, and discuss it. And, and again, there was another example of like using it for pagination like somebody wanted a component for like pagenation and, and that would be really, really nice to do again, but we already have several components that will be able to achieve that.

Out of the box and it's only when maybe we are starting to see problems that we might kind of polyfil and say, right, let's make a real component to help people get a bit more guidance on what to do rather than all of these kind of deviations. But it's nice that people. Talk a lot be and we we've, we've partly encouraged that because we have so many different channels for different things.

So we have like, we have our own internal channel for, for like getting work done. And then we have an updates channel, which everybody can see, so they can see updates all the time of like on the repo and in the design files and things like that. And then we have a and completely open channel that people can come into as well as a design channel.

So we have a dedicated space for it. And I, and I think people are quite keen to talk in there and we. Try and talk in there as much as possible to, to keep the activity high.

Mike: So design systems ultimately are about. Communication

Dave: Y yep.

Mike: yeah.

Dave: It it's funny how it kind of keeps, it always comes back around in communication, which is like, you know, design and kind of all of those things. It's about talking about what we want to achieve with it and, you know, Being able to like facilitate everybody without without going too far as stray.

It's not, it's not because anybody wants to Rock the boat. It's just, they wanna achieve something or they feel like they're going in a direction, which is gonna be suitable. And they, they haven't got the tools to hand and we either need to help them make tools or help them with the guidance. And sometimes it's just documentation.

Like we had a couple of cases where we talked about it today, where it was, it's just a case of just writing some better documentation to help people go towards that right direction because they don't, they don't get to sit. Design system every day and play around with it and kind of try new things. And we, we have that privilege of being able to play with things and, and try stuff out and go, oh, well this would be a really good way to do pagenation.

But no one else knows about that and we need to share that and we need to continue to document and, and expand on our examples.

Mike: So I, I suppose we probably should have covered this at the beginning, but do you work, you work in the sort of style guide design system team. And is there other development teams in Nordhealth just using the style guide? Is that kind of how you are, how you're set up?

Dave: That's right. So there's, there's four of us in the design system team. We've got Eric Nick, Viljami and myself and we focus on the design system, but we're actually gonna kind of expand into actually using the design system in the product, like, you know, much in the same way as I think Google devel people actually rotate into using, into building stuff on Google chromes.

You get like real life experience, which is quite cool to be able to kind of spin around and do that right. As opposed to. It must be kind of difficult to, to, to, to relate so much when you are kind of making examples all the time. You know, if you're writing Laura IPSM all the time, it kind of probably gets a bit sickening to kind of keep

doing that.

So. We'll be doing that. But yeah, we work in that type team, but then we, we discuss, we discuss, excuse me, and actually fit into the greater design team anyway. And those designers are kind of working on all sorts of different products, so they could be. And I say products, not only that, but like parts of products, like our applications are so large that there's kind of smaller applications within it, like, like forms and appointment tooling and things like that.

And there are people that focus on those key areas and as well as people building those key areas,

Mike: Wonderful. Well I think that's it. Have you got any extra things you wanna say about design systems or any questions for me, I suppose.

Dave: Well, to anybody who's listening to this, if I've got anything wrong, then please do correct me, cuz I do get stuff wrong. I am human. And I dunno, I'm bringing up a blank, like entirely. I wanted to ask you a question, but now I'm like going completely blank, I just finished like a terrible cup of coffee, I put a bit of milk in it and it just, it looks so gray. I was like, man, this is, this, this. Coffee is ill.

Mike: So remind everyone how they can find you again.

Dave: Yeah. So on Twitter, I'm David Dans. I'll I'll, I'll spell it out for, just for clarity. D A V I D D A R N E S. I said that really robotically, but I for almost forgot my own name then. No, I do. I do need to get tested for dyslexia because sometimes it's, it's a struggle right? In my name, in a card.

Like I'm not even joking, but that's by the bye.

Mike: You need a stamp?

Dave: Yeah. Do you know, I did that once and my mum did not, was not pleased about me stamping my name in, in her card. So yeah, you can find me there and you can also find me at dan.es, which is my main website, but you, of course, you can just Google David Darns and you'll find me all

Mike: It's it is a good domain name. It's a good domain name.

Dave: Thank

Mike: I am @mikestreety on pretty much everything that's if, if I can't get mikestreety as a username, I don't sign up. So yes, that is that or this podcast has a Twitter, which is @behindsource without the, the. Cuz someone has that or behindthesource.co.uk, there is a mailing list.

I will be sending out some emails to annoy everyone. So please do sign up. So as this is episode one of the podcast I would appreciate any feedback comments, criticisms banter, or what's it called a comedy heckling. That's it via. Email or Twitter or anything. You can email [email protected].

If you'd like to be a guest on the podcast, then please drop an email. Or if you there's a particular topic you'd like to hear about then let me know and I'll go and find someone who wants to talk to me about it. But apart from that, I think that's the end.

Goodbye.

Dave: Bye