[TRANSCRIPT]

0:00:25 - (A): Awesome. Don't make something awesome. Bond. Awesome. Go make something awesome. Bond. Awesome. Go make something awesome. Bond. Awesome. Don't make something awesome.

0:01:08 - (Matt): We are talking about how devs and designers can get along better, work better together. Like some common challenges these two types of folks working together encounter on the regular. Or do you guys have first hand.

0:01:27 - (C): Experience of trying to get things done?

0:01:29 - (Matt): And there's bottlenecks, and it's hard to communicate. What's your guys'experience with that?

0:01:35 - (D): I mean, devs are just the worst, just the absolute worst.

0:01:41 - (Matt): Oh, wait a minute.

0:01:42 - (D): And I say that because they're better than me, and it's the way I make myself feel big and strong. That's an interesting question. I don't know. I'll let Cory, I'll let you start with your wisdom, and then I'll piggyback on them and make myself sound smarter.

0:01:55 - (E): I appreciate that you feel like I have words of wisdom, but I can say from my experience, especially in bigger companies, design and development are often split. And when you're building something in two different places with the same end goal, you have to put them together at some point. And if you're not communicating during that process, it's not going to be a smooth transition to take both of those pieces and put them together.

0:02:18 - (E): So communication is key. I think that's number one.

0:02:21 - (D): Yeah. And there's something interesting that I think the way we typically structure projects, at least on the fawn, awesome side of the fence over here, is that devs and designers, like, we always have a dev and a designer paired together on a project. And I know that when Rob and I do some of the planning for what we're going to be working on, it's actually really helpful because we often approach problems in different ways to challenge each other, where I'll have this great big idea for something and I'll share it with Rob, and he'll be like, that's not possible.

0:02:55 - (D): This might be possible if we do this. What if we had this restriction? How would you do it? And then that actually allows me to apply some constraints, right. Some lines or rails to my thinking. And ultimately, that leads to even, I think, more creative solutions working within a set of boundaries. And what is possible? Can we push our tech in one direction? And he thinks about it, and he either says yes or no. Sometimes he wants to do something in the most straightforward way from a dev's perspective. And I might push back a little bit like, well, yes, but that ultimately is confusing for the customer.

0:03:29 - (D): So let's tweak that here. So it's always a little bit of give and take, ultimately.

0:03:34 - (F): Yeah.

0:03:36 - (Matt): I've always had this picture in my head, and I haven't really sat in on meetings with these two folks, working stuff together, working out things together and collaborating and things. But I imagine the fancy designer guy with his twirly mustache and his pipe and his tweed vest and the developer thin ponytail, and he's wearing, like, a branded polo shirt from the last summit he went to wearing sandals, and they're at it. And the creative guy is like, this is not on brand at all. And the guy's like, can we please just finish the project?

0:04:11 - (Matt): But I'm sure that those are stereotypes.

0:04:13 - (D): I'm sure. I mean, yeah, I'm looking at Corey right now. You don't have a great ponytail you've got going on. Cory's just wearing a nice graphic tee. I've got what actually look like a dad on shirt or something.

0:04:26 - (Matt): Next time you need to grow that Curly mustache and hold your pipe. Got your little.

0:04:32 - (D): Wish?

0:04:33 - (C): Yeah.

0:04:34 - (D): I think what's interesting about faunas in particular is, like, the designer developer relationship has been baked in to its DNA since the very beginning. And with Travis and Dave and what they've said to me, which is funny, is that as they were coming up in the world and learning and coming into things professionally, the roles were actually reversed. Dave, I think, started out as a developer and transitioned into a designer. And Travis was very artistic and started out as a designer and then fell in love with development. And they be on both sides of that, which has helped a lot, I think, in how things tend to run in the relationship there.

0:05:28 - (Matt): Have you had experiences in the past where there's been tension in that work relationship and maybe how it might be different at Fawn.

0:05:37 - (F): Awesome.

0:05:37 - (Matt): And major why? I think why I think that would be part of the reason why is that there is a mutual appreciation on.

0:05:44 - (F): Both sides of the aisle.

