The SpoolCast with Jared Spool

The SpoolCast has been bringing UX learning to designers’ ears around the world since 2005. Dozens and dozens of hours of Jared Spool interviewing some of the greatest minds in design are available for you to explore.

Episode #273 Jenn Lukas - Developing a Living Style Guide with CSS

September 1, 2015  ·  27 minutes

Listen Now

Download the MP3

The notion of being a “designer who can code” has been a prevalent topic in recent years. Delivering static PDFs and working in photoshop is seen as inefficient in some circles. Being able to create a clickable or even responsive mockup to present to developers and stakeholders can be a better way to show your intent. It’s also much easier to iterate by changing a few lines of code.

Show Notes

One of the greatest benefits of using CSS is speaking the same language as your developers. Jenn Lukas takes it a step further. She shares the example of using a unitless line-height. Instead of looking at it in terms of pixels or em values, view it as a multiplier. This allows you to keep a coherent size across multiple devices and screens. Having this common language aids in creating a more collaborative feel to conversations with developers versus dictating to them what to do.

Designers don’t even necessarily need to know the whole gamut of CSS in order to design this way. Being able to use just enough code to create an interface element that not only shows how it should look and work but actually displays it in action is a powerful communication tool. Additionally, you create this living style guide that more closely resembles what the actual finished product will look like and how it will behave.

Full Transcript

