Designers and developers work together when they create new products, but they’re not always on the same page. That’s because the nature of their roles are actually quite different.

Designers craft the look and feel of a product, while developers code it. But they still have to work in tandem to create a well-designed final product. That’s why the better collaboration between designers and developers is established, the better outcome from the design process will be.

However, creating a positive bond between designers and developers can be challenging, because they see product design from different perspectives. Here’s how to work with a developer as a designer.

My personal experience with developers

I started working at a startup when I was 19. I was originally in the marketing department, then, after a year, in the product department. Learning on the job and designing for an app with a steadily growing number of users was scary enough, but what most terrified me were the developers. Our developers were very talented, had years of experience, and were extremely vocal about their opinions.

As I grew into my new role, I invested in maintaining good relationships with developers. Building a sense of camaraderie made all my interactions between departments much more collaborative, pleasant, and less scary.

While good personal relationships with developers may help, keeping your departments as a whole on good terms is harder, and it’s important to understand where these tensions come from in the first place and how to diffuse them.

What happens when designers and developers don’t work well together

Working with designers can be hard for developers when they feel like they’re supposed to just keep quiet and code. It's not unusual when two departments experience tension in the workplace. Tension can hurt your product in many ways:

Designers craft the look and feel of a product, while developers code it. This can lead to different perspectives, but they still have to work in tandem to create a well-designed final product.

Developers are less likely to be flexible to product needs.

Developers will be less likely to think outside the box. Often, they will focus on the programming, and code the solution they’ve asked to code.

Handing off features is harder.

Most people would rather not work with people they don’t like. Developers are no different, and given the already tense product-dev relationship, this can make things even more difficult. Product design review meetings can be derailed by pointless arguments and detail nitpicking.

It isn't good for organizational culture.

When there is no bond between teams involved in the product design process, designers and developers start to work in a silo, which means that each team might not be aware of the work done by the other. Teams create assumptions about how other teams will use the results of their work; most of the time, such assumptions are only partly correct. It leads to extra and unnecessary work done by the teams and hurts company efficiency.

What do developers need from designers?

So how do you work with a developer as a designer? And how can you maximize the chances of successful interaction between two departments? To answer those questions, you need to understand the expectations that developers have. Here are three things that developers expect from designers.

To understand what developers need, you need to know their expectations: Regular communication, a clear understanding of what they need to build, and yes, opportunity to criticize your design decisions.

1. Regular communication

Treating designers and developers as two separate teams that sync only during design handoff is the worst possible thing you can do. When developers sync with designers only during handoff meetings, they might miss opportunities to ask questions about design.

The lack of information about design might lead to a situation when developers make assumptions about design (i.e., they use their imagination to understand how something should work).

Often such assumptions can be incorrect, leading to unnecessary redos?. Most of the time, the isolation between designers and developers is rooted in company culture. Not emphasizing teamwork or maintaining rigid divides between departments only deepens this divide.

2. Clear understanding of what developers need to build and why

Coding with CSS (or any tool)takes a long time. Coding a feature you don’t like takes much longer. Having to stare at each line of code that comprises something you didn’t want to build in the first place just creates resentment towards the designers and the company.

When the development team has no clue why these features are needed, you’re basically doing grunt work. When designers ask developers to code new features, they need to explain what value these features will bring to users.

Collaboration during design thinking sessions where both designers and developers are invited can give both teams a massive boost of clarity.

3. Opportunity to criticize proposed design decisions

Designers and developers can disagree on how something should look and work. Having disagreements is totally fine because the proposed design might not be easy to code. But the way disagreements are treated can have a tremendous impact on how teams feel. When the feedback that developers provide is simply ignored, it can negatively impact how developers feel about their work.

There are a few things worth remembering when sharing or receiving design critique:

• Learn not to take critique personally. Poorly provided critique is especially dangerous for designers because many tend to become very defensive when their solution is being criticized.
  

• Understand each other's point of view. When working together, many disagreements are often escalated or unresolved because neither side is willing to consider the other’s case. Don't become so invested in being right you aren't able to listen.

Practice iterative design. Never think of design as something that is set in stone. Think of a product design as something that can always be enriched with new and fresh ideas.

Within the iterative design model, a product team embraces the build-measure-learn mindset, meaning that when they have a new idea, they create a prototype and test it with a small group of users to see how they react to this design.

How to bridge the gap between design and development

A team’s descent into poor design collaboration doesn’t happen overnight. Typically, this problem exists on an organizational level for a while before it becomes too critical, so management starts to notice it. In order to repair relationships between departments in a company, you have to acknowledge that the problem is usually on a systematic level as well as a personal one.

