Designers: how to work with developers (part 2)

Summary

• According to surveys, including our own, the majority of designers and developers think that designers should know how to code. But there's a difference between knowing how and knowing what. Instead of telling designers to code, we should be telling them to learn the capabilities and limits of code.
• That said, some foundational knowledge of HTML and CSS can only be a good thing for designers to have. It helps them empathize with what developers can and can’t do.
• Regular meetings, including an in-person kickoff, are more important than coding knowledge. The best way to work better with developers is to bring them into the design process earlier.
• Making your design handoff process more developer-friendly is key. Prioritize giving devs stable requirements (i.e. finished, locked-in designs) and don’t hand off in your design tool.
• It would be better to hand off designs in a tool devs are already using, such as Jira, using an integrator like Figma for Jira Pro.

Understanding developers

It’s true that designers sometimes feel ignored. It’s also true that developers sometimes feel misunderstood.

Developers are specific types of people, with personality traits, cognitive styles, and professional tendencies that are the very reason why they’re successful at building digital products.

Because of this, designers who want to know how to work with developers are often encouraged to learn to be developers.

In the first part of this 2-part article, I said that developers shouldn’t have to become designers to work well with them.

By the same token, designers shouldn’t have to become developers. Instead, they should seek a better understanding of how developers work, what they love, what they hate, and what they need.

So let’s look at what those things are.

Should designers learn to code?

This question needs tackling first, because a lot of people argue that there’s a surefire way of learning how to work with developers: learn code.

In Figma’s 2023 survey on developer collaboration with designers, 91% of developers said that designers should know how to code. In our own survey of how designers like to work with devs, 68% of designers said the same. So they don’t feel quite as strongly as devs, but they still think they should know a developer’s craft.  

In our survey, we gave designers three options when we asked whether designers should know how to code: “Yes”, “No”, and “Just the basics”.

Only 19% answered “Just the basics”.

That means the 68% who answered “Yes” think designers should know more than just the basics of coding.

So, on the face of it, it sounds like everyone’s saying designers should code. And if they’re saying that, they’re saying designers should become developers. Because that’s what a dev is: a person who writes code.

However, Erin Casali, senior director of product and design at Xero, says that there is a difference between knowing what and knowing how. And we shouldn’t be asking designers to know how to code, we should be asking them to know what code does.

She uses the analogy of a movie director not knowing how to act and a surgeon not knowing how to build a pacemaker. Both the director and the surgeon need to know what these things are, how they perform, and what their limits are. Likewise, instead of telling designers to learn code, we should be saying: “designers must know the capabilities and limits of their media”.

Obviously, a great way of learning what is learning how. And Casali acknowledges that learning how to code is helpful for collaborating with devs. It just shouldn’t be a requirement. And designers should learn some social and cognitive psychology first, because that’s something that will make them better designers. Coding won’t.

The benefits of (some) coding knowledge

Even though coding knowledge shouldn’t be at the top of a designer’s priorities, a bit of it can only help when it comes to designer-developer collaboration.

In our last article, I said that developers should learn the language of design to work better with designers. The same is true here.

Jon Vieira says that designers should try to get some foundational knowledge of front-end user interface (UI) coding, namely HTML (Hyper Text Markup Language) and CSS (Cascading Style Sheets).

If designers play with HTML and CSS, they’ll see how things are displayed on different devices and get a deeper understanding of the frontend development process. As a result, they’ll be able to think more deeply about their designs and how to make them more efficient for implementation. They will know what aspects of a design are easy to achieve and what aspects are more challenging.

In effect, designers will be able to empathize with what a developer is required to do, and understand what could limit them from doing it.

At the same time, Vieira acknowledges that going deep into coding isn’t necessary. Knowing the basics will suffice.

Open and regular communication is more important than coding knowledge

Erin Casali says that learning code is only one of the ways that a designer can learn the limits of their media. The other way is to collaborate with the people who build it.