0:05:45 - (Matt): Do you guys have experiences there where it's been really hard and then it's, I don't know, something you've had to fight for fallen awesome or, oh, wow, this is refreshing because it's different.

0:05:54 - (D): Designers ask for the impossible a lot more than might be necessary. I have to think back through my career and how relationship ships have happened in the past, but I think really what we try to do, and I am not a developer in any sense of the world, but I know enough to be dangerous. And I think that is actually having at least a little bit of understanding about how the quote unquote other side works. Is helpful.

0:06:21 - (D): We work in technology that I have no clue how it works. I have enough of an understanding, or at least I ask Rob about how it works and get insight into that so that when I am asking for things or we're talking about things, I have enough of a knowledge of that I don't know for it to be easier. And I think the same is true on the other side. So it's not like everyone's always open for questions. We're always open to share.

0:06:44 - (D): Anyone wants to look into our figma files and see how our mockups are going or how the icons are made, we're always open to that. And I think that the same is true on the other side of the fence.

0:06:55 - (E): Do you guys do pair designing? We do pair programming sometimes. But do you guys pair up and design things?

0:07:03 - (D): Mean we'll talk through things and we rebound off of others? Don't? That's a good question. Not in the same way, or at least in my experience. And that's not to say some folks do it, like Brian and Francis might do that occasionally where they get on and work through problems together. I think our pair designing is often more on the discussion side of things and the ideation and coming up with solutions to problems, thinking through it. But when it comes to designing stuff, it's a little different.

0:07:36 - (D): We're still probably maybe, and I guess I'll just speak for myself, a little precious with that and always a little embarrassed with the process about how messy. And I love presenting the finished product because it looks so nice and crisp. But you look back at the process it took to get there, and it is a royal mess.

0:07:54 - (E): I feel the same way about code.

0:07:56 - (D): Yeah, see, exactly. But the difference, I think, is that from a designer perspective, I can look at messy code and clean code, and I usually can't tell the difference.

0:08:10 - (E): And see when you're spending that extra hour just to make sure every curve is just perfect. And I wouldn't notice a difference either. So there's a lot of similarities there.

0:08:19 - (D): Exactly. You're like, you changed what? In that design, that icon is different. How? Well, it's pixel fitted now. It's on the right anyway.

0:08:32 - (Matt): Nerds like a pretty interesting space, like right in the middle of those places. And so I'd imagine you've got a whole lot of experience in both worlds, and you have an amazing solution with shoelace. So what can you say about that relationship? How folks can work better together and then maybe speak a little bit to the solutions that you've put together with.

0:09:12 - (E): Shoelace it's largely dependent on the situation you're in. But I like working on the small team. I like where we can all be on the same page with less effort. I'm really more, probably 70% dev, 30% designer. If maybe I'm being a little nice to myself with the 30 there, but I know enough to get by and I have an eye for good design. Again, it comes back to the communication and be on the same page. I've worked on teams where design to get feedback. To them, it was a process and it had to go through certain channels, and then you don't get a response, usually for a day or two, and that's just slowing down the process.

0:09:48 - (E): It just doesn't make any sense. So to be able to reach out directly with a designer who understands what you're building, what you're doing, has a better appreciation of how that all comes together. I think it's good for developers to maybe not try to become designers, but try to understand and appreciate all the details that go into design and their processes, and vice versa, too. Let the designers try to understand.

0:10:11 - (E): Jory, you mentioned constraints earlier. A lot of times those are technical constraints, not just arbitrary. It's not like we don't want to build things a certain way. It's that there may be a lot of challenges to doing it that way that might not make sense in terms of efficiency or they'll just be completely impossible.

0:10:27 - (D): As we talk through this, obviously more things are coming up. But one thing that I think that is different, that has worked for us well, is literally our split projects. So, like when we are working on a batch of work, we have that pairing of a designer and developer at the very least, and sometimes there's two developers or two designers or whatever, but the very small teams is that they are in the project from the beginning together.

