Designer Confidential: How can I make my designs more dev-friendly?

Welcome to the next installment of Designer Confidential: our column sharing practical advice on solving your toughest challenges like transforming your organization, creating a better-connected workflow between designers and developers, and building a great team. Submit your questions via this form, email us at designbetter@invisionapp.com, or tweet at us at @InVisionApp.

Engineers often tell me my designs are difficult to develop or that certain features will slow down the system. What approaches can I take in creating more developer-friendly interfaces and UX solutions?

—Signed, Lost in Translation

This is a great question, and it’s something I’ve considered a lot throughout my career. I think this friction often stems from differing values for designers and developers. While designers are focused on the experience of a product, engineers often orient towards the overall feasibility of building a quality, performant product within a defined timeline. The first step towards creating more developer-friendly interfaces and UX solutions is to recognize that if a product ultimately cannot be built, it’s not going to meet any user needs.

As much as I’d like to offer a single cure-all for seamless designer/dev collaboration, the truth is that there isn’t a one-size-fits-all solution. The definition of a “developer-friendly interface” differs by organization and team. Not only is it affected by the unique product each team builds, but work culture, skill sets, tech stacks, and legacy issues also have a part to play.

With all this in mind, I think the second step is to zoom out and develop empathy not only for the individuals you’re working with, but also for how their team fits into the greater organization. I’ve found the best way to do this is conducting a series of interviews when starting to work with another team or on a new project.

Here are some good open-ended questions to ask developers:

• Are there any back-end or front-end architectural constraints that would impact your ability to develop in certain ways?
• What’s been hard for you in the past when working with designers?
• What’s worked well? What hasn’t?

Chances are, engineering teams have experienced both good and bad design partnerships. In the same way that understanding your users’ needs helps you focus on the most important experience solutions, getting an understanding of how your development partners view the designer-development relationship and what incidents shaped it will better inform you on how to proceed together as a team.

Collaborate earlier than you think

With a strengthened design-dev connection, you can begin to optimize your processes together from the get-go. No longer will debates around what can be developed begin once designs are “finished”—your engineering partners will be able to identify trade-offs early and often, which you’ll be able to then input into your design. I’d recommend even involving the dev team as early in the conversation as conceptualizing user flows or information architecture. Regardless of visual presentation, the flow of information introduces the potential to add back-end complexity (such as underlying data structure changes), which will almost certainly increase the time it will take to develop.

Develop a common language

To aid collaboration, I’d recommend developing a common language (e.g. shared names for design primitives and components). If the terms used to refer to UI components and styles are reusable and consistent, they’ll circumvent developers having to manually translate a designer’s intentions into the equivalent code. I may be biased, but this is a huge argument for design systems, which clearly compile a collection of reusable components. Acting as a single source of truth, design and development teams can use the system to collaborate more quickly and easily.

Align on a shared definition of success

Even with planning and close partnerships, issues will crop up and lead to development delays. It’s not ideal, but it’s reality. Therefore, your joint design and development team needs to follow the same north star throughout the project: Will success be measured by speed of implementation, increased conversion, or user satisfaction? Understanding this early on can help a team weigh the relative trade-offs that exist from a value versus feasibility standpoint.

While being a good partner is important, I think it’s also critical for designers to remain advocates for their discipline, continuing to make “good design” less subjective in their organization. Though it’s easier said than done, here are some great resources to help you clearly communicate the value of design whenever possible:

• Talk: Communicating the value of design
• A better way to sell the value of design
• The designer’s guide to talking to executives
• The secrets to communicating better with stakeholders
• 7 ways you can make your design metrics even more effective
• Recap: Best practices for designer-developer communication

Now, while it’s helpful to be aware of how other teams operate in order to minimize day-to-day friction, don’t let empathy towards dev cascade into design fading into the background. Both teams should be equal partners in understanding—all in the name of the user.