 All right, welcome everyone to this session today by Learn WordPress. This session is called Designers and Developers, Cats and Dogs Living in Harmony with our guest presenter Kirsten Starcher. Quick introduction. My name is Courtney. I am located in, oh, there we go. I am located in Oahu, Hawaii. As I mentioned, I'm representing the WordPress training team via learn.wordpress.org. And Kirsten Starcher has joined us as the presenter today at OutsideInTheSun.com. She is a developer, a designer, a little bit of everything coming from the Vancouver, Canada area. You can see a comment in the chat, cats and dogs are the problem. It's the owners who can't get along. I just started giggling at that too. And yeah, I will let Kirsten take it from here. I am also letting a few more folks in to the room, but I will stop my share so Kirsten can share her screen. So thanks for joining us today, Kirsten. Oh, thanks very much. Let's see, let's make sure we've got the right screen here. That looks like the one. OK, so yeah, welcome, everybody. Nice to meet all of you. One of you I know I already know. So today I am going to be talking a bit about how designers and developers can work better together, like cats and dogs living in harmony. A little bit about myself first. I grew up in Newfoundland, Canada. I got my undergrad and master's in computer science in the mid 90s. I have been working on the web since there was a web. I've worked in pretty much all aspects of it. I mean, initially there wasn't such a thing as a new media degree and there wasn't any kind of all encompassing package where you could learn all the different things you had to kind of figure it out on your own. So I've done design, I've done development, I've done content creations, and I've often been in that sort of weird little space between design and development. I worked in New York for a few years, doing sites for things like Bravo and the Independent Film Channel, other corporate promotions and sites. I came back to Canada and freelanced full time for nearly 20 years. These days, I mainly focus on WordPress front end development. I'm the senior developer at F squared marketing, where we build custom sites for law firms and the legal industry. I am a dog person, but right now I only have fish tanks. So what we're going to talk about today, a little bit on just acknowledging that people have different communication styles on appreciating the other's perspective and needs. Some tools and some things to keep in mind to help project communication go more smoothly. And things to keep in mind. So I'm going to make a bunch of sweeping generalizations here about designers and developers because, you know, there's a few things that tend to be common to us, but not everybody. I'm thinking about mainly small teams and agencies or freelancers in situations where you have one person dedicated to design and one person dedicated to development. So in the chat earlier, we were asking kind of what everybody's roles are. Are you more of a designer or developer? And I need to get back to the chat so I can see more what the answers were. I got the gist that it was a little bit of this and a little bit of that, that there are some exclusive designers, some exclusive developers, and some who do a bit of a mix of everything. So that's kind of what I would expect. But yeah, I'm going to be looking mainly at the cases where you have somebody who's dedicated to that one track and is mainly trained in that and mainly focused on that. So designers and developers typically do what we do because it suits our abilities and our personal way of thinking, which is great because it makes it possible for us to bring our best specialized selves to a project. But it means we see the same thing in totally different ways and it affects how we communicate about a project. So designers and developers may or may not be a great match in a particular project, but sometimes we're just thrown into a situation together. You could think of it a little bit like college roommates where sometimes you get one very rigid person put together with one very casual late-back person and they don't necessarily agree about who's tidy and what and who organizes that. But they have to find a way to make it work and communicate despite those differences. Communication conflicts aren't uniquely between humans. A tail wagging means a very, very different thing to a dog than it does to a cat. And to a dog going belly up is usually a show of trust or surrender. To a cat, it means they will now use as many of their sharp parts as possible. It's possible for us to barge through life unaware of the underlying messages that we're sending and receiving, assuming that we're being clearly understood or that we understand the other person. In order to successfully collaborate on a website, we have to address both the technical needs of the project and the human needs of the collaborators. We're gonna focus here on the human needs first. We all want to feel that our expertise and our knowledge is respected, that our time and our effort is appreciated, that any decisions made about this project will take us into consideration and that we're trusted. I've often heard designers complain about handing their work over to a developer and having the final result totally miss the point. Maybe it deviated too much from the design or it just wasn't functional. And sometimes the developer has even abandoned the project or just stonewalled and stopped responding to their requests. The choices the designer makes in a web design have been made for a particular reason based on that designer's knowledge of user experience and aesthetics. Designers ideally want the finished product to look just like what they designed and for the site to function intuitively. Micromanaging often happens when the designer doesn't trust the developer to carry out their vision. I've often heard developers complain about a designer fixating on small nitpicky details, changing their mind halfway through, complaining that something doesn't work when it wasn't finished yet or giving designs that can't actually be implemented. Developers need clear information upfront to make the process smooth without having to backtrack and redo their work. They need to be given space to work. The further along you are in the development process, the more difficult the changes can be. Once you've poured the concrete, it can be very difficult to change the ceiling height. Avoidance happens when the developer doesn't trust the designer to appreciate their work. Everyone wants good communication. It might not always seem like that, but we're all looking for it in our own way and nobody wants to be put into an uncomfortable situation that they don't know how to get out of. So first off, align your ducts. Set the expectations upfront. Establish all the project's needs upfront. Get all the boring, dry details nailed down as clearly as possible right at the beginning and keep those details available for handy reference. Document everything. If you're not in charge of the project plan and this isn't your job, at least make sure you've gotten clarity for what you need and what is expected of you. If you're on the contract side of things, you're going to want to put all of that in the contract that you and the client are aware of, of course, but then you're also going to want to have some form of business requirements that you can share with the designer or the developer on your team and have something very clearly knowing what you are building and what you're not. Get any of the little details here. I've got a few notes on the slide about things like who supports the site after the launch, who trains the client, who is filling in content from the old site or from the client submissions. Just make sure all of this is understood upfront because the more that you have upfront and you have something that you have a history and you can refer to it, the less confusion there is going to be later on. So be realistic. Be realistic about timelines. Don't make promises that you can't deliver. If you see a problem pointed out, the other person may not be aware that something isn't manageable or they may already have thought of something and know a solution and then they can put your mind at ease. At least one of you is going to learn something. Sometimes, maybe in the middle of a project, hard conversations need to be had. I've had clients whose previous designer or developer bailed without any explanation, leaving the client lost and confused. If you're midway through a project when you realize you're in too deep or there's something that you don't understand, speak up. The sooner that you raise an issue, the sooner it can be resolved or accommodated. There's nothing worse than at the end when project is supposed to be done, scrambling to find out that something isn't going to be possible and you are going to miss a deadline. We all want to be trusted for our work but the trust only comes in time as you show that you are capable of delivering on your promises and doing your best to ensure that things go smoothly. So be honest about your knowledge and your expertise. If something is new to you, admit you're willing to learn but you're not sure how long this might take. Allowing yourself to be vulnerable helps the other person trust you since they can see you're not just going to bluff your way through the project and that you'll be able to speak up if there's a problem. Often when people aren't honest, it's out of fear. Maybe being judged, getting something wrong, looking stupid, losing the job. You don't have to admit these fears to your colleagues but at least be able to admit them to yourself and ask yourself if this is getting in the way of your relationship with your coworkers or your bosses. So what do we need to know up front and whose perspective are we looking out from? All right, now we have advice for the designers. So involve the developer early because they can confirm that what you've designed is viable. It is really unpleasant to promise the client something and then have it turn out to be a logistical nightmare to build and then you have to go back to them and explain why you had to change what they'd already approved and expected. Also, the developer might be able to suggest some approaches and features and improvements that you wouldn't have thought of, though sometimes the more eyes you have on something, the better. There is a limit to that but definitely having the developer involved early is pretty crucial. Ask your developer for what format they need your design to be in and stick to it. I have asked for slideshow images to be sent to me as 72 DPI JPEGs and had someone send me a nine megabyte EPS file that wouldn't even open. That slows things down, requires a lot of back and forth is totally unnecessary. If you're using Photoshop and you're giving the Photoshop files clean up any unused PSD layers, give the design as a flat PDF or JPEG as well as the source files. So as the designer, it's not your job to know everything but it is good to have sort of a sense of the broad strokes especially if you're coming from a print background. It'll help you make better decisions in your designs. Just knowing a little bit about what is possible with CSS or knowing about where the best break points are for responsive design. Know your way around WordPress to some extent. You don't have to be an expert but know how to do some things around posts and pages and change some settings. Find examples of things that you'd like to see. So maybe you have a particular type of slider or menu functionality that you'd like implemented. If you can show somewhere that is being used on another site and show like I really like how they've done this, maybe a little less of that and a little more of this. If you even find a code pen with an example and the developer can use that as a reference, that is fantastic. It really helps us to visualize what it is that you want the end result to behave like. Remember that the developer's job is not the same as your job and they're looking at your design with different eyes than you are. I'm speaking as a developer, which I mainly have these days. I don't always see, I don't always notice if two font sizes are exactly identical or not. So you wanna make it as easy as possible for the developers to get the details that they need so that we don't miss anything. You can do this either by designing in a tool like Adobe XD or FIGBA or by making your own cheat sheet. Do also keep in mind that the web is a relatively fluid medium and there's gonna be some changes that have to be made for different screen sizes and devices. So be willing to accept a little bit of flux as long as it overall looks like your design. I would like to do a quick chat poll here and find out how many people are using Adobe XD or FIGMA for design and how many are using Photoshop or something else. There's a chat, a couple of FIGMAs. Ooh, paper and pencil, I love it. Some days I swear I'm just gonna go back to paper and pencil entirely. This took away with the whole computer side of it. Okay, okay. Okay, interesting question or answer from Alyssa. I've started designing in the browser now that there's blocks, that's a good point. Yep. Okay, so we've got an even mix of FIGMA and other stuff by the looks of it. And just put you guys over here. So interesting, there wasn't, I don't think there was one person using XD. At least nobody is saying so. But here is an example using Adobe XD. And one of the things that I really like about this or FIGMA is that you can see the CSS details of any element when you click on it. You can also prototype sites more fully than you can in Photoshop. You can set menu behaviors and hover states and things like that. So you can see here, whoops, nope, go back. Here I've got a header selected and over on the right, it's giving me a bunch of CSS settings. So rather than in Photoshop where you kind of have to go in and then go through a whole bunch of different panels, here it's just all on one screen in one place. It's pretty sweet. I was kind of excited when we all started to migrate more towards this. And here's a similar example in FIGMA. Linda XD is an Adobe product that is kind of like FIGMA. So it lets you mock up a site, create each of the pages sort of in one gigantic file, create walkthroughs for the client. Yeah, well apparently FIGMA is better because so maybe don't worry about XD. Seems like at least in this group, FIGMA is winning. So this is what FIGMA looks like. And honestly, even just looking at it, it kind of is tidier like the CSS on the right is to me just kind of easier to deal with. So yeah, here's an example from a site where the designer has set up kind of examples of buttons and page titles and font styles and so on. So I can just go through this, click on anything that I want and it's going to give me the CSS details for it, which is really nice. The designers can also set it up so that you can see what kind of menu behavior they want or what kind of hover states. And it makes it easier for me to then do some of the animated or JavaScript components of things to be more like what they're envisioning. So if you're not using XD or FIGMA, you can still create a nice clear comprehensive design documents manually. So here's an example for a project I did many years ago where the designer gave me a nice little cheat sheet with all the text styles that I was going to need as well as all the colors and RGB codes that hex codes rather that I was going to need. Here's another example where they gave me a font style guide kind of down below and then a section of the design where it refers to those fonts and where it also is clearly marked out the distances between the items. So basically ensuring that I wasn't gonna miss it going around measuring and Photoshop myself. You might be groaning about doing this sort of extra work as a designer. I'm not saying that you have to do this but it will help the developer give you what you want if it's clearly marked in front. Then it's clear that that is important to you in your design that you want these gaps and to be accurate. And means things are less likely to be missed. Oh yeah, Doug, you're right. Adobe did buy Figma. And I guess we have yet to see what that's gonna mean. So for designers a little bit about the care and feeding of your developer. So let a developer focus while they work. Don't look at the work in progress if you can't resist sending fixes. Wait until they are ready for you to look at it. Be like a good waiter at a restaurant here, there if you're needed but you're not constantly imposing yourself. It can be overwhelming to have to sort through a huge laundry list of changes. Sort your changes and tweaks by priority be willing to be a little bit flexible. You may not know whether that little adjustment that you wanna make is going to take you 15 seconds or a few hours but don't assume that it's easy because it's easy for you to do in Figma. Rebuilding something that has already done can be hard and soul-sucking work. Developers, you have some decisions to make on how to implement the design. It's going to be up to you to determine what's appropriate for the site. The decision is going to affect how you and the designer work together and keep things on time and budget. So know when to use a pre-built theme that you bought off of in Forest whether when you're using a child theme or not whether you're building a completely custom theme from scratch whether you're using full site editing maybe. Have a sense of what is appropriate and what is going to serve the project and the site for its natural life. Anticipate a bit between what you've been given. Ask for what you need to know. Is the navigation going to work on mobile? What happens if the client adds one more page and breaks the navigation, can that happen? Here's an example where the design that I was given has a fatal flaw to it. I looked at this and I kind of went how do you get to the middle letters of the alphabet? Like what happens when I click that? How am I supposed to sort that? So I had to go back to the designer and say I don't understand what you need here. What would you like to have happen? And then we had to talk about it and figured out a better way to present things. You may need to extrapolate the basics that the designer has given you to other pages. So do your best to use the elements that you've been given consistently. So if you have a whole new section of the site, keep the header looking consistent with everything else. Use the same types of buttons, use the same types of call outs. You might need to think a bit beyond the design and enhance the designer's vision as long as you're still respecting their work and their intentions and doing your best to use what they've given you. If you have to, of course, go back and ask questions. You might not need to spend six hours going down a JavaScript rabbit hole if the designer is totally fine with an alternative. So if you run into some problems, don't brush it under the rug, have a conversation about it. You'd say, I'm sorry, I looked into this, but this is going to conflict with that and I'm gonna need this to build this a different way. Here are some other ways that I could do this. Instead of just going back and saying, nope, can't do this, nope, too much hassle. Like, okay, great, that happens. What can we do? How can we still stay true to this without just spinning your wheels forever on something that might not really need to be done the way you thought you were gonna do it? And for design, a developer is a bit of care and feeding of your designer. As a developer, I can say it can be frustrating to be told to move that thing over three pixels, but the designers do see things that we don't. And honestly, that is why I don't really consider myself a designer anymore because, left to my own devices, I won't necessarily line things up perfectly and I won't see some of the nuances that can really make or break a design. So that is their job. And it can be a little frustrating, but take a deep breath. Again, if something's gonna be completely unreasonable, then find a way to have a polite conversation about it. If you do have to correct the designer's work for technical reasons, do it respectfully. You may be teaching them something that they need to know for their future work. Developers often get a reputation for talking down to designers or being scornful because the designer didn't know something that seems really obvious to them. Remember that it's not their job to know how to do what you can. That's why you are there. Otherwise they would be doing your job. So for everybody, what about when things start to get difficult? Listening means letting go of your agenda. It means you don't decide what it is you're going to say until the other person has finished their piece. And not just waiting for a gap in the conversation so you can say your thing. Listening means letting yourself be affected and letting yourself be influenced. Trust comes when you know the other person will hear you. So are you willing to hear them? You can reflect what you heard. Oh, my understanding is, it sounds like you'd like to hear your, it sounds like you'd like to see the headers be more consistent from page to page. Am I getting that right? And let them know what they're doing right. Let them know if there's something about the way that they are working with you that you really, really appreciate that maybe the other, someone else hasn't done before or maybe that's been really helpful to you. Let them know and a little bit of appreciation can go a really, really long way. So also for everybody, the designer's request may come from the client or the project manager and they may be as unhappy about having to do something a certain way as you are, may not be their fault. A developer refusing to do something may come from hours of research and testing and frustration. And sure, maybe your design doesn't have the thing you wanted exactly the way you wanted, but it's not personal. In a conflict, do you have the site's needs at heart? Can you admit it if your approach might not be what's needed here? If you know you're right, can you make it easy for the other person to stand down, lower the stakes however you can, find some common ground, a solution that meets everyone's needs and a way of compromising. So investing in the relationship early on is really important. The fruition of the relationship happens the whole way through the process and at the end and in more potential projects if you guys really like working together or have to work together whether you like it or not. In a perfect world, we want not just responsive websites but responsive designers and developers. So that is pretty much everything. I have one link that I would like to drop into the chat for you here and I'm up for any conversation questions. This is a little bit about nonviolent communication in the workplace. I don't know if you may or may not have heard of nonviolent communication but it's basically a way of approaching often difficult conversations in a way that helps to de-escalate situations and meet everyone's needs ideally if you're doing it right, which isn't always easy. I'm going to stop sharing and let's open up the floor. I have any questions? I don't believe anything, any questions came in in the chat. You had a few comments. I believe you had an eye on the chat while you were presenting as well. Yeah, once I put it in the right spot. Yeah, so many windows. Yeah, it's a good resource. Nonviolent communication. Just give folks a minute if they're typing. Maybe there aren't any questions. Maybe it was already in perfect harmony. Yeah, I mean, we could just, we could, we could just play more dog and cat videos. I think with full screen editing, the relationships are emerging. Yes. I'm really with. A lot of out of the box themes that. There's, there's a lot of overlap in, in where, where I as a developer have been asked to tweak. Out of the box themes, but the designer is working in the page builder and in the, whatever the commercial theme is itself designing there. So I think it's a great idea to be brought in to do a little bit harder CSS stuff and play with plugins, but I'm not actually really doing coding per se. I think designers getting familiar with UX helps to bridge the gap between them and developers. Yeah. And I do feel that this has happened more over the. Over the last. I'm going to date myself here, but a couple of decades. What I used to have when I started doing this was designers who had only ever done print. And had never designed a website and then they would give me something and that was expected to anchor in very precise points of the page. And it was kind of like your page doesn't work like that anymore. Especially when CSS was more limited and you couldn't do something like anchor to the bottom of a page. Now there's almost nothing that you. Can't do. Would you ask the developer to be in the onboarding call with a client to scope out better you think this is not needed. I think that depends on the developer and the client. It might have more to do with the size of the project. It's. Not usually needed. I think unless you're doing so. Yeah, again, it does have to do with the scope of the site. I think if you've got something, if you've got kind of like your basic brochure where site. Then I don't think you necessarily need a developer on that if you have something that is more. Kind of a SAS type of site or something kind of heavy duty functionality where there's going to be more complicated user workflow. Then yeah, you might want them on board earlier. Some developers will and some won't be comfortable with that either. Yeah. I think I'm going to give you an authoritative. It depends to that one. How do you deal with a client request that is difficult to execute. If it is going beyond the scope of what's been promised. Kimberly, maybe you can elaborate a bit. Do you mean one that is kind of in the initial. Project scope or something that they're kind of trying to add on after the fact or something that you should be able to do, but you're just finding it challenging. I don't know what you're thinking about that one. I'll just again try to answer broadly. If you've. I'm going to address mainly the situation where a client comes back with changes that are difficult to execute. First of all, if they are. Outside the scope of the project. This is where it's super, super important to have. There we go. Me or may not be a good fit for their needs or won't get them back. So as an example of that, I had a client once who. You guys are going to love this. They asked for a horizontal navigation. At the top of their page. But they wanted the menu to be on a ticker. So that it moved like a news ticker. And scrolled. Constantly. I had to diplomatically find a way of explaining why that was possibly one of the worst ideas I'd ever heard without saying so. And I actually called on accessibility as. A point for that one where one of one crucial thing that you want for really any user, but, you know, especially if you're keeping accessibility in mind is to have consistent navigation on every page. So if you're going to be moving away from the menu. If somebody is going from page to page, they're going to want to see the expect to see the menu in the same place. Otherwise it gets confusing. If somebody has issues with hand motion and the menu is going to be moving away from them constantly. Then they're going to get frustrated and they're going to give up on your site and never come back ever again. That's right. That's a lesson in. Keeping my face. Totally, totally calm up. So basically, but you, you do your best to. To explain like there are going to be good reasons for. For why that isn't going to get them the result they're looking for. And, and you can tell them. You can tell them. You can tell them. You can tell them. Mainly without it having to be about them or their idea. Just like, Oh, okay. Yeah. No, I see why you'd like to do that. That is kind of fun. Unfortunately. Yeah, that can be a bit of a problem because people don't know like this. This can be difficult. And you just, you just give reasons. If something is. Yeah, change requests equals more money. Sean is saying. Absolutely true. Yeah. Yeah. Yeah. And say that's a really great idea. We don't have that in scope at the moment, but I'd be, we could add that on maybe as a. Kind of phase two. Addition. We can, I can scope that out for you. And maybe after a watch. We can work that in. And of course, if you, if they insist on it happening on launch, it's like, okay, that's, that is change control. Yeah. Yeah. Yeah. Yeah. I mean, again, you'd feel it out by the client. There are, there have been some clients that I would, you know, bend over backwards to figure out what they need on the site because they're so considerate and so appreciative. And then there's other site. Other clients where you kind of realize if you give them this one little thing, then the whole world of dangerous possibilities opens up. And I think one of the things that I would recommend is, one, two, do you recommend for the client to send back feedback instructions on changes besides the email? Really love. Rello. Trullo is nice for, you can, you can set up trouble with a couple of, a couple of. Column. So, you know, one is where they put in any new bugs that they see. And you can move that over into a column and when it's accepted and you're working on it or kind of bounce it back to them. If it's something that you're like, oh, actually just try clearing your cash. And so then you can keep track of whatever has been asked for and the conversation for each particular piece. So, and it's fairly easy for them to use as well. So that's, that's pretty handy. Hey, I think. Yeah, yeah, yeah, that's good. Margaret saying accessibility argument is reason number one, why a web splash page would be better than a PDF, which may or may not open. But what convinced him was I said, I couldn't put a functional call to action button on the PDF. Yeah. Yeah, that's it. I mean, you basically, you're looking at what is it that they're trying to accomplish? Why is it that the thing they're asking for isn't going to accomplish that? I mean, if they have, what is their need? If they have their mind fixed on that particular need, then what else is going to meet that need and maybe do it a little better and maybe need another need at the same time. So bring it back to the, it's the name of the tool. Did I mention the tool besides trial? I think I just, I think I just think so. I've used some other tools that I honestly don't like as much. So I'm going to tell you that one. Have you ever received feedback like through Figma or like, you know, using comments on, on there? Or is that a learning curve for a client? I think our designer does that with the client for some projects. So I'm not so much a part of that process because I'm getting it given to me after all of that has kind of been incorporated, but I certainly have seen some of our Figma designs at F squared where there's lots of little comment markups here and there. And it's, I think it's really good for when you actually have that design meeting with the client and you can be marketing, marking it up together as we go through it. So everything is fresh. You're not kind of looking through notes later going, what did I do here? So yeah, that can be pretty useful too. Contents near, I don't know that one, but I'll look it up later. One last question for everybody who here is a cat person. Who's a dog person? And you can be something else. He can be a horse person. That's hard for a person. A dog and a goat together must be fun. I was wondering if Dev and the designers broke out differently. Oh, into dog versus cat. Oh yeah, yeah, yeah. I don't know. We can try that. Everybody put in what your role is. And whether you're dog or cat. I mean, I'm here. I'll put one in dog. Yeah, if you're both. Yeah. Dev dog, dog, dog designer, designer cat. More design, some dev dog and cat project manager, both slightly more cat. Dev dog, but only cat. So it is indeed a mix. Just be expected where. People are complicated. Yes. We more towards a design side and I'm a cat person, but I also love dogs. So. I have a great appreciation for cats, but. But I have puppy nature. I think. All right. Everybody go finish their lunch or. Time zone you're in whatever meal you're closest to. Start or finish. Yeah, I think that's it. No more questions. Mostly. Just talking about dogs and cats. Staying on topic. Oh yeah. Well, thank you. Thank you, Kirsten for your presentation and for. To everyone for attending today. Again, thanks for your. Understanding with the zoom mix up. I'm glad that you all made it in. Yeah. And if you have anything else you'd like to, to ask Kirsten after, after we sign off, you can post in the meetup event. And again, if you want to. Attend more online workshops or on the meetup group and also listed at learn.wordpress.org. Again, thank you Kirsten. Thank you everyone for being here. We will have a recording of this session posted on WordPress.TV and the next 24 hours or so. Thank you. Thank you all very much. Thanks Courtney for putting all this together. Yeah, you're welcome. See you online.