Making It as a Designer: How to Work With Developers

1. Introduction: Hi, I'm Vincent. I'm a designer and developer. As a designer, I understand the frustration that comes up on some web design projects, where maybe you get your design back from your developer and it looks bad. But as a developer, I can understand the frustration of uncommunicated expectations or impossible to meet deadlines. The good news is, these are both solvable problems. By communicating more effectively, we can collaborate more effectively. We become collaborators and not adversaries, and which is what it sometimes feels like. This class is for you if you're a designer who's taking on your first couple of web design projects and you're curious about how the modern process works. Or if you're a designer who's never worked with a developer and you don't know where to start, maybe you're a little afraid to ask. But it's also for you if you're a web designer, you are dissatisfied with how your projects have gone in the past. For our class project, we'll be taking an existing design and turning it into a design system by breaking it down into components. In the process, you'll learn some new ways of thinking about design, and you'll learn some new ways to communicate with your developer as well. You'll ultimately have some tools to collaborate better, and it'll feel a bit less like you're speaking two different languages. I'm excited to get started. Let's go. 2. What's Wrong with the Way We Do Things Now? : What's wrong with the way we do things now? If you've been in this industry for a while, you know, designer and developer relationships can deteriorate over time. For instance, tell me if you've ever felt this way. Maybe you send your designer, your design to your developer, and you get it back and it's like completely wrong and you're like my design was great until the developer got to it. Or maybe they say that they could build it in three weeks and it's been six, like what's the deal? Why can't they get the positioning right? Is this a problem with all developers, like all these problems keep coming up. What keeps, why can't they just blank? These are all questions of communication. As an example, think of your favorite restaurant. Most restaurants are divided into the front of the house and the back of the house, the front of the house is the waitstaff, host, hostess, etc. Back of the house is kitchen staff. Now at a bad restaurant. These two parts of the house don't communicate, and as a result you get surly waitstaff. You don't want to send your burger back because it might come back with something extra in it, but in a good restaurant at your favorite restaurant, those two halves at the house communicate freely. They might even know something about one another's jobs like maybe the kitchen staff sometimes brings a meal out to a customer, or the waitstaff assembles a salad. Even though they seems like they should be speaking two different languages, they communicate and collaborate effectively. How can we do more of that in the design and development industry? Well, first let's take a look at how it breaks down. We'll look at that in the next lesson. 3. What Does the Typical Web Design Process Look Like Now? : What does the typical web design process look like? Okay. Story time. Let's say you're a freelance designer, if you're not already, and you've just landed a new client, let's take it from there. What does that look like? I should note that this applies as accurately to in-house teams or agencies. It also applies to app development. I just talk about web development because that's what I know, but this is probably a similar process throughout. It's been weeks of meetings. You've agreed on the direction. You're excited to start, the client's excited to start, and you're like, let's get going. You work alone for a while. You design your homepage, your internal pages, etc. You send them to the client. The client finally approves. It's been four months of revisions and you're finally there. It's almost time for launch and you have a six month deadline on this project, so you've got two months remaining. You're almost there. You send it to the developer and the developer says, "I can't do this in two months." Even worse, they tell you, "I can't do this in four months. I need at least another six months to build this as it's designed." That's terrible news. You can't come back to the client with that. What do you do? You say, "All right, developer, just try your best and we'll revisit in a couple of weeks." They begin, and they send you their prototypes, and guess what? It's a dumpster on fire. There's headlines in the wrong place, things in the wrong color, nothing works properly. It's all buggy. It's like, what did they do this whole time? Do they not even care? What gives? There's one month left in the process and the client suddenly realizes they forgot the super important page. It needs to be there for a launch. You have furiously designed a new page, and you send that to your developer even though it's probably a little rough around the edges. The developer furiously develops it and it comes back, and again, it's all buggy, it's all wrong. What is their deal? Finally, it's the week of launch, the sites buggy, nobody's happy, it's been stressed all-nighters, the client is not happy, and the site is late. This is an exaggerated scenario, but maybe it sounds a little familiar to you. Maybe you've lived through something similar. Where does this process go wrong? Well, I would say, right about here, at the very beginning. What could we have done differently at the beginning to start solving these problems? 4. Involve Developers Early: I hope you haven't experienced a project like the one we just talked through in the last lesson. But it's likely that it might have sounded a little familiar. Really why shouldn't it? I mean, that's a pretty common process. You design, you send to the developer, they develop it and you keep kicking it back to them until they get it right and eventually they launch it. What's wrong with that? Well, the trouble is good design takes a long time, it takes a while. By wedging development in the last possible minute like that, the developers end up rushing and doing poor quality shoddy work. Another problem with it is that the developers lack contexts, like why am I building what I'm building? When was this decision made and why? In the example project, the designer went away for months. The trouble with that is the longer you spend designing without any input from the developer, the further your design tends to depart from reality. Because it may turn out months later you've designed something that's not even possible to implement in the time that you have allotted for the project. Maybe you're thinking, what about design by committee? Am I at risk of ruining my designs by letting a developer into the process. The design will change. But that's not a bad thing. For instance, a developer can help you understand what's even possible to implement in the time and budget allotted. They can find other problems too, like accessibility problems in a design. Maybe your design is beautiful but it doesn't account for low vision users and a developer can help spot that. They might even know some new technology or techniques that can improve the design. These are all changes, but they're all good changes. It's important that they be discovered before you spend four to six months just making it design pixel perfect. How do we involve developers early? Let's talk about that in the next lesson. 5. How Do I Get Developers Involved Early? : How do I get developers involved, early? What does that mean? When should I involve them? Well, when you have a new project, what's the first thing you do? Do you have a kickoff meeting? Do you have a meeting with the client, to just figure out exactly what they need. Any kind of meeting? Really, anytime very early in the process, is a good time to get developers involved. The sooner the better. Many teams involved developers, here, when they really should be involved, here, very early on. That means no big design reveals, especially not to the developer. For example, for many people, the design process, starts with a meeting like this, where maybe the deliverable is a flowchart. You're trying to map out, how the customer of the website, gets from point A to point B. That's where the developer should be involved. Many design agencies, think that this, looks like this, but it should actually look like this, where anybody who is touching the project is included there early on, in the process. You get him sketching on a whiteboard if that's what it takes. Then throughout the process, keep them involved. Ask lots of questions. Resist the temptation to go, and design by yourself for months and months. If you're not sure what they need, or if you're not sure what's technically possible, ask even if it means you're sending them unfinished designs, or rough assets like wire-frames. That's okay. Any information can help us. Now, ultimately, your processes is up to you. I'm not going to tell you how to work, but, if you can involve your developers early, do it. The result is, the developer is involved in the success of the project. The relationship, is more collaborative, more interactive, less adversarial, and ultimately it leads to happier users, and happier clients, which is important. 6. Improve the Design Handoff Process: The second thing we can do to improve our relationships with our developers and our collaborations is to improve our design hand-off process. Now, the design hand-off is the process that you use to get your designs to your developers so that they can start doing their job, and it's a hard problem. In fact, you'll remember that's where the process from the perspective of the designer in our imaginary project, that's where it seemed to go wrong. The developer disagreed about the scope. They couldn't get it done in time and when they got it done it was buggy and bad. It felt like they just didn't care. But how can our design process make this better? Well, I think to understand this it's helpful to think about what a developer actually needs from a design. What goes through their mind when they get a design from a designer and they start developing? To give you a clear idea of that, let's go through a design file that I've just received. Let's say I'm the developer in that imaginary terrible project and see my thought process there. When I receive a design, one of the first things I start to build out is what I think of as the frame of the site. We're talking about anything that appears on every page like your header, your footer down here, and anything else that might show up everywhere on the site. Then I'll move into other major sections like this hero image here. Any common marketing call-outs, things like that, and I'll get more and more granular over time to the point that I'm building any individual little modules like this. My goal ultimately is to, as faithfully as I can, recreate this design but do it in code. Sometimes the design file, as you'll see, makes that task difficult or even in some cases, impossible. In a more collaborative process I would have been there for all the design meetings that led up to this final design here that I just got. But let's say for the sake of argument that I have no context, I just received this design from the designer with the expectation that in a couple of weeks they have a working website. Let's talk about some of the things about this design that make it difficult and in turn, you'll learn some of the things that your developers will need from you when they get a design file [inaudible] you. Right off the that, one of the first things that I look at is the layering structure. You can see in our layers panel, there are some layer names that are helpful like I have a logo here. Also there, every single layer group is open, which is really aggravating to work with. But we have some layer names here but the major layers, the groups, are all number one, number two. You have random looking, let me find an example, shapes here. I don't know what shape two, shape four, shape three is. What the heck is all that? The layers are very disorganized which makes this a really slow, difficult file for me to work with just right off the [inaudible]. I have to manually go in and select things and tinker around until I get the right part. The second thing I notice here is that in the navigation there. 7. Introducing Design Systems: You may be used to thinking of your web design as pages and layouts. Maybe that's what you're used to handing off to your developer, you're used to sending them a big PSD full of whole page designs. But if you think about it, you're really not designing a whole page, are you?. You're designing a system, a system by which other people create pages. Maybe your developer creates these pages. It's a system that's made up of modular and reusable components. We're talking about headlines and videos and sliders and anything else that's meant to be reused in the website and the design. Think in terms of LEGO, not layout. So you still have to do your full page layouts, but then once there, once you're happy with them, maybe you start breaking things out into small, reusable components. You can also think in terms of guidelines for their use. For instance, how many pixels go between this module and this module, this component and this component. Can this component ever appear next to this other component, things like that. Now, this isn't meant to be a design systems class. There are way better classes for that, some of which we have here on Skillshare. So I'll link to a couple of them. It's really just to get you thinking about breaking your designs down and we can talk about the "why" in the next video. 8. But, But, But... : In thinking about design systems, you may have some objections in mind. Maybe you're thinking, what about layout and composition? If I break up my design into individual parts and pieces that a developer can put together any which way, isn't that going to ruin my design? Well, first of all, we think this way anyway when we're developing. When I get a new project, one of the first things I do is start breaking things up into little reusable chunks so that I can build things later on down the road. It works like that anyway, whether or not that the design accounts for it. But second of all, you can still design in the browser. Think of the browser as another design tool. Just because design is not happening in Photoshop, or Sketch, or whatever your tool is, does not mean it's not happening. You can still design direct. You can still tell us developers how to put things together so that it looks great. You may also be thinking, won't components limit me, how creative and beautiful my designs can be? Well, no. These components, remember, can be put together. Snapped together like Lego bricks. Check out this elephant. It's a giant elephant made out of tiny Lego pieces. Your components don't limit you. Also, it's important to note that your components themselves can be more elaborate. You're not limited in terms of design. You may also be thinking, but this doesn't make any sense for my clients. Like there are small businesses and they just don't have the budget for something like this. I would argue that the design system does not have to be super-large, and detailed, and elaborate. In fact, even a simple one can deliver lots of value. For instance, if you have broken up your design into individual pieces, you can deliver a new page quickly. That would have helped a lot in our example project, where the client had that last minute request for a page, and the developer couldn't deliver it on time. If he could have just reached into his bin of little bits and pieces to put it together, the designer wouldn't have even had to jump into the design tool. Design systems make for smooth hand-off to developers. They don't have to guess as much. Once the system is designed, you can put together new features and new pages without too much hassle. It's ultimately less frustration for everybody involved in the process. 9. Design System Example: Let's revisit that PSD from earlier. The one that the designer centered the developer and we walked through it and all the questions they had. Remember all those questions. Let's look at through what that process might look like if the designer had designed with components in mind. What does it look like to have a design file that takes components and design systems into consideration as part of the design process Let's look at this file. This is a UI kit from a designer named Meagan fishers, she's a web designer. This is in Adobe XD. If you're not familiar, it's Adobe's UI design program. It's excellent if you're not familiar with it, go ahead and download it. It's free, it's really good. They have lots of sample kits. They call them UI kits, but it's kind of the same thing as a design system. Right here under file, Get UI Kits. You can get the one I'm working with here under more UI kits. Let's look at this and see what makes this different from the PSD. At first glance, that seems very similar. There's this marketing section here. More marketing sections. Basic site elements like your nerve, your logo, and eventually your footer. I have a good starting point here. But what makes this different from the PSD? Right off the bat, if we zoom out a little bit, you can see how she has these cardboard setup. You've got the main the homepage marketing with the all the marketing information. Then she takes you with art boards through a sign-up flow. You can see all the steps of the sign-up process for this imaginary application that she's designed. Then you have your dashboard screens; Dashboard 1, Dashboard 2, Dashboard 3, etc all the way down to the booking service. All of these things already give me a broader context of how all of these things fit together. You'll notice that there's no Hover states or anything like that. Where's the design system, where the components? If we zoom out a little bit further, you can see we've got several more art boards here to consider. Now, let's zoom into this one here. She calls it a UI Kit here, but it's a design system. You can use those words interchangeably. Now already, we have examples of baseline typographical styles. We've got our header is 1-4. It looks like we've got some body text and form labels and other minor elements. If you zoom in a little further, you can see she's got font styles and font names and exactly where they're used. Headline and body texts. These are descriptive things that tell us when to use what. We've also got color swatches, each with the hex number of the color. The next art board is called Calls to Action & Icons. Already you get an idea of what each of these elements is to be used for. She's kind of using the art board names, as you might see, layer names in Photoshop. They're a little more useful because inside of this art board, you can see based on these headlines, what the intent of each of these is. This is a call to action on dark or marketing call to action. We can go back to our marketing art board here. You can see we've got, marketing call to action on dark and then at marketing call to action on light. They correspond perfectly with the one she's designed. She's also got Hover states. You can see the Hover state illustrated with the little mouse icon. Then you see a product Primary CTA. What's product primary? Let's zoom back out. That corresponds to the actual product that the user will be using. You can see the matching button right here, Book a service. That already gives me plenty of information just based on how she's named things about which situations call for the use of which of these buttons. Also she's included Hover states, which is great. We have the alternate styles on light and then he or she's included a disabled style. That's a state we didn't talk about when we were looking at the PSD earlier. Disabled styles happen if you don't want the user to be able to click a button in a certain circumstance. Maybe they've entered invalid information and you don't want them to move forward until they've corrected it. The state of disabled needs a design. We've also got a secondary CTA style here with the small icon to the left. You see that repeated here. Here we have icons, which they're all collected right here in one place, which is awesome. I can't tell you how many design files I've gotten where the assets were all scattered throughout the designers hard drive. I had to go chase them down and figure out exactly what assets I needed. Also not just what I needed, but the crops I needed. Sometimes the asset wasn't prepared in the PSD in a way that I could use on the website. These are all ready to go, ready to export right here. That we're talking about assets, let's zoom out and look at this. She's got all of her images here. All ready cropped and ready to go. These are all the side, it looks like all the sidebar images. I can see exactly where each one is used and when. It's already just simple for me to export and drop it into my code. It makes my job much, much easier. If we look at the next art board, we have form fields. It looks like every major form element is accounted for it. We've got our text inputs here. If we zoom in, you can see we've got placed a sample placeholder text. We've got the active state where the placeholder text disappears. We have an active with the user having put in text and then we've got an Error state, which is awesome. It's great to have all of this right here ready for me to start turning this into code. She's also designed some custom toggles and multi-select elements. These are more specialized form elements that you'll see. If you click one the other turns off and if you click the other, the previous one turns off. We've got all of our Hover states, all of our active states present and accounted for. Then moving on, we've got drop-downs. What does it look like when the drop-down is closed? What does it look like when it's open? What does it look like when one of the elements of the drop-down is is hovered over. Then what does the selected drop-down look like? That's another state we didn't talk about once the element is in its final state. What does that look like? I have some more custom select here with some images and some optional text here Then we have checkboxes, which again we have an Error state text areas. That's one that often goes unstyled. These little service components that describe a service and maybe these are different states. It looks she forgot to update the label here, but that's okay. I can generally get an idea of what her intent is here from the design and from seeing it both out of context. Like what does it look like by itself? But also in the context of the finished design. The next thing we can look at is our sidebar elements. You may recall the sidebar being used. Here we've got not just one sidebar, but also a second sidebar that happens later on as the user goes deeper into the app. We have examples of what those look like, what each element looks like on Hover, and when you clicked it, same here, and then there's another little progress bar here that she's designed. Each state gets its own design so that there's no question about what does it look like. When these are started, what does it look like when they finished? It's all right there. We get all states with that sidebar filled out for us. Now we have marketing components again, based on the name of the art board. I can guess that this is only used on the marketing section of the website, so we have this call to action with the navigation at the top, another call to action and just more components. One thing to pay attention to here is how, if we go all the way back to the left, we start with something simple like typography, colors, buttons and their states. We get more and more complex gradually as we go to the right, and you can see that by the time we get to service components, we are talking about elements of the website that are pretty complicated, made up of smaller elements from previous steps. You can see an example of our service buttons here, a little map component here with all of our icons. These are all examples of components that have been extracted out and are repeatable. Then you can see them later on used in the actual application, in the context of the application where the user will go through to book a service for their pattern. Maybe this seems complicated and it's just a lot of work, and it is. But what are the advantages? Why would you do it this way? Well, first of all, there are very few questions while I'm working about where things go and what they do. So even if maybe something isn't accounted for, like a hover state of a certain element, based on all of this additional information, I can make a more accurate guess if I have to. It reduces back and forth significantly, and any gaps that this design file leaves in my knowledge, can be filled by communication. I can ask questions, but fewer of them, so it's less aggravating for you and it takes less time for both of us. The file seems to be missing mobile styles, but that's okay. Let's assume that I have been included here in the design process up to this point, and we mutually decided that the client doesn't need mobile styles. Maybe the client explicitly doesn't want mobile styles and because their customers don't use it. That's okay. But if it turned out that the designer had completely forgotten mobile and there's a scramble to get it done, there aren't that many things here that I can't figure out on my own. There are certain parts of it that I would definitely have questions about what they might look like on mobile. Like this is a pretty wide element. What does that look like? How does that break down? What does this look like on mobile? That might be tough for me to guess at. But for the most part, since we're working with components, I can basically figure out what this will look like on mobile and I can help the designer along and smooth out the process for them. All they need to do is provide me with basics and certain elements that just don't account for it. So what are some advantages of Adobe XD or something else like it, like Sketch over something like Photoshop? Well, if you've been working with Photoshop for a while and that's where you're comfortable, that's fine. But these tools offer some pretty significant advantages. For instance, when we're talking about components, let's look at an example. Let's say the client decides this color here, which we can see in use on the marketing site. That's right here, I think. Let's say they decide that's just too wide and we need to change it. Well, let's open the sidebar, because XD already has the concept of components built in, we can just change this once. Let's say that we want to narrow that call out and we want to make this more narrow as well. Now this is obviously an ugly change but since we change it once there, the change propagates to any other component that is based on which is more close to how things work when we're writing code. You change things once and it repeats everywhere else. Another example. Let's say the client says I just need all of these images to be round. Normally, in Photoshop you'd have to go off, okay, I've got to change all these individually and it takes forever, and then if the client wants it to change again, then you have to change them all again. It takes a while. But here you just change any one of them because they are all related, because they're all based off one another, they all change at the same time, which makes things much easier for you. Another interesting thing XD does for us is, let's say the client did decide they wanted mobile. Normally in Photoshop you would have to go in and just manually position all this stuff like you'd have to figure out this bird goes down here and then what order do these things break in? Because they're going to move in a specific order on the web. You have to figure all that out in your file and do it one by one, but XD allows us to, if you grab that handle, it knows that these are individual elements there, and you can see it breaks them down into their own columns. Then we have a mobile version of this module that require very little extra work on our part. You may remember when I was looking at the PSD that I had to pull out the little measuring tool, I out of habit used the screenshot tool on the Mac, and I use that to measure pixels between elements. But in XD and other tools like Sketch and another one called Figma, you can press the Alt key and it'll show you the distance to the edge of the art board of whatever your mouse is over. If you hold the Alt key, if you've got an element selected then you hold the Alt key and move the mouse over whatever the next element is you're measuring the distance from, you can see that it tells me exactly the pixel distance from the next element over. This is 32 pixels. This column is 32 pixels wide, and this gutter here is 34 pixels wide, which is really convenient for me. When I'm working, I don't have to go back and ask over and over. I don't have to open my measuring tool over and over. I just press Alt and I can see right there what the exact distance is. I'll go briefly into the prototyping capabilities of XD, and there are other tools out there that do this. But if I press the play button here, I get a preview of the application. You can actually link the art boards together in such a way that when you hit play, you get a prototype of the site and it's actually interactable. You can use this to create pretty detailed mark-ups including animations and things like that. So it's scrollable. I can interact with it in a way that I might interact with an actual website. See what happens when I click here. Yeah, it takes me to the next page in that flow. So you can do this by going to the prototype tab, and you can actually create links between art boards and also between elements of art boards, individual components on the art boards so that when you hit the play button, you can click on that thing and it takes you to the next screen, then we can link. If we wanted to go for a more complete one, we can link that to there and let's see what happens when I hit play and click that and it takes me to the next screen. So you get an idea here that this is really more purpose built for the web and for interfaces in a way that Photoshop just can't keep up with it. Just doesn't do most of the stuff. That makes your job easier as a designer, but also as a developer, it makes my job so much easier. There's so much less digging and so much less frustration with using these programs compared to something like Photoshop. For your class project, I would like you to design a system. So take an old design of yours or start fresh and break it down into components. Your design system should include a style guide for typography. So headings levels one through three, paragraph styles, list styles, both are ordered and unordered. Form elements like buttons and text inputs, and links. Include states too like Hover and onclick on the states for the buttons and links. Include some color swatches, some color guides so that the developer knows what to use. Include at least three examples of distinct components. That may seem like a lot, but we've got a checklist for you in the class resources, so you're not flying blind. When you're done, please share it. I would love to see what you come up with and if you have any questions, do not hesitate to ask. I'm sure either I or others in the skill share community can help you. 10. Design System Tips: Here are some tips for creating your first design systems. One of the first things you can do is avoid making arbitrary one off changes. So for instance, if you see that one headline and you really wish it was small caps, it would look so much better. It's important to ask yourself, is this style reusable? If I change this, should all the other headlines change? Also, how does it affect the elements around it? Will they have to change because if this one design change? I'm not saying don't make the thing small caps, just consider the whole system before you do it. Another thing you can do that will make your developer's life easier is be as detailed as possible. Include things like hex color values for your color scheme, pixel distances between elements, things like that. As an example, here's a screenshot of Polaris. It's Shopify's design system. You can see not only do they include the main brand colors, they also include various hues of the colors as well, all in hex. They include some detailed spacing information, but not just the space itself, how to choose spacing, their style guide teaches. If you haven't thought through details like these, your developer is going to have a ton of questions. It'll make things a little bit annoying for you, or worse than that, they will start designing themselves and we all know how that can end. They could also guess wrong and give the impression that they don't care about your design and they don't care if it looks bad. So be detailed. If you don't know what they need, then ask. Another thing you can do is just explore beyond photoshop. Photoshop is an old tool and it makes a lot of this of what we're talking about, very difficult and slow. It really wasn't built to design interfaces, but there are purpose built tools that were, for instance, one of the most popular is called sketch. It's used everywhere in this industry, but Adobe has a tool that's free called XD. It goes feature for feature with sketched really good. Figma is another one that's excellent. All the three tools are worth trying, worth giving your time if you have it. Here's an example of what it might look like an XD. This is again Meghan fishers design. You can see here what she includes in her XD file. Handoff tools are also super useful. There are another purpose-built tool that are just there for the designer developer handoff. XD has this feature built in, you can click share and you can share your design with your developer, but there's also a couple of other tools that are purpose built for this. The most popular is called Zeplin. It's awesome. If you upload really well structured design file, it actually can write code for your developer and get some of the annoying busy work tasks out of the way for them, which is awesome. Avocode is another one that does something similar. Ultimately, these design tools make collaboration better. They make it easier to design, they make it easier for us to build. The handoff tools will make your life and your developer's life easier. Again, it just leads to more collaborative, less adversarial relationships, which is great. So please give the new tools a try, and if you haven't already, I'm sure your developer will thank you for it. 11. Build Trust with Your Devs: The last and probably the biggest problem that that imaginary design process had was the adversarial relationship between the designer and the developer. You may remember the designer being like, Why can't they just get this right? This is a difficult problem to solve, but it's also pretty important. How do we start? One of the first things we designers can do is assume positive intent. I know how frustrating it can be to work so hard on a design, send it to the developer, and it comes back and it's all junkie and messed up. Much of that can be helped by the things that we talked about earlier, the collaborative exercises and designing and system. But still invariably, there will be inconsistencies, there will be bugs, there's just no way around it. Keep a cool head, avoid blaming. There's anything that could have caused the design to come back in an unexpected way. Not the least of which is sometimes as a developer, it's all I can do to get the thing working. Of course, some of the design is going to mess up. Of course things are going to slip through the cracks. The point is, nobody wants to make ugly stuff. It's a tough and often stressful job. Assume positive intent and be patient. If the developer has questions, answer readily and if you have questions, ask please. Another thing you can do is relinquish control. I have a secret for you. It's something that not all designers want to hear, but your design is finished in the browser. It's not finished in Photoshop, it's not finished in sketch. We developers are making design decisions all the time. It can't be helped. There's just always something that the design doesn't account for and we have to make a decision. You can think of it this way. If you were to hire an architect and a builder to build your house, no matter how detailed that architect was in his designs, the builders going to have to change the design even if it's only a little bit, they do so to account for whether or unexpected terrain or whatever, just it's impossible for the architect to account for everything, and that's okay. Another thing to keep in mind is that devices have limitations. You can look at websites on watches and refrigerators now, narrow screens, widescreen, slow computers, fast and slow connections, fast connections. There are endless number of variables that can affect the final product, and the developer often has to make design decisions to accommodate those and that's really a good thing, because those are design decisions that you don't have to make. If they make the wrong decision, that's okay. It's just time to iterate on it. Make it better. Ask lots of questions. If you see something that's weird or if you're not sure where the thing is going to be used. If you're not sure if something you're designing as possible, ask questions early. But by working collaboratively and iteratively like this, we can make things that work for most people most of the time. I'm sorry to say it. But it's not going look great for 100 percent of the people, one hundred percent of the time, so you have to relinquish a little bit of that control. The third thing you can do is learn a little bit about what we developers do. I'm not going to tell you to learn to code, it's your life. You do what you want. But I will say, it's pretty helpful. It can make things easier. It'll help you make more informed design decisions. For instance, and you'll no longer feel like you and your developer speaking two different languages. I'm not saying you'd have to be a pro developer. It just might be helpful to start with like some HTML and CSS as some basics. Skillshare is a great resource for that. Think of code is just another design tool and your utility belt. Those are some good ways that you can get started trusting your developer a bit more. 12. Putting It All Together: All right, let's have another look at that design process that we went through earlier, that really bad project. What might that look like with these new techniques and ideas in place? Well, again, you're a freelance designer, you just landed a new client. You're having your kickoff meeting but because the developers in the room, as you're talking through it, they realize they've worked on a very similar project in the past, and they offer a suggestion as to how this thing might work. The client loves it so that's where you start. You both begin prototyping ideas and eventually after prototyping and throwing out ideas and keeping the good ones, you land on a really solid direction and you start design. It's finally time for the high fidelity comps. You talk to the developers about what they might need, what are you designing for? What devices are your target devices, and you worked it together once the comps are done to break them down into further components. Having the components and the style guides, your developer can develop more quickly than they might have otherwise. The client may all of a sudden has a super important page once again but the developer can just build it, because they have this box of Lego pieces to draw from. You don't even have to open your design tool. Nobody had to stay up late before launch and launch happens on time. Maybe you spot a few bugs, but it's fine because your process is iterative and you can quickly get them out of the way. You can even after launch, keep adding to and improving on the site. Maybe the client has another request for a feature. You can add it pretty easily because you're just adding a component, you're not designing an entirety layout. Obviously, this is an idealized process, just like the previous example was idealized in the opposite direction. There always going to be bumps in the road, but with communication and some good tools, you will launch better projects. Now that you know how this can work, your process will improve. 13. Conclusion: This is really meant to just be a primer, just to get you started thinking about these things. Really, it's a career long practice to work on your relationships with your collaborators, and improve your process. The best thing you can do, is keep reading and try new things. But in summary, we talked about three things that can really improve, dramatically improve your relationship with your developers. The first thing: involve them early, and then keep them involved throughout the process. That means no more designing in a vacuum. Ask lots of questions about what they need from you to execute the design properly. No more big design reveals, because they can sometimes derail a project. Design systems, not pages. Break things down. Include topography rules and colors and things like that, but also break things down into components. Think about it as Lego pieces that snap together. These are faster and easier to build, that really mimic how we build on the web anyway. The third thing we talked about is trusting your developer. You can't 100 percent control the outcome of your design on this medium. There are just too many variables. Once it gets outside of Sketch or Photoshop, it's out of your hands. Also, developers tend to make design decisions, so they're going to make mistakes. The key is to be patient and help them. Now, this process doesn't work for everybody. You'll probably have to adapt it to your own process, on your own team, your own way of working. But again, this is just to get you started thinking about these concepts and improve it, improve your process over time. The result is better, more collaborative relationships with your developers, and ultimately better projects and happier client. I hope this helps you. Go out and build something awesome.