The struggle is real: A story of overcoming the design/development divide
Have you ever looked at a coded demo of your design built by your development team and found yourself tilting your head to one side or squinting your eyes, wondering, “Do they really think this matches the design we sent them?” Yeah. I have, too.
Because “the struggle is real,” I thought I’d share an encouraging experience my team and I recently had with a new development team we were paired with for a project, and what made it so great.
“One Team” Mentality
Before our project kick-off, we conducted an IBM Design Thinking workshop with the entire team (design, development, offering management, etc.). Because the development and design teams were new to working together, we spent time outlining our expectations and preferences during this workshop for how we wanted to work and communicate with one another.
It was during this discussion that the “one team” motto came about. By “one team,” we meant that though we are “the design team” and “the development team,” we wanted to remember we are on the same team. We agreed together that, in order for us to come up with the best outcomes and meet our deadlines, we had to act as one team.
And so we did and everything was smooth and great all the time.
Not really.
Before I get into how we became “one team,” I feel it is important to keep in mind that all teams who do any sort of good have some friction (nobody ever climbed a smooth mountain, right?). Our team had some trouble early on adjusting to one another’s expectations. For instance, our developers wanted designs from us “right away” so they could start playing with the code. And when we dramatically changed the initial concepts and screens we had given them (to “play with”) because our user research directed us to, they were frustrated with us…and we were frustrated that they were frustrated. Things like that made it a bit of a rocky start. And things like that continued throughout the project.
But even with our differences, we were able to forge ahead and make good stuff without totally begrudging and hating one another (or our lives).
Here’s how…
Frequent Face Time
A big part of operating under this “one team” mentality is that we made the effort to spend weekly face time with our development team (I know, tougher for distributed teams). Each week we went over to their space for our weekly design review, and participated in one of their daily Scrums. Aside from these set meetings, we would often spend one-on-one time with the developer that was working on the piece we designed to answer any questions they had.
By sitting in on our weekly design reviews, they were able to hear about our conversations with users and were given the opportunity to voice their own opinions and questions regarding our designs. They saw that we had thoughtful, research-backed intentions for the user experience, and therefore, took our designs as actual requirements for building the product, not merely suggestions or “just what design came up with to help us get started.” :)
In addition to the obvious benefits of real-time, physically pointing and looking at a screen together, the camaraderie (and inside jokes) that developed over the weeks and months we met together face-to-face helped us to remember we worked with humans with good intentions — not a machine or people who only wanted to frustrate us.
…the camaraderie (and inside jokes) that developed over the weeks and months we met together face-to-face helped us to remember we worked with humans with good intentions — not a machine or people who only wanted to frustrate us.
Understand the Gap
Another cool thing that happened as we sought to work as one team, is that we were able to bridge the gap that often exists in the design hand-off because of our different skill sets and perspectives.
This really came into play once our development team got started on implementing our designs. Early on we saw that they were misinterpreting some of what we provided (this is where the head tilt comes in).
Actually, it was pretty much like the Telephone game, where one person whispers a message into the ear of the person next to them, who then passes it along to the next person and so on until you hear the original message completely warped at the end. The reason the message is warped could be because the messenger didn’t speak clearly, or because the receiver filtered the message by, for example, eliminating certain words they felt were unnecessary.
For us designers, things like leading, the spacial layout of elements on a screen and how elements should transition between states are important parts of the design. We know these things affect the user’s experience and even their ability to use a product, and so we include them intentionally in our designs and do our best to communicate those design elements.
But to many developers, such details are either of little consequence or they simply have not been trained to even notice them. Sometimes those details can even clash with the development framework they’re using or hinder their development objectives. As a result, these details often get lost in translation and left off in the implementation of the design.
Own the Design Throughout
If we were going to have a chance at having our designs implemented, we either needed to send our developers to design school (not likely), figure out a way to communicate all of the elements more clearly, and/or we needed to find a way to own the design (i.e. the message) all the way through the development process. In terms of the Telephone game, this would be like going to each person in the line and double-checking/editing the message as it gets passed along to make sure it remains intact.
Without a doubt, coded prototypes are a highly effective way to pass off designs to developers. Due to various factors that are irrelevant to this post, we didn’t have that luxury.
What we did have, however, was a good relationship with our developers, and some front-end coding ability. After the first meeting where our developers demoed what they built, we asked them how they preferred we provide feedback and “fit-and-finish” UI changes. Their answer was to set me up on their development environment so we could see their progress and submit front-end code changes in real time (rather than having to wait for the end of a sprint and submit a list of changes as defects which would then be buried and forgotten among a mountain of other things on their to-do list). This was huge!
A few things that made this particularly wonderful:
- We could own the design all the way through without having to nag our developers on design details that aren’t important to them but are important to the user experience
- We could further develop good rapport with our developers by helping to bear their burden. Our designs required some major hours building the back-end functionality. By taking on coding some of the front-end interactions right in the product, we could both ensure our design details were preserved AND take some things off their plate so they could meet their tight deadlines. Win-win!
We needed to find a way to own the design (i.e. the message) all the way through the development process.
Reflect
At the end of this project, we had a retrospective meeting with our development team to go over what worked well and what could have worked better. Hearing the developers’ perspective confirmed for us what was helpful for both sides and allowed us to identify the things we want to try to replicate in our future projects.
Sure, we had our hiccups through the process (I remember one two-week long struggle over a scrollbar), but it was so great going through it knowing we weren’t in an “us vs. them” situation. Bottom line, I think the root of all that went well was in doing the things that enabled us to have empathy for one another.
Group hug y’all!
