Top Things Devs Wish Designers Knew

I am a developer and I’ve been thinking about how I can be a better partner to my design teammates. To answer that question, I reached out to my friend and design colleague David Janke to see if he’d write an article with me called “Top Things Designers Wish Devs Knew.” “On one condition,” he replied. “You write the opposite article!”

I laughed because I didn’t have anything to say. I am fortunate to have only worked with wonderful designers. The only thing I wish they knew was “keep doing what you are doing!” But Janke’s request was coming from the same motivation as mine, so I reached out to my current and former engineering colleagues to see what their top recommendations were.

I was surprised at the level of interest everyone showed: I had over 50 responses! Here are four of their top suggestions.

1. Design Easy != Dev Easy

Small design customizations can translate to a lot of development work. Making one date picker slightly wider than another and customizing select elements are two examples of design changes that seem like small customizations, but can often be hours of toil.

If these details are critical for the user experience, let’s try it! On the other hand, if it doesn’t have a large impact on the product, skipping those little differences can help get this feature out the door faster. Every little customization we do also adds maintenance cost, so if getting features to market is the priority, let’s streamline what we can.

2. Prediction is Hard

It can be hard to predict which parts of the design are going to be tricky. We may be able to flag some that will be finicky to implement (e.g. the ones listed above), however there are also plenty of things we won’t know about in advance.

For example, one developer respondent recently started some work creating a header and a dropdown. When they first looked at the design, everything seemed doable, including the 6-pixel distance between the header and the dropdown. Many hours later, the developer had succeeded in figuring out a way to do 8 pixels or 4 pixels, but 6 was not happening.

These kinds of things happen quite frequently. Be sure to encourage your devs to approach you if they encounter a situation like this. That way, you can discuss whether trying to get that 6 pixels is worth the work, or if an easier compromise would be fine. Product leader Janice Fraser cites another example of this in her talk on balanced teams. TLDR: The devs and designers didn’t communicate enough. The devs assumed a particular piece of the design was non-negotiable and poured hours of work into making it happen. In the end, the designers would have been fine with an easier-to-implement compromise.

3. Specify Edge Case Behavior

Leaving out these details can leave us feeling unsure. Say the product is primarily mobile, but there will also be a desktop site. On a desktop there is suddenly much more space. How should we lay things out?

Another example is error cases. What should the behavior be when a credit card is invalid? If these types of things aren’t specified in the design and you aren’t available to chat, some devs find themselves feeling uneasy about making design choices when they are not design specialists. They worry they might accidentally cause everyone more work.

Talk to your team members and figure out how much detail regarding these cases is needed up front. Sometimes a 1–2 sentence explanation may work. Other times, a fully-detailed design is called for in order for us to implement the vision.

4. Frontend Engineering?

Learn a little frontend development … maybe. Out of my ~50 respondents, no devs called out the importance of learning to code. However, 2 of my article reviewers (2 designers with some dev experience) called this out as something they feel helps them work with devs. Perhaps we don’t see it on our side, but it may help you. This is an enormous debate and out of scope for this article, but I figured I’d share this even though it did not occur to the devs when I sent out the call for advice.

Summary

I hope this was helpful to designers out there working with dev teams. I’d encourage you to talk with your dev teams about what makes their list. What elements are hard for them to work with? How detailed do they wish you would be with your designs? With clear communication, you can get to a place where you are working harmoniously and making great products with as little re-work as possible.

Look out for David’s article currently in the works and coming soon.

PS — in case you missed it in the first section, you may want to check out the article Beware of These Nine Design Elements Your Front-end Developers Hate.