Profile picture of Coren Feldman

8 min read

How designers can work with developers to create websites that wow

Is your design-dev workflow glitching? Here’s how to repair it.

A 3D illustration of a pen tool set within two silver brackets over a gradient background.

Illustrations by {name}

Stay informed on all things design.

Thanks for submitting!

Shaping Design is created on Editor X, the advanced web design platform for professionals. Create your next project on Editor X. 

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:


A 3D illustration of four different open windows over a gradient background.
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. Most of the time, they will simply code the solution they’ve asked to code without thinking about the end user.



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.


A 3D illustration of a mobile interface and its related graphics hovering around the hardware.
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 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.


A 3D illustration of a fistbump over a gradient background.
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.