Bummer! This is just a preview. You need to be signed in with a Pro account to view the entire video.
Design the Code, Not Pixel-Perfect Comps22:00 with Katie Kovalcin
We know that designers need to code more, but we also need developers to design more. When developers are coding early in the design concepting phase, magical things start to take shape. - Designers refine early design concepts by visually proofing live code - Developers code early design concepts rather than finished templates - Designers piece design as needed - Together, focus on CSS transitions and behaviors early and throughout the design process, not as an afterthought This talk focuses on the perspective and benefits for both designers and developers when collaborating and using CSS early in the design process.
So, if anyone does client work 0:00 you'll know that we often times can't talk about it. 0:07 So while I would love there to be a wholesale skull and 0:11 crystal distributer, this is not. 0:15 This is the actual page layout in site. 0:17 But, for the integrity of the client, I've swapped out the content to 0:20 be New Orleans themed and spooky CSS Stub comp stuff. 0:25 So, we're gonna walk through how we made this site, with New Orleans in mind. 0:29 It starts with everybody being involved from day one. 0:35 It super, super important to have everybody talking about this 0:41 stuff together. 0:45 Like, the back end developer is usually the last person to touch the site. 0:45 And we want them sitting down with the content strategists at the beginning of 0:49 the site, figuring out how they're gonna build that CMS in the end. 0:53 And we want the front end person talking to the designer about ideas. 0:56 we, we just want everybody to know what's going on throughout the whole project. 1:01 We want to create goals together so 1:05 that we can objectively compromise on them moving forward. 1:08 Something like a performance budget where we set the goal for 1:11 how lite we want our pages to be in the site overall. 1:15 We wanna set that in the beginning together. 1:20 Because if a developer sees something like a performance budget or 1:23 this really cool technology or idea they wanna try, that's awesome. 1:28 That's great, but if the rest of your team is not on board or aware of it, 1:32 you're gonna get really frustrated. 1:35 Because, say, you just have this idea in your head like, I'm 1:37 going to meet this number in my head, I'm gonna set a performance budget to myself. 1:41 Well, if the designer isn't aware of that and they hand you a page that's like, for 1:45 whatever reason, 4 carousels in 12 font-weights, 1:50 you're gonna be really upset trying to retrofit that into your budget. 1:53 So if we can set something like this together from the beginning, then, 1:58 when the designer comes to you with a million carousels and plot weights, 2:02 you can go, that's going to blow our budget out of the water, and 2:06 then we can try to compromise and resolve that together. 2:09 We also need to educate the client from the beginning. 2:12 Believe it or 2:16 not, clients do not make websites every day, and that's why they hire us. 2:17 So, we can use this to our advantage. 2:22 What we might think is a typical deliverable of, 2:24 okay, we send them a Photoshop document and 2:27 then we code it up and then like, that's just how websites are made. 2:29 We can just educate them from the beginning on what to expect. 2:34 At Happy Cog, we sort of tell the client upfront, like 2:37 we don't really know what the deliverables are gonna be until we get to know you and 2:41 your team and the problem we're trying to solve. 2:44 So, we can say things like, yeah, 2:46 we're going to do some preliminary design work that's static. 2:50 And then we're gonna move right into code and you're gonna see some design as code. 2:53 And just setting that groundwork to be able to sort of 2:57 be flexible with our deliverables. 3:00 So we wanna be really upfront with them and be able to get them on board and 3:03 excited about these things. 3:08 We even show that project hub at kickoff and 3:09 say, this is what we're gonna be delivering your stuff in, and 3:12 get their development team really excited to see things out that way. 3:14 So we just wanna let them know ahead of time to be expecting to see 3:18 design as code. 3:21 We also wanna make sure that we are using the same words. 3:23 Something like template means a hundred different things 3:26 to a hundred different people. 3:29 So we wanna make sure that when I say, here's a template and 3:30 they give feedback on a template, that we both are meaning the same thing. 3:34 And this is especially important when we start to get into that 3:38 pattern library that uses those sort of, arbitrary words. 3:41 We wanna make sure that when they give feedback and 3:46 we're talking about things that we're meaning the same things. 3:48 And we also need to guide their feedback. 3:52 It can get really overwhelming for 3:55 them if we're like, here's design and design is code. 3:57 And they're like, okay, am I like, looking at the code? 4:00 Am I looking at the design? 4:02 Like, you know, what, what do you want me to look at? 4:04 So being really clear, like, we want, design feedback. 4:07 But we also need to remember that interactions are design. 4:10 Which I'll get in to in a little bit later. 4:14 But, we just wanna be clear. 4:18 Like, hey, re, we, we have reworked, reworked a, b, c. 4:21 And we did x, y, z to resolve that, you know, what, what are you thinking of that? 4:26 So just being clear and guiding the client feedback. 4:30 So, this is also assuming that, okay, now we've done that preliminary stuff. 4:33 We have the whole team on board. 4:37 And we've done our research and wire frames and stuff. 4:39 And now we're gonna get into actual design. 4:42 So, we need to establish our design direction. 4:44 For this particular project that I'm walking us through, 4:47 the client actually provided the design direction. 4:50 They already established, based on their consumer-facing website, 4:54 all these design styles. 4:58 So that was a really nice luxury. 5:00 So that doesn't usually happen, 5:02 you usually have to do some sort of style tile or moodboards. 5:04 So, since I don't have an example because 5:08 the client provided it here's a different example of what I mean. 5:11 Where it's just a collage of elements. 5:13 And how images can be treated. 5:15 And really pushing the brand and seeing, where we can take things. 5:17 And I want to try a couple different directions. 5:21 Maybe one feels a little more like the brand and 5:23 will respond to one a little bit more. 5:25 So we wanna just work with the client until it feels right. 5:29 And then ultimately after a couple rounds move into some sort of 5:31 moodboard that feels more like an actual page. 5:36 And what we really wanna get out of this is different UI elements and 5:39 those sort of pattern library elements. 5:45 We wanna see how they're responding to those, what they're feeling good about. 5:47 So in this example they really liked this sort of cut paper feel for 5:50 buttons, so we knew that was something that we were going to keep around. 5:54 Because the next round, we're going to work on our coded style guide. 5:58 So all of those UI elements, when the client is feeling right and 6:02 responding well to them, we wanna be able to immediately code those out. 6:07 We know we're going to use those, we know we're going to need a button style in 6:10 our type style, so we should start coding those now because those will help us 6:14 moving forward, having those already laid out. 6:19 So what that looks like is, we have all of those basics, 6:22 those atoms those very granular things. 6:27 The buttons, our icons, our typography, forms. 6:30 These are things that we established this early, like right 6:34 when we're design concepting and we know the direction that we're heading. 6:37 So we can see that there's the code for 6:40 them, there, the client team to be able to use and 6:43 extend and we know that we're gonna continue to use it throughout our system. 6:46 Same with buttons and field set, and 6:51 basically all the components that we know every web site is going to have, 6:53 we wanna try and style those out now, and prepare ourselves to build on that. 6:57 So, like I said, 7:03 we still want our designers to design whatever they feel comfortable in. 7:04 So, moving into a full page, this will also probably be a static mock-up. 7:08 And that is totally fine. 7:13 That's totally applicable and not gonna hinder any of this sort of coding it out. 7:14 So this is the flat mock-up. 7:21 What we do is we like to do like a desktop homepage or 7:24 just one page and then do a different device size of like an interior page. 7:29 Because we wanna put as much for the client right now as we can, 7:35 get a nice wide range of those styles and see again what they respond to. 7:39 So we have the desktop homepage. 7:43 And then, like I said earlier the tablet experience is really important, 7:46 so we have an article tablet page with the different type scale and everything. 7:52 So we're able to really push and pull styles see how their working for 7:57 different devices and also be able to con, condense them because when, when we 8:00 start coding this out then, we'll be able to see where we have duplicate styles. 8:05 Because the developer will say, okay which one? 8:11 Is it from this page or this page? 8:13 And then we'll be able to really condense them and 8:14 make a nice clean coded style guide. 8:16 So to get the client sort of used to seeing our designs in the browser we like 8:21 to deliver them sort of like a faux website in the browser. 8:27 What this looks like in our project hub, is we have the mock up and 8:32 this is just one big jpg. 8:36 This same one that we were just looking at. 8:37 And then with a little bit of HTML and CSS, we have a one 8:40 pixels repeating background going behind it, that we took from the JPEG. 8:42 And, you can see that it sort of gives them the feel and 8:46 the illusion that this is a website, even though they can't interact with it. 8:49 They're just used to them seeing it in the browser. 8:52 So then we're gonna get feedback on those. 8:54 And we wanna feel comfortable that this is the right move and 8:59 that we're, we're headed in the right direction. 9:04 If the client's like, this is not really feeling like our brand, 9:07 we'll probably wanna go back to Photoshop and try again. 9:12 But, if it's kind of minor feedback that we feel can easily be achieved in code, 9:14 then we can move into code right now. 9:20 And if you're keeping track, 9:23 this is now the third design deliverable, and we're already coding it out. 9:24 And that is awesome. 9:28 So, the feedback that we got on this comp was this right rail. 9:29 The different modules were feeling like they were kind or running together. 9:35 So, separate those out a bit, okay, easily achieved in code. 9:38 They wanted this promo area to be more tied to the promotional 9:43 products below, okay. 9:46 So a little bit of design rework. 9:47 No big deal. And 9:49 they wanted to add another carousel that had new arrivals, 9:51 in addition to the closeouts. 9:54 Again, really easily achieved in code. 9:56 So we felt confident moving forward that we could code this out and 9:59 make those changes for the next deliverable. 10:02 Which we are now going to deliver them a coded design deliverable. 10:05 When we first put this in front of the client when we first tried this out, 10:10 they came back and said things like, 10:16 when I click off of the drop-down in like the gray area I want it to close and 10:19 not like, have to click the link again to close it. 10:23 And we were like, oh no, 10:27 we, we weren't clear this is a design deliverable, we need design feedback. 10:29 And then we were like, a little lightbulb went off like, no this is awesome, 10:33 this is awesome that they're thinking about this, this early on because now it 10:38 won't be tracked as a bug at the end of the development. 10:41 So these are things that when we put it really early in front of the client and 10:45 get them thinking about these things and interacting with it we'll catch a lot of 10:50 those things really early on and not get pushed down the stream. 10:52 So things like the dropdowns and popovers and 10:57 stuff, those are things that probably haven't been accounted for in design yet. 11:00 And that's totally fine because now we can catch them because the developer's coding 11:04 it out and then saying hey, I need a style for this. 11:08 And then if you're keeping track, if the developer is getting more used to 11:11 design and getting a little bit more design savvy. 11:16 It's really awesome to just take a first crack at styling that and 11:18 then go to the designer and say, hey, I styled that drop down, what do you think? 11:21 And then the designer can either go in and 11:25 sort of finesse it or just say like, no, good job. 11:27 And that's especially awesome for responsive layouts. 11:31 If a developer can take a first crack when they're coding it to sort of say, hey, 11:34 like what do you think if we put this over here. 11:39 And then the designer can say, 11:43 yeah that's awesome good idea or you know again do a little mock up. 11:44 So, like I was saying before, trying to catch these things with the client early 11:51 this watched items over on the right rail through wireframes and 11:56 early design and everything, we didn't think about how to sort of, unwatch them. 12:01 And then as soon as we put them in front of the client and 12:06 they were sort of interacting with it, they were like, how would we unwatch this? 12:08 And we were like, oh, we haven't thought about that. 12:12 So we developed this little system. 12:16 And again that's something that wouldn't have been accounted for 12:18 until much, much later. 12:21 And we're catching it really, really early on in the design deliverables. 12:22 So since this is still a design deliverable, 12:28 we definitely want it to still be designed and designed well. 12:30 I know that I was feeling a little guilty when we tried this at first, 12:35 that the developer was spending all the time on like, my design deliverable, so 12:39 I started to get in there and really finesse and nitpick the CSS. 12:43 And now is the time for it, that to really work and work well. 12:47 so, we wanna keep design iterating on these things. 12:52 Something like hover animations, 12:56 unfortunately I kind of would forget about those until the very end. 12:58 We're just like we'll pick a darker color, whatever. 13:03 But in that time where I was like really trying to play around and 13:07 like, get into those little granular details and really smooth things out like, 13:10 little messages like, how would that alert go and adding the little bounce and 13:13 stuff, those hover animations that usually kind of get overlooked. 13:17 Now is the time for the designer to get in, get in there and 13:22 really have some fun with that and figure out some cool CSS animations. 13:25 So, I had a lot of fun with this because I had the time to sort of nitpick. 13:31 We're really only coding out like, two pages at this point. 13:35 That's only like two pages worth of CSS. 13:38 So, now is the time for us to get in there and really smooth things out and 13:41 really get those to that pixel perfect detail. 13:45 But actually in code and not in Photoshop. 13:49 So now is the time for 13:54 us to QA and then our system as we build on it, will already have all of 13:56 those nice details that we've spent the time working out really early on. 14:00 Like I've been saying, 14:04 we want to catch these things early because they are design iterations. 14:06 They are not bugs. 14:10 Bugs are, this is broken in Internet Explorer. 14:12 Bugs are not, I want the modal to close when I click in the grey area. 14:14 Those things that usually are tickets at the end of development that 14:18 are sort of less important than like, actual bugs we can account for 14:24 those now, especially design. 14:28 A lot of times, I know I tend to make tickets that are like, 14:30 little design nitpicks and those usually don't get accounted for 14:35 because we have real bugs to solve at the end of development. 14:38 So we wanna get that stuff in now. 14:42 We wanna get the, those client in, iterations in now. 14:43 And all those design iterations now. 14:47 And as we continue to build this out, we wanna make sure that we're documenting it, 14:50 we're making it this modular, extensible code. 14:54 This is that homepage that we saw coded out. 14:57 And you can see we have the footer pulled out. 15:00 You can't really see it that well, but you can interact with all of the links. 15:03 This is a fully functioning code that they can pull. 15:06 Let's take a look at the stories, those news items that were there. 15:10 There's the description, and then the code for the client's team to then pull out and 15:13 reuse once our engagement's done. 15:18 So, we can take it a little step further and go down to just then that news item. 15:21 So you can see how these blocks kind of build on each other and 15:27 we can get more detailed as we dig in. 15:31 [BLANK_AUDIO] 15:33 So this next part is a little bit more fluid. 15:36 And will take a lot of back and forth with your team to sort of figure out. 15:40 Designers really like to be perfectionists and, you know, 15:45 figure this stuff out before letting anyone else see it. 15:49 But we need to sort of let go of that and 15:54 really talk it out with developers to figure out what they need from us. 15:56 So the developer can say, hey I really need this module design from you, and 16:01 really just trying to fill in those gaps in our system. 16:07 Dan Maul has said it really nicely where he said it's about deciding in browser, 16:11 not designing in browser, and I really like that. 16:15 Cuz we are making these decisions actually in, in the browser for our actual website. 16:17 So the next page in this site that we designed was this article archive. 16:23 And you can see this has already been designed and coded. 16:29 So as much as it pained me, I just took a screenshot, 16:35 I didn't have to design anything, I didn't have to change anything about it. 16:38 Just putting that in there for scale and for reference with the rest of the page. 16:41 Our header, obviously has already been designed and coded. 16:46 I don't need to design that right now. 16:51 The only thing in this next deliverable that needed to be designed was this 16:53 filter, and then the tagging system and breadcrumbs that went along with it. 16:56 And, a lot of that was about the interaction and not 17:01 necessarily the design, so, this didn't take that long to actually design out. 17:05 But we wanted to bring that into code so 17:11 then we could see how those tags would come up, how the filter would expand and 17:13 collapse, how we would close some of those filter checkboxes. 17:17 And then we put it in front of the client again. 17:22 They, once they were actually interacting with it. 17:25 They said, we want that filter to remain sticky as they scroll down that page, 17:27 so again that is something that we caught on really early on that is 17:32 a design iteration and not a bug. 17:35 So taking a look at the code we have that same stories, 17:37 same code, same components that make it up. 17:42 And then here's the new piece that we made, the filter. 17:46 And again, fully interactive. 17:49 We can dig a little deeper, the descriptions. 17:51 And then all the code is right there in the project hub. 17:54 So we are just making sure that we document and build out our code to be this 17:57 extensible system, that Twitter Bootstrap idea that we're making for the client. 18:03 [SOUND] And as we continue to work through this it's gonna 18:07 take a little bit of trial and error between your team. 18:13 I know when we started doing this. 18:18 As you can see the design part of it ends 18:21 up being a lot faster the more that we're building on it. 18:23 The more we're just kind of piece designing what needs to be filled in. 18:27 When the designer ends up designing like three pages and 18:32 then the developer has to code out three pages obviously that's gonna 18:35 take a little bit more time than that took. 18:38 Which, it's totally okay to be up front with the client and 18:40 say hey, we did these pages as a static mockup and these pages coded. 18:43 We already sort of laid out that groundwork way in the beginning when we 18:50 told them what to expect, that we're gonna deliver coded design you're gonna 18:54 see some static mockups, that, the, faux in browser, you're gonna see some of this. 18:59 So just being really open and letting them know what to expect is totally okay. 19:04 And like I said, it'll take a little bit of teamwork to figure out that timing. 19:10 But it's also important to always be in communication with your team. 19:13 If you're not already using Slack, I highly recommend using Slack. 19:19 Slack has been awesome and a really important component of working this way. 19:24 You have the different channels, which we have one for our team. 19:30 But also you can do things like type to Github, so 19:34 that when every time someone pushes it'll alert everyone in that channel. 19:36 Whose working on that project like, oh this is what's going on. 19:40 So, that's really cool. 19:43 It's really great to just get quick feedback toss in a screenshot of 19:44 something and then have people weigh in on it on the team. 19:49 But then it's also really great for having direct messages where, 19:53 when I'm working really closely in that iterative fluid process with a developer, 19:56 they can send me a link and say, okay yeah, here's where I took 20:00 that first stab at styling the mobile comp for that article page. 20:03 And then I can click on it and 20:09 then say oh, what if we changed this little piece to be this. 20:10 And I quickly mockup in Photoshop and send a screenshot back. 20:14 You can see how it really works well to have that quick iteration. 20:17 And I'm not exactly sure why it's so 20:21 much better than it's predecessors but it like, really, really is. 20:23 It's way better than HipChat, any of those things. 20:25 So you should look into Slack if you're not already on it. 20:29 So now we continue to design. 20:33 And continue to work and build on our pages and 20:35 now we've laid a really, really, really solid foundation for development. 20:39 We have our CSS really finessed out. 20:43 We have a lot of our layouts working. 20:46 We have this nice style guide. 20:47 We have our modules. 20:50 We have all of these pieces that then will make development, 20:51 hopefully much less painless. 20:55 We've hopefully caught a lot of those design iterations early on and our, 20:57 hopefully our bug ticket count at the end will be much smaller. 21:02 So now we're just gonna just move into development and 21:07 continue to build out the rest of the site. 21:11 So back to Bill Bernbach, he said, let us prove to the world that good taste, 21:16 good art, and good writing can be good selling. 21:20 But I think if he were making websites today, 21:24 he'd say that it's about good design, good code, and good content. 21:26 When we don't bring all perspectives into the equation we get dull results. 21:31 These really boring, 21:36 uninspired layouts of a large image with some boring type below it. 21:37 And when we don't work together we also have giant, 21:41 boring images with some boring type below it. 21:45 So we want to have the whole team bringing all their 21:50 perspectives together to build the best solutions for our clients. 21:54 Thank you. [APPLAUSE] 21:59
You need to sign up for Treehouse in order to download course files.Sign up