Sometimes relationships don’t work out. People are too different, they don’t communicate, there’s a lack of trust. Sometimes it’s all of the above.
Developer-designer collaboration can seem like a completely mismatched couple trying to make it work for the sake of the kids. In this case, their app needs them.
Maybe the answer is to sleep in separate bedrooms. So, keep developers and designers siloed and working independently.
But parents need to make decisions about the kids together. Same with developers and designers who need to collaborate to deliver a great feature.
Does one of them have to change? Or is there a way of meeting in the middle?
Basically, if good designer-developer collaboration doesn’t happen, the ones who lose out are the customers. So let’s figure out how to get developers and designers hopping back into bed together.
In our experience there are four reasons why developer collaboration with designers breaks down.
You know how some people are just 100% made for each other?
Yeah, designers and developers aren’t. They’re very different people. It’s like scientists and religious people. Put them in a room together and it won’t be long before someone flips a table.
Designers are theoretical. They use their creative and imaginative ‘right brain’. Developers are more practical, relying on their logical and analytical ‘left brain’. A designer’s imagination has no bounds and neither do their tools. If a designer makes a user interface (UI) in Figma, it’s not going to tell you if a screen is too big for certain mobile devices, because Figma lets you build a utopia. But then a developer has to come along and code it, and that’s when shit gets real.
It’s the same as an architect designing a building with floating floors; only when you actually build it do the laws of physics get added to the equation.
Because developers write code, they think and speak in code, too. But code isn’t a designer’s first language. Developers speak in things like HTML, CSS, and JavaScript. But designers speak in colors, fonts, and layouts.
What makes the language barrier even trickier is that designers and developers sometimes use the same words to mean different things. A “button” to a designer might not be a “button” to a developer. It might be a link. And vice versa.
Although developers and designers have the same overarching goal—to make great software—their day-to-day objectives differ a lot.
A designer might want a bold, unconventional layout to grab attention. But a developer’s priority will be maintainability and compatibility with legacy systems. Similarly, a designer might want to use an image with a large file size, but a developer’s concern will be to reduce load times.
It means that sometimes the ideas a designer has are unrealistic, because they haven’t considered the technical constraints.
Naturally, developers and designers use different tools. Developers write code in integrated development environments (IDEs) like VS Code and use Jira to manage their workflows. Designers work in user experience (UX) design tools like Figma.
There isn’t much overlap between these tools because developers and designers are doing different jobs. I wouldn’t use Figma to write a blog any more than a designer would use Microsoft Word to make an image. Development is about logic, making stuff work, and following a process. Design is more explorative, unstructured, chaotic, which is why designers work on an infinite canvas filled with theoretical compositions of shapes and colors that don’t have to work or be correct.
Using different tools does mean developers and designers are technically siloed, which can make it difficult for them to get on the same page. It also makes the language barrier worse. For example, in Figma, you’d put a black line called a “stroke” around a rectangle to make a button. But to create that same line in CSS, a developer would probably use a “border”, not a stroke. They’re similar, but not the same. Create the rectangle in SwiftUI and you’d need a different approach again.
Have a look at this total breakdown in communication and trust between a designer and his developers in this Reddit post called “Designers vs developers and the lies they tell us”. The original poster (OP) is mad as hell, ranting about having to deal with developers who lie to him about not being able to implement his designs. He calls developers lazy and their managers too afraid to make them work.
Responses jump on the fact that the OP clearly doesn’t know how to work with developers. He seems to view them as subordinates who should do what he says. The OP responds by saying it isn’t up to him to build and nurture collaborative relationships, that he doesn’t have time, and that that’s what product managers are for.
Maybe this guy’s just an arrogant asshole. But it’s clear that different processes, languages, tooling, and ways of thinking make it difficult for designers to know how to work with developers and vice versa. As a result, some just won’t bother trying.
“Good designers and good developers actually have a lot in common. It’s not like we’re marine biologists and coffee baristas, we’re all just making web stuff.”
Austin Bales, Facebook product design manager
So far this article has focused on designers vs developers like they’re engaged in a battle only one side can win.
Maybe to get designers and developers working together more successfully, we should focus on what unites them, not on what divides them.
Austin Bales believes that designers and developers share a love of clarity and simplicity, and a skill for defining and implementing patterns. Diógenes Brito, former product designer at Slack, says that both designers and developers need to use a combination of convergent thinking (finding well-established “correct” solutions to problems) and divergent thinking (generating original ideas and creatively exploring multiple potential solutions) to problem-solve and innovate.
How does recognizing the similarities between the two disciplines help with developer-designer collaboration? Well, Brito would argue it should lead to the blurring of boundaries between the two. He describes himself as a “full stack designer and engineer”, i.e. he does both design and development and believes it is not impossible or rare to be both. Netflix is an example of a company that has “full cycle developers”, meaning their developers are jointly responsible for the full software life cycle: design, development, testing, deployment, operations, and support.
In effect, their solution to design-to-dev misalignment is for designers to be able to code, and developers to be able to design.
But is this what they want?
In October 2023, Figma conducted a survey of 200 front-end developers about their relationships with designers. 91% of respondents said they think designers should know how to code.
I shared this stat on LinkedIn asking product designers what they thought of this. Product designer Marek Canavan said yes, designers should know how to code even if they’re not expected to do it. UX lead Ruben Lourens said that knowing how to code should make you a better designer. Developer Paul Pasler said it’s great when designers can code or at least understand the challenges of front-end development, but knowing how to code isn’t mandatory and nor should it be. He also said that designers and UX professionals should focus on mastering their craft.
It seems like designers and developers have to choose whether to be a specialist or a generalist. With Netflix’s model, a full cycle developer has to be interested and proficient in the entire software development life cycle. However, Netflix acknowledges that “some developers prefer focusing on becoming world-class experts in a narrow field” and that “the need to be broad, with reasonable depth in each area, may be uncomfortable and sometimes unfulfilling”.
Adopting Netflix’s full cycle model means creating hybrid workers that are good at both disciplines, but could’ve been excellent at one. Designers forced to think like coders could experience a mental shift towards constraints; instead of boldly exploring imaginative concepts, they preemptively limit their ideas because of technical feasibility.
Erin Casali, senior director of product and design at Xero, points out that there’s a difference between knowing how to code and knowing what code does. She says that architects don’t need to know how to build skyscrapers, surgeons don’t need to know how to build pacemakers, and movie directors don’t need to know how to act. But they do need to know what these things do, how they perform, and what their limits are.
“Learning the language doesn’t mean mastering the code.”
Kristian Mikhel, former product designer at Grab
Likewise, designers should understand the capabilities and limits of development, which involves at least a basic understanding of code. But they don’t need to become programmers, which takes years of hard work and commitment. And way more important than coding are other things designers should learn: psychology, marketing, selling, and how to do user research.
It goes both ways. Learning the basics of design, how to create personas and empathy maps, and facilitate user testing are all things that would benefit developers trying to deliver better products.
Getting developers and designers to understand at least a bit of each other’s craft is a way of getting them to talk to each other. To sit and work things through together and understand where the other is coming from.
Which brings us to the real problem. It’s not that designers can’t code, or devs can’t design. It’s that, too often, developers and designers just aren’t willing to work together as a team.
That angry Reddit user is a good example of a designer who just has no interest in collaborating. I then read an article about a game designer who learned to code because he found it too tough to explain to programmers in detail how he wanted certain things to work. He also said he was frustrated that developers were regularly making small design decisions while writing code that he had no impact on. And that it’s easier to build your portfolio if you just make the games yourself rather than relying on someone else to code them for you.
So, this game designer became a programmer in order to go it alone and avoid teamwork. This worked for him, but in most contexts it wouldn’t. Software teams juggle multiple projects with overlapping deadlines and collaboration is absolutely necessary to avoid bottlenecks. Not just necessary. Desirable. An exchange of ideas and viewpoints from people with different perspectives sparks innovation and leads to richer products.
So the question is, how do you encourage designers and developers to work together as a team?
Let’s assume we have designers and developers that understand each other’s craft and are willing to sit down and talk to each other. And yet they still don’t.
Why? Well it’s probably the tools they’re using, and the big chasm that lies between them. Designers are creating things in Figma, while developers are managing their work in Jira. For some teams, the solution is getting the devs to spend more time in the design tool. And Figma’s really pushing this. Figma’s “dev mode” is designed to ease design-to-dev handoff by allowing developers to:
The problem with this is that it puts all the onus on a developer to learn how to navigate designs in Figma and work out which one they’re supposed to be coding. It also means they need a Figma license.
Most devs don’t want this. They don’t want to context-switch from Jira to Figma or pay for a license for a design tool. If design handoff is easier, it’s only because devs are being asked to do more work.
Improving collaboration shouldn’t be about asking either designers or developers to do more. It should be understanding that each side has a different workflow, and that there needs to be a way to bridge the two.
An app like Figma for Jira Pro can act as this bridge. It lets designers add point-in-time versions of Figma designs to Jira issues, ready for devs to implement. A designer can choose different ways to display their designs on a ticket, and a developer has the option to move the design around, zoom in, and view it in full screen or its original size, all from inside Jira. Developers can also download it in various formats, including SVG, and open an information panel containing additional details about the design.
Yes, there needs to be give on both sides. The best collaboration requires an investment of time, understanding, and a bit of upskilling. But designers and developers don’t need to become something they’re not, nor do they need to add a whole new process to their workflow. There are better ways of bridging the gap.
Find out more about how Figma for Jira Pro could improve developer-designer collaboration at your organization.
A former lawyer, Berry loves theme parks, has published a sci-fi conspiracy thriller trilogy called Million Eyes to rave reviews, and is a specialist in writing content for tech companies.
