So just in sense of introductions, so we're both from Image Conscious Studios. My name is Adam Jezaweiro. 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 a 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.

Yeah, I feel like I tried to be the unicorn. People have heard the term unicorn. We'll talk about it here. I've served as designers, front-end, as back-end, 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. Right, in our play today, I will be playing the designer. Kevin will be playing the developer.

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 did we put this talk together? So for too long, we feel there's been friction between design and development. And we feel this is based on fundamental misunderstandings 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, you know, 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'd 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 Mull, 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 any of us could do on our own. And so unicorns need not apply.

So as Kevin was saying, the unicorn, it's that one person who's magically a full stack dev, 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, 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 client's problems. We want to improve our user's experience, and we want to create our best work.

And we can't do it alone. OK, 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 a Beals album? You know, 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 were 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, having open lines of communication throughout all stages of a project.

So development, first off, development must be at the table throughout discovery, strategy, and planning sessions, and 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, but we really want development at the table throughout, helping to make those decisions. And we want to get developers out of the basement. So, you know, 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, you know,

not only is it going to be for that technical perspective, sure, but it's also, you know, 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 wireframes, site maps, down to design comps. You know, we encourage internal reviews often. So, you know, we use tools like Hangouts and Vision and Slack. Those are great tools that kind of allow this, especially when you have remote teams. A lot of us maybe have remote teams. But having that sort of internal review often, like, we'll sometimes rev something two,

three times before we even bring it to our first round for the client. And that's not just amongst 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.

Okay? 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, explain why. So that'll bring, 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. You know, 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 wire frame, right? It looks pretty normal. Nothing too crazy going on there. We've got a logo and some navigation and some text overlaid over an image, right? 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 wire frame. There's nothing really moved. There's nothing really crazy. The development team's 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. You know, 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. You know, as a front-end developer, I might get this, and I might say to myself, how can I do this as efficiently as possible? How can I build that as efficiently as possible? Send me a JPG.

That's all I need, right? I've got some text laid over an image. Just send me a JPG, right? 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, you know? Just have a 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's 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. Sort of. There's a sore 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? Yeah? Send me a JPG? Is that still the right answer? Is that what we're left with now, because Internet Explorer,

I'm not cursing Microsoft in a 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 JPG. I looked at a solution. It doesn't work somewhere. I've checked off all my boxes. I'm done. No, just send me the JPG. 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? Like, what's the right technical solution? We could use conditional tags. They're a pain to manage, right? 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. So 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 okay. 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'll ask us to develop for all of the browsers.

And when Internet Explorer and Edge catch up, they'll just, you know, they'll look great, finally, again. And so we work with design, and we say, all right, well, what is our alternative? What's our alternative? Okay, well, you know, that's not those rich, inky blacks we were really looking for. But it gets the intent across. It gets the idea across that it's got this, you know, 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, okay, 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. And maybe that's a little bit too much power in the client's hands. Yeah, you know, maybe there's some vocal opposition to that.

But then that's okay. 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 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, I'm trying to remember what it was even,

the old Adobe Fireworks, not Fireworks, Cold Fusion, you know, 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 I've 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 at 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, you know, 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 sort of understanding those things. And, you know, we talked about it as well. You know, 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, you know, their dreamings of better designs, you know, and actually sit down at the table and be part of that conversation.

You know, even after that handoff, even after that wireframe went from A to B and turned into a design, you know, 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 workflows. 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 know, you might be in a kind of small A Agile, big A Agile,

more of a waterfall, shop, maybe some kind of a 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, focused 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. Oh, 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. You know, 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 say for, you know, 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 onboard, they're being kept in the loop, 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, but it's this 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 results. And there's no 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's really hitting the gas in the development stage,

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's 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. So 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 can then bring that to development, where we've probably moved 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's 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's just 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 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 Cal. Yeah, yeah, I mean sometimes throughout all of those processes, and I feel like, you know, 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 design and 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, sometimes it doesn't make sense or sometimes you're assuming things that maybe ought not to be assumed. We just wrapped up a site for Inca Bioworks, and this is kind of what the home page, part of the home page 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 can hit that button there, and that's going to open, and 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 a background image that's blurred. Well, what happens on the other pages? Yeah, just use the same background image. Don't you want to use the actual pages header to provide some consistency there? Is that even possible? We might have video up there, and 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, but I'll pay for it. If the budget is, 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 it's 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. It was like, try the, you know, I tried probably four or five different ways of doing it.

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, you know, before acting,

