By Shyam Habarakada
Circa 2011. I was finally getting the schedule to draw the blue assignment bars while dragging the infinite timeline sideways, when I noticed my designer standing behind me, looking at my screen.
I turned around in my chair, my eyes tired from staring at the screen for hours and yet wide open with excitement after just getting past this hurdle.
“It’s working!”
“The gradients and drop-shadows are missing in the assignments.”
“I’m not thinking about gradients right now.”
“When can we see it? The drag handles are missing too!”
“Not right now. I’ll add them later.”
He looked somewhat disappointed. I turned back around, thinking about waiting for new data to load vs. being able to scroll sideways quickly. It wasn’t quite working the way I wanted yet.
The schedule was the heart of 10,000ft, and we both wanted it to look and feel great. But we were not paying attention to what the other person was doing. Instead, we were focusing on what we wanted to see in the product we were designing and building together.
I never bothered asking why he wanted to see the gradient drop shadows that day, as he had on a few previous occasions. Nor did he ask me why I was prioritizing things the way I was.
A typical problem
This type of tension is common when designers and developers are trying to work together on projects. Feeling like the other person didn’t quite see or hear my point of view. Or they didn’t understand what I was asking for. Or worse, feeling like they are wasting my time.
So, we start to complain: My designer is incompetent because she keeps changing the design and seems to have trouble getting to the correct solution quickly. And she’s just wasting my time.
Or: My developers aren’t capable of quickly iterating over a set of ideas. They’re stuck trying to find the one perfect solution. If left on their own, they would build a crappy, unusable product.
Despite being highly critical and one-sided, there is some truth to these points of view. Left to ourselves, it is quite unlikely that we would design, build, and ship a viable product on time.
What is going on?
Designers intentionally try to look at multiple solutions. Comparing. Not locking down on any one idea too soon. Tweaking. More tweaking. Sometimes making big wide turns and going in completely different directions. Trying not to get lost in the small details early on. In their ideal world, developers are there with them at every turn.
Developers often think about quickly finding the best solution they can start building because they’re ultimately held accountable for shipping with quality, on time. Laying the groundwork. Trying to make sure the correct architecture is in place. Thinking about testing and security and performance. Hoping that the designers have thought through all the essential design details in time to start building.
The traditional waterfall model of building software was reasonably compatible with these unique ways designers and developers operate. The process, with a lot of help from product or project managers, kept them from having to deal with each other any more than what was absolutely necessary. It, of course, took a lot longer to find out if things went well. And we’ve convinced ourselves that this waterfall model went wrong more often than not.
Recently, for reasons we won’t go into detail here, highly-collaborative and iterative teams are the expected norm. And effective, ongoing collaboration between designers and developers has become a crucial factor determining the success of any product company.
Early attempts
Early attempts to improve this collaboration focused on tools and asset handoff workflow. A category of tools showed up and promised to allow designers and developers to iterate on the same canvas, seamlessly transferring UI design ideas to final product code. Then came the idea that good designers must know how to write code. A few actually could.
My personal favorite was the concept of a “devigner” — a sort of unicorn-hybrid of a developer-designer. Good idea, but it’s yet to become an established career choice. This is actually a good thing because we want teams made up of highly skilled designers and expert engineers. Not mediocre devigner types.
Ideas for better collaboration
At 10,000ft we aspire to become highly collaborative teams focused on achieving specific shared outcomes. Our feature teams consist primarily of designers, developers, and a project manager.
We apply several principles with effective designer-developer collaboration (among other things) in mind.
- Establish a clear, shared understanding of the high-level goal. At 10,000ft, we call these the desired outcomes. Write them down.
- Don’t expect the developer to take the same approach as the designer would. Or vice versa. Instead, expect that each discipline will approach the shared goals from a different angle, with their unique point of view.
- Plan to spend a lot of dedicated time designing together, side-by-side. The focus of these sessions is taking the outcomes we wrote down and coming up with potential solutions. And iterating until the team feels satisfied with the design.
- Agree on a set of project milestones and define specific decisions and deliverables that are to be made by each milestone.
- Hold [sprint] retrospectives and pay attention to the feedback you’re getting from everyone else. Give honest, respectful feedback.
We are continually designing and improving our process as much as we’re designing improvements to our product. Collaboration is a continuous work in progress and a lot more than a new tool or workflow that you install.
Be aware of your own negative bias
“He didn’t seem very interested in the problems we’re trying to solve. Maybe I’m reacting to a typical engineer behavior?”
“I just need a designer to make this pretty before we ship.”
Comments like these, usually a person critiquing or commenting about a person from another discipline than their own, hint at the negative bias we may have towards people in those other disciplines. Being aware of these biases and working to correct them is another important aspect of effective cross-disciplinary collaboration.
Ask “why?” respectfully, instead of jumping to incorrect and often offensive conclusions. It will go a long way towards building trust and mutual respect. Ingredients essential for effective collaboration.
If you did just one thing…
I recommend focusing on creating a clear, shared understanding of the desired outcomes for your project.
Neither designers or developers should expect to change how they work so the other party will be happier. These jobs require unique ways of thinking, skills, and creativity. Focus on establishing a clear understanding of your shared goals, then figure out how to work towards them in small, manageable increments. Two steps at a time.
Originally published at www.10000ft.com.