0:10:56 - (D): And so as they are shaping, they are discussing it, they are coming up with solutions to the problems that we're trying to solve as a team and bringing their unique perspectives into that from a designer perspective and from a developer's perspective, so that the finished product is not a surprise to anybody. So they are working together throughout the whole process. And it's frustrating for developers to like, and even for designers to come at something, build a complete solution visually, and then hand it off and have that developed. And the end result there is always going to be worse than if you start using collaboration, because you just don't know. I've been in that situation a number of times where I've come up with a visual design for something that flow, I think, works, and et cetera, et cetera.

0:11:48 - (D): And then the end product, while it works, there's something missing and there's that, I don't know, a little special sauce there that you just can't. Maybe I didn't consider something. I don't know. They're just questions that aren't answered in that process that can get answered if you're working as a team from the get go, which is what we try to do.

0:12:13 - (Matt): Yeah, it seems like it's baked into the way that we work, too, using shape up. There's a lot of different models that work for folks. That seems to work for us pretty well. And then we've got that six week split. Like you said, you're pairing up people together, but then we're trying to deliver something in these slices, which is essentially you're trying to deliver a feature or something like one little chunk at a time to where it's complete.

0:12:41 - (Matt): So when you think in those terms, you have a designer or developer working together to create something and then ship.

0:12:48 - (C): It.

0:12:51 - (Matt): They'Re going to be seeing the process all through along the way, lots of communication, and hopefully you're going to have something where there's unity in what it is you're shipping. Like, yes, we feel good about this. This is our template moving forward, and you can continue to do the next slice. Everybody says buy in and can tweak along the way.

0:13:11 - (D): Yeah, and we treat them. I think that metaphor comes from, if I'm recalling, I think they use like a cake as a metaphor where you think of slices as like a vertical slice. So if you have a big cake in front of you, you are trying to work in a slice of cake from, in that little chunk so that it's edible, you can eat it, you can digest it, you can use it, it tastes good, it works. Versus what could happen the other way where if the design and dev is separate and you work in horizontal slices, you end up with a sheet cake that doesn't have any frosting on it.

0:13:46 - (D): It's less than ideal. And while it may kind of work, it's not a full experience. That's what we try to do, at least, and we are sometimes successful, sometimes less than, always trying to get better. Something that I love about shoelace is that, to me at least, it provides, like, a common ground for both designers and developers to work from. Where there is this core set of components that folks can use, that's a given.

0:14:15 - (D): So you know how technically something's going to work well visually, it's going to work well. And then you can in either direction, add to it or I guess, add to it. I'll say it twice, where a designer can apply styling to it and make a card or a button or something a little bit more visually appealing or to match your brand a little bit better. And on the flip side, like how that technically behaves or how it fits into the overall picture from a developer perspective, it provides you with a common set of tools that both designers and developers can use, which just makes it so valuable and so helpful in that communication in the design process, in the build process.

0:14:55 - (D): Corey, I don't know if Travis ever told you this, but I was at one point doing a very quick mockup of we have this thing at font awesome. We call it the factory, which is where we upload new icons and new icon styles and we can make changes to icons and we can add search terms and stuff. It's kind of like the middleman between once we design an icons and once they actually get into with font awesome proper. And so it's like this little environment that I use to add icons to.

0:15:24 - (D): And when we were in the process of designing that, I needed a quick prototype of some ideas for how it could look and structure and oh, would this work better with a tabbed interface or would this work better with sliders or checkboxes or XYZ? And instead of mocking something up in Figma, I literally just pulled up a code pen and shoelace, and I threw in just a bunch of little components and just was able to move things around and get a very quick visual representation of how I wanted things to look. And I was like, that's interesting.

0:15:56 - (D): Let me swap this out. And just, it was a way for me as a designer to play with something that had some interactivity to it and was a basic structure super helpful. And that's probably not necessarily the way shoelace was always meant to be used, but it was a way that I was able to use it to kind of help and showcase some ideas I was having.

0:16:17 - (E): We never know how people are going to use our projects, so trying to build something that anyone can just pick up and use no matter what their skill set is.

0:16:25 - (C): Right.

