Photo by Francis Luu

How to Work with Engineers

A Cheat Sheet for Designers

Julie Zhuo
Aug 28, 2013 · 7 min read

Once, a long time ago, I was a product manager. Then, I was an engineer. For the past seven years, I’ve been in design. Every single day, I work with people in all of these roles. Every single day, I find new ways to appreciate the responsibilities, challenges, and art behind each of these three pillars of product development. Engineers are the magicians of the crew, who, with a few taps of their fingers, take the plans and the pixels and Voila! A working implementation. As a designer, how do you best keep up with their meme-savvy, self-deprecating, script-loving ways? Keep reading.

Engineers are the translators of ideas into reality.

All this is to say: engineers are the shit.

Which means…

Want to make stuff happen? All you need to do is just convince one or two engineers.

Or, imagine this scenario: some small part of your product irks you. Like really irks you, in an itch-in-an-inconvenient-place kind of way. Something about the design is just plain wrong. What should you do?

A. Bring it up at your next team meeting where it’ll get put on a list to be prioritized by a team that triages those sorts of things so they can assign it to some future engineer after she’s joined and needs a couple ‘practice’ tasks to get through.

B. Be pretty tight with an engineer and walk over to her desk. Ask her to spend 5 minutes fixing the thing. Watch her submit the diff. (Possibly you may need to barter a t-shirt design for her 80s cover band or something, but you are a pro with Illustrator.)

Guess which version gets your thing fixed the fastest?

That said…

Things go easier if the engineer you’re working with appreciates the value of good design.

How do you work with such engineers? Well, you can hire them. Lucky for you if you can, because awesome UI-oriented engineers are in high demand.

Or you can help every engineer you work with develop an appreciation for good design. How? Don’t just throw mocks over the fence—explain what you’re doing. Teach them about your values, and why you think the design you’re proposing is worth building. Help them learn how to tell if their implementation matches the mock exactly. Talk to them about what’s going on in your head when you say something looks bad.

The relationship building matters here. People shift their values and priorities based on conversations with other people. It’s an old-school but effective way to do things. (“Slow Ideas” from the New Yorker is a thoughtful, excellent read about this strategy.)

Plenty of engineers don’t come to the table with an eye for design details, but most care about the user experience and want to make it better. I’m not saying every engineer will enjoy doing detailed UI work, but it always helps to expand on the why of a design.

Because the more excited an engineer is about a design—the more they understand its rationale and see its value—the quicker and better it’ll be implemented.

Save yourself time; understand engineering constraints early.

Don’t go through the heartache of falling in love with a design that’s out of the question because you didn’t understand the technical or time constraints early enough. (And even if it is a design that’s worth going to bat for, your case is going to be much stronger if you do understand the constraints.) The worst thing that can happen is that you spend your time perfecting a design that has no chance of working out. Good designers are scarce enough as is, and there are enough big problems that we don’t need that kind of inefficiency.

So the next time a brilliant idea possesses you but you have a sneaking suspicion that it might be hard to build, don’t wonder. Ask the engineer.

The inverse of this holds as well…

Save the engineers time; help them understand how final the design is at any given stage.

Of course, no engineer writes code that never gets thrown away. It’s part of the job, same as design. Good engineers understand that the product development process is messy, and we don’t always know what’ll work until it’s real. Stuff will get changed. Designs will get redesigned. But setting context on what pieces are still exploratory and what pieces are locked down helps engineers figure out how to architect code that is either faster to write or more flexible to modify later.

The best way to ensure designs are implemented as intended is to work extremely closely with the engineer.

It’s easy to cast blame when the end product is not something that everyone’s proud of. Oh, my mock was great, but the engineer didn’t implement it correctly. That’s poisonous thinking right there. You, the designer, own the product that goes out to users, not the Photoshop mock on your computer. If something wasn’t implemented correctly, why didn’t you do something about it? Why didn’t you ask the engineer to show you the implementation right after she finished it so you guys could go over it in detail? Why didn’t you check in during the building phase to see if she had any questions about the design? Why didn’t you file a task for her to fix the bug after you saw it?

That’s right. Own it.

The quickest way to an engineer’s heart is to be complete with your designs.

Want to be a design hero for engineering? Make sure your design solutions are complete and consider edge cases like:

  1. Internationalization: what does this design look like in another language? Notably German with its layout-threatening long words?
  2. Error states: what happens when network connectivity is lost; databases crash, etc?
  3. User extremes: what does this page look like if the user using this has no information or activity? What about if the user has tons and tons of information or activity?
  4. Transitions: what is the precise way that screen A becomes screen B? Good tools are mighty helpful here, as described in How to Survive in Design (and in a Zombie Apocalypse).

Not only does designing the above cases inspire confidence that you’ve actually thought through everything holistically, but they help engineers plan out how to architect the system, and give proper estimates for how long things will take. Not to mention, complete designs prevent last minute scrambles to put together shoddy blank states because nobody caught them until it was too late to do something better.

So be a good citizen. Make sure your designs are complete. Don’t just design for some idealized use case. Get out of mock-fantasyland. As every engineer knows, what counts at the end of the day is what ships.

This is Part 3 in the series. You can also read about How to Work with Designers and How to Work with PMs.

The Year of the Looking Glass

A collection of essays by Julie Zhuo on design, building…

The Year of the Looking Glass

A collection of essays by Julie Zhuo on design, building products, and observing life.

Julie Zhuo

Written by

Currently: Inspirit. Former Product Design VP @ FB. Author of The Making of a Manager Find me @joulee. I love people, words, and food.

The Year of the Looking Glass

A collection of essays by Julie Zhuo on design, building products, and observing life.