Engineers for Designers: Working Between Teams

(This is the second in a 4 part series about engineers for designers. This series is based on a talk originally presented as part of Whitespace.)

In the last post, I discussed the personality and role of engineers as a starting point for how designers can best work with engineers. A half-Neo, half-Vizzini mentality paired with coding tasks leads to a unique attitude that can be difficult for non-engineers to relate to. Having gone inside of an engineer’s head, I want to continue by discussing how engineers work with product and design and what their expectations are.

Like last time, I will qualify this by saying that I am targeting this post to software engineers and graphic designers in web applications. Specifically, this post comes from the perspective of startups and other small teams with less structure around the processes discussed.

How Engineers View Design and Product

Bear with this somewhat poor analogy.

Let’s say that a product and ecosystem is an apartment building. The end user is in the loft at the top of the building. Engineers are on the ground floor. Unfortunately, this particular apartment building has poor plumbing, so when someone takes a shower, water leaks. Product and design reside on some middle floors. The question for those teams is, “Are you plugging leaks, or are you take a leisurely shower yourself?”

For the most part, end users are just creating work for engineers. Users want different behavior, or they think they found a bug, or a feature isn’t fast enough. It can be annoying to deal with ignorance, but all feedback is valid. An application should work for its users, and there are no brownie points for building a beautiful application that no one uses.

Even so, tension often develops between customer needs and engineering architecture: customers want things that engineers don’t want to do. And since most customer feedback comes through product and design, it’s easy for engineers to worry about whose side these teams are on. Don’t let this happen.

Everyone is on the same side: product, design, and engineering all want to see the application succeed. The best way to align design with engineering is to convince engineers that you’re saving them work. If not for the valiant work of product in refining and filtering feedback and design in coming to a stable, concrete concept, engineers would be mired in unnecessary iteration and uncertainty.

Now, all of that is very abstract, and I don’t intend to tell designers how to do their job. What I will say is that it’s very helpful when designers put thought into the entire system and the big picture. Thinking through entire workflows and use cases provide a holistic sense of how an entire application comes together.

If design doesn’t think about the big picture, then design is making work for engineering – and by extension, more work for themselves down the line. Engineers will have to make assumptions about how things work, which others might not be happy about. In a codebase, every possibility must be accounted for, or else there’s a logical hole in the flow of the application. The frequency is irrelevant: any hole causes errors, and the stability of the product is compromised.

In summary, the most important thing is that engineering believe that design and product are saving them work. I say “believe” because not only do you have to do it, it’s also important that you communicate the thinking that goes into your work. Engineers will respect your effort and work as well, so everyone wins.

How Engineers Work with Designers

Having talked at a high level about the relationship, let’s get into the details of how engineers work with designers. I’m going to start this discussion at mockups. Discussion before the mockup is great and appreciated, but it varies between teams and is often unstructured.

Engineers are finicky about what types of mockups they like. Some engineers with stronger front-end skills (you may have heard these cleverly titled as “front-end engineers”) do well with little direction. Maybe they just need a high-level description or can work straight from an illustrator file. Feel blessed when you find engineers like this.

Other engineers, such as myself, can’t tell colors apart or count pixels. With engineers like me, you will probably need to annotate your mockups with exact pixel measurements and styling. I recommend you have a discussion with each engineer on their preferences. You should be willing to accommodate their needs to some degree, lest you see your beautiful designs turned grotesque in the hands of engineers.

Regardless of their preferences, I recommend that you always sit down for a 5 minute meeting with your engineer anytime you hand off a mockup. Hopefully, it is mostly head-nodding and agreement, but occasionally something will be misunderstood. A quick verbal check can save days of work and confusion.

Upon occasion, there will be big disagreements and conflicts about design choices or technical constraints. Maybe some detail is a lot of work, or maybe your engineer disagrees with the design. This goes generally for workplace discussions, but you should embrace the dissonance while walking away without taking anything personally. It can get heated, but remember that everyone is on the same side. People can have different perspectives on what the best approach to a shared outcome is. I think these conversations should be like workouts: they feel awful while you’re in it, but afterwards, you should feel great and want to do it again.

Also, always leave a paper trail about decisions and discussions. It’s easy to forget what was agreed upon.

One way to work together better is to create or use a style guide. Engineers design code to be modular so that the same components are used in multiple places. Using this principle avoids redundant work, improves the maintainability of code, and reduces errors. Style guides provide the same modularity to design components, and they map nicely to what engineers have to do. Although style guides do require a lot of forethought and maintenance, I believe that they also save work for designers as well.

One more thing in this section: engineers generally respect design skills and will defer to you. One way to violate this trust is to misunderstand your interface. It’s not necessary that you have detailed knowledge of the exact technical tricks to make it work, but it’s worth doing a tutorial to have a handle on the technology. For HTML, know elements will naturally be laid out and what the difference between padding and margin is. For iOS, know what the different types of views are. It will make conversations a lot easier, and your engineers will trust you more.

Design Review

After the initial mockup handoff, engineers usually go back to their computers and happily hack away until they are “done.” There will likely be questions along the way, so stay open to iterating, and always document those changes. At the end of it, however, your engineer should send the feature back for design review, where you look at their work to see if it was completed satisfactorily. Usually there’s something not quite right, and so you send it back to engineering with feedback. In this feedback, I have 2 pieces of advice: be specific and be positive.

If something doesn’t look right, be specific about what doesn’t look right. “Redo this graph” isn’t helpful, but “the font on the axes should be bold,” is. Engineers aren’t intentionally negligent: they just don’t have the same concerns that designers do. Call it out, or we’re going to miss it again. This may take another discussion if your engineer doesn’t understand the problem, but do it if it’s worth getting right.

No matter how it goes, be positive in your review. Almost all reviews are bad reviews. Sometimes engineers will surprise you by going above and beyond (and you should really appreciate those engineers), but most of the time, a deviation from the mockup means that something was done incorrectly. Even so, a good engineer hopefully did most things right, and that dwarfs the list of 10 things to fix. It helps to keep them receptive in knowing that their work is appreciated when the rest of the feedback is negative.


Since there are typically far fewer designers in a web startup than engineers, you as a designer are often in a position to dictate the implementation process. The first part of this series hopefully helps to build some empathy, and above are some ideas on the exact methods for sharing mockups and reviewing engineering work. Of course, be flexible: it’s really all about good communication, and that takes work and is very context-specific.

Next time, I’ll get into what I think is the most valuable part of this series: why do engineers always say “no,” and what can designers do to make them say “yes?”

Posted by: Kevin Leung, VP of Engineering