Dogs and Cats Living Together... Mass Hysteria
CC Attribution 3.0 Germany:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Gesuero, Adam
Brooks, Kevin
How designers and developers can get along. For years, developers and designers have had a rocky relationship. Lack of communication and understanding between both departments means details get lost in the shuffle, and often the intent of the design is lost. Frustration ensues. The work suffers. It doesn’t have to be this way! Adam & Kevin from ICS will show you how design and development can work together, in harmony, to create amazing websites and digital products.
 So, just in sense of introductions, so we're both from Inge Conscious Studios. I'm, my name's Adam Jezowar. I'm the creative director and founder of ICS. I've been building websites for over 12 years. Started this agency sort of as a solo designer developer. I've kind of been on both sides of the aisle. We've now grown into a nine-person team. And before starting ICS, I was an in-house designer at various startups and agencies throughout Boston. So, Kevin, do you want to give it quick? Yeah, sure. I feel like half the room knows me. I'm Kevin Brooks. I've been a developer for, yeah, about 13 years now. I feel like I tried to be the unicorn. Some people have heard the term unicorn. We'll talk about it here. But I've served as designer, as front-end, as backing, all across the board development at various points in my career. But I remember starting out with a four-person development team, working in higher education very early in the web, before we had visual designers to design websites. So I remember what the days of not having designers mucked things up was like. And now I've come to love them. So that's what we do. In our play today, I will be playing the designer. I will be playing the development. So at ICS, we believe very much in open communication. We're a small team, so it perhaps makes it easier for us. But we really try to keep everything as transparent and open across departments as possible. We also really believe in collaboration. We believe that, especially across departments, collaboration, that's how we all get to do our best work. So can't we all get along? So why do we put this talk together? So for too long, we feel there's infraction between design and development. We feel this is based on fundamental misunderstandings between the two. Between the two disciplines, how they work and what we're trying to achieve. So there's misconceptions that designers tend to be perceived as artists or worse yet creatives who are only interested in expressing ourselves and creating pixel perfect designs and that we have little to no interest in actually how things get created and how things get built. And on the development side, developers kind of have more of that reputation of maybe being challenging to work with, don't really care about how things look or feel, maybe just want to find the quickest solution, maybe they're kind of stubborn. So the truth is that the truth seems to be somewhere kind of in the middle. And the truth is that we both kind of are after the same thing. So what we like to do is change the dynamic and build relationships based on empathy, understanding and trust. So for a while, there's been an argument that designers need to learn how to code. And this is becoming an increasingly challenging task. So roles are fragmenting. There's no longer just designer or developer. There's front end dev, there's full stack, there's a UI designer, UX developer. It's becoming increasingly challenging for a designer to really, to master those skills. And Cameron Moll, who's CEO of Authentic Jobs, quoted saying the argument that designers must code and excel at both disciplines is becoming an increasingly daunting task. So what we feel is that while designers will benefit from having that basic understanding of code, particularly HTML, CSS, and developers should learn to develop an eye for design, we don't have to master each other's disciplines. We simply need to learn how to understand and respect what each other brings to the table and how this shared collaboration elevates our work beyond what anyone else could do on our own. And so unicorns need not apply. So as Kevin was saying, the unicorn, that's that one person who's magically a full stack dev, a UI UX designer, kind of crushes it on all levels. So maybe you know some, maybe some of you are that person. If so, that's great. But it's a rare occurrence. I have yet to ever meet one in the wild. And it's not really something that you could build your team around. So again, it's not about one person mastering all skills. It's about bringing those skills together to collaborate. So design loves development and vice versa. So design and development are complementary disciplines that support and enhance each other's efforts. And we're all aligned towards the same goals. We want to solve our clients problems. We want to improve our users' experience. And we want to create our best work. And we can't do it alone. Okay? So we both share a love for creative problem solving. So design excels at creating elegant visual solutions to solve our client or user challenges. Development excels at engineering efficient solutions to solve those problems. It's really two halves of the same coin. So if you think about these two, we all know who we're looking at, right? So both tremendously talented. But what would you rather listen to? A Wings album or Beals album? So Paul needed John's sardonic wit to tame his sort of saccharine tendencies. John needed Paul's whimsy and melodic skills to elevate his work together. They're one of the best songwriting teams in the history of modern music. Sure they created some decent stuff on their own, but really when they were together, that's when the magic happens. So communication is key. So how do we start to understand and empathize and collaborate better? So it really starts with communication and the open lines of communication throughout and all stages of a project. So development, first off, development must be at the table throughout discovery, strategy, and planning sessions, particularly when clients are present. Too often project managers, product leaders, maybe creative directors, they go to those meetings and they kind of strategize. Then a whole bunch of decisions are made and then development just sort of gets handed those decisions. So we want to change that. We strive at ICS to not do that. We really want development at the table throughout helping to make those decisions. And we want to get developers out of the basement. So that means if you're not invited to those meetings, talk to your project lead, say, I need to be at that meeting. Have at least a representative from your team go to that meeting because not only is it going to be for that technical perspective, sure, but it's also design is beyond just how the pixels look on the screen. So you're actually designing solutions. You need to look at it from a holistic angle. So bringing development to the table ultimately just leads to better design solutions. So developers need to be reviewing the design and UX artifacts that often designers are creating. So those could be wire frames, site maps, down to design comps. We encourage internal reviews often. So we use tools like Hangouts, Invision, and Slack. Those are great tools that kind of allow, especially when you have remote teams. A lot of us maybe have remote teams. But having that sort of internal review often will sometimes read something two, three times before we even bring it to a first round for the client. And that's not just among the design team, but project management's in on that and development's in on that. And so we're all kind of looking at things together and ensuring that it's the right solution for our client's problem. So when developers are communicating with designers, you want to educate them. Educate us. Don't assume that we know. Don't just say, can't be done. And I've been in that situation. Don't just say that. Explain why. So the designers will then bring that knowledge with them to their next solution. The next solution will be stronger. And it'll just sort of kind of move you along that path. So I'm going to let Kevin jump in on this one. Yeah. So I kind of want to go through a real-world example. We do try to have everybody at the table as much as possible. We want development and design, all communicating, all being part of that same conversation, because we are after the best product for our clients in the end, not even just necessarily the easiest thing for me as a developer to build. So this is a basic wireframe. It looks pretty normal. Nothing too crazy going on there. We've got a logo and some navigation, some text, overlayed over an image. Not too complicated to build. Not too complicated to design either. Excuse me. So this is what it looked like once it was designed. Which again, the designer did a great job. It fits within the specs of the wireframe. There's nothing really moved. There's nothing really crazy. The development team is going to go, hey, wait a minute. I built to that. And now you designed this. And that's an apple. And that's an orange. And now we've got to go and redo work. Really nothing like that going on here. But maybe there is. This is where the handoff might have happened. And now you really still need to have a conversation. Everybody still needs to be talking to each other. As a front end developer, I might get this and I might say to myself, how can I do this as efficiently as possible? So how could I build that as efficiently as possible? Send me a JPEG. That's all I need, right? I've got some text laid over an image. Just send me a JPEG. That's probably the easiest thing to do. I just need that image. Now as a client focused team member, that really sucks. It's easy on the budget. Just have the client send me the image. They're just going to make 20 images and they're going to email them to me. And we'll load them in and the world will go on spinning and everybody will be happy. The problem with that is an image like this requires that the client is going to have to go in and use Photoshop or some other image manipulation tool. It doesn't really take advantage of the technology that we have available to us. So let's dig in. What's really going on here? What is the designer actually doing? And what should I be seeing as a front-end dev looking at that Photoshop file? And I should be noticing that that's a black and white image with this yellow overlay that's using Photoshop's multiply filter. Multiply for probably about 12 of the last 13 years of my life as a developer was like the work of the devil because there was absolutely no way to do that in anything but an Adobe product, right? But now today, can we do that with CSS? Yeah. Yes, we can. We absolutely can. Ah, sort of. There's a sort of thumb sticking out there and it sort of is shocking that even in this day and age, this effect works in everything except for Internet Explorer, even Edge, even the newest version, even Microsoft Edge. You cannot use background blend mode and have it work. Instead of getting this nice overlay with these rich inky blacks coming through and that nice colorization that you want, you'll just get the black and white image. You won't even get any of the color coming through. So where does that leave us? Send me a JPEG. Is that still the right answer? Is that what we're left with now because Internet Explorer, not cursing Microsoft into Microsoft building, but come on. And you know, at that point, you might say, well, all right, now we've really got to find a different solution. Does the budget support that? Maybe, maybe not. Should it? Probably if we're going to build the best that we can for our client. So you know, at that point, it could be easy as a developer to go back and say, well, look, just send me the JPEG. I looked at a solution and it doesn't work somewhere. I've checked off all my boxes. I'm done. No, just send me the JPEG. Or we could actually have a conversation. We could actually talk to each other and say, how can we make this work? Is there some sort of alternate design that we can do for those other browsers that maybe don't support the features that we can take advantage of? And then how do we present that? What's the right technical solution? We could use conditional tags. They're a pain to manage. They're just a pain to work with in a lot of different ways. Or we could use, again, new CSS. And we could use at supports. This is sort of like media queries for features that the browser supports. We could actually write in our CSS files, do you support this feature? And handy as this is to tell if a browser can support this feature, Internet Explorer doesn't even support this feature to check if it supports features. But that's actually OK. In this case, that's more of a benefit because it'll just ignore whatever declaration you have, just like it would ignore a media query or anything else. So you can start to build your normal, every browser code and then progressively enhance, which is sort of what we want to do online. So it allows us to develop for all of the browsers. And when Internet Explorer and Edge catch up, they'll just look great, finally, again. So we work with design. We say, well, what is our alternative? What's our alternative? OK, well, that's not those rich and key blacks we were really looking for. But it gets the intent across. It gets the idea across that it's got this color key to it. You're still seeing the image. It's a solution arrived at through talking it out, through understanding what the roadblocks are, understanding what the technical features allow us to do, and then working around the things that maybe don't necessarily work. Can we make it better? Now that we have that solution in place, now that we're not relying on a static image, can we extend that? You bet. Yes, we can. So now that we've got that color separated from the image itself, the client's just uploading a black and white image, now why don't we say to ourselves, OK, well, why not allow the client to control that color? Suddenly the CMS can do that. Suddenly we can just ask for a color field. And the client can then come back and say, great, I can do whatever I want. This is fantastic. Maybe that's a little bit too much power in the client's hands. Yeah, maybe there's some vocal opposition to that. But then that's OK. We can sort of come back and say, well, we'll keep that color palette within the brand guidelines, things that we've already defined during discovery. So at that point, we're using everybody on the team to really arrive at a solution. And maybe it's just a header, but it's a header now that is really empowering the user to really control that, to really manage their site in the best way that they possibly can. Clients win, we win. That's really kind of how we look at things. When we all communicate together, when the designer communicates the aesthetic intent of what they want things to look like, how they want them to behave, when the front end developers sort of act as that bridge to say, these are the features, this is how we can do that. And the back end developers come in and support that with fields and everything the back end needs to do. That's when we build a successful site. That's when we don't have to ask the client to go and pay the Adobe tax and have to run Photoshop to manage their website. It's why people don't pay to run, try to remember what it was even, the old Adobe Fireworks, not Fireworks. Cold-fusioning. Cold-fusioning. All those proprietary systems that we're trying to break away from. This is just another element of breaking away from those proprietary systems. Now there is a caveat to all this. So talked about a couple of different CSS solutions. Some of them are a little bit newer than others. When you're working with teams, especially when you're working with different teams on different projects, there's a real difference between the technical abilities and the technical skills that you have available to you. And that's why part of conversing, part of communicating with each other is understanding what each member of your team can actually do. That JPEG solution might be the best solution that that developer can offer you. Sadly. They might not know that app supports exist, or that background blend mode exists, or that all of these other things that are going to make the site better for the client. They might not know that those are available to them. So really, go into a project. Don't assume that everybody on the team can do exactly what you've seen on another website or what you've done with another developer. That's really where communication comes in as well as understanding those things. And we talked about it as well. That JPEG solution might be really all the budget can support. Budgets matter. Unfortunately, sometimes they matter. All of this collaboration we're talking about, it really does require more time with people on your team to be at those meetings, to be part of those conversations. And you really got to step back and say, is this worth it? And ultimately, I think it is. Ultimately it's going to help you build a better product at the end. But it does have to be something that you include, whether it's story points or whether it's the actual dollar amount at the end of the day. You've got to build in the ability for those team members to take that time out of their shackles in the basement or their dreamings of better designs. And actually sit down at the table and be part of that conversation. Even after that handoff, even after that wire frame went from A to B and turned into a design, that's really where communication still needs to happen and still needs to be budgeted for. So it's a little bit nontraditional in that way. So we're talking a lot about designers and developers talking. Project managers should be part of that conversation too. So let's talk about some of the tools and where it goes. Cool. Thanks, Kevin. So one thing that we really try to do is break things down into manageable, smaller chunks, especially larger projects. So you might be in a small A Agile, a big A Agile, more of a waterfall shop, maybe some kind of hybrid approach. Regardless of that, you want to try to find ways to break these cycles of design and development down into sprints, whether they're formal sprints or not. So these kind of short focus sprints allow design and dev to collaborate more readily and it fosters this kind of shared responsibility. So that's design and development. Let's sketch out a solution. Let's quickly get that into the browser. Let's test it. Let's validate it. It's not working great. Let's together sit down and just decide on a solution. This is so much better than the typical design, sitting down, headphones on, creating something for two weeks and then saying, here, development, make this. At that point, clients probably already signed off on it. That's the steps you're taking regardless if it's going to work or not. So we feel like those kind of sprints, breaking things down, really kind of fosters that. So don't wait for the cake to be fully baked before you want to take a peek at that recipe. You want to be able to get in there, get into the kitchen and get your hands dirty. So let's look at maybe what we would call the old way of a workflow. So we've got, there's obviously more people that would be on the team, but let's just take for our sake, designer and developer, moving through kind of key stages of a project. So a lot of times, and I've been in this experience through agency life, et cetera, where it's like design is kind of present through those, what we'll call it research and strategy and those kind of three components of design, the UX, the IA and the UI. And then there's sort of this, there's the handoff, okay? And then a big bunch of PSDs, hopefully they're labeled, layered, are dropped into a developer's lap and then that developer has to decipher and figure it out and make it happen. And at this point, again, things have, you know, the designer's going to get in a sandwich and it's all in the developer's lap to decipher and create this. So what we've moved towards is this sort of more commingled workflow. So you'll see we've got design and development, they're at the table throughout all of research and strategy and discovery. And it waxes and wanes. So then we move into design. Clearly, the designer steps up the role there, creates those artifacts, creates the wireframes, et cetera. But development is like on board. They're being kept in the loop, whether, you know, they're reviewing, they're at those meetings, et cetera. They're catching things. You know, and we're, as designers, we're actively bringing it to development and saying, what do you think of this? How does this solution work based on the specs we've laid out, et cetera? Obviously roles kind of flop, flip-flop. We get to development, QA design kind of comes back in and then, you know, so it, but it's this, it's just sort of natural ebb and flow between the two. And it basically just fosters cross-pollinating across this whole process. And that's what we do at our shop and we really feel like it just basically brings better, better results. So we have a more real handoff here. So by the time we've kind of reached the development portion, we've probably already tested a few things out. We've got some prototypes. We know where we're going. So, you know, once development is really hitting the gas and the development stage, there's, there's really no big surprises and that's really what we want to try to eliminate. So prototyping, you might be doing this, but prototyping is a great way. It also encourages design dev to work together, test things out, it's kind of an iterate on them. It's kind of part of that, trying to break things into sprints. Style guides, if you're not using those, are just a great way for design to communicate with development. A lot of times these can be kind of built together. A lot of times design might be working on, you know, maybe they're doing style tiles or they're doing more of a proper design comp. And then what we want to try to do is quickly take that and distill that into the core elements of the UI. We could then bring that to development where we probably move past that wireframe stage. So development can then start to take, you know, the approved wireframes, style guide and start actually assembling things in the browser while design is maybe still working out other content types, other pages, other areas of the site. So if we work in sort of a hybrid waterfall, we're not an agile shop, I've actually seen it referenced as a sashimi waterfall, but it's essentially, it's like if you could imagine layers on top, right? So we still kind of move through those traditional stages, but we try to overlap them as much as possible. So we find that, again, this is sort of a great way. And of course, the style guide is going to ensure consistency across UI elements. And then there's modular systems. If you've heard of Brad Frost's atomic design, it's probably deeper than we can really get into right now, but he kind of uses this like atomic model to break a web product down into like its basic core elements already down to like a, you know, text field or like a button and things like that. So this is just another way that that kind of more, it just fosters a more iterative design process. And then sometimes you need clarification of intent. And I'm going to now pass this back over to Captain. Yeah. Yeah. I mean, sometimes you run all of those processes and I feel like going back to the balance of design and development, I mean, that's almost like 3D. If you want to extrude that and sort of see that they're not happening distinctly, you know, that design doesn't just stop and development just starts, that they're happening in tandem. You know, if you're trying to do atomic designing, you're trying to break things down into smaller sprints or anything like that. Those do foster those types of communication that you need to really understand. And even if you're not, you know, when you get something from a designer, sometimes you look at it, even if it's a well-labeled, well-structured photoshop document illustrator, you know, whatever you work in, Sketch. That doesn't make sense. Sometimes it does. Sometimes it does make sense or sometimes you're assuming things that maybe ought not to be assumed. You just wrapped up a site for you in Kibaya Works and this is kind of what the homepage, part of the homepage ended up looking like. It had this really great, big image as a background, text overlay. And then you open up this nav and it's like this full panel nav and that's great. It's a great way to kind of get into the site where, you know, maybe there isn't as much navigation as there could be. It's a great way to just sort of dive in and give it a little bit more of a polished presentation. So, you know, I get this file and I'm looking at it and it's like, that's great. That's beautiful. All right, I can build that. I know how to build that. I'm going to hit that button there and that's going to open. Everything's going to be wonderful. I say, well, okay, you've got this background here. So it's kind of blurring what's going on there and it's locked into the PSD. There's just this background image that's blurred. Well, what happens on the other pages? Yeah, just use the same background image. So you want to use the actual pages header to provide some consistency there. Is that even possible? We might have video up there. I think that might be my favorite question as a developer. Is that even possible? And you know, looking at that, I thought, I don't know. Anything is possible to pay for it. That's if the budget is... Right. Yeah, if it's a rich budget, then absolutely. We'll say yes to almost anything, but technically that's a really fun exercise. Is that possible? Can you blur a video and have that not kill the client's computer whoever's looking at the site? I wasn't sure how that would actually work. And that's where we build prototypes. Does this work? What's the right solution? How do we figure out if that works or not? And so we tested a bunch of different options outside of the CMS because that's a lot easier to just sort of tool around in. And ultimately, yes, it is possible. So this is what the careers page looks like. It has a full screen video at the top and you can open that navigation. The video actually keeps playing and is blurred in the background and there's really no loss of performance because the browsers have optimized how all this works. Yeah, that was my response too. I tried probably four or five different ways of doing it. I said, well, I'm just going to blur the whole damn body. And it worked. And it didn't kill performance in anything that I could find. Even running Internet Explorer, I think 10 in a virtual machine on my Mac, it didn't even really choke that. I was like, all right, well, this seems production ready. All right, let's roll with it. And I guess the point of that is before acting, make sure you understand what your teammates are trying to do. Come to that conversation. If you're a designer, it's really, really easy to say, well, you know what, I want to move the title over here. And I'm going to move the subtitle over here. That's fantastic. It's really easy to do in Photoshop, right? Just move all those elements around. And then you hand that off to your developer, development team. And one of them looks at it and has a heart attack because they just built everything that was wire framed out and you broke that. And now they've got to go and redo work. So head that off. I talked about budget earlier. You have to budget for these conversations. But if you can get ahead of those things and prevent people from having to redo things, it's probably either break even or net gain on some levels, I think. And for developers too, it's really easy to sit back and say, it's not what was in the wire frame. That's not what was approved in the wire frame. And that's not what I built to. And now you're changing it. You need to go back. It's really easy to do that. It's a really terrible thing to do sometimes. Sometimes budget totally. You can go back and say, oh, the money's not there. We're not doing that. But for the most part, you want to be collaborative with your team members. You want to sit back and say, well, why did you do that? What are you trying to do with that? How can I arrive at a satisfactory development solution to achieve what you're trying to do? The way the web is now, there's so many opportunities for subtle interactivity, for animation, and things that don't necessarily have to be storyboarded and wire framed and specced out that you can do in development to say, what does that hover state look like? What does that transition state look like? Those are the places where we really can collaborate and really just add a little bit more icing onto these products. And being part of those discussions is where that sort of stuff can happen. I think it speaks to how you think of those different project phases. So we'll create wire frames, we try to get approval on those, but I think we allow a certain amount of fluidity to them as well. So we're not going to say, hey, that's not how the wire frame was. We're going to allow those kind of surprises and things that were inspired once we get into development to happen. And I think that also only happens when we're communicating. Yeah. There are definitely opportunities for a wire frame to be handed off, and you can go out and start building custom content types and building your fields and building everything that you need to support that design. But while that's happening and the designers are still working, it's not hard for a designer to come and say, hey, we want to change that. Does that really throw you off? Have you started building that yet? If you have, how much change is that? And really to sort of suss those things out. So with that, let's go make some kick-ass work together. There you go. Boom. There it is. All right. So we can keep this going on as a conversation. I don't want to keep you from learning more about the goat from the god of zoats. Let's try to. No, I think we definitely have time for a little conversation here if people want to ask questions. Yeah. I'll say the biggest thing I tend to run into, and of course my experience is more of that design, does there a thing, hands it off, and then it's all me. Yeah. The biggest problem I see with that is the designers don't think about dynamic content. They put three boxes together that each have two lines, but that's not realistic. In one fixed screen. Yeah. So having that process of having both the designers and developers working together at the same time, does that help that a lot then? It does to a degree. I think there's a certain element of insisting that the designer use either some real world content if it's available. That's the best. And it's usually the one that gets the most pushback because it's going to break that pristine design. But that's usually the best way to go about it, or to use variable length content and make sure that whoever is actually generating the content knows that there's at least some limit to right toward or to have in mind when they're creating that content. But you're right. It's hard when you get that design file and everything is exactly as it should be. And you've got a row of three elements and they're all exactly the same height. Isn't that the worst when it's like a title's in there and then they throw in real content and it's just all over the place now. It's a pumpkin mouth of... It's tricky to try to remember to make sure the designer does that. Sometimes it doesn't, for us, it doesn't get to QA until we realize QA because QA throws everything in there that they can't. And then it breaks. Yeah, I mean, I think having that conversation up front can definitely help them help designers to be a little bit more open to trying those things, knowing that you will face that plate that they're going to hand you sometimes makes them a little more empathetic. But sometimes you just have to insist. This is a library of test content. See how all of that works. And design to those really extreme edge cases to make sure that the design supports them. And hopefully you get the opportunity to see those designs and flag that. And before it's really handed to you for official, it gets signed off on you, then you can challenge that designer. And then hopefully the next time he or she is like, right, I remember it's not always going to be this exact level of content. And then I'm wondering, with that different process of the developer being more integrated at the beginning, you find that takes more time away from the developer from other projects or does it all kind of work out in the end because they're not trying to figure things out later? Yes and no. I mean, I think at a perfect world, Kevin would kind of attend all of our meetings. It's like doesn't always work out that way because maybe you're trying to crush on another deadline. But then at the end of the day, it should kind of come out in the wash, right? So he's got less backtracking he has to do and things like that. Yeah, I think it does come out. I mean, I've noticed that there's definitely a time savings in a lot of cases where I don't have to step back and say, well, you know, you changed this or you handed this off. But maybe that's not as good a solution as doing it another way. The stuff that would have come up earlier and probably would have saved everybody some time. That being said, I can remember being a contractor, being a contract developer coming in. That makes it even more difficult to say I want to be at those upfront meetings if who you're working with maybe doesn't subscribe to that or doesn't see the value in adding those hours to your budget when the budget's already pretty contained and pretty finite. So it's not the easiest thing in the world to do by any stretch of the imagination. But I think I've definitely noticed a difference in projects where I'm part of those conversations and projects where I'm not. And the ones where I am, things tend to go more smoothly. I think even like your ramp up time, right? So because we're small and we have to kind of move between projects a lot. So when you're at present at those meetings or even if you can't be at the meetings, like we'll use Basecamp, so we'll put meeting notes in. So even if you can't be at the meeting, you're probably going back in and just seeing where we are, right? So when it's time for you to really ramp up, you're not going from first gear to fifth. You're already kind of like, so I think it's easier to transition and get up to speed and then if you have to move to something else, it keeps everything kind of moving at a nice pace versus a dead and then, whoa! Also, I think that's really reasonable for certain key things like the developers have to do a wireframe review. There are certain things like that where it's just like, you know it's going to save your time in the ad. So it's a really good review to argue for the developers to spend time doing that. And Chris can speak to that one to me. It doesn't take them a huge amount of time to look at the wireframes and roll their eyes. There's always that question, like where is that thing right there? What is that supposed to be? What does it do? Where is it coming from? We don't have that piece of information on any of the stuff that we've been talking about building, how do we get there? Those are the things that you notice from that side. Right? I was looking at the modified timeline there and looking at the different widths of designer versus developer and wondering, as I look at that, that's a fairly complex resource allocation problem if you're trying to run a company and you've got a certain number of designer assets and developer assets. Do you have any tips or tricks or tools that you use to make sure that you're doing the most efficient job you can of using the people you have, keeping them relatively busy, but still managing to pull off that shift of intensity? Yeah. I mean, Amanda, our project manager, could probably speak better. To that, she manages that better. I mean, I think a big part of it is we meet beginning of every week, Monday morning. I mean, everybody in the shop is around the table and what are you working on? What products do we have for the week? What deadlines do we have for the week? What's on your plate? What's on your plate? And really trying to make sure that there isn't anybody at the start of that week who's feeling like they can't get everything done they need to that week. And that there's somebody at the other end of the table that's going, I'm going to get golf today. This is great. We want to make sure that the balance is there between everybody who's at the table and obviously balance that between developers and designers as their roles are fit to do. I think that's the biggest part of it is as a team, we're always sort of communicating with each other. I'm communicating with our other developer throughout the week. What are you working on today? How are things going? Do you need help with anything? Or vice versa, hey, you got some time. I really need this to spill onto your plate. It's really just an ongoing conversation. I wish I could say that there was a tool out there and I think we've tried some tools that rely on Gantt charts and things like that and they often end up being, you know, you're spending more time managing that than actually getting things done. So I haven't found the magic bullet for that yet. To be honest with you, we use like a Google sheet that kind of shows what everyone's working on. What we try to do, we're actually trying to, high tech guys. One thing we do try to think about is sort of like complexity levels of projects and thinking about, okay, so a designer right now maybe has three or four projects on their plate. One of them is very intensive and that's going to be half their week and the other two are like, because of the phase they're in are much lower intensity. They just might need a few hours throughout the week. So we try to balance that same with you. Like you probably have one primary project that you are just in the weeds on, but you know, there's enough breathing room in your schedule that you can also keep an eye on those other two to three that we also have in the, it becomes just a, you know, plate spinning act, you know, sometimes slips, but yeah, that's kind of how we try to approach that. Yeah, I think a lot of it is being aware that, you know, you're not going to be able to necessarily just have your head in the weeds on one single project, you know, for multiple days, like that's just a rare occurrence, right? Yeah. You know, you're going to have your blocks of time that you know you need to carve out, but you know, it's sort of a habit thing. You've got to, you know, maybe later in the day, that's usually how I do it, three or four. But just to bed for now, I need to go check in on how this project, this project and this project are doing, just so that I'm not a roadblock to those conversations that people aren't waiting for me to answer questions so that everybody else can keep moving. So it's just trying to be empathetic toward other people on the team to not be that one that everybody's going, what's Kevin doing? You know, you know, where's he at? So, yeah. If you have any tips or experiences on different tools for collaboration, not over, you can always be in the same office on Monday morning. That's true. Okay, how do you work, especially with your clients as well as the developers and the designers? What works? Well, I mean, so our office is in Boston. I work out of my home in Maine. So I'm lucky enough and close enough that I can actually drive down on Mondays and be on the team for one day a week and be in person. But the rest of the week is all remote for me. And even though the rest of the team is in the office, we use Slack. Slack is a great tool. I was tremendous. I feel like it really changed our inter-office communication. Yeah, it really, yeah, and I'll admit I was resistant to it at the start. I don't want another communication platform to worry about. You've got email, you've got base camp, you've got Google chat and Instant Messenger, you know, all these other tools we were trying to use. And it's really centralized a lot of that communication out of these, you know, trial and error sort of systems that we were going for. And if there's a history, there's a history. You can go back. We would have had a conversation. I can scroll back and see right that's what we talked about. Yeah. We don't allow our clients into Slack. Some shops do. We don't. That's an internal tool. Yeah. We use base camp, which, you know, isn't perfect, but we've been sort of sticking by it. But you can have your own, you can have different channels in Slack. So you could have a client. You could. We haven't done it. Because I think part of it is I think the concern on my end was I didn't want it to blur the lines of the barriers between, and our clients just suddenly pop in and just. Yeah, we're working through that right now. Yeah. It feels almost like. I've heard stories. Yeah. Yeah. I feel like it's similar to like letting a client text you. Like there's just certain avenues of communication that don't work well, you know, as well as others, I would say. And I think base camp, base camp for the most part is what we use for file sharing and, you know, more email type communications, scheduling. And then we have a piece in Google Hangouts for video chat and. It's okay. It's all right. It's all right. And it's awesome. What is that? I just just did the other day. Yeah. It was good. I had. I feel like I've never used one that I didn't have some sort of. So what about well, Slack gives you audio calls. Slack not 50 video. Not 50 video. No. Yeah. Yeah. Yeah. Yeah. Right. It's a proprietary. It's got a bit of a price tag to it. But when it were, yeah, I mean, when I've used it with other clients, it's like, all right, it's more solid. This works. It works better than some of the other paid solutions out there. I will say that. And then if it come to it, we Skype. You know, we Skype as well. Skype also does give you for freebies Skype does give you the chat. It does. That's what we use. Yeah. Yeah. Yeah. Skype for whatever reason. No money, but low quality. Yeah. Right. Right. Skype is always for me, how to barrier with clients who say, I don't have a Skype account. Yeah. And that's, and they usually they'll come in. Well, yeah, I have a Gmail address. And so the barrier to entry is usually a little bit lower with Hangouts, but, but Skype is fine when we get to use it. We have a couple of dedicated hangouts, really easy to set up a dedicated Hangout with a couple of internal Hangouts. So it'd be like, hey, meet me over in ICS-1. And then we're just, and then with Slack, you can really easily just sort of push that over. And then we can all be kind of in a meeting within a couple of minutes. Yeah. Yeah. Yeah. Yeah. Yeah. I missed like the first two or three minutes. So I didn't quite get. So what you're doing, are you only doing front end development or you also want to like do some other back end? So we, and maybe I'll get tired and feathered for saying this, don't do a lot of clone work in our shop. We actually do a lot of WordPress work in our shop. I tend. We have done a lot of work. We have done a lot of work. We have done a lot of work. We have done a lot of work. Yep. Yeah. We have done a lot of work. And clone is fine. I'm just asking because like when you showed your simplified diagram with the designer and developer, I thought, well, actually the way you describe it, the designers like makes like, they're stuff to Photoshop and then hands it off. That's not how I would see design with the person. Like, or on the other hand, the developer is not a single person in that case. It doesn't mean, for me, a developer could be somebody who knows how to implement all the business logic with the data that I see. Yeah. And that person doesn't need to know anything for like, not more than the basics about CSS. For me, you could also say that could also be the job script of the designer. Like, I don't know, the traditional way is like the designer builds their stuff in Photoshop. You could also say designer is somebody, like, it just depends on what gets handed over. So you could also say, if the designer just hands over a prototype in HTML and CSS because that's what they know. That would also mean the conversation that you described is still just as valid as necessary. Yeah. So I told you, but so yeah. Maybe they mean web developer when they say developer. And when we use the term developer, we tend to mean, yeah. Down a little bit deeper in the process. Yeah. Yeah. And I think, you know, it's a little bit simplified just for the purposes of the talk, but you're absolutely right. I mean, you know, in our shop, there's myself and another developer. I end up doing more of the structure, the code, the foundation, less of the CSS, less of the front end stuff, more of like server management and stuff like that. But I'm still going to be at those conversations because that's my job. But there's some elements there that's more appropriate for our front end developer to know. So it is a little bit simplified just for the purposes of the talk, but you're absolutely right. There are some levels of development that it just doesn't really apply to. Yeah. So I think that's the key with the statement, you know, you need to apply because nobody can know everything. But in that case, it looked like, okay, in this case, the developer would be the unicorn, the developer would need to know the hard core back end stuff, like in my worldview, plus like CSS and all this and the rest. That's right. Which, that kind of blurs a design line, absolutely. There are a lot of designers who would be handing off HTML, CSS. Yeah. Yeah. Can you show the slide again with the designer and developer working together? Yeah. The pumpkin one. The pumpkin dude there. Yeah, that one right there. Yeah. Yeah. So I mean, it's definitely simplified, but. Yeah. There's usually other people involved. We just, for the sake of this, distilled it down to those two roles. Right. Exactly. Exactly. You don't need like journals and fixtures and fairs. Even though they exist. It's true. That's right. That's right. So which one are you? I'm the dog. You're the dog. I would have made that choice. Yeah. Yeah. Absolutely the dog. Yeah. I'll be handed the cat role and I'll be. Who's the cat and who's the dog? I'm apparently the cat. We just decided that. We have, we have, we have. I'm the dog. I'm definitely the dog. I'm a, yeah. I'm a desirer by. Yeah. Origination. I would go with that. Yeah. Awesome. This is great. Thank you. You're very welcome. Thank you. Thank you.
 So, just in sense of introductions, so we're both from Inge Conscious Studios.  I'm, my name's Adam Jezowar.  I'm the creative director and founder of ICS.  I've been building websites for over 12 years.  Started this agency sort of as a solo designer developer.  I've kind of been on both sides of the aisle.  We've now grown into a nine-person team.  And before starting ICS, I was an in-house designer at various startups and agencies  throughout Boston.  So, Kevin, do you want to give it quick?  Yeah, sure.  I feel like half the room knows me.  I'm Kevin Brooks.  I've been a developer for, yeah, about 13 years now.  I feel like I tried to be the unicorn.  Some people have heard the term unicorn.  We'll talk about it here.  But I've served as designer, as front-end, as backing, all across the board development  at various points in my career.  But I remember starting out with a four-person development team, working in higher education  very early in the web, before we had visual designers to design websites.  So I remember what the days of not having designers mucked things up was like.  And now I've come to love them.  So that's what we do.  In our play today, I will be playing the designer.  I will be playing the development.  So at ICS, we believe very much in open communication.  We're a small team, so it perhaps makes it easier for us.  But we really try to keep everything as transparent and open across departments as possible.  We also really believe in collaboration.  We believe that, especially across departments, collaboration, that's how we all get to do  our best work.  So can't we all get along?  So why do we put this talk together?  So for too long, we feel there's infraction between design and development.  We feel this is based on fundamental misunderstandings between the two.  Between the two disciplines, how they work and what we're trying to achieve.  So there's misconceptions that designers tend to be perceived as artists or worse yet creatives  who are only interested in expressing ourselves and creating pixel perfect designs and that  we have little to no interest in actually how things get created and how things get  built.  And on the development side, developers kind of have more of that reputation of maybe  being challenging to work with, don't really care about how things look or feel, maybe  just want to find the quickest solution, maybe they're kind of stubborn.  So the truth is that the truth seems to be somewhere kind of in the middle.  And the truth is that we both kind of are after the same thing.  So what we like to do is change the dynamic and build relationships based on empathy,  understanding and trust.  So for a while, there's been an argument that designers need to learn how to code.  And this is becoming an increasingly challenging task.  So roles are fragmenting.  There's no longer just designer or developer.  There's front end dev, there's full stack, there's a UI designer, UX developer.  It's becoming increasingly challenging for a designer to really, to master those skills.  And Cameron Moll, who's CEO of Authentic Jobs, quoted saying the argument that designers  must code and excel at both disciplines is becoming an increasingly daunting task.  So what we feel is that while designers will benefit from having that basic understanding  of code, particularly HTML, CSS, and developers should learn to develop an eye for design,  we don't have to master each other's disciplines.  We simply need to learn how to understand and respect what each other brings to the table  and how this shared collaboration elevates our work beyond what anyone else could do  on our own.  And so unicorns need not apply.  So as Kevin was saying, the unicorn, that's that one person who's magically a full stack  dev, a UI UX designer, kind of crushes it on all levels.  So maybe you know some, maybe some of you are that person.  If so, that's great.  But it's a rare occurrence.  I have yet to ever meet one in the wild.  And it's not really something that you could build your team around.  So again, it's not about one person mastering all skills.  It's about bringing those skills together to collaborate.  So design loves development and vice versa.  So design and development are complementary disciplines that support and enhance each  other's efforts.  And we're all aligned towards the same goals.  We want to solve our clients problems.  We want to improve our users' experience.  And we want to create our best work.  And we can't do it alone.  Okay?  So we both share a love for creative problem solving.  So design excels at creating elegant visual solutions to solve our client or user challenges.  Development excels at engineering efficient solutions to solve those problems.  It's really two halves of the same coin.  So if you think about these two, we all know who we're looking at, right?  So both tremendously talented.  But what would you rather listen to?  A Wings album or Beals album?  So Paul needed John's sardonic wit to tame his sort of saccharine tendencies.  John needed Paul's whimsy and melodic skills to elevate his work together.  They're one of the best songwriting teams in the history of modern music.  Sure they created some decent stuff on their own, but really when they were together, that's  when the magic happens.  So communication is key.  So how do we start to understand and empathize and collaborate better?  So it really starts with communication and the open lines of communication throughout  and all stages of a project.  So development, first off, development must be at the table throughout discovery, strategy,  and planning sessions, particularly when clients are present.  Too often project managers, product leaders, maybe creative directors, they go to those  meetings and they kind of strategize.  Then a whole bunch of decisions are made and then development just sort of gets handed  those decisions.  So we want to change that.  We strive at ICS to not do that.  We really want development at the table throughout helping to make those decisions.  And we want to get developers out of the basement.  So that means if you're not invited to those meetings, talk to your project lead, say,  I need to be at that meeting.  Have at least a representative from your team go to that meeting because not only is it  going to be for that technical perspective, sure, but it's also design is beyond just  how the pixels look on the screen.  So you're actually designing solutions.  You need to look at it from a holistic angle.  So bringing development to the table ultimately just leads to better design solutions.  So developers need to be reviewing the design and UX artifacts that often designers are  creating.  So those could be wire frames, site maps, down to design comps.  We encourage internal reviews often.  So we use tools like Hangouts, Invision, and Slack.  Those are great tools that kind of allow, especially when you have remote teams.  A lot of us maybe have remote teams.  But having that sort of internal review often will sometimes read something two, three times  before we even bring it to a first round for the client.  And that's not just among the design team, but project management's in on that and development's  in on that.  And so we're all kind of looking at things together and ensuring that it's the right  solution for our client's problem.  So when developers are communicating with designers, you want to educate them.  Educate us.  Don't assume that we know.  Don't just say, can't be done.  And I've been in that situation.  Don't just say that.  Explain why.  So the designers will then bring that knowledge with them to their next solution.  The next solution will be stronger.  And it'll just sort of kind of move you along that path.  So I'm going to let Kevin jump in on this one.  Yeah.  So I kind of want to go through a real-world example.  We do try to have everybody at the table as much as possible.  We want development and design, all communicating, all being part of that same conversation,  because we are after the best product for our clients in the end, not even just necessarily  the easiest thing for me as a developer to build.  So this is a basic wireframe.  It looks pretty normal.  Nothing too crazy going on there.  We've got a logo and some navigation, some text, overlayed over an image.  Not too complicated to build.  Not too complicated to design either.  Excuse me.  So this is what it looked like once it was designed.  Which again, the designer did a great job.  It fits within the specs of the wireframe.  There's nothing really moved.  There's nothing really crazy.  The development team is going to go, hey, wait a minute.  I built to that.  And now you designed this.  And that's an apple.  And that's an orange.  And now we've got to go and redo work.  Really nothing like that going on here.  But maybe there is.  This is where the handoff might have happened.  And now you really still need to have a conversation.  Everybody still needs to be talking to each other.  As a front end developer, I might get this and I might say to myself, how can I do this  as efficiently as possible?  So how could I build that as efficiently as possible?  Send me a JPEG.  That's all I need, right?  I've got some text laid over an image.  Just send me a JPEG.  That's probably the easiest thing to do.  I just need that image.  Now as a client focused team member, that really sucks.  It's easy on the budget.  Just have the client send me the image.  They're just going to make 20 images and they're going to email them to me.  And we'll load them in and the world will go on spinning and everybody will be happy.  The problem with that is an image like this requires that the client is going to have  to go in and use Photoshop or some other image manipulation tool.  It doesn't really take advantage of the technology that we have available to us.  So let's dig in.  What's really going on here?  What is the designer actually doing?  And what should I be seeing as a front-end dev looking at that Photoshop file?  And I should be noticing that that's a black and white image with this yellow overlay that's  using Photoshop's multiply filter.  Multiply for probably about 12 of the last 13 years of my life as a developer was like  the work of the devil because there was absolutely no way to do that in anything but an Adobe  product, right?  But now today, can we do that with CSS?  Yeah.  Yes, we can.  We absolutely can.  Ah, sort of.  There's a sort of thumb sticking out there and it sort of is shocking that even in this  day and age, this effect works in everything except for Internet Explorer, even Edge, even  the newest version, even Microsoft Edge.  You cannot use background blend mode and have it work.  Instead of getting this nice overlay with these rich inky blacks coming through and  that nice colorization that you want, you'll just get the black and white image.  You won't even get any of the color coming through.  So where does that leave us?  Send me a JPEG.  Is that still the right answer?  Is that what we're left with now because Internet Explorer, not cursing Microsoft into Microsoft  building, but come on.  And you know, at that point, you might say, well, all right, now we've really got to find  a different solution.  Does the budget support that?  Maybe, maybe not.  Should it?  Probably if we're going to build the best that we can for our client.  So you know, at that point, it could be easy as a developer to go back and say, well, look,  just send me the JPEG.  I looked at a solution and it doesn't work somewhere.  I've checked off all my boxes.  I'm done.  No, just send me the JPEG.  Or we could actually have a conversation.  We could actually talk to each other and say, how can we make this work?  Is there some sort of alternate design that we can do for those other browsers that maybe  don't support the features that we can take advantage of?  And then how do we present that?  What's the right technical solution?  We could use conditional tags.  They're a pain to manage.  They're just a pain to work with in a lot of different ways.  Or we could use, again, new CSS.  And we could use at supports.  This is sort of like media queries for features that the browser supports.  We could actually write in our CSS files, do you support this feature?  And handy as this is to tell if a browser can support this feature, Internet Explorer  doesn't even support this feature to check if it supports features.  But that's actually OK.  In this case, that's more of a benefit because it'll just ignore whatever declaration you  have, just like it would ignore a media query or anything else.  So you can start to build your normal, every browser code and then progressively enhance,  which is sort of what we want to do online.  So it allows us to develop for all of the browsers.  And when Internet Explorer and Edge catch up, they'll just look great, finally, again.  So we work with design.  We say, well, what is our alternative?  What's our alternative?  OK, well, that's not those rich and key blacks we were really looking for.  But it gets the intent across.  It gets the idea across that it's got this color key to it.  You're still seeing the image.  It's a solution arrived at through talking it out, through understanding what the roadblocks  are, understanding what the technical features allow us to do, and then working around the  things that maybe don't necessarily work.  Can we make it better?  Now that we have that solution in place, now that we're not relying on a static image,  can we extend that?  You bet.  Yes, we can.  So now that we've got that color separated from the image itself, the client's just  uploading a black and white image, now why don't we say to ourselves, OK, well, why  not allow the client to control that color?  Suddenly the CMS can do that.  Suddenly we can just ask for a color field.  And the client can then come back and say, great, I can do whatever I want.  This is fantastic.  Maybe that's a little bit too much power in the client's hands.  Yeah, maybe there's some vocal opposition to that.  But then that's OK.  We can sort of come back and say, well, we'll keep that color palette within the brand guidelines,  things that we've already defined during discovery.  So at that point, we're using everybody on the team to really arrive at a solution.  And maybe it's just a header, but it's a header now that is really empowering the user to  really control that, to really manage their site in the best way that they possibly can.  Clients win, we win.  That's really kind of how we look at things.  When we all communicate together, when the designer communicates the aesthetic intent  of what they want things to look like, how they want them to behave, when the front end  developers sort of act as that bridge to say, these are the features, this is how we can  do that.  And the back end developers come in and support that with fields and everything the back end  needs to do.  That's when we build a successful site.  That's when we don't have to ask the client to go and pay the Adobe tax and have to run  Photoshop to manage their website.  It's why people don't pay to run, try to remember what it was even, the old Adobe Fireworks,  not Fireworks.  Cold-fusioning.  Cold-fusioning.  All those proprietary systems that we're trying to break away from.  This is just another element of breaking away from those proprietary systems.  Now there is a caveat to all this.  So talked about a couple of different CSS solutions.  Some of them are a little bit newer than others.  When you're working with teams, especially when you're working with different teams on  different projects, there's a real difference between the technical abilities and the technical  skills that you have available to you.  And that's why part of conversing, part of communicating with each other is understanding  what each member of your team can actually do.  That JPEG solution might be the best solution that that developer can offer you.  Sadly.  They might not know that app supports exist, or that background blend mode exists, or that  all of these other things that are going to make the site better for the client.  They might not know that those are available to them.  So really, go into a project.  Don't assume that everybody on the team can do exactly what you've seen on another website  or what you've done with another developer.  That's really where communication comes in as well as understanding those things.  And we talked about it as well.  That JPEG solution might be really all the budget can support.  Budgets matter.  Unfortunately, sometimes they matter.  All of this collaboration we're talking about, it really does require more time with people  on your team to be at those meetings, to be part of those conversations.  And you really got to step back and say, is this worth it?  And ultimately, I think it is.  Ultimately it's going to help you build a better product at the end.  But it does have to be something that you include, whether it's story points or whether  it's the actual dollar amount at the end of the day.  You've got to build in the ability for those team members to take that time out of their  shackles in the basement or their dreamings of better designs.  And actually sit down at the table and be part of that conversation.  Even after that handoff, even after that wire frame went from A to B and turned into a design,  that's really where communication still needs to happen and still needs to be budgeted for.  So it's a little bit nontraditional in that way.  So we're talking a lot about designers and developers talking.  Project managers should be part of that conversation too.  So let's talk about some of the tools and where it goes.  Cool.  Thanks, Kevin.  So one thing that we really try to do is break things down into manageable, smaller chunks,  especially larger projects.  So you might be in a small A Agile, a big A Agile, more of a waterfall shop, maybe some  kind of hybrid approach.  Regardless of that, you want to try to find ways to break these cycles of design and development  down into sprints, whether they're formal sprints or not.  So these kind of short focus sprints allow design and dev to collaborate more readily  and it fosters this kind of shared responsibility.  So that's design and development.  Let's sketch out a solution.  Let's quickly get that into the browser.  Let's test it.  Let's validate it.  It's not working great.  Let's together sit down and just decide on a solution.  This is so much better than the typical design, sitting down, headphones on, creating something  for two weeks and then saying, here, development, make this.  At that point, clients probably already signed off on it.  That's the steps you're taking regardless if it's going to work or not.  So we feel like those kind of sprints, breaking things down, really kind of fosters that.  So don't wait for the cake to be fully baked before you want to take a peek at that recipe.  You want to be able to get in there, get into the kitchen and get your hands dirty.  So let's look at maybe what we would call the old way of a workflow.  So we've got, there's obviously more people that would be on the team, but let's just  take for our sake, designer and developer, moving through kind of key stages of a project.  So a lot of times, and I've been in this experience through agency life, et cetera,  where it's like design is kind of present through those, what we'll call it research  and strategy and those kind of three components of design, the UX, the IA and the UI.  And then there's sort of this, there's the handoff, okay?  And then a big bunch of PSDs, hopefully they're labeled, layered, are dropped into a developer's  lap and then that developer has to decipher and figure it out and make it happen.  And at this point, again, things have, you know, the designer's going to get in a sandwich  and it's all in the developer's lap to decipher and create this.  So what we've moved towards is this sort of more commingled workflow.  So you'll see we've got design and development, they're at the table throughout all of research  and strategy and discovery.  And it waxes and wanes.  So then we move into design.  Clearly, the designer steps up the role there, creates those artifacts, creates the wireframes,  et cetera.  But development is like on board.  They're being kept in the loop, whether, you know, they're reviewing, they're at those  meetings, et cetera.  They're catching things.  You know, and we're, as designers, we're actively bringing it to development and saying, what  do you think of this?  How does this solution work based on the specs we've laid out, et cetera?  Obviously roles kind of flop, flip-flop.  We get to development, QA design kind of comes back in and then, you know, so it, but it's  this, it's just sort of natural ebb and flow between the two.  And it basically just fosters cross-pollinating across this whole process.  And that's what we do at our shop and we really feel like it just basically brings better,  better results.  So we have a more real handoff here.  So by the time we've kind of reached the development portion, we've probably already tested a few  things out.  We've got some prototypes.  We know where we're going.  So, you know, once development is really hitting the gas and the development stage, there's,  there's really no big surprises and that's really what we want to try to eliminate.  So prototyping, you might be doing this, but prototyping is a great way.  It also encourages design dev to work together, test things out, it's kind of an iterate on  them.  It's kind of part of that, trying to break things into sprints.  Style guides, if you're not using those, are just a great way for design to communicate  with development.  A lot of times these can be kind of built together.  A lot of times design might be working on, you know, maybe they're doing style tiles  or they're doing more of a proper design comp.  And then what we want to try to do is quickly take that and distill that into the core elements  of the UI.  We could then bring that to development where we probably move past that wireframe stage.  So development can then start to take, you know, the approved wireframes, style guide  and start actually assembling things in the browser while design is maybe still working  out other content types, other pages, other areas of the site.  So if we work in sort of a hybrid waterfall, we're not an agile shop, I've actually seen  it referenced as a sashimi waterfall, but it's essentially, it's like if you could imagine  layers on top, right?  So we still kind of move through those traditional stages, but we try to overlap them as much  as possible.  So we find that, again, this is sort of a great way.  And of course, the style guide is going to ensure consistency across UI elements.  And then there's modular systems.  If you've heard of Brad Frost's atomic design, it's probably deeper than we can really get  into right now, but he kind of uses this like atomic model to break a web product down into  like its basic core elements already down to like a, you know, text field or like a button  and things like that.  So this is just another way that that kind of more, it just fosters a more iterative  design process.  And then sometimes you need clarification of intent.  And I'm going to now pass this back over to Captain.  Yeah.  Yeah.  I mean, sometimes you run all of those processes and I feel like going back to the balance of  design and development, I mean, that's almost like 3D.  If you want to extrude that and sort of see that they're not happening distinctly, you  know, that design doesn't just stop and development just starts, that they're happening in tandem.  You know, if you're trying to do atomic designing, you're trying to break things down into smaller  sprints or anything like that.  Those do foster those types of communication that you need to really understand.  And even if you're not, you know, when you get something from a designer, sometimes you  look at it, even if it's a well-labeled, well-structured photoshop document illustrator, you know,  whatever you work in, Sketch.  That doesn't make sense.  Sometimes it does.  Sometimes it does make sense or sometimes you're assuming things that maybe ought not to be  assumed.  You just wrapped up a site for you in Kibaya Works and this is kind of what the homepage,  part of the homepage ended up looking like.  It had this really great, big image as a background, text overlay.  And then you open up this nav and it's like this full panel nav and that's great.  It's a great way to kind of get into the site where, you know, maybe there isn't as much  navigation as there could be.  It's a great way to just sort of dive in and give it a little bit more of a polished presentation.  So, you know, I get this file and I'm looking at it and it's like, that's great.  That's beautiful.  All right, I can build that.  I know how to build that.  I'm going to hit that button there and that's going to open.  Everything's going to be wonderful.  I say, well, okay, you've got this background here.  So it's kind of blurring what's going on there and it's locked into the PSD.  There's just this background image that's blurred.  Well, what happens on the other pages?  Yeah, just use the same background image.  So you want to use the actual pages header to provide some consistency there.  Is that even possible?  We might have video up there.  I think that might be my favorite question as a developer.  Is that even possible?  And you know, looking at that, I thought, I don't know.  Anything is possible to pay for it.  That's if the budget is...  Right.  Yeah, if it's a rich budget, then absolutely.  We'll say yes to almost anything, but technically that's a really fun exercise.  Is that possible?  Can you blur a video and have that not kill the client's computer whoever's looking at  the site?  I wasn't sure how that would actually work.  And that's where we build prototypes.  Does this work?  What's the right solution?  How do we figure out if that works or not?  And so we tested a bunch of different options outside of the CMS because that's a lot easier  to just sort of tool around in.  And ultimately, yes, it is possible.  So this is what the careers page looks like.  It has a full screen video at the top and you can open that navigation.  The video actually keeps playing and is blurred in the background and there's really no loss  of performance because the browsers have optimized how all this works.  Yeah, that was my response too.  I tried probably four or five different ways of doing it.  I said, well, I'm just going to blur the whole damn body.  And it worked.  And it didn't kill performance in anything that I could find.  Even running Internet Explorer, I think 10 in a virtual machine on my Mac, it didn't  even really choke that.  I was like, all right, well, this seems production ready.  All right, let's roll with it.  And I guess the point of that is before acting, make sure you understand what your teammates  are trying to do.  Come to that conversation.  If you're a designer, it's really, really easy to say, well, you know what, I want to  move the title over here.  And I'm going to move the subtitle over here.  That's fantastic.  It's really easy to do in Photoshop, right?  Just move all those elements around.  And then you hand that off to your developer, development team.  And one of them looks at it and has a heart attack because they just built everything  that was wire framed out and you broke that.  And now they've got to go and redo work.  So head that off.  I talked about budget earlier.  You have to budget for these conversations.  But if you can get ahead of those things and prevent people from having to redo things,  it's probably either break even or net gain on some levels, I think.  And for developers too, it's really easy to sit back and say, it's not what was in the  wire frame.  That's not what was approved in the wire frame.  And that's not what I built to.  And now you're changing it.  You need to go back.  It's really easy to do that.  It's a really terrible thing to do sometimes.  Sometimes budget totally.  You can go back and say, oh, the money's not there.  We're not doing that.  But for the most part, you want to be collaborative with your team members.  You want to sit back and say, well, why did you do that?  What are you trying to do with that?  How can I arrive at a satisfactory development solution to achieve what you're trying to  do?  The way the web is now, there's so many opportunities for subtle interactivity, for animation, and  things that don't necessarily have to be storyboarded and wire framed and specced out  that you can do in development to say, what does that hover state look like?  What does that transition state look like?  Those are the places where we really can collaborate and really just add a little bit more icing  onto these products.  And being part of those discussions is where that sort of stuff can happen.  I think it speaks to how you think of those different project phases.  So we'll create wire frames, we try to get approval on those, but I think we allow a  certain amount of fluidity to them as well.  So we're not going to say, hey, that's not how the wire frame was.  We're going to allow those kind of surprises and things that were inspired once we get  into development to happen.  And I think that also only happens when we're communicating.  Yeah.  There are definitely opportunities for a wire frame to be handed off, and you can go out  and start building custom content types and building your fields and building everything  that you need to support that design.  But while that's happening and the designers are still working, it's not hard for a designer  to come and say, hey, we want to change that.  Does that really throw you off?  Have you started building that yet?  If you have, how much change is that?  And really to sort of suss those things out.  So with that, let's go make some kick-ass work together.  There you go.  Boom.  There it is.  All right.  So we can keep this going on as a conversation.  I don't want to keep you from learning more about the goat from the god of zoats.  Let's try to.  No, I think we definitely have time for a little conversation here if people want to  ask questions.  Yeah.  I'll say the biggest thing I tend to run into, and of course my experience is more of that  design, does there a thing, hands it off, and then it's all me.  Yeah.  The biggest problem I see with that is the designers don't think about dynamic content.  They put three boxes together that each have two lines, but that's not realistic.  In one fixed screen.  Yeah.  So having that process of having both the designers and developers working together  at the same time, does that help that a lot then?  It does to a degree.  I think there's a certain element of insisting that the designer use either some real world  content if it's available.  That's the best.  And it's usually the one that gets the most pushback because it's going to break that  pristine design.  But that's usually the best way to go about it, or to use variable length content and  make sure that whoever is actually generating the content knows that there's at least some  limit to right toward or to have in mind when they're creating that content.  But you're right.  It's hard when you get that design file and everything is exactly as it should be.  And you've got a row of three elements and they're all exactly the same height.  Isn't that the worst when it's like a title's in there and then they throw in real content  and it's just all over the place now.  It's a pumpkin mouth of...  It's tricky to try to remember to make sure the designer does that.  Sometimes it doesn't, for us, it doesn't get to QA until we realize QA because QA throws  everything in there that they can't.  And then it breaks.  Yeah, I mean, I think having that conversation up front can definitely help them help designers  to be a little bit more open to trying those things, knowing that you will face that plate  that they're going to hand you sometimes makes them a little more empathetic.  But sometimes you just have to insist.  This is a library of test content.  See how all of that works.  And design to those really extreme edge cases to make sure that the design supports them.  And hopefully you get the opportunity to see those designs and flag that.  And before it's really handed to you for official, it gets signed off on you, then you can challenge  that designer.  And then hopefully the next time he or she is like, right, I remember it's not always  going to be this exact level of content.  And then I'm wondering, with that different process of the developer being more integrated  at the beginning, you find that takes more time away from the developer from other projects  or does it all kind of work out in the end because they're not trying to figure things  out later?  Yes and no.  I mean, I think at a perfect world, Kevin would kind of attend all of our meetings.  It's like doesn't always work out that way because maybe you're trying to crush on another  deadline.  But then at the end of the day, it should kind of come out in the wash, right?  So he's got less backtracking he has to do and things like that.  Yeah, I think it does come out.  I mean, I've noticed that there's definitely a time savings in a lot of cases where I don't  have to step back and say, well, you know, you changed this or you handed this off.  But maybe that's not as good a solution as doing it another way.  The stuff that would have come up earlier and probably would have saved everybody some  time.  That being said, I can remember being a contractor, being a contract developer coming in.  That makes it even more difficult to say I want to be at those upfront meetings if who  you're working with maybe doesn't subscribe to that or doesn't see the value in adding  those hours to your budget when the budget's already pretty contained and pretty finite.  So it's not the easiest thing in the world to do by any stretch of the imagination.  But I think I've definitely noticed a difference in projects where I'm part of those conversations  and projects where I'm not.  And the ones where I am, things tend to go more smoothly.  I think even like your ramp up time, right?  So because we're small and we have to kind of move between projects a lot.  So when you're at present at those meetings or even if you can't be at the meetings,  like we'll use Basecamp, so we'll put meeting notes in.  So even if you can't be at the meeting, you're probably going back in and just seeing where  we are, right?  So when it's time for you to really ramp up, you're not going from first gear to fifth.  You're already kind of like, so I think it's easier to transition and get up to speed and  then if you have to move to something else, it keeps everything kind of moving at a nice  pace versus a dead and then, whoa!  Also, I think that's really reasonable for certain key things like the developers have  to do a wireframe review.  There are certain things like that where it's just like, you know it's going to save  your time in the ad.  So it's a really good review to argue for the developers to spend time doing that.  And Chris can speak to that one to me.  It doesn't take them a huge amount of time to look at the wireframes and roll their eyes.  There's always that question, like where is that thing right there?  What is that supposed to be?  What does it do?  Where is it coming from?  We don't have that piece of information on any of the stuff that we've been talking about  building, how do we get there?  Those are the things that you notice from that side.  Right?  I was looking at the modified timeline there and looking at the different widths of designer  versus developer and wondering, as I look at that, that's a fairly complex resource allocation  problem if you're trying to run a company and you've got a certain number of designer assets  and developer assets.  Do you have any tips or tricks or tools that you use to make sure that you're doing the  most efficient job you can of using the people you have, keeping them relatively busy, but  still managing to pull off that shift of intensity?  Yeah.  I mean, Amanda, our project manager, could probably speak better.  To that, she manages that better.  I mean, I think a big part of it is we meet beginning of every week, Monday morning.  I mean, everybody in the shop is around the table and what are you working on?  What products do we have for the week?  What deadlines do we have for the week?  What's on your plate?  What's on your plate?  And really trying to make sure that there isn't anybody at the start of that week who's  feeling like they can't get everything done they need to that week.  And that there's somebody at the other end of the table that's going, I'm going to get  golf today.  This is great.  We want to make sure that the balance is there between everybody who's at the table and obviously  balance that between developers and designers as their roles are fit to do.  I think that's the biggest part of it is as a team, we're always sort of communicating  with each other.  I'm communicating with our other developer throughout the week.  What are you working on today?  How are things going?  Do you need help with anything?  Or vice versa, hey, you got some time.  I really need this to spill onto your plate.  It's really just an ongoing conversation.  I wish I could say that there was a tool out there and I think we've tried some tools that  rely on Gantt charts and things like that and they often end up being, you know, you're  spending more time managing that than actually getting things done.  So I haven't found the magic bullet for that yet.  To be honest with you, we use like a Google sheet that kind of shows what everyone's working  on.  What we try to do, we're actually trying to, high tech guys.  One thing we do try to think about is sort of like complexity levels of projects and  thinking about, okay, so a designer right now maybe has three or four projects on their  plate.  One of them is very intensive and that's going to be half their week and the other two are  like, because of the phase they're in are much lower intensity.  They just might need a few hours throughout the week.  So we try to balance that same with you.  Like you probably have one primary project that you are just in the weeds on, but you  know, there's enough breathing room in your schedule that you can also keep an eye on  those other two to three that we also have in the, it becomes just a, you know, plate  spinning act, you know, sometimes slips, but yeah, that's kind of how we try to approach  that.  Yeah, I think a lot of it is being aware that, you know, you're not going to be able to necessarily  just have your head in the weeds on one single project, you know, for multiple days, like  that's just a rare occurrence, right?  Yeah.  You know, you're going to have your blocks of time that you know you need to carve out,  but you know, it's sort of a habit thing.  You've got to, you know, maybe later in the day, that's usually how I do it, three or  four.  But just to bed for now, I need to go check in on how this project, this project and this  project are doing, just so that I'm not a roadblock to those conversations that people  aren't waiting for me to answer questions so that everybody else can keep moving.  So it's just trying to be empathetic toward other people on the team to not be that one  that everybody's going, what's Kevin doing?  You know, you know, where's he at?  So, yeah.  If you have any tips or experiences on different tools for collaboration, not over, you can  always be in the same office on Monday morning.  That's true.  Okay, how do you work, especially with your clients as well as the developers and the  designers?  What works?  Well, I mean, so our office is in Boston.  I work out of my home in Maine.  So I'm lucky enough and close enough that I can actually drive down on Mondays and be  on the team for one day a week and be in person.  But the rest of the week is all remote for me.  And even though the rest of the team is in the office, we use Slack.  Slack is a great tool.  I was tremendous.  I feel like it really changed our inter-office communication.  Yeah, it really, yeah, and I'll admit I was resistant to it at the start.  I don't want another communication platform to worry about.  You've got email, you've got base camp, you've got Google chat and Instant Messenger, you  know, all these other tools we were trying to use.  And it's really centralized a lot of that communication out of these, you know, trial  and error sort of systems that we were going for.  And if there's a history, there's a history.  You can go back.  We would have had a conversation.  I can scroll back and see right that's what we talked about.  Yeah.  We don't allow our clients into Slack.  Some shops do.  We don't.  That's an internal tool.  Yeah.  We use base camp, which, you know, isn't perfect, but we've been sort of sticking by it.  But you can have your own, you can have different channels in Slack.  So you could have a client.  You could.  We haven't done it.  Because I think part of it is I think the concern on my end was I didn't want it to blur the  lines of the barriers between, and our clients just suddenly pop in and just.  Yeah, we're working through that right now.  Yeah.  It feels almost like.  I've heard stories.  Yeah.  Yeah.  I feel like it's similar to like letting a client text you.  Like there's just certain avenues of communication that don't work well, you know, as well as  others, I would say.  And I think base camp, base camp for the most part is what we use for file sharing and,  you know, more email type communications, scheduling.  And then we have a piece in Google Hangouts for video chat and.  It's okay.  It's all right.  It's all right.  And it's awesome.  What is that?  I just just did the other day.  Yeah.  It was good.  I had.  I feel like I've never used one that I didn't have some sort of.  So what about well, Slack gives you audio calls.  Slack not 50 video.  Not 50 video.  No.  Yeah.  Yeah.  Yeah.  Yeah.  Right.  It's a proprietary.  It's got a bit of a price tag to it.  But when it were, yeah, I mean, when I've used it with other clients, it's like, all right,  it's more solid.  This works.  It works better than some of the other paid solutions out there.  I will say that.  And then if it come to it, we Skype.  You know, we Skype as well.  Skype also does give you for freebies Skype does give you the chat.  It does.  That's what we use.  Yeah.  Yeah.  Yeah.  Skype for whatever reason.  No money, but low quality.  Yeah.  Right.  Right.  Skype is always for me, how to barrier with clients who say, I don't have a Skype account.  Yeah.  And that's, and they usually they'll come in.  Well, yeah, I have a Gmail address.  And so the barrier to entry is usually a little bit lower with Hangouts, but, but Skype is  fine when we get to use it.  We have a couple of dedicated hangouts, really easy to set up a dedicated Hangout with a couple  of internal Hangouts.  So it'd be like, hey, meet me over in ICS-1.  And then we're just, and then with Slack, you can really easily just sort of push that  over.  And then we can all be kind of in a meeting within a couple of minutes.  Yeah.  Yeah.  Yeah.  Yeah.  Yeah.  I missed like the first two or three minutes.  So I didn't quite get.  So what you're doing, are you only doing front end development or you also want to like  do some other back end?  So we, and maybe I'll get tired and feathered for saying this, don't do a lot of clone work  in our shop.  We actually do a lot of WordPress work in our shop.  I tend.  We have done a lot of work.  We have done a lot of work.  We have done a lot of work.  We have done a lot of work.  Yep.  Yeah.  We have done a lot of work.  And clone is fine.  I'm just asking because like when you showed your simplified diagram with the designer  and developer, I thought, well, actually the way you describe it, the designers like  makes like, they're stuff to Photoshop and then hands it off.  That's not how I would see design with the person.  Like, or on the other hand, the developer is not a single person in that case.  It doesn't mean, for me, a developer could be somebody who knows how to implement all  the business logic with the data that I see.  Yeah.  And that person doesn't need to know anything for like, not more than the basics about CSS.  For me, you could also say that could also be the job script of the designer.  Like, I don't know, the traditional way is like the designer builds their stuff in Photoshop.  You could also say designer is somebody, like, it just depends on what gets handed over.  So you could also say, if the designer just hands over a prototype in HTML and CSS because  that's what they know.  That would also mean the conversation that you described is still just as valid as necessary.  Yeah.  So I told you, but so yeah.  Maybe they mean web developer when they say developer.  And when we use the term developer, we tend to mean, yeah.  Down a little bit deeper in the process.  Yeah.  Yeah.  And I think, you know, it's a little bit simplified just for the purposes of the talk, but you're  absolutely right.  I mean, you know, in our shop, there's myself and another developer.  I end up doing more of the structure, the code, the foundation, less of the CSS, less of the  front end stuff, more of like server management and stuff like that.  But I'm still going to be at those conversations because that's my job.  But there's some elements there that's more appropriate for our front end developer to  know.  So it is a little bit simplified just for the purposes of the talk, but you're absolutely  right.  There are some levels of development that it just doesn't really apply to.  Yeah.  So I think that's the key with the statement, you know, you need to apply because nobody  can know everything.  But in that case, it looked like, okay, in this case, the developer would be the unicorn,  the developer would need to know the hard core back end stuff, like in my worldview, plus  like CSS and all this and the rest.  That's right.  Which, that kind of blurs a design line, absolutely.  There are a lot of designers who would be handing off HTML, CSS.  Yeah.  Yeah.  Can you show the slide again with the designer and developer working together?  Yeah.  The pumpkin one.  The pumpkin dude there.  Yeah, that one right there.  Yeah.  Yeah.  So I mean, it's definitely simplified, but.  Yeah.  There's usually other people involved.  We just, for the sake of this, distilled it down to those two roles.  Right.  Exactly.  Exactly.  You don't need like journals and fixtures and fairs.  Even though they exist.  It's true.  That's right.  That's right.  So which one are you?  I'm the dog.  You're the dog.  I would have made that choice.  Yeah.  Yeah.  Absolutely the dog.  Yeah.  I'll be handed the cat role and I'll be.  Who's the cat and who's the dog?  I'm apparently the cat.  We just decided that.  We have, we have, we have.  I'm the dog.  I'm definitely the dog.  I'm a, yeah.  I'm a desirer by.  Yeah.  Origination.  I would go with that.  Yeah.  Awesome.  This is great.  Thank you.  You're very welcome.  Thank you.  Thank you.