Once we started addressing these issues, teams start to come together organically. At the end of the day, we’re all working on the same team, towards the same goal. Here are 7 ways to bridge the gap.

Improving collaboration between designers and developers will require culture change: openness to feedback, willingness to listen, clear explanations of your process, and becoming a little less precious about your ideas.

1. Designers should learn to give–and ask for–constructive feedback

Giving and receiving feedback are integral parts of the design process. Designers should collect feedback from various sources— from users, developers, marketing specialists, and stakeholders. But it's vital to ensure that the feedback is constructive, meaning that it's based on unbiased facts rather than personal preference.

Constructive feedback is directly connected to user or business goals. For example, “I like this design a lot, but I think that the button will make more sense at the top” is subjective feedback because it doesn’t state why the person says that. In comparison, “I like this design, but I think the button should be located at the top. Our tests show that this location for a button will help us increase sales by 25%” is constructive feedback that is rooted in research and analysis.

2. Listen to developer’s notes on product; don’t dismiss them

Working in a creative department is difficult sometimes because a lot of what we do is subjective. We usually don’t have the time or means to granularly test every concept we have while designing, and we have to apply our own judgment on some level in the design process.

For this reason, creative departments can become cliquey and not want to listen to outside opinions. It's vital to listen to input from other departments, including developers, because it helps make them feel involved in the product design process and because it builds better, more well-rounded products.

3. Explain the design process and how you reached conclusions

When you’re presenting a feature and debating with developers (constructively!) on the design of a feature, it can be helpful to explain the UX design process for context on how you reached the design that you have.

It’s not necessary every time, but sometimes, it can save time to work through the different design considerations, so that you’re all on the same page and can work together on resolving any issues.

4. Don’t be precious about your ideas

Some things you work on aren’t going to get into the product. Sometimes, entire features that have been designed and have fully fleshed out specification documents will be scrapped or stuck in the backlog, never to be seen again.

Designers need to have some flexibility and see the big picture. If you go into any meeting unwilling to move on your design, your features and your relationships with your coworkers will be worse for it.

Write better specs by writing clearly. Don't assume your directions will be understood without explicitly stating it.

5. Write specs developers love

When I first started working in product I asked a coworker in the Android team for input on how to write specs. Specs are documents that explain how a design should look and work in detail; most of the time specs are provided along with mock-ups or prototypes that help developers understand how things work in dynamic. He added, “Always write like you’re explaining to a four-year-old.”

I’ve always found that to be great advice. Write clearly and don’t assume anything will be understood without explicitly stating it. It's recommended to provide high-fidelity mockups along with notes on how functionality should work so that developers can review the mocks and read the description before implementing design. This cuts down on the back-and-forth clarifications that can get people on edge.

6. Take an active part in high-level conversations on implementation

It’s easy to check out when developers are talking about things you don’t entirely understand. Try sitting in on development and cross-functional team meetings, and ask questions. Not only will developers appreciate it, but you’ll also start to understand more about how the back-end of things work.

I found that, after attending a lot of technical design review meetings, I was able to better estimate development times, avoid designs that weren’t executable, and even pitch ideas for implementation in brainstorms.

7. Practice designer developer collaboration

When developers are giving designers feedback during the design process, the whole team saves time.

Designing with implementation in mind helps avoid a lot of the interdepartmental ping-ponging that happens when the design requirements include things that are technically infeasible or would burn too much development time. Developers also appreciate being included and will gladly be a sounding board or another pair of eyes.

Design to development hand-off checklist

A good design handoff makes developers' lives much easier. Here is a checklist that designers can use to validate their solution before the handoff meeting:

More collaboration between design and dev teams will smooth out everday processes and improve outcomes.

1. Design is consistent.

Consistency is an integral property of good design. You need to ensure that every element of your design is in place. Plus, all UI elements you use in your design should be a part of your design system.

2. Design system is up to date.

Ensure that your design solution is created using the latest version of the design system and developers have access to this version.

3. Design is responsive.

If you design a product that will be used on different screens and resolutions, you need to define clear rules that will help to scale content and UI elements. It's also important to test your design on multiple screens to see how it looks and works.

4. All visual assets can be easily exported in proper resolution.

Developers should not experience any problems with exporting visual assets such as photos, icons or illustrations. When they need a certain image from your design, they should be able to get it in a proper resolution in one click.

5. All complex visual effects are clearly described.

Visual effects like animated transitions between screens should be described with specific timings so that the development team doesn't have any problems coding them.

Better designer-developer collaboration means better design

So how do you work with a developer as a designer? The answer is simple—you create a collaborative space that harnesses the creative ideas of all team members, no matter whether they are designers or developers. After all, we’re all on the same team, working towards the same goal, creating the best possible design for our users, even if we disagree on how to get there.