make sure you understand what your teammates are trying to do. Have that conversation. You know, 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 development team, and one of them looks at it and has a heart attack because they just built everything that was wireframed out, and you broke that, and now they've got to go and redo work. So head that off. You know, I talked about budget earlier, and 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 breakeven or net gain on some levels, I think, and, you know, for developers, too, like, it's really easy to sit back and say, it's not what was in the wireframe. That's not what was approved in the wireframe, and that's not what I built, too,

and now you're changing it, and 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, and 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? You know, 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, you know, storyboarded and wireframed 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 kind of 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, too, to like how you think of those different sort of project phases. So we'll create wireframes.

We try to get approval on those, but I think we allow a certain amount of fluidity to them as well, right? So we're not going to say, hey, that's not how the wireframe was. We're going to allow those kind of like 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. Yeah, there are definitely opportunities for, you know,

a wireframe 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, you know, 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, you know, really to sort of suss those things out. So with that, let's go make some kick-ass work together. Oh, there it is. All right.

So, you know, we can keep this going on as a conversation. I don't want to keep you from learning more about Zope from the god of Zope. Let's try to. No, I think we definitely have time for a little conversation here if people want to ask questions. I'll say the biggest thing I tend to run into, and of course my experience is more of that design does their thing, hands it off, and then it's all me.

Yeah. And the biggest problem I see with that is the designers don't think about dynamic content, and they put three boxes together that each have two lines, but that's not realistic. Right. In one fixed web screen. Right. 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, you know, yeah, right. I mean, but that's usually the best way to go about it, or to use variable length content and make sure that whoever's actually generating the content knows that there's at least some limit to write 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, you know,

exactly as it should be, and, you know, you've got a row of three elements and they're all exactly the same height. Right. 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. That's a pumpkin, pumpkin mouth of. I'm trying to think of a following. It's tricky to try to remember to make sure the designer does that.

You know, sometimes it doesn't, you know, for us it doesn't get to QA until we realize, you know, QA because, you know, the QA throws everything in there that they can't and then it breaks. Yep. Right. Yeah. I mean, I think, you know, having that conversation up front can definitely help them, 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, you know, this is, you know, a library of test content, see how all of that works. And, you know, design to those really, you know, extreme edge cases to make sure that the design supports them.

Yeah, and hopefully you get the opportunity to see those designs and flag that. And before it's really handed to you for official, like it's been signed off on your, 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, you know, with that different process of the developer being more, you know, integrated at the beginning,

do 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? It, you know, yes and no. I mean, I think perfect, 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, you know, 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, you know, maybe that's not

as good a solution as doing it another way. You know, the stuff that would have come up earlier and probably would have saved everybody some time. You know, that being said, I can remember, you know, being a contractor, being a contract developer coming in. You know, 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, you know, the budget's already, you know, 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, you know, 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, you know, when you're present at those meetings or, you know, even if you can't be at the meetings, like we'll use base camp, so we'll put meeting notes in. So even if you can't be at the meeting, you're probably going back and just seeing where we are, right?

So that 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, like it keeps everything kind of moving at a nice pace versus like dead and then, whoa, yeah. Also, I think that it's really reasonable for certain key things like the developers have to do a wireframe review.

I mean, there's certain things like that where it's just like you know it's going to save you time in the end. So it's really easy to argue for the developers to spend time doing that. That's, you know, and Chris can speak to that more than me, you know, it doesn't take them a huge amount of time to look at the wireframes and roll their eyes. But there's always that question, like where does 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 you get there? Those are the things that you notice from that side. I was looking at the sort of modified timeline there and looking at the sort

of different widths of designer versus developer and wondering, as I look at that, that's a fairly complex like resource allocation problem if you're trying to run a company and you've got a certain number of designer assets and developer assets.

How do you, do you have like 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 kind of shift of intensity? Yeah. I mean, Amanda, our project manager, could probably speak better to that.

She's kind of manages, she manages that better. I mean, I think a big part of it is, you know, we meet beginning of every week, Monday morning. And I mean, everybody in the shop is around the table and what are you working on? What projects do we have for the week? What deadlines do we have for the week? You know, 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 on the other end of the table that's going, it's a warm day, I'm going to go golf today. This is great. You know, 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. You know, I'm communicating with our other developer, you know, throughout the week. You know, 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. Yeah, I mean, 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, it's 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, that 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? 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, I'm like, all right, putting this 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. Do you have any tips or experiences on different tools for collaboration? Not over, you can always be in the same office on Monday morning, but. That's true. 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 Austin. 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 part of the team, you know, 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. It changed, I feel like it really changed our interoffice communication. Yeah, it really, yeah, it's, and I'll admit, I was resistant to it at the start. Like, I don't want another communication platform to worry about.