0:16:26 - (E): That's why I like the idea. This thing is basically custom elements. They're HTML, you know, basic HTML. You can start plugging things in. If you're not a designer, you don't have to be. You can still have something that looks good, but if you are a designer, you can spend hours customizing and doing whatever you want to your heart's content.

0:16:43 - (C): Yeah, I love that.

0:16:45 - (Matt): At whatever level of skill they're at, like jury said, you can kind of throw paint on a wall and envision something. It's not like you're going to have it fine tuned, but I would imagine in the idea stage, when you're working together with somebody, you can say, I'm thinking sort of like this. You've got your colors dialed in, you've got your basic shapes and the foundation.

0:17:09 - (F): Of what a site might look like.

0:17:11 - (Matt): And you have somewhere to start pretty quickly. Seems like it would be good for morale for people to say like, hey, there's something we can look at here, something we can start with.

0:17:21 - (D): Yeah, absolutely. And that, I think, is the power of a design system is that it helps teams work faster and more cohesively because you have an agreed upon set of elements or interactions or components that are kind of default there and you don't have to reinvent the wheel every time. And so you can be like, well, I can't tell you how many times we have been building things. And in the sketching phase, we have a certain interaction or layout or element that we have just sketched in.

0:17:53 - (D): When I say sketching, I mean like, literally with pencil and paper. And when we get to the next phase of mocking it up, we're like, oh, you know what? We should just use this. We already have this pattern that we use elsewhere. Let's just not. Even though the other one might be more unique and maybe slightly better suited, the benefits of using what we already have far outweigh any extra work or customizability that we'd have to put into it.

0:18:19 - (D): And then that means that you get to focus your energy elsewhere and spend time on newer things or the things that truly need some more mind power.

0:18:47 - (F): In. And it stands out to me is the Brian Chesky talk, the CEO of Airbnb. He had talked about the struggle that it was obviously when Covid hit, it was the perfect storm. Like, they were ready to go public and stuff, and then, bam, Covid hits. But he talked about how it was so important to him to really get involved in design again and really strive to be design first. At that time, it was really interesting to hear him talk about that.

0:19:18 - (F): Like you said, like the silos teams or individuals working independently and maybe they're not communicating well, and then you realize, okay, these things are coming together really well. What stood out to me from his talk is that the benefit of being design first is that you have everybody talking, probably specifically on the creative side, a lot of us have had that experience of shoehorning the creative aspect of a project in the last minute.

0:19:51 - (F): I've had the experience as a writer where a site gets built, and then at some point they say, okay, we're ready for the copy. And I'm like, no, this is not how this works. We need to know what we're going to say, because what we're going to say, of course that's going to inform the design. This all has to go together. Do you have any thoughts on maybe some takeaways from that talk and what he was saying about those silos?

0:20:16 - (C): Yeah, and exactly what you said. That's the exact opposite of the way it should be. And that is something I struggled with a lot, especially in my previous work where I was still working in iconography, but I was in a specialist role, and a lot of that boiled into being shoehorned and brought in at the very end. And a little bit of a coat of paint is the polish phase. Right. And that was always a little bit of miscommunication with design as well, because more on, like, the UI and UX side, because there were decisions that had been made up to that point that maybe involved iconography, but some of that stuff wasn't considered, or there were different constraints they were working with.

0:20:59 - (C): And so some things, like, we get to that final phase, and me coming in and being like this doesn't make sense, and it being kind of a. Well, it's too late now, but being design led is interesting, and it's an interesting way to put it, because in a way, even a lot of engineering and development you are designing, it's being done in its own way. But I think with what a lot of Brian was talking about in that talk at config was more about using design as a rallying point so that everyone could have a shared vision and including them in that.

0:21:36 - (C): So rather than it being something where stuff is handed over the fence or crosses a silo and is translated, I guess one of the famous examples is designing a thing and then giving the red lines or the specs to the engineers and being like, all right, build it now focusing on looking at the entire thing as being a complete thought through experience and using design in that sense, and then figuring out where all the different pieces fit into that and making sure that everyone's communicating along the way.

