 As curators of the modern web, we all have little monsters we battle every day. And if you've ever had a 10-minute conversation with me about web development, you'll know that for me, that monster is usually JavaScript. I am forever battling JavaScript. My curly quotes are in the wrong place, my object doesn't exist, or it just plain doesn't work and refuses to tell me why. But I know that I can use it to build great things. And so I think we're going to have a love-hate relationship until one of us parishes. Now I consider myself a designer who codes. And so while I'll happily admit my struggles with JavaScript to anyone who's willing to listen to me, the monster that I don't tend to confess to is this. I'm not actually very good with color. For years, every site I built used the same color palette, white, black, red, and sometimes if I was feeling really adventurous, yellow. And if you look at my outfit, contents of my suitcase, or my shoe collection, you'll see that I haven't branched out a great deal since. And whilst I've developed an appreciation for color over the years, mostly via painting every room in my house, a different bold color, I still really struggle with getting color right for the web. My approach was often go to a site like coolers.com and hit the space bar over and over again until I land on a palette by chance that I like. And even when I do hit a palette that I like, it's never quite right when I apply it, so I have to tweak it and tweak it and tweak it. I never really felt as though I had a handle on color, but all that changed once I started using style guides. And I'm going to tell you how. But first, we're going to talk about what a style guide is and what we mean when we say living style guides. And then we'll talk about why a living style guide is so great and why it's going to make your life better and make you a better, happier, more productive designer and or developer. And then finally, we'll talk about how to actually get started using them, what you should put in them, and an overview of tools and techniques that will come in handy. And along the way, as promised, we'll be looking at lots of pictures of zombies just to make sure that everybody is paying attention. So a style guide at its core is a set of standards for the writing and design of documents. And you've probably seen one before. There are style guides for all forms of writing, for journalism, for academic writing, for government and law, for scientific writing. And there are style guides for design. These are common to print and branding, but they're still sort of new to the web. Traditionally, you would lay out a style guide in cork or in design or whatever you were using for a page layout, and then you'd print it. And they were often really well designed themselves, but they were quite static. They didn't change very much or very often. And anytime they needed to change, those changes needed to be done in a completely manual way. But on the web, our design systems change and adapt constantly. And so an out-of-date or stale style guide is worse than none at all. So what we need is a style guide that updates continuously as we iterate on our design. So when we talk about a living style guide, that just means that it's constantly updated. And ideally, that happens as automatically as possible, because humans are terrible at remembering to go back and update the documentation, but machines are pretty good at it. And that's really where living style guides get to being magic. So you may notice a lot of terms being thrown around if you read about style guides. And these terms all denote slightly different things. So a toolkit is more about the code itself and a pattern library is more about the individual components. And then you have style tiles and element collages, which are sort of similar but are often divorced from code. There's a lot of overlap here. And they all form this sort of really messy, complicated Venn diagram. So let's not get bogged down in terminology. We're going to talk about style guides here. And when we talk about style guides, what we're talking about is design documentation. A style guide is just a way to communicate and clarify your design decisions. Now, there are lots of reasons why you might want to document your design. The most notable is to improve the consistency of your work. When a project goes on for a long time or has a lot of people contributing, so for instance, most open source projects, it's very common to see a wide variety of styles that are super close but a little bit off. So multiple different shades of gray that aren't really visually distinct from one another, or margins that are one or two pixels different, or lots of sans-serif type faces that look more or less similar. And nobody is immune to this problem. This is a button on eBay's site. You use it to buy a thing. But I looked a little closer, and these are also buttons. And every single one of these is slightly different. The color is different, the gradient's different, they have different shadow effects. Some of them have rounded corners, some of them have arrows, some of them have underlines, sometimes the font size changes. When you see it on one page, it seems kind of ridiculous. And this is where a living style guide can really help. Because what likely happened here is that people didn't know that there were button styles already available. And so they made new ones. Or maybe there was a style guide but it was totally static and the styles changed and nobody updated the document. Seeing everything on one page like this makes it easier to spot those inconsistencies. And you can also use it to document your variables and styles. And when you keep them updated, people know what to use if they inherit your code long after you've left. Now the way we design is becoming more and more componentized, which means that mockups have less meaning and layout is becoming less vital. So adopting a component-based or style guide-driven approach to your workflow can really help to speed it up. And this doesn't need to be a big paradigm shift. You may already be using style tiles or element collages or whatever in your design process. And if you build those in HTML, you have the beginnings of a style guide already. If you tie that into your build system, you have something that's automatically updating as you change your styles. It can take a bit more time to get started with this sort of thing, but it does lead to faster development in the long run. Your first iterations are a lot truer to your final result and you don't need to repeat work as you move to the development stage. So you can sort of smooth that handoff between design and development. One of my biggest frustrations with modern web development is that I'm always needing to switch back and forth between pages because if I change one thing on one page, it'll change a different thing on a different page. With a living style guide, you have all of the elements that make up your site in one place and you can easily see how changing one of those elements will affect others. And it's that whole everything-in-one-place thing that really leads into improved testing across the board. So you can do better accessibility testing, better visual regression testing, you can do device and browser testing, you can test for performance issues. This is a tool I use called ToteA11y for color contrast and I just load my style guide in my browser, enable the tool and it finds any trouble spots. I'm throwing myself under the bus a bit because every pink thing is where I'm failing in color contrast, so I need to go fix that. And I'll admit to having gotten a little lax about browser and device testing as well lately, but with a living style guide, it's a lot easier to do that testing because again, you can test most everything from a single page. And then there's performance. As more and more people begin to access the web from mobile devices, performance becomes more important and it's not just a development problem, performance really is a design problem and it's something that we need to be thinking about in the design phase. So we can use a style guide to spell out any code rules we might have for a performance or maybe specify our performance budget and we can also use it to prevent duplicating elements. Every style or icon or font file that you duplicate adds to the weight of your page. When you see everything on one page, it's easy to audit the unused styles. So this is a tool called dust me selectors and it scans the page and outputs all of the CSS selectors in your style sheet that aren't being used by your HTML. And if you look here, you can see I have 250 unused styles. My style guide isn't completely built. It's not actually that bad. But if I scroll down to the bottom, I can see all these image and gallery styles that I'm not going to use in my project. And so I can go in, remove those styles from my CSS and save some weight. Design documentation means that not only is every element on the same literal page, but every person is on the same figurative page. Now I love developers, but I think spending all day staring at a terminal window can lead to what I'm going to call a tragic underuse of white space. So sometimes if you're working with a developer, your design can get a bit mangled in the process. But if you have a style guide, you have this documentation that spells out your gutters should be 40 pixels. That implementation is a lot clearer and you increase the understanding and dialogue between developers and designers. This means that we don't need to just hand off a design and abandon it. That process becomes more iterative. And style guides don't just improve your relationship with developers. Spelling out available styles and how to use them is good for everybody you work with. For other designers, for copywriters, for content editors, and for future you. A style guide is also an opportunity to show off a little bit. Many companies are posting them publicly, which allows for more discussion and transparency. And it also shows a commitment to good design, which can help with hiring initiatives. Buffers, for instance, has a link right at the top saying that they're looking for product designers. If you can show that you have a culture of design, designers will be attracted to your organization in much the same way that showcasing your open source contributions does to attract developers. But the number one most important reason to use a style guide is that it will allow you to build more beautiful websites. Seeing everything in one place allows you an overarching and holistic view of how your design system works and how all the pieces fit together, which makes it easier to smooth out any conflicts and ensure that everything's been cohesively designed. Now style guides are pretty flexible. You can basically put whatever you want in them. But if you're stuck for ideas, here are a few things that commonly show up in them. Branding is a pretty obvious place to start. So here's my logo, here's my logo type. Here's where you find the file, so everyone knows where to download the file in a format they can use, and any rules for its use. So maybe you want a 10 pixel gutter around it. Maybe it should never be on purple and it should always be facing that direction. You can also put all the colors that are used in your pallets here, both hex codes and CSS variables, and make them copyable if at all possible. Again, include usage instructions. I like to use really big swatches so I can see how the colors work together. And you can make those proportional to usage. So your primary color could be, say, three times as big as your accent color. You can also include rules for accessibility here. So if you have a certain contrast ratio you're trying to hit, go ahead and include it. This is Yelp's style guide. They have their primary red there, it's called Yelpy Red, which I thought was really adorable. This is a really subtle way to enforce brand and to add personality. And again, this can help with things like hiring initiatives and public perception. Include any typographic styles, so heading, lists, block quotes, et cetera. This is a good opportunity to ensure that your type styles are really consistent. I once audited a site and found five different, more or less the same sans-serif typefaces being used. Every extra font file you use adds to the weight of your page. And it's very easy to accidentally load a lot of weights and styles that you may not be using at all. And I'm quite guilty of this myself. I recently checked my own site and it had nine different font files being loaded, some of which weren't being used. Show buttons and form elements. So active hover and focus states, any primary and secondary buttons, inactive buttons, and all your form elements to make sure that everything fits together. If you're using a grid, it's great to document it. And any other layout structures you might use. So I always set a variable for a gutter and then I have a few rules like you can divide it by two and four and you can multiply it by two but that's about as much as you can do with it. Include a visual representation of your icon library. If it's big, make it searchable. And again, usage instructions. So I use SVG icons for all of my sites and I provide a PHP function for developers to use as well as a short code for content editors to use. And this makes it easy for everyone to pick out an icon and use it. All of the elements that make up your site should be included here. So anything that's repeated more than once. Cards, dropdowns, interactive elements, avatars, feeds, images, captions, galleries, all of that. Let's say you're building a custom WordPress site which I feel is a safe bet. Any custom short codes you might be including should also be documented. This is particularly helpful if you have content editors who might be a bit less technical. And again, you can show the short code and the visual output and the reasons for using it. Include animation patterns as well. So any saved key frames or Bezier curves. It's nice to show how the animation actually works and include rules for how those interactions should work. So you may want to use an ease in function when an object moves into the screen and ease out when it leaves. Having a motion style guide will help your interactions to feel choreographed rather than chaotic. And your style guide is good place to enforce other kind of related stuff like code standards or rules for copy, grammar, and tone. Copy is actually pretty integral to design and to how a site works. For instance, do your headings use sentence case or title case? I've seen lots of websites where they alternate between the two. If you're stuck, I recommend sentence case. It's easier to read and you don't need titles. Tone also is a big part of brands. For the golden standard here, look to Mailchimp's voice and tone guide, which does a great job of communicating personality as expressed via microcopy. Whatever you put in your style guide, it's important to remember that it's documentation. So make sure to explain it as fully as possible. Start with the what. Here is a medium blue color that we use as our primary accent and then move to the how. Here is the hex code for that color and the variable that we use. And for bonus credit, include why as well. So we use blue because it's calming and gentle and serene and if zombies are calmed, they won't try to eat our brains. And don't forget that you can style the style guide itself. Especially when they're automatically generated, style guides on the web can be a little bit boring. So I like to style mine to fit in with the feel of the site. Think of them as an advert for all of the great design you're doing, especially if you're interested in attracting design talent to your organization. If you're stuck and need inspiration, look to all of those great print style guides. So now that you know what to put in one, how do you actually go about making one? The hardest part here really is choosing a tool. There are loads. When I started writing this talk, styleguides.io had 102. Today, they had 105. So trying them all out is sort of logistically impossible. So we're gonna touch on a couple of the major tools you're going to come across in more or less the order of complexity, by which I mean the order in which I tried them. So first up, I looked at static generators. These tools are the easiest way to generate and manage a style guide, especially if you don't want to touch the code, but they're not going to build you a living style guide. This is stylify.me. It's a super basic tool. You just enter your URL and it'll spit out any colors you've used and type styles, and you can download it as a PDF. I'm picking on eBay again here. You can see they suffer from that multiple shades of gray problem. They have multiple shades of off-white as well and an excessive number of type styles. This is a nice, quick way to see what you already have and assess where there may be problems. But it's obviously not living at all. You would need to regenerate this manually every time you update your site. And it's pretty limited to what it's able to pick out of your CSS. For a more in-depth tool, you can try something like Frontify Style Guide, which is a platform for creating and maintaining a style guide. This is great for more traditional and controlled style guides, but it's really closer to those old print guides because it's totally manual. You have to enter all those colors and things manually. And the danger of these tools is that it's very easy to let your style guide get outdated unless you're going to be super vigilant about ensuring it's updated every time you change your styles. So one way to start dipping your toe into style guides that are a little bit more alive is to start by adopting a style guide-driven approach to your design work. So I start my projects by doing wireframes, which I mostly build and sketch. Each component is a symbol, and once I'm finished with the wireframes, I can just go to the symbol library, design each component individually, and I end up with a library of styles and a full mock-up that uses those styles. Now, I like to use Sketch for complicated projects, but a Sketch file isn't alive. And simple projects may be better suited to HTML. WordPress is actually a pretty great tool for HTML wireframes. It's relatively easy to input all your content and then to tweak the functionality and placements a little bit in a skeleton theme in order to mimic the content and functionality of your final site. And if you build your wireframes in WordPress and then you start your design process by building an HTML and CSS style guide inside of your theme, when your style guide is done, your website is kind of done. So what I've been doing lately is I have a bunch of PHP files that I put inside my theme. They're manually coded with a bunch of snippets of markup, and they pull in my main themes, style.css file, as well as some additional styles for the style guide itself. This is all tied to my build system, so it looks in the SAS source files for variables and automatically builds the styles for the style guide. It's pretty simple to implement, and I've been building it up ad hoc as I've been working on more projects. I extracted the code into a plugin. It's at github.com slash seramonster slash zombie style guide. You can feel free to fork it, experiment it with it, complain about it. I like this method because it gives me lots of control. It's tied to my build process, and I can use things like live reload with it. Ended updates with my style.css. So it's a little alive, but it's still kind of only half alive because I need to manually add all those snippets, and if I don't update the markup, the examples won't be up to date. So I wanted to investigate further, and this led me to CSS documentation parsers. There are loads of these, SAS down, style down, hologram, DSS, style.com, but the most popular is KSS, which stands for Nile Style Sheets. It's basically a syntax for the comments in your CSS. So I use drop caps pretty heavily on my site, and the code for those looks like this. With KSS, it looks something like this. Those comments become the text and sections of my style guide. So here you can see my drop caps are in section 2.2, and I've provided the markup for KSS to use as well, and then when I parse the code, I get a style guide that looks something like that. Now KSS is just the syntax. It doesn't actually do the parsing or build the style guide pages itself. For that, you need another tool. I've been using SC5 style guide, which is just a tool that generates the style guide itself from your KSS notation, and you can use it via gulp or grunt, and it has this nice feature where you can edit your variables via the web interface, and it'll save them to your source files, which is kind of neat. It's a little bit ugly by default, so you may want to style it a bit to match your site, and I've been struggling a bit with getting custom styles to work well with it, which is why it looks sort of atrocious right now. So CSS parsers are a bit more alive. You can see the snippets as you're working on the CSS code that refers to those bits of markup, but ultimately you're still maintaining two code bases, and you're still manually writing that content, and you still need to keep those snippets up to date. For a truly living style guide, what you basically want is a bunch of components that are included in both your style guide and your site. And for that, you'll want to look at style guide platforms. These are full-featured applications all on their own, things like Fractal Pattern Lab, Source.js, Rizzo, Fabricator, and they kind of require a bit of a rethink about how you build a site, because you need to start by building the components individually and then piecing together those components in order to build your site. A tested Fabricator, and it was pretty simple to get up and running with. You just run a few commands, and it outputs this ready-to-go style guide, and you use the provided toolkit components in order to build your site. It starts getting really technical here, and I'm not entirely sure how these tools would fit into a typical WordPress setup, but they could be worth investigating if you're working on something that's quite complicated and long-running, or if you're using React or a similar tool to build your front-end, and you already have a componentized set of components. But the bottom line is, you want to find something that fits into your workflow. The more complex your project, the more complex a solution you may need, but a simpler project might warrant simpler tools. So I might not be able to tell you the perfect style guide tool for you, but I can tell you what helped me finally sort out my color problem. So this is what my style guides look like right now. Big swatches of color. I've set all of my colors as SCSS variables, starting with neutral base colors that I use for backgrounds, body text borders, et cetera. Then I include a primary color in three different tints, and then an accent color or two, as well as a highlight color. And this gives me a pretty extensive palette to work from, and I only use those colors. Then my original approach was to just set one primary color and then use SAS's dark and lightened functions to get tints and shades of that color. But if you do that and you look at those colors all together, you can see that it's not quite right. Those lighter tints are too saturated, and the darker shades aren't saturated enough. So we're going to adjust the saturation as well. Less saturation for tints and more for shades. And this is a little bit better, but it's still not quite right, because if you look, the shades are getting kind of bluish, and the tints feel a bit washed out. In order to get our color just right, we need to adjust hue as well. Hue indicates the color part of color, so like red, yellow, purple, and we represent hue as a circle with red at zero, green at 120, and blue at 240. You can break color down into hue, saturation, and lightness. And when we create tints or shades, we've already adjusted both the saturation and the lightness, and we need to compensate for those adjustments by adjusting our hue a little bit as well. The thing about colors is it's just numbers. So to make a darker shade, for instance, you want to shift the hue toward the closest primary color of light. So red at zero, green at 120, blue at 240. So if my original color was 144, my closest primary color is 120 for green, and I shift my hue down a bit and end up at 130. If you're going lighter, you want to shift toward secondary colors. Yellow at 60, sine at 180, and magenta at 300. So my original color again was 144. My closest primary color is 180. I shift my hue up a bit this time and end up at 150. And when we do that, we go from this to this. And that may seem like a super subtle difference, but it's actually a big improvement because when I apply these techniques to my original color palette, instead of this, I end up with this. And ultimately, this has led to my feeling more confident in my color choices, and it's allowed me to build better palettes for my sites. And I never would have figured that out if it weren't for style guides, allowing me to see everything on one page. So that's one monster down. Next up, JavaScript. Thank you. Sarah, thank you. We've had several people declaring over the course of these past two days that design isn't just about making things look pretty, and I think that underlines just how deep and technical design actually can become. Do we have any questions from the room? If so, I'll ask you to follow protocol as before and take to a mic done by the floor. We have a question just done on this side. Thank you. Hello, my name is Mike, and I'm interested in what style guide platforms have you tried out, even if there were more complicated? It was the first time I've heard about those, even though I've used SC5 in cases and I was really happy about how projects went using them. Well, I'm still struggling with SC5, mostly because the custom styles are a bit weird. The only sort of full-featured platform I've tried was Fabricator, and it's honestly probably a lot more involved than something I want. I'm still leaning towards simpler tools. Thank you. I'll try Fabricator out. Let me know how you find it. Thank you. Do we have any more? Is this one approaching from down here? It is. Thank you. Andrew from US, thanks for your talk. Could you go back to that slide so we could get the URL? I did have a question. What's your process with clients? Do you show them these style guides as part of your design process and do you show them working design with it or can you speak to that a little bit? How do you establish this style on a new project, let's say? So I feel like that's always contextual based on the client. I've had clients that I can show a scribble drawn on a napkin to and they understand what I'm talking about. And I have clients who need to see basically a full-blown website before they can visualize it. So I think you have to feel that out to some degree, which is a great vague answer. I think a style guide is understandable and I think in a lot of respects that's actually more representative of what you're likely to be building than a mock-up because when people see a mock-up they tend to think, oh, that's what my website is going to look like. That's not really how the web works anymore. It's different on all kinds of different screens and devices and a mock-up generally doesn't show the interactions either which are becoming more important and things like animations, you can still show in a style guide. So I think with education, you can definitely show those to clients. Thank you, we've got time, maybe for one more? I think we might be done. Oh, no we do, we have one very late entry, just over here. Hello Sam here, thank you very much for a great presentation. I would like to know how having a pretty good style guide can make you more productive with finishing the theme actually. Sorry, could you just rephrase the question a bit? Actually, I wanna know how can style guides make you more productive and influence how you can faster finish your theme on the website. Okay, so the question was how can style guides help to make you more productive? Yeah. Basically, it just helps with getting a workflow up and running more quickly. You can use a style guide, this is going to depend on what your individual process is but you can use a style guide to sort of negate the mock-up stage which is often slow and manual and not necessarily super representative of what your final product will be. You start with a style guide, you can actually get up and running with it really quickly but the real benefit is that it allows you to move more quickly into the development stage of things because you don't have to take a bunch of Photoshop files and recreate them in code. You already have all of those components and snippets ready to work with. So once you're ready to move to the development stage, you can get that through a lot quicker. Thanks. Fantastic. We're gonna wrap it up there. Ladies and gentlemen, can you please thank Sarah Seymour?