We've got email, we've got Basecamp, we've got, you know, 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 it'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.

We don't allow our clients into Slack. Some shops do. We don't. That's an internal tool. We use Basecamp, 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 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, the barriers between having our clients just suddenly pop in and just Yeah, we're working through that right now. It feels almost like I've heard stories. 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 Basecamp, Basecamp for the most part is what we use for file sharing and, you know, more email type communication, scheduling. And then we end up using Google Hangouts for video chat and It's okay. It's all right.

We use Zoom and it's awesome. What is that? Zoom. I just used it the other day. Yeah, what was that? It was good. I feel like I've never used one that I didn't have some sort of problem. So what about, well, Slack gives you audio calls. Does Slack not give you video? Not video. No. No. Yeah. Yeah, right. It's proprietary.

It's got a bit of a price tag to it, but when it works, yeah, I mean, when I've used it with other clients, it's like, all right, this works. It works better than some of the other paid solutions out there. I will say that. And then if it comes to it, we Skype, we Skype as well. Skype also does give you, for freebies, Skype does give you the chat.

It does. It does. That's what we use. Skype, for whatever reason... For no money, but low quality. Right. Right. Skype has always, for me, had a barrier with clients who say, I don't have a Skype account. Yeah. And usually they'll come in, well, yeah, I have a Gmail address.

So the barrier to entry is usually a little bit lower with Hangouts, but Skype is fine when we get to use it. And we have a couple of dedicated Hangouts. It's really easy to have a dedicated Hangout with a couple of internal Hangouts. So it'd be like, hey, meet me over on ICS1. And then with Slack, you can really easily just sort of push that over, and we can all be kind of in a meeting within a couple of minutes.

Yeah. Yeah. Yeah. I missed the first two or three minutes, so I didn't work quite good. So what you're doing, are you only doing front end development, or do you also work with the server or some other backend? So we, and maybe I'll get tarred and feathered for saying this, don't do a lot of

Plone work in our shop. We actually do a lot of WordPress work in our shop. We have done Plone work. Yeah, we have done Plone work. And Plone is fine. I'm just asking because when you showed your simplified diagram with the designer and developer, I thought, well, actually, the way you describe it, the designer

makes their stuff in Photoshop and then hands it off. That's not how I would see a designer. On the other hand, the developer is not a single person in that case. For me, a developer could be somebody who knows how to implement all the business

logic with the database, et cetera. And that person doesn't need to know anything like the basics about CSS. For me, you could also say that could also be the job scripture of the designer. I don't know. I think the traditional way is the designer builds their stuff in Photoshop.

You could also say designer is somebody, it just depends on what gets handed over. You could also say if the designer just hands over a prototype in HTML and CSS because that's what they know. The conversation that you described is still just as valid as necessary.

I totally agree. Yeah? Do you think they mean web developer when they say developer? And when we use the term developer, we tend to mean? Down a little bit deeper in the process. Yeah, and I think it's a little bit simplified just for the purposes of the talk.

But you're absolutely right. 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 the 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 developers 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. I totally agree with the statement because nobody can know everything. But in that case, it looked like, in this case, the developer would be the root point.

The developer would need to build the hard core backend stuff, like in my world view, plus CSS and all this. That's right. That kind of blurs a design line, absolutely. There are a lot of designers who would be handing off HTML and CSS. Can you show the slide again with the designer and developer working together?

I like that with the pumpkin one. The pumpkin too. Yeah, that one right there. So it's definitely simplified. Yeah, there's usually other people involved. We just, for the sake of this, distilled it down to those two roles.

These are dogs and cats. Dogs and cats, exactly. We don't need like turtles and monsters and fairies. Even though they exist. It's true. So which one are you? I'm a dog. I'm a dog. I would have made that choice. Yeah, absolutely a dog.

I'll be handed the cat role. Who's the cat and who's the dog? I'm apparently the cat. We just decided that. I'm the dog. I'm definitely the dog. I'm a designer by origination. I would go with that. Awesome.

This was great. Thank you. You're very welcome. Thank you.