0:22:10 - (F): Yeah, it's funny, on the podcast when I listen back, we should be careful not to be too self congratulatory, but there are some things say at fawn. Awesome. Where, because Dave and Travis, they have the design side and the tech side.

0:22:29 - (Matt): They really appreciate both.

0:22:30 - (F): And this really is a design driven tech company, basically. So it seems like those type of silos don't really exist in the same way, which is really refreshing. Yeah, you yourself had said that it's refreshing that those issues aren't there. Like, what stood out to you when you joined the team? Like, oh, okay, maybe we can get more done or we can all work together better. Is there anything that stands out?

0:22:57 - (C): Well, size for sure, is a huge asset. With the size of company that we are. You don't know everybody super well, but you're not dealing with hundreds of employees, and there are levels of bureaucracy in between you and people you can talk to to get things accomplished. What better fosters that kind of open relationship? And being able to have a lot of that downtime conversation and especially a lot of the stuff we do with snack activities is a huge thing because that's oftentimes just random pairings of people who are, like, coming to realize, yeah, this is a problem, or this is something that both annoys us, both design development, whatever, DevOps, and just fix it. And so these little groups kind of form around a problem, and we try to fix it in a week or at least make it better.

0:23:46 - (C): And that breaks down a ton of barriers for normal split work with people who already can develop a shared knowledge base, or a shorthand of working together, or a better understanding of people's work styles and preferences, the ways they prefer to think about a problem or ask questions and stew on feedback or all that kind of stuff, that goes a long way, I think, towards really smoothing out a lot of those work and.

0:24:18 - (F): Communication issues naturally, with the way that we do our workflows, with the six week splits and then there are cooldowns, is that it's important to have a little bit of ebb and flow in the way that we work and the timing of how we work. Because if everybody's just always, like, heads down, like trying to ship something all the time, but then you don't let up on the gas, then have some dedicated time for something that you would really like to get to, but you always end up putting off, it seems like those problem issues end up being a five alarm situation at the end of something, and then everybody's like scrambling or whatever.

0:24:56 - (F): But when you have these rhythms that kind of come and go with your work, you can come together. And the great thing, too, is that people can self organize around the fact, like, we like working together and, hey, we got a problem. Let's knock it out. It just seems like those rhythms are really conducive to creating something really rounded and people are really connected and they're working well together.

0:25:29 - (C): Yeah, exactly. And because of the way that those work, rhythms kind of go, if you really enjoy working on this thing, there's a chance that it'll come back again or you could extend it into some more substantial work. But it's also like, I really am not enjoying working on this. It can be like, well, it's only going to last another three weeks and then we could be done, move on to something different.

0:25:50 - (F): How can these groups work better together?

0:25:53 - (C): It's been really cool seeing folks that I know and have talked to a lot, but not about work specifically and seeing them be very available with their time and their patience. For me asking what I think are stupid questions because I don't fully understand some of the dev environment or framework things that they're talking about. Something that I've definitely seen with design and development working together. And this is maybe just the normal thing in life, is not wanting to appear in your eyes stupid by asking questions or showing that kind of gap in knowledge is seen as a weakness. But it's such a great way to not only learn things and gain new skills, but also to let somebody who knows a lot about a thing to share their knowledge and experience with you and open yourself up to that. So being able to have that lack of ego here has been really huge to see of people who are willing to answer very low level questions, very basic stuff. They don't get annoyed, but most of the time they're excited to actually bring someone into the fold, I guess, as kind of be like, oh, you don't know about this? Let me tell you, it's great.

0:27:12 - (F): A lot of this really comes down to cultural stuff, which we talk a lot about on the podcast and in the blog and stuff, is that we can talk about work rhythms and methods and we do shape up, and that works well for us, but the tools are only going to go so far if there's ego and not a good work culture. Good luck.

0:27:38 - (C): Yeah.

0:27:39 - (F): There is really something to be said for working hard at creating a healthy culture where it's safe to ask those stupid questions. I think that definitely goes a long way.

0:27:53 - (C): Absolutely. And.