Jared Spool: Welcome everyone to another episode of "The SpoolCast." I'm Jared Spool, your cruise director for this next few minutes. Today, we have the wonderful Jenn Lukas visiting us. She's going to be speaking at the UI20 conference, November 2nd, through 4th, in Boston, Massachusetts, where she's doing a full day workshop on "Mastering CSS to Build A Living Style Guide." I am so excited about this, and I'm so excited that Jenn's going to be there. Today, I'm excited about talking to Jenn. Jenn, how are you?
Jenn Lukas: Yeah. I'm excited too. That's how I am, excited.
Jared: Excellent. One of the things that I love about your presentations is how you make things that feel technical and complicated feel very accessible. I've seen you speak on a variety of topics, including on getting started with CSS. You take this thing that has all this mystery around it, because when you look at CSS code and you don't know what you're looking at it's a bunch of letters, carets, semicolons, and lots of brackets. It's filled with the brackets. There's a rhyme and reason to it and once you take that apart for us you make it really easy to understand what's going on and how it works. It's one thing to master something like CSS, it's another thing to master teaching something like CSS. How long did that take you to do?
Jenn: That's a good question. [laughs] I could give you the overnight or I could give you the still working on it answer, I suppose. I don't think I would ever say I completely mastered something because I think if I ever did I'd be bored because I wouldn't be learning anymore. I'd say I'm still doing it, always improving doing the stuff. One of the things that worked really well for me, and I believe in general, is the more that you teach and speak about things the more you understand it yourself. Becoming a teacher, leading workshops, and talking a lot about the subject of CSS has helped me to really fine-tune and cement my own skills in it. There's that idea, someone was talking about this recently, the rubber duck programming idea, where if you run through a problem, explain it as if you're talking to an inanimate object like a rubber duck.
Jared: Really?
Jenn: Yeah. I think it was Mike Monteiro. Someone was telling me about this. It's interesting because once you have to speak about what you're trying to do, the problem you're trying to solve, sometimes speaking about you'll solve the problem yourself. You begin, when you have to vocalize something, to understand what it is that you're doing.
Jared: You've been teaching groups like Girl Develop It, right? Am I correct that that's teenage girls?
Jenn: No, Girl Develop It, it was started in New York by Sara Chipps and Vanessa Hurst.
Jared: Right. I was thinking of...there's another one.
Jenn: Yeah, Tech-Girls is one of the ones maybe you're thinking of? There's a few. I worked here with Yasmine Mustafa to start it in Philadelphia. I taught the first class -- it's been four years ago now? -- an intro to HTML and CSS class. It's geared towards women. We have had teenagers with parental permission. Want to make sure that you're not off rogue-learning code at a young age. [laughs]
Jared: That's definitely something you need parental oversight on.
Jenn: [laughs] Don't want to go down the wrong path. It's really fun. I like teaching anywhere from 16-year-olds to 60-year-olds about this subject. A lot of the reason that I've been successful in it is because I love it so much. I found a passion when I got into front-end development and I really enjoy it. The more people I can talk to about it and teach, the more I'm like, "Yes, let me tell you about this thing I love." Because I've tried talking to people about my love of sports, and the Phillies, but you can't really find the right crowd for that, I've got to tell you. [laughs]
Jared: No, even at a Phillies game it's hard to find the right crowd for that.
Jenn: [laughs] Yes, exactly, so I'm sticking with what works, and what works so far has been my love passion for CSS and speaking about that.
Jared: When you and I first started talking about this what I was looking for -- for the program -- was what do designers need to know to be able to code. Because there are some that jump right into, but there are a lot of folks who are really hesitant. They believe that programming is a technical art that is to be done only by those who are well versed in the craft and it's not the realm that a designer should be in, but it's not hard to learn basic CSS, right?
Jenn: I would completely agree. I think a lot times learning anything new can be really intimidating for people, myself included, all the time. We think about things like sewing. If you don't know sewing right now, if you jump in and you're like, "You know what I'm going to do? I'm going to sew a dress," you'll probably be like, "Hmm, maybe I should start a little smaller, like with a pillowcase or a bag." Starting to learn sewing is something that when you first start you're like, "Wow, I know nothing about this." Then as you move through it you're like, "Oh, I understand these steps," and you build on them, you progress over time, and you learn more about it. It's the same thing learning anything, learning CSS, as well. You might not jump right in, you might not sew a dress, you might not build an entire website by yourself, but you take these little steps in learning and understanding the language, what it is, and how it works to build the websites that we design and build and code-write for these days. Jared: Once you start down that road of learning it, it actually can be a really powerful thing, right? As a designer it's not like you're going to get sucked into the development team and be expected to produce the production code, but there's some real advantages to having a knowledgeable access to that dialect of the design.
Jenn: Completely. It's so important to have an understanding, even if not the 100 percent thorough understanding, a good grasp of what it is that's being built to create your designs. When we understand the tools that we work with we all become better at our jobs. The same way as a developer understanding design principles can make me develop better. I know what to QA for, I know how to keep a consistent grid, I know what goes into good typography. These are the rules that make you more well-rounded. Before I knew that you might look at something, I'll make it a design, and I'll be like, "Oh yeah, that looks bold," but maybe it turns out it's really semi-bold. You want to be able to identify these things. Going the other way, to be able to know what CSS and technology is capable of really helps people to create better, stronger designs. To know where you can push the limits of design, to know where things can be scaled back, to know what goes into the building blocks of creating something. If I was going to make a table, certainly I could throw something together. It probably wouldn't last, but I could put something together. But if I knew what wood was going into my table I could help make better decisions about what table would last longer, what stains would work well with that. It's understanding the tools that go into it. As a baker I could look up a recipe to make biscuits and certainly follow it, but if I understood more about things that go into the type of flour, maybe then I would understand that they actually say White Lily Flour is a great type of flour to make biscuits, to help them rise better. I'm going from going, "Oh, yeah, I can make these biscuits," or "I can make these biscuits super-awesome."
Jared: It's interesting because when I hear people push back on the idea that designers should learn this stuff one of the answers they often give is, "Well, no one's telling the developers they need to learn design." I'm like, "Yeah, actually we are. We just don't need to say that here."
Jenn: [laughs] Yes, that's true. It's interesting, I think I've heard that before, too. Certainly design is development. I sent a link to someone the other day about the difference between em dashes and en dashes in smart quotes. These are the things that, even basic copy rules and learning about serial commas, can help make everyone better at their job.
Jared: I saw you stand in front of an audience of 500 developers and explain to them good typography habits and how to master fonts. Val Head has taught them how to design with animation. We spend a lot of time telling developers how to design. [laughter]
Jenn: Yes, I would say that's true. I wouldn't get up there and tell a developer how to create a typeface from scratch, nor would I be capable of doing that. There's the limit. You don't need to go as far as that, but there are basic rules and principles that are great to learn and know to get better at what you do.
Jared: Some of it is is that if we're all speaking the language, then suddenly things that come naturally to me, when I pass it over to you as a developer, you can look at my intention and see beyond the surface imagery.
Jenn: Exactly.
Jared: If I want the line-height a certain spacing because I think it's going to make the text more readable I can set that in the CSS. Then you're not guessing that I picked this or think that might be an attribute of Photoshop that caused these lines to be this distance, and you take whatever default comes with whatever and not explicitly set it, even though I was being quite deliberate. You can't tell what that intention is in terms of what's deliberate and what are we leaving off the table right now without seeing some sort of underlying markup to tell you what was played with and what was left alone.
Jenn: Completely. Even you using he word line-height instead of something like leading would let me know that you gave some thought into that. Exactly, using the correct terminology when we're describing what we're hoping to achieve really helps people communicate together. We talk about things, going back to type, the difference between describing typefaces and describing fonts. From a technical place I might describe fonts is the actual files that we're including on the site. You might say, "Ah, we shouldn't use so many fonts." I might be, "Oh, maybe you don't want this many typefaces, or maybe it means we shouldn't use a bold weight, an italic weight, a light weight of the actual files that we're including.
Jared: Exactly, "Maybe we should cut down on the files because we want better performance," or whatever it is we're going for versus, "We've created a ransom note."
Jenn: [laughs] My favorite kind of design.
Jared: [laughs] Yes, it's so freeing. It doesn't constrain.
Jenn: [laughs] "Get out of here warnings, Typekit, about how many fonts I'm including. I'm going for this."
Jared: It doesn't constrain me.
Jenn: [laughs] This is my web.
Jared: That's right. The web should be free. [laughs]
Jenn: Don't worry. We'll not be creating any of this in the workshop. [laughs]
Jared: That's good. No ransom notes?
Jenn: No ransom notes, unless that's like really wrote then I'll support you in smart ways.
Jared: The thing is that to be able to do this, you don't have to know every little nuance and subtlety of CSS. There's a subset of CSS that you can master that isn't that difficult and will get you from a designer perspective a lot of the distance of where you need to go.
Jenn: Completely. I'm certainly saying, "Hey, learn this," then go out and just become a one person team. Again, the idea here is that we're learning enough to be able to communicate better with our team, our clients, our employees, our vendors, and be able to talk to them better about how we want our designs actually translated. The idea is to learn enough to be able to say, "Oh, you know what's happening here? We actually need to bump up the font size," or, "You know what? Let's actually use this color variable instead of this one," or, "I see we're adding another font-face rule here. Let's actually use the conventions that we've already set up from this place." The idea is that we're learning these sort of parts of CSS that help us better say to the developer, to the team around us to describe our designs in a more technical way without going sort of over the top of having to know everything.
Jared: That makes perfect sense to me because it seems like people get intimated. I don't want to learn how to cook because I think I'm going to have to become Rachael Ray.
Jenn: [laughs] Then you also need to spell out your acronyms all the time. Please, don't do that.
Jared: Did she do that?
Jenn: She does that thing where she's always like, "Put a little EVOO on it, Extra Virgin Olive oil." Then sort of going down, "Don't forget your EVOO, Extra Virgin Olive oil." I'm like, "I get it. I know what EVOO is always at this point."
Jared: That's so funny which it doesn't actually take that much effort to say extra virgin olive oil. Actually, after the first time, you don't have to tell them that there's still extra virgins in it.
Jenn: You just say, "Here, put in the oil," like this is what we're doing here. I will say she has engrained that into my head, maybe what she was trying to do.
Jared: That's so funny. I've actually never watched her. I've only read her cookbooks.
Jenn: I've never read her cookbooks. I'm a Martha fan.
Jared: Her cookbooks are really awesome. Now that we're on the subject. She has this set of cookbooks called "30-Minute Meals" which when I was learning how to cook, I found those cookbooks to be really helpful because they have all these interesting combinations of ingredients, but each meal is really easy and really fast to make.
Jenn: It's almost like setting a series of conventions for you to follow as you learn how to cook. [laughs]
Jared: Exactly. There's a lot of similarities here. It works out really nice. Because we don't need all of CSS to do, what I had asked you for because one of the things that I'm seeing a lot of designers now take on is pattern libraries and style guides. A pattern library style guide is a great way to communicate with your whole team. The basic conventions are that you're going to follow as a team to make sure that the interface all looks like it comes from one company and one organization and that across different products and service you have what Nathan Curtis cohesion which is basically this sense that all of this stuff was meant to work together. The idea of creating a sort of living style guide, this idea of not only do you describe what the interface element should do and how they work, but you actually create enough code that people can see them in action and see them working. That we can do that with a subset of the full CSS language set. That's what I ask you to sort of explore and see. Could we teach a workshop on just enough CSS to do this? You've done a good job. It's going to be a great workshop. I'm curios how you decided what parts of CSS were perfect for this.
Jenn: Totally. Thanks for the compliment. I'm happy you enjoy it so far. I'm currently consulting for a group that I've help craft a style guide with and sort of done some basic training. I have a lot of conversations there and I identified a lot of sort of where trouble spots and where parts go smoother. One of the things that we've discussed and implemented there is sort of getting people more on the same language about how they're describing things. A perfect example, it comes down to describing your font rules in CSS, one of those things that comes up a lot is something such as line-height. We talk a lot about line-height and make sure that we're calling line-height because that's the technical term in CSS for it and that we sort of don't get anything awesome translation. Then we take a step further. You're in your Photoshop and it's a font size of 12 pixels and line-height of 16. Let's go easy math right now. Let's say your font size is 10 pixels and your line-height is also 10 pixels. You hand off the specs to your developer. You say, "OK, this is 10 pixels and the line-height is 10 pixels." One of the things that we like to do in CSS is instead use a unitless line-height. Unitless line-height means that we sort of drop the pixel value or points or ems or anything that we could use for describing the line-height. Instead, we think of it as a multiplier. Something like a line-height of just one would be one times your current font size. The thing that's great about things like unitless line-height is when it comes to designing across small screens and large screens and all those sizes in between is it becomes a multiplier for whatever your font size changes through throughout the document. You can keep this coherent line-height throughout your screen even if you're bumping up your font-size from 10 to 20 depending on what size device you're on. Describing things like this makes it easier too to fine-tune your design as it goes through different screen sizes. I looked at the things especially in designing and this like we all know mobile growth. We all know small screens. We all know other crazy devices that are happening right now. That's me designing certainly more of a handful than it used to be. I looked at a lot of the CSS that would help us conquer that. We'll talk a little bit about things like media queries because I think it's important, not just for developers to know how media queries work, but also for everyone else involved in the process to know how exactly with technical is working. If we're designing Mobile first, when do we apply this min width? The section of saying, "Oh, when we hit 600 pixels, why do we want something else to happen?" We'll talk a little bit media queries because, again, that's something that knowing about how that works will really help us design better. Knowing where the changes happen. How to apply those. To show, basically by yourself, you could pass off documents that says, "At small screens, I want my font size to be 20 pixels and at large screens I want it to be 16 pixels." Being able to write the code yourself that you can even test it in the browser then pass that off to a developer.
Jared: The whole idea is that as a designer, I have intentions of what I'd like to see the design be, but I'm not the one who's going to produce the final code to get there, so I have to communicate that to that person, and so things like specifying the line height, using multipliers to show the proportions of things, and using media queries to be able to demonstrate the change in behavior that I want the page to have when I move from one thing to the next. That's important. In a style guide, if I'm trying to get everybody to have the same changes in behaviors when we go from the smaller screen to the bigger screen, having a way to demonstrate that in the style guide itself would be powerful.
Jenn: Completely. We talk a lot about these things, but it's certainly easier to show it. That's why prototypes have been so valuable over the last few years, because it's really more important to get things into a browser sooner than ever before.
Jared: There are lots of things that people can learn by reading books. There are lots of things people can learn by scanning the Web and seeing blog posts, but my experience in learning coding in general, and CSS in specific, is that it's something that you want to practice with. Some of it's just teaching your fingers the right sequence of things. When do the curly braces happen? When do the semicolons happen? All those things that, when you leave one of them out, the machine interprets it differently, and then you've got a problem. In the workshop that you're going to do, you've built in a lot of practice.
Jenn: I have. I've also built in self-QA and debugging, so I think you've nailed it. One of the biggest issues when we learn on our own, and there are certainly amazing valuable resources on the Web to learn a lot of things these days, but what happens is when your code breaks, all of a sudden you're like, "Oh no. What do I do?" One of the things that I like to talk about when I teach is how to identify the problems in your own code, so you can learn how to fix it yourself. The good news about CSS is that most of the problems you'll run into are a pattern of each other, so if things like typos, things like missing semicolons. We'll go through how the easiest ways to find out where your code is breaking and why that's happening. We've a lot of tools at our disposal to use, so it's really great the amount of ways that it's made it easier for us to bug our own code.
Jared: That's very exciting, because for a lot of people basic user experience design says that nobody likes to feel stupid, so we shouldn't create environments and tools that make us feel stupid. Having to face these technical things and not know how to get out of a problem, and having to ask for help is one of those instances where it's like, "People are going to think I'm dumb." If I know how to start the process, solve it myself, and have the tools to do that, that saves so much of that effort, and then there's that feeling of accomplishment.
Jenn: For sure. I go back and forth on this a little bit. It's important to know, I guess, you should always feel comfortable asking for help, but it's when to ask for help, so one of the things I do generally in life is I work on something. If I hit a problem or a bug, I give myself...it's the 15-minute rule. I give myself 15 minutes to fix it. If I haven't fixed it or figured it out after 15 minutes, I'll ask someone for help.
Jared: That's a good rule.
Jenn: It works well, because it gives you that chance to use your own skills. I know these tools I have for debugging. Can I figure this out, or let me Google this, and see if someone's answered this on Stack Overflow, or any of the other resource sites out there. If I'm still not getting it, then I want to turn and ask someone, because if it's something like there's a typo in your code, you're not seeing it, you still can't find it, and someone walks over and, "Look. You wrote position absolutely, instead of position absolute." That's something that you don't want to spend an hour on it. You want to spend your 15 minutes, see if you can solve it. If not, move on.
Jared: Position absolutely.
Jenn: Allison Wagner, who I used to work with, and I, used to always joke about that. That was one of her favorites. She would write it all the time. You're going to have it, because you're just used to writing real words, and there's definitely a lot of real words in CSS, which is also a really nice part about it. That was one of the jokes we always used to joke about. "What's the problem?" "It's position absolutely, when it should be absolute." [laughter] See, CSS if full of fun times.
Jared: That's right. Part of me wants a T-shirt that says "Position absolutely." That's my new favorite band name.
Jenn: It's good. [laughs]
Jared: I'm really excited about your workshop. I'm tickled pink that we're doing this, and I think that it's going to be a fantastic day, and that we're going to learn a lot.
Jenn: That makes two of us. I'm excited about it.
Jared: If people who are listening would love to come to her workshop, and who wouldn't, the way you find out more about it is you go to uiconf.com. That's U-I-C-O-N-F.com, and you'll see the workshop from Jenn Lukas, who is talking about mastering CSS to build a living style guide. That's going to be November 2nd through 4th in Boston, Massachusetts at the User Interface 20 Conference. It's our 20th year of doing this conference. Isn't that crazy?
Jenn: That's awesome.
Jared: It's nuts, because we're not that far away from having audience members that are younger than the number of years we've been doing the conference.
Jenn: [laughs] So cool. It's so cool.
Jared: It is. We're just going to keep doing it until we get it right.
Jenn: [laughs] This is the year.
Jared: This is the year, then we don't have to do it next year. That'll save us so much time. You can come, and you can see Jenn at the conference and all the other great speakers. Check out the website. Again, that's uiconf.com. Jenn, thank you so much for spending this time today, and talking to me.
Jenn: Thank you. I'm so excited. I'm excited for getting to the workshop and eating clam chowder.
Jared: [laughs] We will get you some awesome clam chowder. There's a place just around the corner from the hotel, which has amazing clam chowder.
Jenn: Fabulous.
Jared: I will take you there myself. It's a fabulous little place called the "No Name" that is right on the wharf. Their clam chowder is some of the best in Boston.
Jenn: I can't wait to prove it.
Jared: Everybody who's listening, we'll all go to the No Name. It'll be fun. Fantastic. Jenn, thank you again.
Jenn: Thank you, Jared.
Jared: I want to thank our audience for listening, and as always for encouraging our behavior. We'll talk to you soon. Take care.