Originally posted on GregHausheer.com
If you work in software, you’ve definitely experienced this type of conflict before. Whether you’re a designer or engineer, junior or senior, at some point while passing off work between design and dev teams you’ve received the other person’s output and thought:
What the F*ck?
If you’re a designer, the engineer’s work looks nothing like the wireframes you created in Sketch. Sure. It has a header, footer, and content in the middle. Nice work, junior developer! Everything else is wrong. The font family. The font size. The padding and margins. All wrong! It’s not even the same yellow the designer picked...why didn’t the engineer just grab the hex value from the file?
It goes both ways.
Why did the designer break the grid? Where are mobile and tablet views? Why did they pick 12 different font-sizes for such a small app? The yellow they picked isn’t WCAG Accessible either. Am I supposed to just guess a hover state for this button?
If a moment like this hasn’t happened to you, you’re lying. Whether you’re a freelancer or part of a larger team, there’s always tension in the room at these pass-off or final review moments.
No matter how professional or experienced your team is, designers and developers will always butt heads when working together, and it’s often the "other team's" fault.
Designers create something beautiful but not practical. Developer's ask too many questions and over complicate the engineering. These are just a few of the stereotypes both professions face, and it's the most frequent question I’m asked: how to get design and dev teams to work well together.
Here’s how you fix it.
1) Have a shared, written, and highly visible scope of work, and physically refer to it at every check-in.
How many times if you’re a freelancer have you started working on a project without a written Scope of Work or Service Agreement? At my company (Lightmatter) we did this countless of times in our first year of business. Now? Never. We don’t start without signing an agreement and receiving a project deposit, no matter how small of project.
It doesn’t matter if you’re an independent consultant working for a client or a project manager at a product-focused startup leading creative and engineering teams: having a shared, written, and highly visible spec is necessary for great work. Don’t just create and share a Google document, and then refer to it verbally in your meetings. Print it out. Open it up online. And call the other person out if they’re not viewing it while you are during your Sprint meeting.
If it’s not brought up and present at every meeting, scope can drift. My favorite post-mortem exercise with our team is to review every SOW after a client engagement and document which items changed.
For one client in our first year, we were only supposed to create just wireframes, and somehow we ended up building a full app. How did we get manipulated into a situation like that? Watch scope carefully, and document change requests when they happen.
Props to that client for the mind games they played on us.
2) Encourage pairing, early and often.
Engineers love to talk about the benefits of pair programming. In this style of work, two engineers work together to build a feature or solve a problem with their code. One is the “driver” with their fingers on the keyboard while the other is the “navigator,” often responsible for thinking out loud and discussing with the other the best method or approach to solve their problem.
The most effective way to write clean code is to have someone else watch.
Taking this a step further, try having your designers and developers “pair program” when working together. This means the engineers are in the room when designers work on the UX, UI, color theory, animations, transitions, error states, or any other design decision that’s ever made.
Having that voice in the room to (politely) nudge a design decision in a more favorable technical direction can save weeks once development is underway. And when the majority of work is being developed by the engineer, having a designer critique the front-end UI each day will save projects from looking nothing like how they were designed.
Pairing is hard to do. Both sides will argue that working in their own silos will save time. There’s an inertia to meet, but it’s overcoming that feeling that prevents larger mistakes.
3) Compromise.
When a project is near complete, both sides become anxious. The layout may not look exactly as the designers intended. But the engineers complain and ask why the had to style a certain feature for Internet Explorer, despite their pleas to not support that browser. Designers get caught up in “pixel perfection” while engineers work until it looks good enough by their definition of "done".
When this final push happens, the best solution is to require a compromise, where each team receives a limited number of “must-haves".
It’s up to you to decide how many, but it forces teams to prioritize what matters most. For designers, an example could be requiring a custom font, even if it means more styling and testing across different browsers for the engineers. For developers, it might be reducing the media queries from 3 to 2, so as to simplify the amount of code needed to maintain the layout.
Having each team give ground also educates and builds sympathy. Designers learn why engineers agonize over styling for old browsers. Developers realize how much work goes into color theory and layout decisions.
Mild conflict at this phase is good for teams to experience. It builds friendships, trust, and forces each team to be more creative and selective with their final choices.
What if it still doesn’t work?
Regardless of how detailed your specifications may be, how often you pair program, or the compromises you make, the teams you work with still may not get along.
No amount of process, checklists, or check-ins can fix this, and it comes down to replacing people or refocusing them on different projects. But by having a strategy in place like this one, you can surface conflict early in the project rather than waiting until the final pass-off where it may already be too late.
Top comments (0)