Illustration by Prabhat Mahapatra

I have often heard the claim that designers and developers are different. They speak different languages. They care about different things. They do different work so specialized that neither can understand the other.

As a designer myself, I must admit I’ve experienced some of these labels over the years but the reality is, none of this needs to be the case today. The industry that designers and developers work within has evolved an incredible amount over the past few years. There has been a lot of focus and innovation on design tools that is helping to bring both disciplines closer together.

There has also been a progression in underlying processes and new best practices being shared throughout the community that is uniting us. Design and development are actually closer than ever and there is no reason you cannot establish this connection in your organization too.

Let’s look at a few of the key challenges and how we can tackle them!

Collaborate early, and continuously

Design and development are both part of a broader product development lifecycle and collaboration between these functions should be taking place early and throughout this process. If your design team is reaching out to their development partners only after they are finished with their designs, this is a sign that there could be a problem! With late stage collaboration, it’s possible that some of the elements in the design may not be deliverable in actual code – some designed app behavior may not be visible to the developer at all or even the basic design elements, like colors, may get lost in translation.

In order to avoid these pitfalls, it’s critical for design and development to engage early in the product development lifecycle and stay engaged throughout. It’s super helpful for designers to engage with developers even at the discovery stage, when it’s all about wireframes and mockups. Not only will they gain critical context on the design approach, they’ll be able to share development realities, provide opportunities to automate next steps, and also gain clarity from the team on the basic elements of the design. It’s also a great way to align on clear goals and expectations across the product team and establish a project rhythm, all especially important today with the increase in remote work due to COVID-19.

A travel booking UI is overlayed with design specs in Adobe XD.

When it comes to collaboration, it’s also important to remember that there are other teams involved in the product development lifecycle other than designers and developers. There are copywriters that may need flexibility in space needed for copy, there are marketers that need web pages optimized for promotional campaigns, and there are also product managers and execs that need summary level updates on progress. Ensuring that you engage this broader team throughout the project will make the process smoother for everyone, including the designers and developers that are right in the middle of it all.

At Zeplin, we are also seeing an increase in the collaboration between designer and developer functions. One indicator of this is the use of Zeplin Styleguides. With Styleguides, designers at Audi AG are connecting assets from their design systems to code components developers are using during the application build process. This feature is also helping designers gain confidence that the app will be built in alignment with an established design system; meanwhile, developers gain efficiency as they are able to reuse connected components. It’s a great way to collaborate early (and always).

Being organized makes good things happen

Product development today is a very iterative process. While such iteration helps build the best experience for the user, it can also create a ton of complexity for the project team. Designs can go through what feel like endless iterations, sometimes resulting in differences between iterations that aren’t even visible to the naked eye. Determining what the “final” version is can be difficult, and even understanding how a project is structured can be tricky. In order to resolve these challenges, you can start with some very simple steps.

  • First, defining categories that can be used to structure your work will help immensely. You can define categories for each of your projects so everyone knows which projects the designs belong to, a category like “Project Alpha Signup Flow” for example will be super helpful to everyone. You can also use categories to define work allocation among members of the team so it’s clear who is working on what, like creating a category called “Anna” for the screens that developer Anna will be working on.
  • Second, getting aligned on how you will communicate feedback and updates will also help the team stay organized. With the choice of multiple communication tools today, across email, chat, application-based comments, and more, it’s tough to know what tool to use and when to use it. Without a plan for team communication, you’ll end up wondering if that feedback was tagged in a doc, sent in a reply to an email or in a chat channel, which is frustrating. Driving clarity on how you will use the various communication tools available to you will help avoid those moments of frustration.

At Zeplin, we’ve been leveraging our integrations with popular communication and coordination tools like Slack and Jira to ensure our own internal team is staying organized. In fact, with half our crew split across San Francisco and Istanbul, integrations like these help us stay aligned and not miss a beat. We also recently introduced Project Status and Pins to help teams define the categories that make sense for their workflows – all to help teams stay organized, so good things can happen.

Not all specs are created equal

Lastly, one of the leading causes of the “we speak different languages” cliché is confusion about developer specs, commonly referred to as “handoff.” Specs are specific data elements that developers need in order to bring a design to life, and these include things like dimensions of assets, distances between assets, colors, fonts, responsive behaviors, and more. What can make this more complicated is that assets can come in different formats, like .png or .jpg; or maybe the developer needs a vector asset in .svg or .pdf! Specs also vary by platform, so when developing for Android, distances are measured in dp/sp while developing in iOS distances are in pt. For the designers on the team, specs may seem straightforward but for the developers, they may pull their hair out if they aren’t getting exactly what they need. Ensuring that the team is aligned on the exact specs that are needed is critical, and that means spending time on clearly aligning on the specs that developers need to move the project forward.

With the Zeplin and Adobe XD integration, our teams worked together to ensure developers will get exactly the specs they need from design teams, in the formats they need them and across the various platforms they need so no one is pulling their hair out. We even provide sample code snippets that go a step further to help developers collaborate well with their design counterparts – trust us, it will save them hair too.

What’s in store for the future of designer-developer collaboration?

Overall, the gap between the world of design and the world of development is narrowing. The innovations we are seeing in design tools and the evolution of best practices is driving more collaboration between designers and developers than ever before.

As innovations and evolutions continue, I’d expect this connection to get even stronger. I can foresee product development workflows where design and development actually use a common toolset, where design systems also define common development values, rules, and UI elements. With additional capabilities like component states and content-aware layouts, designers will be able to represent designs more like a developer would do in code, making it easier to communicate in a single common language. Imagine a scenario where a designer adds a new icon to their style guide, automatically generating a corresponding component, then triggering a pull request for the developers to update a code repository, all in the right specifications and format. It may all sound like magic but it’s actually not that far away at all.

Once this happens, maybe we’ll see that designers and developers are actually super connected and they aren’t really that different at all 🙂


Check out Zeplin, the better way to share, organize and collaborate on designs, built with developers in mind.