Bridging the Gap between designers and developers
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Part Number | 65 | |
| Number of Parts | 89 | |
| Author | ||
| License | CC Attribution - ShareAlike 3.0 Unported: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this | |
| Identifiers | 10.5446/31498 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
RailsConf 201665 / 89
1
2
3
5
7
8
11
12
19
22
28
29
30
31
33
45
47
50
52
53
58
62
67
71
74
76
77
78
79
80
81
84
85
86
88
89
00:00
GoogolProcess (computing)Lattice (order)Projective planeOrder (biology)Line (geometry)Web-DesignerExpected valueGroup actionData managementWeb applicationClient (computing)Software developerPlanningCore dumpRevision controlLevel (video gaming)Mixture modelBuildingRule of inferenceOffice suitePerspective (visual)Mountain passFront and back endsForm (programming)DivisorQuicksortInternet service providerPrototypeCodeTheoryHeegaard splittingNumberWebsiteRight angleSoftware testingGoodness of fitDebuggerProduct (business)Mathematical singularityBitCuboidFigurate numberCompilation albumWeb 2.0CurvatureLogical constantComputer animation
06:51
QuicksortNumberFeedbackCycle (graph theory)Sound effectPoint (geometry)Multiplication signTouch typingTask (computing)Lattice (order)Dot productVideo gameInferenceProduct (business)WebsiteInternetworkingSoftware developerLevel (video gaming)Web 2.0Arithmetic progressionSimilarity (geometry)AreaSocial classTransformation (genetics)PlanningCompilation albumProjective planeCurvatureProcess (computing)Figurate numberCausalityEndliche ModelltheorieWordWeb browserSystem callClient (computing)Metropolitan area networkKey (cryptography)Server (computing)Limit (category theory)DivisorRule of inferenceComputer animation
13:31
Perspective (visual)Bootstrap aggregatingMultiplication signNumberPoint (geometry)Thermal radiationTouch typingStandard deviationSoftware developerShift operatorProjective planeFunction (mathematics)Type theoryBitCodeMountain passDifferent (Kate Ryan album)Open setText editorFeedbackCuboidProcess (computing)Sound effectLattice (order)Computer fontPhysical systemPixelPlanningExistential quantificationCircleTrailCountingDirection (geometry)Phase transitionIntegrated development environmentSemiconductor memoryVapor barrierWeb pageComputer configurationAreaSelf-organizationSpacetimeSet (mathematics)Computer animation
20:12
Computer animation
Transcript: English(auto-generated)
00:15
My name's Ryan, I'm here to bridge the gap between designers and developers.
00:22
Which I did 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. There's a guy at the office that's not allowed to know about that. So, you know, I figured I'd start off and kind of give a little bit of a backstory of kind of where I've come from,
00:42
and maybe some of the things that I've been able to experience and observe that kind of led to this idea. So about seven years ago, I banded together with two business partners to start an agency called Oodle. So when it was in its infant form,
01:02
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 you know, we went out and thought we were gonna do great things, and we did, we've grown to be a pretty significantly sized agency now, but through that journey,
01:22
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 you know, all of that fun stuff. So through that journey, and through working with other designers and developers, some of which who were great,
01:40
some of which who were not so great, you know, I've learned a lot and seen a lot of things. Number one being, you know, kind of the rift between designers and developers. There's like the fundamental split between the left brain and right brain. Just out of curiosity, how many people would consider themselves mainly a designer here?
02:02
All right, that's when I figured what was gonna happen. How many devs? All right, everybody, yeah. So, you know, it'd be an unfair fight if I were to like split and be like, all right, we are actually gonna do the Braveheart thing. But, you know, the idea is that designers are creative
02:21
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, you know, as I started thinking about this, I was like, you know, it's interesting
02:41
because it gets reinforced constantly. Like even little comics like this that, you know, they are showing exactly how different a designer and a developer are. But at the core level, they're really the exact same almost.
03:00
They just have different tendencies. So, you know, as I continue to think about this and, you know, the kind of the divide that exists, I was like, you know, really all we're doing is distracting us from the one thing that we want to do, which is to build great customer experiences.
03:20
And I know there's probably kind of a mixture. You know, we're obviously, I'm here from the agency perspective because that's what I do every day, but, you know, I know some of you are with product development and kind of singular focus, which I envy often. But, you know, 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,
03:41
you know, 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, you know, separating them. So much so that as I was talking to Jake this morning about this talk, and I was like, you know, there's really kind of that divide
04:02
winds up silently getting amplified, even within our own office. So in our office, you know, as we started to hire creatives and hire developers and even refer to the creative and development department, we slowly found out that, you know, everybody kind of exists in these pods and there is literally a wall between
04:21
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 create a great customer experience, you know, how do we do that? Well, it all starts with a kickoff of some kind.
04:42
In our world it doesn't, and 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,
05:01
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.
05:21
And then I laughed because I was like, I've shown this to clients before. Like 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.
05:42
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 hot link sort of prototypes. And then once the designer's done with it,
06:01
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, you do that final testing. And then there's just maintenance, ongoing, forever.
06:20
Everything kind of follows this, whether it's an app, whether it's a website, whether it's a 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,
06:43
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.
07:00
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,
07:21
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 kind of that creative flair, something with a strong CTA.
07:41
So Carl comes up with this design. Super proud of it. You have the design and dev handoff, and Joe, 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
08:01
that is on his plate. And Joe goes to work coding this site. Three weeks later, Carl hears the website that you built for that cooking class. It launched, it's up, it's doing pretty good. He's like, ah, cool. I'm going to go check it out, see what it looks like when it's live.
08:23
So, hopefully this works. Yeah, it did. So Carl goes out to the web and pulls it up in the browser, and looks at it, and kind of is 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
08:41
the Photoshop comp that we just looked at. So Carl goes over to Joan's office, and is like, hey, what's going on? Like, 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
09:01
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 like this cool rollover effect. Where's my mouse? All right, I lost my mouse. All right, well.
09:21
You know, there's the button rollover effect and all that kind of stuff. She doesn't understand why, why would, it even fades in and out. Carl didn't put a rollover effect in the PSD. Joan had to infer that, and kind of went the extra mile there. So they're both mad, they're both mad because
09:42
they feel like Joan feels like she did what she was supposed to do. Carl feels like their work was kind of 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.
10:03
And at the end of the day, we're just kind of sitting with little shitty product. And we have to solve that. So how do we solve that? Well, the first step is admitting that there's a problem, as with everything. And in our world, there's lots of problems.
10:24
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,
10:41
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 give it. So these become problems in how does a designer
11:00
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
11:21
and overcome those problems. And you have to do it together. So 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 kind of show how everything kind of goes through.
11:43
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 tasks 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.
12:02
So I was like, well, you know, we think about this feedback area as getting feedback from the stakeholders. Oftentimes that's like customers, clients, executive, et cetera. We never really think about there as the internal stakeholders.
12:20
So when we look at this, there's a perfect opportunity here to bring in internal stakeholders through the development life cycle and through the design life cycle. 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?
12:41
You know, 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,
13:01
you have to plan for what you're going to do. If you just have a meeting where you're like, 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,
13:22
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
13:40
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, you know, we as people who write code know a lot of things that affect the customer experience and ultimately affect the design output.
14:00
The 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.
14:22
You know, I can't count the number of times that through a development process, if I get to the end and think, you know, if I had just asked the designer like why we have five different font sizes in this, I could have saved quite a bit of time in code and hassle on my end
14:41
because the reality is I get to the end and the designer looks at it and they're like, why are these like slightly different? And we wind up consolidating to one font size anyways because in Photoshop it's really easy just to kind of 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, you know,
15:02
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 like five column layouts or like five boxes side by side. It doesn't work with the standard Bootstrap layout
15:22
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.
15:43
And lastly, I think, you know, going the extra mile. You know, it's a little bit cliche, I think, but you know, as you're progressing through the project, I think remembering that everybody has the same intent or desired output of a great customer experience.
16:03
Going that extra mile and searching for something or bringing something up later in the process is important. You know, 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
16:22
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. You know, if you move on as a designer to your next project and kind of purge this one from your memory,
16:41
which ultimately in the example that I gave is exactly what happened. Carl 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.
17:00
And, you know, 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? And there actually isn't a third step at all. I tried to think of another step and I was like, you know, really it's all about working together and kind of those three principles of having a plan, asking questions,
17:21
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.
17:43
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,
18:02
there were touch points where those two were 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.
18:25
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 the subtle effects, but you've also got the little perspective shift as the mouse moves around.
18:42
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.
19:03
But by never checking in, never actually were 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-skilled, still kinda sucks. But, you know,
19:20
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
19:40
to do that. Designers work in Photoshop and Sketch and developers work in VIM 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 kinda break down some of the barriers
20:01
and produce some better work. That's all I got.
Recommendations
Series of 18 media