 My name is Megan Dove. You might have seen me around. I have a long time volunteer with WordCamp Montreal. This is my first year as an organizer and also my first year speaking. So this talk is going to be a general overview. I'm not really going to go into a lot of technicalities. I've run it past some designers. I've run it past some developers. It's generally just things that it's easy to forget when you're in a working environment and getting frustrated by your teammates and the people in the different silos. So let's get started. It's a universally acknowledged truth that the amount of time it takes to build the entire site will inevitably be exceeded by the time spent doing small changes after you think you're finished. I don't know if that's true for anybody else, but in my head that is a universal truth. And I can tell you a story about it. We were working on a website. We were working on a website. Things were going really well. We had done about 90% of the project. We had only used up 40% of the time budget. And it was amazing. We were so proud of ourselves. It was just so smooth. And the client was making additional requests of us. And we were so confident. We were like, we're going to throw that in for free. This is our first time working with these people. They're going to be so happy with us. They're going to send all their business our way. This is great. And then all of a sudden we used up the rest of our time and we were over budget. And you might ask how that happens. And being a designer, what I say is blame the developer. So I know a lot of you at WordCamp might not like to hear that. Basically he hit a bug in the fixed navigation. It didn't work on a certain device in a certain browser. He knew that we had the extra time and he went down the rabbit hole of trying to debug it. And it was a serious issue. We're still working on figuring out exactly how to make it work perfectly. He used up the rest of the time. He only came and spoke to me after he had used up that time and said, okay, well, we're out of time. And I was like, you didn't have to do that. It wasn't fundamental to the design. You should have come to me hours ago and I would have told you it's a two-minute fix. Take it off of that one device. Use a media query. It was a two-minute fix, but it was too late. Because he waited too long to talk to the designer. Now, of course, in defense of my developer, he has plenty of things to blame the designer for. First one is over-complicating the design. And I want to be explicit on this. This does not mean having a complicated design. Because complicated designs can be good if they're adding value. If I'm just making it complicated for no reason, then I'm making my developer's life miserable for no reason. I'm guilty of giving vague style guides or handing over wire frames that don't show every element of the site in the way that he needs. He ends up guessing. He ends up approximating what he thinks I want. I end up getting frustrated because I expect him to read my mind and that's not what I designed. It leads to conflict within the team. Also, talking to the client before talking to the developer, this is a big one. I've learned my lesson. I do not do this anymore. But it's important if you're a designer. I have gone out. I have spoken to the client. I've said, yeah, we've done this before. It's just a small change. I'm sure we can do this no problem. And I go back and it's a problem. And I've just made a promise that can't be kept that the developer is the one who's going to have to stress over. So, to take it back to the beginning, a little bit more about me. My name is Megan Dove. I have my own graphic design and web development company. I've had that for six years. I studied graphic design in college. And before that, I took web technology. I never really wanted to be any kind of developer. I learned code in order to work better with developers. So, I will always see myself as a graphic designer first. I have books for sale at the Musee de Bozalt and the Canadian Centre for Architecture. I love print. I love typography. I love letterpress. I'm a tactile type of person. I'm currently working as a designer at a Montreal startup called Motor Leaf. They're using artificial intelligence in greenhouses to improve real prediction. And if you talk to me about it later, it's my favorite topic of the moment, how they're going to save the world. On that team, I'm doing print design for marketing. I'm also taking care of their corporate WordPress site. It's a startup. So, I'm also doing the UI and UX design of their software. And most recently, I've been doing the front-end development of their software. Because the dev team has been occupied with a beta release. So, it's a busy job. In order to understand why I wanted to do this talk and why I work the way that I do with developers, you really have to understand one thing about the developer, my partner, that I've worked with for six years. And that thing is that he's pretty much Ron Swanson. So, if you get the reference, I call him a code monkey. This is not something I think of all developers. But he's one of those people who he learned to code in the basement of his parents' house. And he wishes that he had never come out. He does not like to talk to people. He's not a go-to-a-meeting and have a communication type guy. He's a grunt kind of guy. He is a when you ask him to do something kind of guy. And if you're a designer and you approach that, you're like, I'll figure it out. I'm sorry for asking. So, the other thing you need to know about him is that he is my boyfriend. I make him sound terrible. He's also the most fabulous person. You know, much like Ron Swanson. I want to be friends with him, you know? If you're in a relationship that can stand the added stress of professional interaction, the thing is you gain all sorts of insights that you're not necessarily going to get from your co-workers. A couple of examples of those that I've gotten from my developer boyfriend. You don't really know how code works, do you? Yes, I could do that, but it's stupid for you to ask me and I'm not going to do it. What the hell are you trying to do here with this design? It makes no sense. Do you know how long that's going to take? I did it my way. If you want it different, learn to do it yourself. And my favorite, this is why developers hate designers. Now, in his defense, things like these are normally said at 3 o'clock in the morning on a deadline after we've both worked a full day at our day jobs. And you know, what we really want to be doing is drinking whiskey and eating steak, like Ron Swanson. He's also given me some interesting insights into the people that he works with on a daily basis that have made me reconsider what the developer teams that I work with think when I say, hey, can you just change this quickly? There's no such thing as quickly. So his insights there are something like he asked me to change the image from portrait to landscape. So I turned it sideways. You're the designer. Do your job. I don't have Photoshop. Or I have just spent the entire weekend working on a site. I told them how long it would take. I gave them an estimation. They really wanted this client so they completely ignored me. And now they're nowhere to be seen. Or I just spent the same amount of time working on an animated button that wasn't in the initial brief as I did on the entire site. And being a designer, I once again say, blame the developer. My question there is, did you tell them it was taking you way too long to solve a problem? Did you update your designer or your project manager and tell them that something that looked easy on paper is actually taking you hours? Did you tell them they were allowing scope creep and it was going to push back the deadline? And did you make sure that they actually understood when you said it? Or did you kind of mumble it while they were walking by and you were facing the wall? Because you don't actually like talking to people. It is the responsibility of the developer to tell people with less technical skill than they have that there might be an issue and to make sure that it is understood. So the biggest issue that arises between design and developers is pretty easy to solve. What we need to do is we need to stop thinking that we can read each other's minds. And I have to say that if lack of communication is the biggest problem between design and development, I put the onus on designers. Because a good designer by default has to be borderline psychic. Part of their job is talking to clients and drawing out what they want. If they're doing their job properly, they're going to get answers so that by the end of the project, there's going to be no surprises. The designers have to make sure that they're also taking the time to do this with their developers. Because these are the people who can tell you how long a project is really going to take. That maybe that fancy thing that you like just isn't worth it. That you could be making a lot more money on your site if you stop being such a designer. Unfortunately, good designers are few and far between and high in demand, much like good developers. So these are some interesting statistics. I like to look at the bottom one because it's the most extreme. IBM in the last five years has gone from a ratio of one designer to every 72 developers and engineers to one in eight. And this is something that is true across the board in Silicon Valley. People have started to appreciate not just design, but design thinking. The way that you're organizing your systems, the way that you're organizing your workflow, and it is designers who are instituting these things. The problem is that design schools just aren't keeping up with what is needed for design and technology. They're stuck in the past, they're training for print, and the skills that they're learning are not easily transferable. This is a quote from Tech Crunch 2017 and it echoes something that John Mada said in his report on design and tech. There's not enough people to meet the surge in demand. The Bureau of Labor Statistics doesn't list UI or UX design as a career. So in spite of increased demand at your companies, in spite of increased need for design, schools aren't teaching it. If you're a designer who does learn code, you're often taught the wrong thing. I was in design school. We had designed a book. We were told, okay, you're going to take this book and you're going to make it into a website or an application. Well, which one? Well, on a tablet. You know, because websites and applications are interchangeable in a graphic designer's mind. So I did the design and I said, okay, it's in 12 columns, it's perfect, it's skills this way, everything's going to drop down. And he said, no, get it better aligned, do this. And I said, well, it's not going to work because when you change it from portrait to landscape, everything will break. And he said, no, you're the designer, you don't think about how they're going to code this later, you just design it and you get the developer to do it. That's like, have you met a developer? Like, who are you going to say that to? I was like, not only that, who's going to pay for this project? But this is what you're being taught in design school. And it's unfortunate. Now, the reason I'm telling you all this is because if you're a developer, you might be inclined to think that a designer who's doing a poor job of making a handover to you, just sucks. And that it's got nothing to do with you, that it's not your responsibility. But the fact is, given those statistics that I just showed you, given the state of design education, if you want to be working with a designer who's giving you what you need, chances are, you're going to have to play a part in training them to give you what you need. So again, to put it back on the designer, I do think that it's on a designer to learn code in order to be able to better work with developers, to be able to better work with their clients. I think it's just necessary, I think everybody should learn code. But at the same time, I think it's important that you understand that by learning code, oftentimes, designers are doing themselves a disservice. Now, I've already said that I prefer print design. I like marketing. I like paper. I like the smell of ink. But I learned code. And what that means is that if I'm working in an office where there's two designers, and I'm the one who knows code, I get taken off of marketing and all of that creative stuff, and I end up being a front-end developer. And I'm not a front-end developer. I can do some front-end development, but I think most front-end developers that I know would be kind of offended at me taking that title. So too many companies, this isn't really to do with the developers or the designers. This has to do more with management and project management. Too many companies these days are saying that they're looking for a designer. And what they actually need is a front-end developer. Or too many people hire a front-end developer and say, all right, you're also doing all the design and the UX. Now, there's things do overlap and you can be good at all of them. But they can also be mutually exclusive, and you need to be clear about what you're looking for. So while developers are inevitably the ones who are staying late to figure out the bugs in a site that needs launched yesterday, it's also true that designers have similar frustrations. I was recently working on a project where I did a UI design. I did it very quickly. In two weeks, I presented it. I just wanted confirmation that the direction we were going in was good. And they said, yeah, good, finished. I was like, no, no, it's not finished. I just, this is very quick. You know, there's 15 different colors of green here. I need to clean this up before I hand it off to the development team. And they were like, no, no, it's finished. And I was like, no, it's in CMYK. You can't do that. And then they took it and they gave it to the developers. So it looks like I don't care about you guys. And it looks like you should be using the eyedropper and you are guessing on my design and it's not always just because we're not considering what you need sometimes and oftentimes design is the first thing to be forgotten. So having explained a bit of where we're both coming from, I believe, there are a few things I think we can do to understand each other better and to improve our projects and working environments. So developers, I need you to understand. We need you to understand. Design is not arbitrary. Good design is not arbitrary. There's a structure and hierarchy to design just like there is in code. We're doing the same thing. We're just doing it on different areas of a project. The thing is elements of design are often the first thing to be dropped because of scheduling. UX suggestions get overlooked. Everyone has an opinion. Everybody has a favorite color. Everybody wants the logo just a little bit bigger and they know a guy who did design one time in his garage. So he said, change it and you're going to change it. Great. The point is if you're making changes to the design or you think something's bad, instead of just being dismissive and say, well, no. Explain why you're doing it. Explain that it's going to take more time. Explain that you've looked at their design, you've considered it, and you've got a better suggestion. Don't let them think that you just don't care about their expertise. Designers, it's your responsibility to give developers exactly what they need. They should not have Photoshop open. They should not have to guess on the spacing between lines or the size of text. They should be able to look at a document. My preference is to do the handover in layers. You should be saying what your margins are. You should be seeing how you've defined things. You should be using one color and you should be defining it in the way that they're using it. I do hex. I also tend to do CMI cages so that it's all in one document. But there should be no guesswork involved. Developers, if you do happen to notice a problem, oftentimes designers are in a hurry. They do a mock-up and a title is one line long. Great, but in the real world that title is going to end up being 15 lines long because people write copy poorly. If you see that this is going to be a problem and that the text isn't going to start until after the break point on the page, mention it ahead of time. We all have to work together to make sure that the design, when it's handed over to the client, continues to work. Also, it's necessary to understand the role of responsibility of the people that you work with, but it's not necessary to know how to do their jobs. Little things that you try to understand, though, will be helpful. I recently did a style guide and I handed it over and I was so proud of myself because I was like, I did this for Android. I set up the measurements for Android and for iOS. I put in the hex. I put in the RGB. I put in all the margins. It's in layers. You don't have to guess on anything. And I ended up being the one doing the development. And the minute that I went into the back end of the code, I was like, okay, I set out the colors for you as minimum is this color, average is this color, maximum is this color. In the code, it was in a different order. It's a very trivial thing, but in my design guide, it took me a minute to fix the order so it matched the code. If I hadn't done that, it would have been a lot more frustrating for the developer, but I have no way of knowing unless the developer tells me or unless I end up doing the development myself. Sorry. From a developer perspective, I know sometimes you can't be bothered about opening my style guide. I know sometimes you don't care. I know sometimes you just guess and you have no interest in knowing what it's really supposed to be because the front end person or the designer will go in later and fix it. But I don't care how colorblind you are. And yes, my boyfriend is colorblind, although he says that he's not colorblind, we just disagree on color names. I say green and he says gray. But I don't care how colorblind you are. You know when something looks off. You know when it looks different. You know when that shadow is different. It just frustrates designers. And what it means is if I think you're not going to open my document anyway, why am I going to take the time to make something good for you? It's small encouragements that we can lend to each other that lend validity to our knowledge that actually encourages us to work better together. Designers, I'm going to go back to it again. Provide layers, whether you're working in Photoshop or Sketch or Illustrator or XD, take the time to just draw in those lines. You're using guidelines anyway. When you're creating the design, you have these things in mind. So spell it out, make it easy. You're going to have the joy of seeing your design the way that you really want it and your developer isn't going to want to kill you. So as I said before, we're really doing the same job. We're applying ourselves to the same problem, organizing information in the most efficient way possible possible with a hierarchy. Yeah. I started out learning H2, like for me personally, I started out learning HTML and CSS, went on to JavaScript, I moved into C sharp a bit because I wanted to understand more about 3D through like unity. And now I'm being told at work because I know those things I should probably be getting on. What are they using right now? PHP is another one that I'm supposed to learn. And there's another one too that they would basically, and this is the issue, the minute that you say to a designer learn some code. Oh, if you know this, you should know this too. Go home and learn. You know, it's a never ending cycle. And the thing is, no matter how well I think I learned code for a designer, there is a developer or front end developer who can do it better than me. So why not have them do the job? That's the you're going to have a more productive workflow. But yeah, I would say starting with HTML and CSS, if you're working on WordPress, obviously moving into PHP so you can do more of the back end. And even if you're not changing the direct code, you can understand the HTML and CSS elements in the PHP. So yeah, I'm speeding through this. It's awesome. So the other things that I would recommend and some people might disagree with me, I would say that you need to, in order to really make this work, establish a common language. Don't wait until you start coding. Now this is something that's kind of foreign to designers, because we see things and we but we do kind of do it. We set paragraph styles much in the same way that in CSS you're putting classes. But we don't really name them. Sometimes it's title and sometimes it's text. And if you can get your designer to start thinking, for me personally, I like the block element modifier like BEM naming. It can be problematic with WordPress because of default classes. But it's a good place to start to get everybody naming things the same way so that you're using extensions and so that you're always calling a title a title, title green, title white, so that you can look at the code and understand no matter what your level of proficiency with the code is. Use atomic design. Now I think personally that atomic design is very intuitive to anybody who's working with WordPress because it's already very modular. You're already working with plugins and you're already working and looking at things as a system that you can drag into or that your client can drag into. You don't need to use atomic design specifically. You can call it whatever you want. Basically, if you don't know what atomic design is, you can look up Brad Frost. It's starting at the smallest level, finding patterns in the code that you're making, finding patterns in the design. If you're always going to have a modal box, build from something very simple and expand on it and try to keep your code very simple, modular, expand it as you need it. But don't go crazy and just add classes and styles for no reason. It'll keep everything so much cleaner. Include UX and UI testing in your project scope and price. Again, this is a good way to piss off designers and also kind of developers because at the end, if you're in a rush to make this site work, you don't have the time to sit back and make sure that it works the way you wanted to or that it's intuitive for your client to use or for their clients to use, but it's just as important as the functionality. You can have the greatest site in the world that's completely functional, but if it's ugly and you can't work through it properly, the client's not going to use it in a snow point. We need each other to make this work. And finally, this isn't really for designers or developers. It goes back to the it goes back more to the management. If you're working on software or larger projects where you're constantly launching, testing, launching again, include your designer and your main developer in defining what your minimal viable product is because they can give you advice and they can recommend things. What you think is, as long as it does this, it's good. They might be able to make suggestions that will improve it and improve your workflow. So this is my final slide. It's 22 minutes. I timed this awesome. So going back to quote John Meadah, because come on, dark crush. Anyone with computer in a design program can create a page layout. But unless you're trained in design, it won't look very good and it won't communicate very well. Everyone here is working in technology, I'm assuming, or using technology in some way for their job. And while advances make our careers and workflows easier, it also democratizes our knowledge. Now, this is something that's normal for developers. It's always been the case that if you're a good developer, you could have learned it on your own. You could have learned it in a basement. You could have learned it in school, but practice makes perfect for designers. It's a little bit harder for us to come to terms with because it's always been rather exclusive. You had to go to school and you had to have expensive tools, and now that everybody can use Photoshop and InDesign, we're a little bit threatened, you know. So I think it's important for all of us to recognize that with coding bootcamps and online tutorials and Udemy classes, we can't forget the expertise that comes with education or experience and practice in one area. We really need to recognize that expertise and to ask for it when it's needed. Many developers can design or have opinions on design, and the thing is a designer has normally been trained to live design. It's like a disease that you can't unsee. You've got your credit card out on the metro and you're measuring the side of the poster and you're like, that's like a millimeter off. It's not centered and your friends think you're a complete jerk. And well, no, it's true. That's a true story. And while many graphic designers and front-end developers can do code and can work in the back end to a degree, you have to understand that somebody who's worked on complex systems for years who has not just learned a language but has learned a way of looking at the hierarchy of code and how pages work together and who has learned from years of junior mistakes, they're always going to have something to contribute to a project that nobody else will. And you have to ask them for it oftentimes or because in my experience, a lot of developers are not the most communicative people. They sit in front of computers all day for a reason because they like them more than people. This could just be my boyfriend. I don't want to like throw any labels out there, but that's my experience. So I've just got one last thing to say in conclusion and to sum it all up, I don't think we just need to communicate with each other about the projects that we're working on or with the people in our individual departments. We need to share our knowledge and that's part of why I love WordCamp because everybody here is trying to learn, trying to improve and willing to share what they know. We need to be honest about our limitations. If you're a designer and you can do some code, don't hesitate to say, I can do this, but a real front end developer can do it better. Give people the honor that they're due. And we really, really need to appreciate and start asking more for the expertise of others because if we don't, it's to the detriment of our work environments and all of our projects. And that's all. So I think that in development, that's understood that ideally with like more responsive systems, you're starting with smaller first and working your way up. I think from a design perspective, the problem is that oftentimes when you're included in a briefing for clients, they don't want to see five different designs and they don't understand when you show it to them. So if you have a client and they say, we need this website for our farm, if you show up and you say, OK, so here's the phone design. They're like, no, I want a big header image and I want this. So you end up by necessity having to create that. And I find also in the design process a lot of people don't want to pay for five different designs. So what ends up happening is you do this big design that they actually understand because in their head, they want a website. And then your design kind of just gets chunked down to fit. And that's kind of what I meant when I said include the UI and the testing and everything in the initial brief. This has to be explained to clients because they don't know either. You know, 50 percent of people are going to be looking at your website from a cell phone, which means that we have to start this way. It's going to cost more money because it takes longer both to code and to do the design of. But I find oftentimes that's not said. It's either expected that it's just going to happen or you expect clients to know and it never gets mentioned. And that's one of those things at the end that you're like, oh, my God, we just did the whole site. We didn't know they needed it for mobile too. Like they didn't pay for that. So if anybody has advice on that, I'm coming up for a review and I would this is this is one of my personal pain points in I like to know a little bit of everything. And I I want to know more code because I feel dumb. If developers like you're dumb, I'm like, oh, my God, why didn't I know that? I should have learned PHP long ago. Like, even though it's not my expertise, the problem is you can end up as a designer doing five different jobs and it's usually not recognized that you're doing five different jobs. For me, the best thing that I've been able to do is very, very specifically say, I can do this. I'm willing to do it to this extent. But eventually you're going to have somebody else do it or I'm going to have somebody else that I can change it off to. And it's really setting at the beginning when you get hired, the understanding that, yes, I will jump in and help the team wherever I can. But this is my professional goal. This is what I want to do. And if you want me to jump in and do what I can to help, I expect you to also support me in my professional goal. So far, I could probably use some tips myself because I just get to keep getting told to learn more and more code. So it's not really working for me. I don't know. I'm going to end up being a developer and I don't want to. Development for me is kind of like Sisyphus, you know, like design. You're like, hey, moved over, beautiful. Developers are like, hey, I just fixed this. And then the stone rolls down the hill and the site breaks again and you just push it back up and that's all you do all day long and it's just frustrating or maybe it's just because I'm bad at code. But that's how it makes me feel good. Done.