Developer Handoff – FREE Full Lesson from Shift Nudge

Hey, what's going on, MDs here? And in this video, I'm going to share with you a full lesson from the Shift Nudge interface design course, all about developer handoff. In the video, you'll hear me talking about the layout lesson, the truncation lesson, responsive design. I even talk about a video down below where I explain a lot more detail about an actual handoff. Now, those are all part of the full course. This is just one lesson video out of the course, but it's still really valuable content. So I wanted to kind of lift the curtain on the course, give you a sense for what's in there, and also just give you a really good video about developer handoff. So without further ado, let's get set up. All right, that's pretty good. The biggest thing to remember with developer handoff is that communication is absolutely critical for the whole process to work smoothly. And in fact, the term handoff is not even really a great way to look at it, because most design and development projects should be built by with the designer and the developer both working together from the very beginning, throughout the end of the project. There are lots of times where that might not be possible, and I understand that is a limitation in certain scenarios. But anytime I've ever worked on a project of my own, whether it was for a client or a personal project, and I just was isolated and designing, designing, designing, and then I threw it over the fence to the developer, something is definitely going to go wrong. There's something that I might not have thought of, or there may be some kind of limitation that I was unaware of, or there might be something that I design that is just weird for a developer to implement, and it might take them an additional two weeks to do something custom that I was unaware of as a designer, when I could have just had a very simple conversation with them in the very beginning while I was thinking through those design decisions that would have made the project that much better. And so I could embrace those constraints and the developer can embrace the design that we're trying to push forward. So it really takes a good relationship between the development team and the design team, or a designer and developer to. To make something that is really great. So I posted this tweet as a question on Twitter to just get some real feedback from the developer community. So instead of focusing on specific tools for developer handoff like Zeppelin or Figma code or anything like that, those things have their place and they can be very beneficial. But 90% more important is gonna be the communication that goes on between the designer and the developer. So let's take a look at some actual responses that I get on Twitter about this exact same developers. In your opinion, what is the best thing a designer can do for you before, during and after handoff to ensure a smooth process? And I intentionally left the word handoff in there because I know that kind of triggers some people. And I wanted to get people's real reaction because I don't necessarily love the term handoff either. And you'll see that a lot of developers look down on that term as well. One of my favorite responses is, is from this guy, Andy Ingram. He says honestly and sincerely, I don't mean this as a jab, but never using the words handoff is a good start. The interaction between design and development should be more heavily integrated. The concept of handoff has a strong smell of waterfall process that doesn't actually work. And then he goes on to say, I also have thoughts about issues arising from conflating design as a process and design as a skill set. Think graphic design or UI design. What we're learning in this course, UI design. But everyone involved in making the product should be involved in the process part. Otherwise you can and do overlook constraints. And I think he absolutely nails it, because developers and designers thinking about the same problem together is how you're going to get to the best solution. Not by having designers sit in a room by themselves thinking of something to design and create without consulting the people who are going to implement it. You can both come up with solutions and ideas for layouts and interactions, and then you, as the designer, can go in and make it look really nice and think about some clever interactions and clever things around that constraint that you've already previously agreed upon with the developer. And this goes back to implementing those, those little systems for your layout, aligning things and measuring. All right, eight pixels from here, and this is 32 pixels. And letting a developer know that you're using this eight pixel grid system. If you're using that implicit grid, that back from the layout lesson, that's going to let them know, okay, if you see something that's like 27 pixels, you know, go ahead and feel free to make that 28 or 32. You know, feel free to use multiples of eight or multiples of four, because if something is slightly off, there's a good chance that it got nudged down. Or maybe I overlooked that. So I'm using multiples of four. We've got 12 pixels on the side, we've got 16 pixels here. And maybe just showing the system that you're using for designing that is really going to help them implement that better than just kind of lobbing it over and expecting them to know what to do without having to talk to them. It's not going to work if you're not willing to talk to the developer. A lot of people don't like to get all integrated and have big discussions with the developers and designers. There can be a lot of conflict and a lot of people don't like conflict. So I would encourage you to embrace that conflict, embrace those constraints and work together to create something great. Let me read a few more of these Nate Taylor says not look at design as something to be done in Isol handed off but collaborated on. That probably sounds pedantic and I don't mean it to, but the best designers I've worked with have worked with me up to and including releasing the feature. Same thing, working together. Communication my buddy James hall says sounds pandering, but communicate. Assume the developer doesn't get what you sent. Don't assume they know what should be done in some spot and then he follows up by saying ask was anything unclear or anything I can help with? One day later, three days later, five days later, inevitably something is going to come up that developer might not necessarily think to ask you you about. Or maybe they're unclear on, or maybe they don't. They're maybe they're afraid to push back on your design. So make it let them know I designed this to about 90% complete. There's some wiggle room maybe in some of the hover states or maybe the way the component margin is built in. Let them know where there's wiggle room and what you've designed in stone. If something is really really important, focus on that. But let them also know what areas are not necessarily tied down quite as tight and you might want to circle back with them a week later and kind of fine tune those areas. Peter's got a response here. Examples of different interactive states what does hover look like? What does focus look like? What does the disabled state look like? Number two if there's any notes or examples of desired UI animations or effects like references, things that they can reference other websites. Oh, make the drop down menu, do something like this, send a link. Those can be really helpful to show the references, notes, examples for accessibility considerations, how tabs or forms render when it's just keyboard navigation, for example, like what should be the tab order of a form if somebody's hitting tab, should it go this way or that way? But really, Again, look at this. This is all about communication. It's communicating what should happen. And the best way to communicate with someone is to talk about it. And you can write lengthy, lengthy documentation, but a lot of times it's going to be better just to sit someone down and talk through it. Maybe you do write a little bit about documentation. Sometimes that can be an overwhelming amount of work to try to write documentation about every single thing. Maybe some big things need it, but just talk to the developer, ask, hey, I can write documentation about all of this stuff. Need that? Or should we just have a conversation and just try to work together about what you can talk about, discuss, and then hand over? We've got Robin here. He says involve developers in the process from the very beginning. Same thing Michael says, please use a design tool suitable for digital. No InDesign or Photoshop, please. Please keep your file tidy by using layers and symbols and components where possible. The amount of times I thought one thing was a variation simply because they didn't update that one button. This goes back to just being mindful of your components and having a system for things defining your colors, defining your font sizes and using those symbols components where it makes sense. You know, if you have a green button over here and a red button over there, maybe the font got changed from semi bold to medium, but you forgot to update that. If you hand that to someone, someone like Michael is sitting here thinking, ah, now I need to make another button with a different class name because this one's medium weight instead of semi bold weight. And lots of times they might not know to go back and you, hey, did you mean to make this one medium and this one semi bold? Because they have to literally go in and type everything out in code. This one's green, this one's medium font, this one's semi bold. All of that has to be listed out in detail in code. So if you're not communicating, they're gonna interpret what you give them and that communication breakdown is gonna cause problems. Wilson, include error states on your forms. Not every form is going to be completely perfectly filled out. So what does the error state look like? Muhammad follows that up. Error, empty. Loading overflow. These are four different states that you might not necessarily think about when you're designing static comp. So first of all, what does it look like when someone fills out a form or does something and there's an error that's thrown? Where does that error message go? What does it look like? What does it look like when there's a feed that's Empty. Or maybe no one has sent any emails or no one's written any posts, no one has uploaded any photos. What does that empty state look like? Does it say something? Is there an illustration? Is there a little helper tip that says, hey, click here to create a new thing? You know, that might be an opportunity to throw in some branding or to put some illustration or a little helper text. Regardless of what you do in those empty states, there's got to be some type of empty state. So don't forget to design for those situations. The loading states. When something is loading and taking a while, do you want them to just pick their own animated loader or pick their own loading screen? Or do you want to design for that? You know, talk about that? Ask them, could we use one of these animated SVGs? Maybe we have a PNG sequence. Talk about that, what is needed, what's possible, and design for that Same thing for overflow. Think about back to that truncation lesson in the typography module. There's lots of titles that are three lines or one line or four lines. Where does that truncate? What is the rule around that truncation? Maybe you pull that component off to the side and you list out and you annotate a few little rules about truncation. If it goes two lines, do this. If it goes three lines, do this. If you look back at that truncation lesson in typography, that will be a really good example of that. Database spits out information into the UI and you as the designer and the developer get to decide, okay, we're only going to show 20 characters and then we're going to put. Or if it's landscape mode and it's wider, then we can show all of them. But just thinking about those constraints because ultimately that has to be coded up and maybe situations like this, maybe it needs a little art board off to the side with some documentation so you can actually have a nice buttoned up piece of component to hand to someone and they actually know how to implement it. Jessica says give me a design for a tablet. Hahaha, who am I kidding? That'll never happen. Honestly, I'm over the moon. Anytime the design file has everything organized in groups and named properly, you're communicating. When you're organizing your groups and you're naming things properly, that is communication. You're communicating. This module is this name and this is what it should be. So Jessica's asking, I want nice and tidy communication. I want it to make sense. Look back to the responsive lesson and look at those different sizes and think, do I need to provide like a medium sized view so they can get an idea of what should happen at that particular breakpoint? Because you might not need it, but depending on the website, you might actually need it. But it's going to go back to communication. There's no one size fits all for developer handoff. You have to talk to the developer about what should happen. And the less you talk about it with the developer, the more room for error. I still to this day have situations where I'm working with a client and maybe I'm not talking to the developer. So I have to be very, very clear, very, very strict about annotating things and explaining things. And sometimes I'll make a video. You can see another video down below where I explained an entire website to a developer that I never talked to and I listed all the prototypes. Sometimes that happens and that's not ideal, but I get that sometimes that happens. But even still, there's no one size fits all. It's more about just explicitly communicating the things that are important about your design. Jack says just be consistent. Have a design for buttons, have a design for form fields, have designs, don't deviate. You know, if you have a dropdown button that's 20 pixels tall and 100 pixels wide, don't create another one that's 30 pixels tall and 120 pixels wide if that other one will do. So think about being consistent and basically implementing everything that we've learned in this entire course to a systematic UI design system. You're very mindful of font sizes, font weights, layout, margin, color, have color definitions. Everything should be strategically decided upon by you. And that way you can very clearly communicate to your developer what's going on in your designs. This is a great statement from Devin, except that there may need to be adjustments. I go into almost every web design knowing that I can only get it to about 90% complete because the other 10, even 20% is going to have to happen in the browser. There's going to have to be adjustments made. I'm going to have overlooked something. I'm not robotic and methodical enough to cover 100% of every single thing that needs to happen. So the more you can accept that, there's going to be some wiggle room here. I need to go into this developer conversation knowing that something I've designed might need to be changed a little bit and I need to be okay with that. So I need to lose my ego about my great design and actually listen to the person who's going to be coding it up because there's going to have to be some wiggle room here and there, back and forth on both. Maybe, maybe there's a custom drop down that needs to be coded and extra JavaScript needs to be written. Maybe you feel really strongly about that and maybe there's a developer that doesn't want to do that, they just want to do the default one. You know, there's going to be trade offs back and forth. So you have to be willing to understand and to know what about your design do you feel is really important and where are the areas that could use a little bit of help from development. And that way both sides know there might need to be some adjustments made. Marin here says there should be no handoff. Design is a continuous process. Echoing that statement of communication over a handoff, Adam says, in a perfect world, a designer should know why atomic design is so important and implement new patterns from those storybook atoms, which is really just defining those single individual small components and then embedding those into larger components and then embedding those into other components and having those granular dimensions of 8 pixels on top, 12 pixels on the side, 16 pixel font this color, and then I'm using that as a component inside of this other compone or at least a textile and know that everything is like this Lego building block. And so if you can get those smaller components right, everything is just going to fit together that much better. Another one, don't have a handoff. Collaborate from the get go on the solution formation and respect questions from both parties. Benedict says also when there is a handoff, it's already likely that the developer was not involved in the design process and that is bad. Johnny says if there's a handoff, then it's being done wrong. Joshua saying which parts of the design are set in stone and which are flexible. Sometimes slight differences visually can make a huge difference in effort. This goes back to that 90%. Like when you get ready to hand off and it's like, okay, here's the designs know that there should be some adjustments and there might be some slight differences that could be solidified because it will reduce the level of effort. So it's all about communication. There's not going to be one size fits all. Do exactly this and then everything will work out. It's the same thing in a marriage or a friendship or any other relationship. You have to have clear communication and you have to be respectful for that relationship to work. It's no different in the designer and the developer relationship. There's got to be mutual respect for each other, clear communication, and there's got to be some give and take. Matthew says, don't just provide a screen, provide a component library of elements on the screen. And I think Mitchell's tweet sums this whole tweet thread up really nicely. Build an open and honest relationship with your counterparts. The tools you use, the strategy, the timing, all of it is useless unless the trust you share with your counterpart is airtight. Have clear dialogue, and that should open the path for any correction needed. So there it is. Communicate with your developers. You're only going to come up with a good handoff if you've already had good communication. There's not been one single project that I've worked on where we designed in isolation and handed it off, and it turned out amazing. The absolute best projects I've ever worked on has been when I had a tight integration with the development team or the developer and we were able to bounce back ideas back and forth, back and forth. You can just cut out. So much time wasted, so much headaches if you, if you can have those quick conversations. Hey, what do you think about this? Actually, that won't work because the top bar is draggable and. Okay, let me try something else. Just there's a way that you can kind of get into this flow and you don't have to ask a developer about every single little tiny thing. But if there's something you're stuck on about implementation, if it's like a table or responsive or something in Xcode, whatever you're designing, ask a developer or ask a friend that might be a developer that if you can't get a hold of the actual developer, honest open communication is going to be the best bet for dealing with handoff. No real homework on this one. I just wanted you to have the arsenal of information. When it comes to handoff, the absolute best handoff is going to be the one that you and your developer decide on. All right. I hope you enjoyed that video. If you have any questions, hit me up in the comments down below. And if you're curious about Shift Nudge, you can head to Shiftnudge.com, hop on the email list there. Enrollment opens a few times per year. The schedule kind of fluctuates, but being on that email list is the best way to stay up to date for when individual enrollment opens again. Other than that, feel free to subscribe if you haven't already to check out more content like this. And I'll see you in the next video, Sam.