No design is useful unless it’s implemented as intended — this an uncomfortable truth all designers need to let sink in. Being able to collaborate fluidly with developers is an essential skill to being a good product designer. Developers are also “users” of our design work, which we need to account for and give them a good experience.

Photo by Annie Spratt on Unsplash

It’s not really a hand-off

The first step is to shift the frame of mind of what the relationship should be. The designer isn’t supposed to simply pass down a list of instructions to the developers. We are not all-knowing. The best designers are great information aggregators. They understand the value of involving team members with different skills and points of view — developers, marketing, sales, etc. Of all the departments in a company, in most cases, product designers collaborate the most with developers, so working well with them is crucial for the success of a product. Emphasis on “collaboration”. It’s a dance, not a hand-off. This is not to be confused with a chaotic lack of process. A dance is always led by one party while the other one follows along. Roles can change for different phases of the production process, but there should always be a clear decision-maker and constant input between them.

Have a dedicated development consultant for each project

A product design process is often a balancing act of business requirements, technical constraints, user needs, and principles of good design, which is why involving other departments early in the design process is essential to avoid unnecessary rework. However, people are busy with their work. Simply throwing up a design for review by anyone on the team will at best yield a lot of superficial feedback, or at worst, be ignored. One way to solve this issue is to group people in squads (i.e. small teams that work together closely on a project), however, not all companies work this way. Regardless of how the company is organized, it’s important to find a developer that will commit to providing careful feedback. They can often help find simpler solutions and identify potential edge cases or errors, which will in turn help the designer provide a more robust solution. Depending on what works best for the company, the “consultant” can be a dedicated developer that commits to playing this role for all projects or to rotate through the dev team and assign a “consultant” for each project.

Record changes on a separate Figma page, in a separate branch

Let me first preface this idea by clarifying that it assumes you’re using Figma (or a similar app) and you’re working on an existing app, to which you’re adding a new feature or making improvements.

Often, changes to an existing system have multiple touchpoints, which means multiple screens need to change, new screens are added, or redundant screens are removed. All this is hard for a developer to track if it’s spread throughout a multi-page Figma file with tens or hundreds of screens. Therefore, to make it much simpler for the developer to understand the task, I found that this workflow works well:

1. Create a new Figma branch for each project and a new page titled “affected screens” within it. Collect all screens involved in your design into this page or add the new screens to it.
2. When the design is ready for development, include the link to the “affected screens” page in the project document, as detailed in the next point.
3. After the design has been implemented and it’s pushed to production, move the screens back to their correct place and delete the “affected screens”. Finally, merge the branch so the main Figma file always reflects what’s in production.

How to prepare a project document

For each major project, the designer should write a detailed document that includes the following:

• The problem definition, an explanation of why the project is important, and what impact fixing it will have.
• User feedback or research insights related to the problem
• A detailed description of the solution that covers the expected behavior for the “happy path”, edge cases, and error states.
• Links to design files, prototypes, mind maps, or other design artifacts that can help developers understand the proposed solution.
• A video recording to present the feature (try Loom or Jumpshare). Why demo it if it’s also written down, you might ask? As I mentioned above, developers are a type of user of the design work, so we should try to make it easy for them to understand their part.

How to prepare a kick-off call

Before we dive in here, let me address another thought you might have, my designer friend, which is: why should you schedule a kick-off call after doing so much to describe and demo the feature? Well, because people don’t read carefully. Most often, they skim. They watch demos at 2x speed. They forget or get distracted, and even if they don’t, you might’ve missed something. This call gives developers a chance to make sure they understood the design correctly and ask follow-up questions.

To make the meeting as efficient as possible, send the feature doc ahead of time and ask the meeting participants to review it so they can come prepared. The meeting should take no longer than 20–30 min. Here’s an outline of what the kick-off meeting should look like:

• Begin by asking if everyone got a chance to review the doc. If some people didn’t prepare, allocate 10 min for silent reading to allow everyone to get up to speed.
• Next, briefly cover what the problem you set out to solve was and why it matters to the customer
• Remind participants of the process you when through, the discussions that were had, and how these led to the final solution
• Briefly present the “happy path” and the feature doc
• Open the floor for follow-up questions
• Finally, confirm with developers the estimate for development time and when you and the team can start testing the implementation.