 Good afternoon, everybody. Thanks for coming to our session. This is designer to developer, how to go from paper to style guide and still remain friends. Of course, this assumes that the designer and developer are friends to begin with. But the ultimate goal is to talk about how designers and developers can work together to make a quality product. And maybe become friends later, who knows. But all right, my name's Chris Doherty. I'm a senior front-end developer at Media Current Designer. I've been working with Drupal since Drupal 5. I don't know what year that was. And with me today is my colleague and friend. We're friends right now. We'll see at the end of this. My name's Carrie Fisher. I am the accessibility lead and also a senior front-end developer at Media Current. I've been working with Drupal since I remember four, but I mostly worked with five. So I think that was back in 2005-ish or so. We both work for Media Current. We are a mainly distributed team of over 70 people. We do everything from strategy to design to development and support. We have a headquarters out of Atlanta, but a lot of us work remotely. So today we're gonna talk about how designers and developers can work together more effectively and efficiently. Some of these items may seem common sense, but when you're heavily focused on a project, you may lose focus on the big picture. So this is kind of a global reminder and talking about our workflow. Along those lines, we're gonna be very agnostic about the tools that we use. We have specific ones that we use at Media Current and that we prefer as designers and developers, but you can use whatever tool works best for you. So it all starts with good communication. How does your team work together? As Carrie pointed out, we're a distributed team, so we use things like Hangouts and Zoom and Slack, which you'll see. And before even beginning any kind of design, you just wanna set yourself up for success. So there's a few things that we recommend. One is project management tools. Two, setting up a place where you can share files. And three, nomenclature, which is very, very important. So in this particular presentation, we're gonna focus on our client, which in this case would be Media Current. MediaCurrent.com, the current site, which you see here is about three years old. It's a Drupal 7 site. We've been tasked to redesign it. I mean, not really, but it's just a presentation, guys. So the focus of this is gonna be on the homepage and they have some key things that they want us to look at, particularly when it comes to design and content. And so to begin, yeah. So like I said, we're agnostic. We tend to use JIRA for project management and I know you're all kind of rolling your eyes, like this is a project manager's task. This is not really concerning me other than I put my time in here. Well, I disagree. It is an excellent tool for sharing notes. If you're a designer and you're working in the discovery phase, you're working with the strategist, you're working with a writer, you're working with a client and the front-end dev may not be on the project. This is an excellent place to store detailed notes, feedback you get from the client, some of the early thinking, a lot of the strategy thinking. So I highly recommend, if you don't have a project manager who uses something like this, just do yourself a favor and set it up. In addition, file sharing. So in fairness to Carrie, she never said any of this. This is solely my creation. I'm not something of a failed screenwriter, but these are just my thoughts and my notes. So don't do this, okay? Don't have the, Carrie's the front-end developer. She's starting to work on the site. She's coming to me asking where things are. Now, have a place where you're gonna set up all your files. Have a file structure that makes sense. So as you can see, we have wireframes, we have design. Maybe there's subfolders within each of those for the different pages. But just have a place where you're gonna store everything, have it make sense, logical. And then reach out to the front-end developer first. Spend some time. Even if it's, let's say it's an hour, who cares? I mean, you're gonna save that time later on down the road. She might be going crazy. Did he share this homepage sketch with me? And she might be looking around her notes and whatever. Do everyone a favor and set this up right. And in addition, nomenclature. Again, this is like a pet peeve of mine. Something that I, well, not a pet peeve. It's something I need to work on. Is when you're in those early discussions, discovery meetings with a client, and you're talking about requirements, you're talking about strategy, start to come up with names for things. And it'll serve you well down the road. Because you start to apply names, you talk about things in a coherent fashion. You're consistent. It'll serve you well once you get from discovery into doing wireframes, design, and ultimately into the style guide. And everybody's on the same page. I mean, you can get a real mess. The client's talking about something and they're using one set of language. The designer's using a separate thing. Fed is using something else. So you wanna avoid all that. Okay, so we have the file structure in place. We have the client nomenclature and we have some ticketing system set up. So now we're moving on to the second phase, which is the initial design. To make sure that our workflow is effective, we wanna make sure that we communicate early and often. We wanna share the wireframes. We wanna wanna share ideas, a brainstorm as a team, and then eventually share those with the client and give them an idea of the direction that we're thinking. You don't wanna wait and spring like final mockups on them. You want to make sure that they're involved in the process from the beginning. Also, when you're designing, you wanna keep in mind the assets that you may need. For instance, if you're creating a homepage and you have a hero section, you already know that you're gonna need a hero image, right? You're gonna need one for tablet, you're gonna need one for mobile and desktop. Maybe you need to consider retina displays or other options that the client may want specifically. So you just kinda keep that in the back of your mind. But if you write it down as you're designing, you won't forget it later. So it's good to keep in mind. And also, if you see any potential technical issues when you're designing, keeping that in mind and maybe sharing that early with the developer or at least putting it in the ticket. So an example of that will show in a few minutes, but like a hover state, for instance, is difficult to convey in a flat design. But it's something that you've already thought about. You've thought about where the link you want it to be. You wanna change on this hover state or colors or whatnot. You may have layers, but then the person that's getting this file may not understand exactly what you want. So again, going back to our demo for Mediacurrent.com, the redesign of the homepage, we kinda start out as designers here as sketching old school pen and paper, right? Maybe pencil, even if we're not feeling so lucky. And then we move on to a drafting program like Photoshop or InDesign or whatever your favorite drafting program tool is. For wires, we've also used like UX pen and there's some other ones out there that are a little bit more simple. And then we move on to getting the feedback like we talked about. So again, we have a little scenario here where I'm asking Chris about a specific part of the design and he says, oh, this part, this is what it's named. So then that way we're establishing a vocabulary that's the same and then that we're on the same page. So in the future I'm gonna ask him for the resources grid instead of that thingy with like the images and blocks. So that way we have a common language. So here in this little gif, we're showing two lists. We're seeing it showing an asset list and a component list. Again, when we are designing, we're kinda taking mental notes but the mental notes aren't good enough. We wanna convey that information in a place and that shared resource place where everyone can access it at any time. Maybe your project manager, maybe your QA, maybe your development, they all need this information eventually and why not just create it from the beginning. And then finally, this is one of the ones that we're talking about for predicting issues, right? We already know in our mind and in our wires where we want our menu to be located on desktop. Maybe we haven't had time to make a tablet or a mobile version yet or maybe we haven't fully articulated exactly what happens when you click that hamburger button but that kind of information is stuff that you can add to the ticket and then just make sure it's clear. Like again, flat design, it may be difficult to know like what happens when I click that hamburger icon for instance. All right, so now we've got wireframes. We've got some continuity going here. We're on to design. We've shared some wireframes with the client. We've shared wireframes with the front-end developer so we can identify possible issues down the road. And we go into design. We've got the mock-ups, we get sign off. And so next step is to translate design into code. So what do you need to provide the front-end dev as a designer? So a few things, one, some specifications. Some of you've done this probably, I'm sure. Assignments when it comes to asset creation. Just plan that out because there's a lot of gray area, right? I mean, who does what? And communicate further about component features when you get to that higher fidelity design. So yeah, design specifications. So yeah, Slack is a little hard to read sometimes. Maybe Carrie's getting a little annoyed with me because she's like, where is this now? She's looking for the font size and I haven't provided it to her. Just be proactive, do the right thing. I know this stuff can be tedious, but just do your best, get all this stuff specced out as much as you can. And it's also important to be flexible because this might be specced out for desktop. You're not gonna spec it out for every break point. So some of those measurements might be off along the way as you adjust your responsive design. So it's important to keep that in mind as you go along in the process. And then component behaviors. So again, there are gaps in your understanding. When you look at a PDF that has a component like this one and it's got these hover states and maybe it's clear like to you, like how it's gonna work. Like you have in your mind, okay, I know what this transition is gonna look like. I know how long I want that fade into happen. I want that entire block where it says developer. I want that whole thing to be a link. But how is the front end developer gonna know unless you sit down and have a communication? So it's important to set aside some time, do it right, and talk it through. Because you don't want, last thing you want is to come back and your vision is slightly off from what the front end developer thought. And in addition to the continuation of that, things like, we're still in design phase, but things like these asset creations. Like I said, it's kind of a blurred line, right? The front end dev could be like, okay, yeah, I want an SVG, I'll make it. Or you could be like, I'll go ahead and make that ping. Just settle it out once you've got the design working. You've got the design files open. Just pick up the phone or Slack or Hangout, whatever. And have a conversation. Like how do you really want to do this? Were you thinking SVG? I can cut it up for you if that's what you need, if you want a ping, whatever. But just have a plan for how you're gonna approach these kinds of issues. Cool. All right, so we have all the assets ready. We have our ticketing system. We have our mocks, we have the wires. Now we get to the fun part, at least for me, because I'm a developer mostly. We have talked about components a little bit in theory, and now we're just gonna see them in action. But don't worry, I know this is like UX track and I won't freak you out too much with technical details. But what we're doing is we're showing, using style guides really as a design tool, right? So much like you build a house out of Legos where you build the foundation and the walls and you've got your windows and your roof, we're doing the same thing with components and pieces, pieces of the website. We're building this complete website. So the designer takes a lot of hard work, like takes a lot of time making this complete page and then the front-end developer takes it apart basically into the little pieces. We kind of do reverse engineering of the design. But by doing that, we get these pieces that we can reuse. We get these flexible components that the client can look at and can study and the client can take it to their shareholders and they can actually see it in real time and real browsers, they can avoid having to do some of that translating that we're talking about where design and functionality kind of overlap. Like how do you convey all that in a flat design? It's difficult, but with a style guide, it's very easy because it's code, it's real and it's live. So clients really like them. So going back to our scenario where we're redesigningmediacurrent.com, this is just a quick still shot of the style guide that's kind of what you get when you first get there. So you get a menu on the side with a lot of information. And these gifts are gonna kind of show you breaking these down into the components. So again, components are like pieces. So again, we deconstructed the complete final design that the designer took a long time building and break it into these little more usable pieces. So one of the main things, again, what we're talking about component functionality, we can see that here in this hero highlight, we're using, we're seeing the different break points. So we're gonna see mobile. Maybe in this example, he can see it and say, oh, I need to adjust the font size on that mobile device. It needs to be a lot smaller, for instance. So we can go back and forth on that a little bit. And again, we have the ability to show the style guide to the client. So this is like a URL, this is like a website, right? Where they can go, they can take all their time to really look at it and then say, this is not exactly what I wanted this component to look like. This is not exactly what I thought this piece of the website was gonna actually do. And so it gives them a way to really convey and look at and get into the nitty gritty of the code if they want to and say, hey, in IE, this doesn't work or something. So this is a way, and I should mention that all of this happens before any development happens at all. So in the past, like when we were talking about how we've been working with Drupal for a long time, right? We had to wait for the backend developers to create their whole website, and then we would come in as themeers. And usually by that time, you're out of budget, you're out of time, and you're really like racing the clock. All of this is happening before the backend developers even get to the site. And so it gives you a jumpstart on design and gives you a jumpstart on QA. If you're concerned about things like accessibility, it also gives you a jumpstart on that as well. It's a really awesome tool for design. All right, so Kerry just showed you the style guide, how it's a great tool to demonstrate the design functionality of the client. It's also a great design tool, and as a designer, I'm pretty geeked about it, you can do a lot with it. Kind of blows my mind actually that this is where we are. But anyways, so a few things. It's a great tool for reviewing the design as a designer. And a lot of things like Kerry said already about how you can preview what things are gonna look like before they're in Drupal. Testing, I don't know what your particular QA process is. A lot of times the designer is on the forefront of that, so it's an awesome tool for that. And then it's great, great, great for adding new features and functionality to the site. It's a great way to identify how we can build new features within the theme. So as I've said before, there's always gonna be gaps in your design. Things you don't anticipate, you're not thinking, oh, that's gonna break at 730 pixels, so it's good to see these things up close. And then, you know, this is cool. You can, the designer and the front end dev can kind of work together to work around those problems. Kind of, you can just set up a screen share, go into a hangout, whatever. And you can work through these problems in real time, fix it, get it looking right, and you're on your way. And then, again, QA, testing responsive design. This is great. I mean, you can look at it in different browsers, different devices, all before it's built in Drupal. Get all those problems hammered out before anyone sees it, really. And finally, another conversation here. Now, we've been through this process. We're kind of sympatic, though, at this point. So, you know, we're doing pretty good, but we're at the point now where the client comes to us. And this might be further down the road. It could be like a month later. It could be two months later. Oh, we want to add this to the home page. And so, I've kind of sketched something out. I'm like, Carrie, do we have the pieces to build this? And she can look at it and say, OK, well, we do. We have the titles. We've got the buttons. We might need to create a date or something like that, or we might need to create one of those images, whatever we decide to call it. And it really eases the development process down the road, because you can just pull things together. Like Carrie said, the LEGO brick analogy is great. All right, just to recap, the first step we're going to do is for the designer, for going from paper to style guide, is that we're going to build a foundation. So it's going to be based on communication, which we do early and often, both within the internal team and then with the client. Then we move on to that initial design phase when we're talking about wires. We're going to be sharing the assets within the team and making sure that we list out all the things that we need for each component. Make sure that we're on the same page with no enclature. And then we're going to do a design handoff. Typically, it's different in developer. You may be both the designer and the front end developer, so I guess you talked to yourself in that sense. But you're establishing your rules and you're being flexible about communicating the design. So you can say, this is my idea for this design on these different breakpoints. But you, as a developer, if you run into issues or questions, let's reconvene and talk about it. So the fourth one was using style guides as a design tool. It helps break your design into manageable pieces that are flexible, reasonable, and client-friendly. And then finally, be flexible. So anticipate design adjustments or just new functionality and new pieces to your website. Changes happen as the site grows. So at this point, I think we have a few minutes for questions if anyone has it. But otherwise, we're here for a while. Oh, and I should also preface that by saying if you want to see more of the nitty-gritty of the code behind the style guide, we have a lot of great examples we can give you. I'm personally interested in. I have to plug my accessibility style guide. It's a 11y-style-guide. It's on GitHub. And it's a really great example, too. The question is essentially about the style guide. When you create that, do you generate that out of something or is it just manually put together? Or do you use? For instance, if you created that for that specific site or did you use a tool that can gather that out of existing site and then redo the changes? I don't know. Are you talking about from client to client? Yeah. What kind of tools do you use to create these style guides? There's a lot of style guide tools out there. KSS Node and Pattern Lab are kind of the two big ones, but there are all kinds of ones that are out there. But we tend to use KSS Node for our style guides. And what we do is we have a theme generator also on GitHub that, again, we can give you these links if you're more interested. But we run the style guide, the theme generator, and it makes us kind of a bare-bones style guide. And then we have worked with enough clients and built enough components at this point that, for instance, like a logo, every site's going to have a logo. Most, I guess, 99% of the sites are going to have logos. So we've already built that component. And so the cool thing about style guides is you can take that markup, and you can bring it into the style guide as a new component, and then you can just adjust it to fit your client. So you don't have to rebuild the logo over and over and over again. You build it once, and then you just re-theme it based on your client needs. So maybe your logo is a ping, or an SVG, and then you just swap out the image for the next client. Or maybe you have red lettering for one client and purple lettering for the other client. So you know when I'm in the CSS, you adjust it. The file structure is such, in the KSS node, that you have a component. And then you've got your SAS folder, your SAS file. And then you've got your twig markup in this case, because this is Drupal 8. So how about getting the client to understand this process and envision the page that they are getting when you cut from wireframes to the style guides and to this kind of almost componentized design and browser? Sure, I can take that. I think, yeah, that is a really good question, by the way. And I think if you do the design process the correct way, and that's why nomenclature comes into play. You familiarize them with the notion of components. Even at the early stage of wireframes, where they're thinking, OK, this is the hero. I know what that is. And that's a basic example. But if we're talking about the highlights block, and then they've seen the wireframes a million times at this point, they come back. They see the style of that. Oh, yeah, the highlights block, of course. It really comes down to doing the design and presenting the design the right way. Terry wants to say something. Yeah, no, I just want to add one more. We deconstructed the design into all the pieces and into all the components. But then you can create a page like this where you put all the pieces back together. And component-driven development is awesome, because let's say they want to shift something around. They would say, oh, no, I want that thing at the bottom. I actually want it back at the top. And it's a matter of copying and pasting one line of code. Because basically what you're seeing here is the logo. You're seeing a menu. You're seeing the hero. And then you're seeing the hero highlight blocks. They're all together as one page. So it's a little bit of a novel concept. But you can reshuffle your pieces however you want and then make the client happy. How long should it take to move from strategy, foundation, wireframes, mock-ups, to development, finally to show a preview to the boss or the client? Consider it to then we have to redo the corrections. Did you ask how long it takes? Yes. Well, it really can vary pretty significantly. For example, for one section with image, title, content, and just that. Jim, do you have some thoughts on that? From what? From design to development. Yeah, it really depends. I mean, for instance, for this demo, we actually produced this. We would approach it from a real client. And we were just doing one page. And so it took us a couple of weeks, so a few days for design, some talking, some communication. And then once he had that and gave me the assets, I could build it pretty fast. Well, I mean, for one page in this demo situation. But a client can go up. There's a lot of back and forth. So it depends on how picky your client is, too. There was no actual client review here. So that I can add significantly. If we had a real client review, probably it would have taken a couple of months, but yeah. Any more questions? Are you guys good? Are we're good? Thank you, guys. Thanks, everyone.