 My name's Ryan, here to bridge the gap between designers and developers, which I didn't make it to the keynote this morning, but apparently he's already started off the whole bridging theme with PHP and Rails, so I'm not real sure. This guy at the office is not allowed to know about that. So I figured I'd start off and give a little bit of a back story of where I've come from and maybe some of the things that I've been able to experience and observe that kind of led to this idea. It's about seven years ago, I banded together with two business partners to start an agency called Udall. So when it was in its infant form, I was a designer. So it was basically, I was a designer, John was a developer and Mark was a business guy. So we had that trifecta and we went out and thought we were going to do great things and we did. We've grown to be a pretty significantly sized agency now, but through that journey I've gone from being the only designer that we had to spending my days today writing mainly code, front end and back end and all that fun stuff. So through that journey and through working with other designers and developers, some of which were great, some of which who were not so great, I've learned a lot and seen a lot of things. Number one being kind of the rift between designers and developers. There's the fundamental split between the left brain and right brain. Just very curiosity, how many people would consider themselves mainly a designer here? All right, that's when I figured what was going to happen. How many devs? All right, everybody, yeah. So it'd be an unfair fight if I were to like split and be like, all right, we are actually going to do the Braveheart thing. But the idea is that designers are creative and they don't really get what developers do and developers kind of feel the same way. Designers don't really feel the pain of slicing up some comp or meeting some weird expectation or need or desire of a client or even a customer. So as I started thinking about this, it's interesting because it gets reinforced constantly. Even little comics like this that are showing exactly how different a designer and a developer are. But at the core level, they're really the exact same almost. They just have different tendencies. So as I continued to think about this and the divide that exists, I was like, really all we're doing is distracting us from the one thing that we want to do, which is to build great customer experiences. And I know there's probably kind of a mixture, we're obviously, I'm here from the agency perspective because that's what I do every day, but I know some of you are with product development and kind of singular focus, which I envy often. But at the end of the day, we're all focused on building great customer experiences, whether it's for a client or whether it's for kind of the end customer and you need both design and development working together in order to do that. However, we keep putting them in boxes and separating them so much so that as I was talking to Jake this morning about this talk, I was like, you know, there's really kind of that divide winds up silently getting amplified even within our own office. So in our office, as we started to hire creatives and hire developers and even refer to the creative and development department, we slowly found out that everybody kind of exists in these pods. And there is literally a wall between design and development in our office. And you know, we need to kind of figure out how to tear those down in order to do things better. So when we go to talk, when we go to create a great customer experience, you know, how do we do that? Well, it all starts with a kickoff of some kind, in our world it doesn't. In most worlds, you're going to have an initial meeting or something where somebody came up with an idea, they presented it, and they said, yes, let's do that. How do we get that done? I don't know, let's talk to this guy. And ultimately, you've got this kickoff. Everybody leaves the kickoff, they're excited. They have ideas of where they're going to go, what they're going to do. Maybe you've got some action items, a formal plan, or you've got a project manager who's going to take all that stuff. You might even have a defined process of something like this. I literally just googled web development process. And everything looked like this. And then I laughed because I was like, I've shown this to clients before. Not this one, but a branded version of this. And the idea is that there's this planning process where you come up with the project management plan and the timeline and the risk, maybe you're really complicated and you've got risk management and all those sorts of things. And then once we have that figured out, we know exactly when we're going to deploy this thing, and there's definitely not going to be any delays. So we can go straight into design, where we do those wireframes, maybe we'll build some prototype things using something like Envision, like the hotlink sort of prototypes. And then once the designer's done with it, we're going to hand it over to development. Development's going to code it, they're going to hopefully test it. And then we launch it, everybody's excited. We do that final testing. And then there's just maintenance, ongoing, forever. Everything kind of follows this, whether it's an app, whether it's a website, whether it's web application, something like that. The reality is it doesn't work that way. It never works that way. There's always something that pops up. There's always these blurred lines where design and dev specifically, it's just not that clean. You can't hand a flat Photoshop comp off and expect that what gets created is actually going to be something good. So the best way that I can think to talk about that is to look at an example. So I made up an example that reflects or embodies a lot of the things that I've seen happen at our shop a hundred times. So again, following that process, we have a design. Just for the sake of keeping my own thoughts together. We're going to say that we have a designer named Carl. And Carl was tasked with creating a design for a cooking class. Really wants to go with this contemporary simple design, but still have that creative flair, something with a strong CTA. Carl comes up with this design. Super proud of it. You have the design and dev handoff. Joan, our developer, takes over and she says, yeah, this looks fine. I think we can do this. So Carl goes about and in our world Carl moves on to the next project that is on his plate. And Joan goes to work coding this site. Three weeks later, Carl here, the website that you built for that cooking class, it launched. It's up. It's doing pretty good. He's like, oh, cool. I'm going to go check it out, see what it looks like when it's live. So hopefully this works. It did. So Carl goes out to the web and pulls it up in the browser and looks at it. He's like, all right, well, this isn't really what I thought it was going to look like, which is weird, because it looks exactly like the Photoshop comp that we just looked at. So Carl goes over to Joan's office like, hey, what's going on? This looks nothing like I intended it to. It's very flat. It's very boring. There's nothing going on. Why is this? We talked about all these other things that we could do, but at the end of the day, it's just boring. It's kind of flat. But Joan's also pissed, because Joan's like, well, what do you mean? I even gave you this cool rollover effect. Where's my mouse? All right, I lost my mouse. All right, well, you know, there's the button rollover effect and all that kind of stuff, and she doesn't understand why it even fades in and out. Carl didn't put a rollover effect in the PSD. Joan had to infer that and went the extra mile there. So they're both mad. They're both mad, because they feel like Joan feels like she did what she was supposed to do. Carl feels like their work was underrepresented. So that just creates this giant war, and perhaps they're going back and forth, and they're trying to figure out how to fix it or whatever. And at the end of the day, we're just kind of sitting with a little shitty product. And we have to solve that. So how do we solve that? The first step is admitting that there's a problem. That's with everything. And in our world, there's lots of problems. Just looking at the web, I started just writing some down. We have all sorts of problems. We have new things like WebGL that we're not really sure how it all works yet, or what the capabilities are. We have animations. We've got parallax stuff. We've got 3D transforms. We've got design aspects of those and design principles. And then there's also the technical side with limitations, things like Internet Explorer that blows up everything you get there. So these become problems. How does a designer portray that they want you to use some fancy WebGL effect? Or how do they portray using 3D transforms? How do they even know what 3D transforms exist to use? Those are all problems. Second step is figuring out how to work together and overcome those problems. And you have to do it together. So as I was thinking about how do you do that and where can you work together? Because that's kind of a broad brush thing. I stumbled across this graphic, which is something that we use to show how everything goes through. And ultimately, most people are probably following a similar model, because scrum is a cool thing that everybody's excited about now. Where there's some sort of task that you're doing. There's some sort of weekly cycle, or monthly cycle, or hopefully not quarterly, but there's some sort of deployment, and there's a feedback loop of some sort. So I was like, well, we think about this feedback area as getting feedback from the stakeholders. Oftentimes, that's customers, clients, executive, et cetera. We never really think about there as the internal stakeholders. So when we look at this, there's a perfect opportunity here to bring in internal stakeholders through the development lifecycle and through the design lifecycle. And the great thing is we already have a spot where we should be doing it anyways. So it's easy to just kind of connect the dots there. So what's that look like? There's a few keys, I think, to having this successful feedback loop. Number one is entering with a plan. So it starts at the level of planning to have those internal feedback touch points. But then in those, you have to plan for what you're going to do. If you just have a meeting where you're like, all right, we're going to show you the progress, and that's it, Carl, our designer, may not actually know what he's supposed to present as potential problems. He may just show up and say, yeah, it looks fine. And then ultimately get to the end and have the exact same reaction, which I'm sure some of you have experienced, where you've asked for feedback along the way and none was given, and at the end it's still the same situation. So you have to plan for the type of feedback. You have to coach for looking for effects or looking for making sure that you're meeting the design intent that they're looking for, and vice versa. Designers in that feedback process need to solicit feedback from developers to say, we, as people who write code, know a lot of things that affect the customer experience, and ultimately affect the design output that designers just don't know about, perhaps, or exactly how it works. So being in that mindset of providing detailed feedback and direction is important. Second one is asking questions often. I can't count the number of times that through a development process, if I get to the end and think, if I had just asked the designer why we have five different font sizes in this, I could have saved quite a bit of time and code and hassle on my end, because the reality is I get to the end and the designer looks at it and I'm like, why are these slightly different? And we wind up consolidating the one font size anyways, because in Photoshop it's really easy just to tweak that stuff by a pixel or two and not even realize it. The same is true on the design side. There are things that perhaps a designer will try to fit something into a nice neat little box, because they know that somebody likes to use bootstrap for their grid system or something, and it's just kind of not working, I think, about five column layouts, or like five boxes side by side, doesn't work with the standard bootstrap layout, but the reality is if a designer just says, hey, I need five side by side, how can I do that? And you're like, oh yeah, it's fine, just do it, because it's not that much code. So asking questions and keeping that open dialogue between kind of the design and the dev crew is important. And lastly, I think going the extra mile, a little bit cliche I think, but as you're progressing through the project, I think remembering that everybody has the same intent or desired output of a great customer experience, going that extra mile and searching for something or bringing something up later in the process is important, the whole idea, I think the boxes of designers and developers being very different people along with that whole process can often lead to a developer thinking that if something's in the design phase, I don't need to worry about it. In fact, I shouldn't worry about it. The reality is you should. You should go the extra mile and care about it during the design process. The same is true when it's in development. If you move on as a designer to your next project and kind of purge this one from your memory, which ultimately in the example that I gave is exactly what happened. Karl moved on to his next project because he was done with the design piece and it's moved to development and purred the little circles and it's never gonna come back to development or design. And by never checking in, there was never that gentle nudge to say, well, we're kind of off track here. Can we bring it back to center? There actually isn't a third step at all. I tried to think of another step and I was like, really, it's all about working together in kind of those three principles of having a plan, asking questions and going the extra mile for your counterparts that is truly important. And if we do that, we can help to bridge that gap a little bit. So now I'm gonna rewind and think about what could have happened to the exact same project had we done that. So we started off with a great kickoff. Everybody was excited. We created a plan to have a weekly review so that in the three weeks that it took Joan to create the simple page, which would be slightly obnoxious. There were touch points where those two are talking to each other and they're actually looking at how it's all coming together. And so it actually came together a little bit nicer. It looks fundamentally, it looks the same, but we've got this nice little radiating heat effect, which was ultimately something that Carl wanted. They wanted this subtle effects, but you've also got the little perspective shift as the mouse moves around. So it takes something that, these are two very minute little features that the designer as they were looking, perhaps found that, saw somebody else do the mouse perspective thing and were like, that's pretty cool. We could do that with this because it's really simple and it gives some dynamic movement and a little bit nicer feel. But by never checking in, never actually gave, we're able to give Joan the gentle nudge. So now we've taken our little poo and we've polished the poo a little bit. That's tight scope, it still kind of sucks. You know, so at the end of it, as I think about it, designers and developers aren't really all that different. We're all people who have a common goal of building great customer experiences. And we use the tools that we have at our disposal to do that. Designers work in Photoshop and Sketch and developers work in them and a million other code editors. So I think if we understand that and we understand that we can contribute to each other's work heavily, I think we can kind of break down some of the barriers and produce some better work. That's all I got.