How designers and engineers can play nice (and still run with scissors)
As a designer at engineering-centric companies for the last 10 years or so, I spend a lot of time working with engineers. These collaborations are the most functional and fruitful work relationships I’ve had.
Designers, you can create these kinds of relationships with engineers too — you just need to cut through the personal biases of both designers and engineers to create space for effective partnerships. If you are successful, the benefits far outweigh any of the growing pains and minor adjustments it takes to get there.
I’ve worked in consulting, in academia, and at one of the top engineering companies in the world. I’ve seen design behaviors from many perspectives and worked with many types of designers (from the very technical to conceptual to visual and otherwise).
There are a few consistent patterns of bad designer behavior that undermine our reputation with engineers. I’ve found great success by refining my approach to design in an engineering-centric company, and in the process created long-lasting, trusting, and efficient relationships with engineers where other designers have failed. A good designer can exponentially amplify their work if they have a great engineering partner, but to do that, they need to make a few small adjustments.
Here are my top tips for creating effective design and engineering relationships. My goal is to reduce bias on both sides of the fence, and help designers and engineers form stronger alliances to make better products.
1. Use the tools they use
As a designer joining a new team or starting a new project, the first step to is to ask a simple question: “How do you like to work?” Many designers make the mistake of using tools and processes that they are used to, or that they found success with on previous teams. But things move fast in software and every team is different.
I’ve found I can skip over any painful process mismatch by simply asking the engineering team how they like to work and what tools are already in place. Some teams might like to create a collaborative document to track bugs, or use formal bug tracking software. Some might even be OK living in email, or use an agile process with something like Pivotal Tracker.
The key to a designer’s success is not how pretty their mocks are, but how successful they are at communicating their design so the working product is as close to ideal as possible. A really great designer can adapt to any tools necessary to effectively communicate design — even if it takes a little longer to use a new tool, it pays off in spades down the road by reducing friction with engineering.
2. Participate in the entire engineering cycle
Designers can easily sour their relationship with engineers when they wait until late in the product cycle (right before launch) to become active. For an engineering team working toward launch, it’s frustrating when an outsider swoops in demanding a bunch of detailed changes. (And if you don’t get involved until right before launch, you are effectively an outsider.)
Engineers need designers to participate in the whole life cycle of a product or feature, not just developing the front-end. Designers should be deeply aware of (if not involved in) the hard engineering challenges of setting up basic data structures, storage, retrieval, and UI frameworks. Designers should celebrate and promote every engineering milestone along with the rest of the team — even if it’s a janky half-built prototype using #00C links set in Comic Sans.
Too often I observe my fellow designers rip into the aesthetics or interaction design of an early engineering prototype. When an engineer is met with critical feedback from a designer about issues they haven’t even begun to think about, it doesn’t encourage that engineer to include the designer in future reviews. This is how designers end up begging for massive changes the week before launch, and how we almost never get them.
3. Be specific about what needs improvement
Many designers think they are done when they give a completed, “pixel-perfect” mockup to an engineer. Designers start to get twitchy when a product or feature gets close to launch, and the front-end isn’t looking “to spec.” But instead of responding to the engineer’s latest build with “this doesn’t match my mockup, here’s the mockup again in case you lost it” — be specific!
Designers are trained to catch even the smallest details that most people won’t ever notice. Engineers aren’t purposefully missing the details — it’s just not a priority for them like basic functionality and deploying bug-free code are. It’s the designer’s job to catch these errors and point them out as specifically as possible, because the person you are working with hasn’t been trained to look for those types of details.
File bug reports with screenshots from the live demo and your mockups side-by-side. Annotate the screenshots with detailed descriptions of what needs changing. Show and tell. I often file a bug with annotated “before and after” screenshots and summarize the needed changes as a bulleted list. This way, both visual learners and language learners have the format they need to move quickly and deliberately.
I’ll even go as far as to file interaction design improvements separately from visual design polish because you might have engineers on your team that are stronger in one area or the other — it can be easier to divvy up the work if it’s broken into those categories. Generally, engineers respond very well to lists of improvements that they can methodically move through and check off once complete. It’s a little more work on my part, but I’m more likely to get changes in with this small amount of legwork.
4. Meatspace chats are lovely, but they can’t be tracked
Lots of designers I know would prefer to work out design details in person with a product manager or engineer. This is great, and can help improve team cohesiveness, but the side-effect is that there is no “paper trail.” Unless you are working on a team of two (you and an engineer), everything needs to be documented for the wider team to access and respond to.
So even if you do have a productive in-person chat with your engineer about design improvements, go back to your desk and immediately summarize it in an email or bug report. This gives the entire team a chance to respond, and acts as a record of decisions being made. Any decision that doesn’t come with documented rationale is up for grabs when things get tangled toward the end.
5. Drink a beer with your engineer
Never underestimate the power of socializing with team members. Get to know them, and allow them to get to know you. You can accelerate trust and communication if someone feels you care about them as a person — and not just a set of skills that you rely on to realize a design vision.
Engineers! You didn’t think you’d get off the hook so easily, did you? With all the things that designers can do to make your lives easier, likewise there are a few things you should be doing to create better relationships with designers.
1. Don’t let your first answer be “no”
As a designer, there is nothing more frustrating than to get excited about an idea, start chatting about it with an engineer, and have them shut you down before you even really explain the potential!
I find that lots of engineers (especially ones I haven’t worked with for ages), often respond negatively to design ideas and innovations because they seem like “too much work for something that doesn’t seem important.” Trust me, designers understand that you are working hard to make something minimally viable that doesn’t break if you look at it sideways.
But there is a reason why teams need both design and engineering. It’s our job to make an intuitive, fun and innovative experience that people love to use and want to keep coming back to. Otherwise, all the hard engineering work will be for nothing.
Designers can get carried away with fun or novel ideas, but instead of saying “no” outright, spend a little time trying to understand why your designer is so excited about the idea. Consider talking with her or another engineer about ways to achieve the same effect with less engineering overhead. If your designer thinks you’re an eager and open-minded collaborator, you are more likely to get that icon you need from them at 4am the night before the push.
2. “Fit and finish” is not engineering busywork
Different disciplines consider different things to be extremely important. To a great designer, attention to detail and creating a truly polished experience are paramount. These details matter; they can be hard to articulate but generally affect a user’s subconscious response to a product or feature. Many small detail mistakes can accumulate and lead to a sense that a product isn’t professional or reliable. Conversely, a highly polished app can create a stronger emotional response than one that is flawlessly engineered but has a sloppy user interface.
When a designer asks an engineer to move an icon three pixels to the left, or align two blocks of text on the same baseline, that one change might not seem important — but a collection of these things can really make a difference.
3. Do a gut check with your designer before you launch
If your designer is doing well on the list above, don’t punish her by releasing a feature without giving her a chance to review it — however small you think the changes are. Treat your designer as you would any other team member: Your designer is invested in the success of the product just like the rest of the team.
When you do a gut check with your designer, make sure you actually give her time to respond, suggest changes, and iterate before shipping. Showing the product to a designer just before launch as “FYI only” is as bad as shipping it without running it by your designer at all.
Hopefully my experiences — and the approach I’ve developed — over the last several years will help create stronger alliances between designers and engineers. I believe that this truly leads to much stronger products and better user experiences in the end.
What has worked well for you? Where have you struggled? Share your stories in the comments!