Day_1__Dogs_and_Cats_Living_Together____Mass_Hyste_ZDXdW1QnpKU_0_71.png Day_1__Dogs_and_Cats_Living_Together____Mass_Hyste_ZDXdW1QnpKU_72_167.png Day_1__Dogs_and_Cats_Living_Together____Mass_Hyste_ZDXdW1QnpKU_168_263.png Day_1__Dogs_and_Cats_Living_Together____Mass_Hyste_ZDXdW1QnpKU_264_2507.png Day_1__Dogs_and_Cats_Living_Together____Mass_Hyste_ZDXdW1QnpKU_2508_3947.png Day_1__Dogs_and_Cats_Living_Together____Mass_Hyste_ZDXdW1QnpKU_3948_4115.png Day_1__Dogs_and_Cats_Living_Together____Mass_Hyste_ZDXdW1QnpKU_4116_4919.png Day_1__Dogs_and_Cats_Living_Together____Mass_Hyste_ZDXdW1QnpKU_4920_5423.png Day_1__Dogs_and_Cats_Living_Together____Mass_Hyste_ZDXdW1QnpKU_5424_6155.png Day_1__Dogs_and_Cats_Living_Together____Mass_Hyste_ZDXdW1QnpKU_6156_6287.png Day_1__Dogs_and_Cats_Living_Together____Mass_Hyste_ZDXdW1QnpKU_6288_6587.png Day_1__Dogs_and_Cats_Living_Together____Mass_Hyste_ZDXdW1QnpKU_6588_6743.png Day_1__Dogs_and_Cats_Living_Together____Mass_Hyste_ZDXdW1QnpKU_6744_7067.png Day_1__Dogs_and_Cats_Living_Together____Mass_Hyste_ZDXdW1QnpKU_7068_7703.png Day_1__Dogs_and_Cats_Living_Together____Mass_Hyste_ZDXdW1QnpKU_7704_7799.png Day_1__Dogs_and_Cats_Living_Together____Mass_Hyste_ZDXdW1QnpKU_7800_8675.png Day_1__Dogs_and_Cats_Living_Together____Mass_Hyste_ZDXdW1QnpKU_8676_9383.png Day_1__Dogs_and_Cats_Living_Together____Mass_Hyste_ZDXdW1QnpKU_9384_10355.png Day_1__Dogs_and_Cats_Living_Together____Mass_Hyste_ZDXdW1QnpKU_10356_10955.png Day_1__Dogs_and_Cats_Living_Together____Mass_Hyste_ZDXdW1QnpKU_10956_12779.png Day_1__Dogs_and_Cats_Living_Together____Mass_Hyste_ZDXdW1QnpKU_12780_12911.png Day_1__Dogs_and_Cats_Living_Together____Mass_Hyste_ZDXdW1QnpKU_12912_12971.png Day_1__Dogs_and_Cats_Living_Together____Mass_Hyste_ZDXdW1QnpKU_12972_13067.png Day_1__Dogs_and_Cats_Living_Together____Mass_Hyste_ZDXdW1QnpKU_13068_13679.png Day_1__Dogs_and_Cats_Living_Together____Mass_Hyste_ZDXdW1QnpKU_13680_13835.png Day_1__Dogs_and_Cats_Living_Together____Mass_Hyste_ZDXdW1QnpKU_13836_14207.png Day_1__Dogs_and_Cats_Living_Together____Mass_Hyste_ZDXdW1QnpKU_14208_14831.png Day_1__Dogs_and_Cats_Living_Together____Mass_Hyste_ZDXdW1QnpKU_14832_14927.png Day_1__Dogs_and_Cats_Living_Together____Mass_Hyste_ZDXdW1QnpKU_14928_15143.png Day_1__Dogs_and_Cats_Living_Together____Mass_Hyste_ZDXdW1QnpKU_15144_15215.png Day_1__Dogs_and_Cats_Living_Together____Mass_Hyste_ZDXdW1QnpKU_15216_15839.png Day_1__Dogs_and_Cats_Living_Together____Mass_Hyste_ZDXdW1QnpKU_15840_16895.png Day_1__Dogs_and_Cats_Living_Together____Mass_Hyste_ZDXdW1QnpKU_16896_18779.png Day_1__Dogs_and_Cats_Living_Together____Mass_Hyste_ZDXdW1QnpKU_18780_19475.png Day_1__Dogs_and_Cats_Living_Together____Mass_Hyste_ZDXdW1QnpKU_19476_19643.png Day_1__Dogs_and_Cats_Living_Together____Mass_Hyste_ZDXdW1QnpKU_19644_19787.png Day_1__Dogs_and_Cats_Living_Together____Mass_Hyste_ZDXdW1QnpKU_19788_20183.png Day_1__Dogs_and_Cats_Living_Together____Mass_Hyste_ZDXdW1QnpKU_20184_21203.png Day_1__Dogs_and_Cats_Living_Together____Mass_Hyste_ZDXdW1QnpKU_21204_22739.png Day_1__Dogs_and_Cats_Living_Together____Mass_Hyste_ZDXdW1QnpKU_22740_24047.png Day_1__Dogs_and_Cats_Living_Together____Mass_Hyste_ZDXdW1QnpKU_24048_24299.png Day_1__Dogs_and_Cats_Living_Together____Mass_Hyste_ZDXdW1QnpKU_24300_24515.png Day_1__Dogs_and_Cats_Living_Together____Mass_Hyste_ZDXdW1QnpKU_24516_24803.png Day_1__Dogs_and_Cats_Living_Together____Mass_Hyste_ZDXdW1QnpKU_24804_25187.png Day_1__Dogs_and_Cats_Living_Together____Mass_Hyste_ZDXdW1QnpKU_25188_25307.png Day_1__Dogs_and_Cats_Living_Together____Mass_Hyste_ZDXdW1QnpKU_25308_25487.png Day_1__Dogs_and_Cats_Living_Together____Mass_Hyste_ZDXdW1QnpKU_25488_25631.png Day_1__Dogs_and_Cats_Living_Together____Mass_Hyste_ZDXdW1QnpKU_25632_25787.png Day_1__Dogs_and_Cats_Living_Together____Mass_Hyste_ZDXdW1QnpKU_25788_27575.png Day_1__Dogs_and_Cats_Living_Together____Mass_Hyste_ZDXdW1QnpKU_27576_28871.png Day_1__Dogs_and_Cats_Living_Together____Mass_Hyste_ZDXdW1QnpKU_28872_30635.png Day_1__Dogs_and_Cats_Living_Together____Mass_Hyste_ZDXdW1QnpKU_30636_30935.png Day_1__Dogs_and_Cats_Living_Together____Mass_Hyste_ZDXdW1QnpKU_30936_32399.png Day_1__Dogs_and_Cats_Living_Together____Mass_Hyste_ZDXdW1QnpKU_32400_32987.png Day_1__Dogs_and_Cats_Living_Together____Mass_Hyste_ZDXdW1QnpKU_32988_33191.png Day_1__Dogs_and_Cats_Living_Together____Mass_Hyste_ZDXdW1QnpKU_33192_35639.png Day_1__Dogs_and_Cats_Living_Together____Mass_Hyste_ZDXdW1QnpKU_35640_36023.png Day_1__Dogs_and_Cats_Living_Together____Mass_Hyste_ZDXdW1QnpKU_36024_37451.png Day_1__Dogs_and_Cats_Living_Together____Mass_Hyste_ZDXdW1QnpKU_37452_37511.png Day_1__Dogs_and_Cats_Living_Together____Mass_Hyste_ZDXdW1QnpKU_37512_37727.png Day_1__Dogs_and_Cats_Living_Together____Mass_Hyste_ZDXdW1QnpKU_37728_37787.png Day_1__Dogs_and_Cats_Living_Together____Mass_Hyste_ZDXdW1QnpKU_37788_38567.png Day_1__Dogs_and_Cats_Living_Together____Mass_Hyste_ZDXdW1QnpKU_38568_42755.png Day_1__Dogs_and_Cats_Living_Together____Mass_Hyste_ZDXdW1QnpKU_42756_42887.png Day_1__Dogs_and_Cats_Living_Together____Mass_Hyste_ZDXdW1QnpKU_42888_43031.png Day_1__Dogs_and_Cats_Living_Together____Mass_Hyste_ZDXdW1QnpKU_43032_66107.png Day_1__Dogs_and_Cats_Living_Together____Mass_Hyste_ZDXdW1QnpKU_66108_66155.png Day_1__Dogs_and_Cats_Living_Together____Mass_Hyste_ZDXdW1QnpKU_66156_66215.png Day_1__Dogs_and_Cats_Living_Together____Mass_Hyste_ZDXdW1QnpKU_66216_67652.png