As we said in part 1, designers and developers are different people who bring different expertise to the table. By talking to developers throughout the process, designers can learn what’s possible and what’s not without knowing anything about coding.

It takes effort by both designers and developers to fully engage with each other. In Figma’s survey, 55% of front-end developers said they wanted to be brought into the design process earlier. And 92% said they would like designers to know more about the development process.

Clear lines of communication are key, particularly as so many product development teams today are distributed. Slack is great, but it’s very easy to hide in our caves and not come out.

There should be an in-person project kick-off meeting for the whole team. Designers can explain the problem to be solved and get feedback from developers and other stakeholders on early ideas and mockups. Developers can outline technical limitations there and then so that designers don’t create something unbuildable.

After this, there should be regular check-ins before, during, and after design handoff to discuss any issues and make sure the design is still working.

Romina Gomez, lead frontend engineer at Struck Studio, says that in-person meetings, either in the office or over video calls, are “great for helping devs to see what’s important from a usability perspective, and designers to see the edge cases where their mockups might not make sense.”  

Your design handoff process should be as developer-friendly as possible

‍“I love getting design mockups where all my questions have already been answered and everything is clear and organized. It just makes everything go a lot faster when I’m not having to go back to the designer to ask for clarification all the time."
Janine Isabelle, Developer, Rowan Made

Developers want clear, unambiguous, and stable requirements for what they need to build. Many don’t get this.

So, if you want to know how to work with developers more effectively, take a good long look at your design handoff process.

Don’t hand off designs in your design tool

A lot of handoffs happen in Figma. Figma offers a developer mode and a ‘Ready for dev’ label that can be added to designs on the Figma canvas. In a previous blog we talked about how marking designs as ‘Ready for dev’ isn’t a very good way of managing a Figma handoff or collaborating with developers.

We won’t repeat all that here, but suffice it to say, many devs don’t want the cognitive load of navigating Figma and scouring through a long list of dev-ready designs.

Make handoff happen in ONE tool

Other handoffs happen across a mix of tools and are a complete mess. We’ve spoken to designers who sometimes use Figma, sometimes make tickets in Jira and link designs to them, and sometimes don’t use Jira and hand off in a bunch of Slack and Microsoft Teams group chats.

It means there’s no single source of truth, which makes the process overly complicated and can lead to devs missing key details or building the wrong thing.

So, streamline your tools and hand off designs in a single space that’s more central and neutral. It makes sense for handoff to happen in Jira because both designers and developers are managing tasks there. A designer can use an app like Figma for Jira Pro to embed their Figma designs in Jira tickets, which developers can view, inspect, and download without logging in to Figma.

Stable requirements = final, locked-in designs

Giving devs stable requirements means providing them with a final design that’s fixed and doesn’t keep changing while they’re trying to implement it.

One of the problems with Figma’s ‘Ready for dev’ label is that it doesn’t stop designers from tweaking designs after they’ve been marked ready.

Figma for Jira Pro, on the other hand, enables you to pin a specific version of a Figma design to a Jira ticket. Any changes to the design in Figma won’t propagate to Jira unless the user updates the version in Jira. Until then, the design is locked.

Key takeaways

Knowing how to work with developers effectively is essential for designers who want their work to be fully actualized.

So let’s sum up what developers want:

• Developers want designers to better understand the development process and at least some coding, so that they can appreciate the capabilities and, most importantly, the limits
• Developers want to be brought into the design process earlier so that they can feed back on the feasibility of early ideas and mockups
• Developers want open and regular face-to-face communication before, during, and after design handoff
• Developers want to receive a final design in a single tool that they’re already using to manage their work, like Jira
• Developers want a final design to be locked in, not liable to change at any moment.

In general, developers want designers to appreciate their work in the same way that designers want devs to appreciate theirs. If both sides can do that, the only compromise is dedicating a bit more time to communication. If you want to create awesome products, that’s a compromise worth making.

In case you missed it, have a read of our blog on how to work with designers.