Here's what developers want designers to know about developer handoff

I became a developer because Sketch Symbols didn’t exist when I was a designer. In fact, I’ve been chasing the concept of symbolic design my entire career.

User interface design handoff has come a long way since I first became a developer. Just a few years ago, we were primarily using raster images, which made the handoff process a bit arduous. As a developer responsible for the implementation of many interface designs, I spent the bulk of my time juggling multiple files and licenses for each tool to get what I needed from the source. Most of the time, I would just eyeball the general layout and colors from the raster and hope for the best.

Now, we have an array of tools to make it easier for both designers and developers to “pass the baton.” The problem is that there are certain habits and behaviors that we’ve adopted from our tooling of yesteryear that are preventing us from realizing a better handoff process today.

What’s at stake for your design team

As a designer, the greatest risk is your iteration velocity in your design tool. The benefit of design in a direct manipulation tool like Sketch is that you have less structure and implementation details weighing down your design exploration. That means the velocity you can explore ideas — iterations — is greater than your developer counterpart. If a designer adopts too much of a developer's habits and workflows without considering the risk, they might prevent themselves from taking full advantage of designing in Sketch.

If a designer adopts too much of a developer's habits and workflows without considering the risk, they might prevent themselves from taking full advantage of designing in Sketch.

Creating a better designer-to-developer handoff process requires intentional collaboration. Both designers and developers can work together to coordinate their tools in service of better integration. So if you want to think more like an engineer in an effort to create a more seamless design handoff, consider these seven principles for better designer to developer handoff.

Agree on your product language

For a long time, designers and developers didn’t want to waste time on naming. But we now realize that if you’re building a design system, naming is actually critical. A name can pull a lot of organizational weight. It often defines the scope, behavior, and relationships of the content in your system. When it comes to naming, I recommend:

• Using a name that is less likely to change. That’s right: Commitment is key.
• Thinking about naming in the context of the hierarchy of your components and how they all relate to each other.
• Syncing up on the form of your common product language is not as important as the content. In CSS you might have “cta-Button,” in Ruby “ctaButton,” and in Sketch “CTA Button.” The form can be ignored because converting the casing here can often be automated. It’s important for the content to be the same so that each one reads the same verbally.

At Abstract, we have a flat product language. If a Symbol or component is used in a certain context, we make sure that context is encoded into the name.

Organizationally, this allows our teams to align on the same taxonomy in conversation. Without the flat taxonomy, something as ominous as “Button” could mean any button in the system, depending on the context it was used in. In our case, our product language only allows for one true “Button” or “AnythingButton,” or “AnythingInGeneral,” despite the context it is used in. It’s a global namespace that can be used organizationally.

Zendesk’s Garden is a great example of the power of shared product language. On their Dribbble page, they describe how universal naming has helped their designers and developers communicate:

“We've got almost 20 library files! They directly mirror our code components, and share the same names as our code components. This helps our ~50 product designers speak the same language as their developers.”

Pick your platforms

Developers can waste a lot of time extrapolating intent and direction. Imagine, for example, when a developer is given a design for mobile and desktop — but not tablet. The obvious solution might be to design a screen for every possible option. But that’s ultimately a very time-consuming task, with only short-term rewards. The next new screen size is just around the corner.

The key is to be intentional about the platforms you provide designs for. For example, if you are targeting web, and your design is cross-platform, the widths of each artboard can be aligned with your media queries in CSS.

If your platforms support theming or Dark Mode, you might not need to manage separate designs if you have defined a scale for color that accounts for dark contrast or can be dynamically swapped out. I’ll discuss this in more detail.

Another approach is to think about theming. If you pick a unified color palette, you can systematically create a color system for any screen that exists, or may exist in the future.

Use the Layout, Luke

Browsers and other targets for code can have layout properties like margin, padding, and more to manage the spacing of repetitive elements in designs.

Sketch and similar direct-manipulation tools provide simple layout concepts, like Resizing Constraints and Text Anchoring. Sketch recently announced that in the future, they’ll offer native support for Layout concepts that will allow you to go above and beyond designing how your screen appears at multiple sizes with the properties you’ll often want for code.

These additional properties provide more context about an element’s behavior, allowing you to design the layer hierarchy as a blueprint that is more aligned with the code implementation.

Define your design scales

Design scales can act as your fundamental building block. They can be named and, generally, can be ported between your code and design tooling. There are two different classes of design scales — color scales and unit scales. Both are useful because they act as a palette for developers and designers. In my experience, mistakes often stem from unforeseen combinations, so I recommend limiting the ranges to avoid headaches down the road.

Scales help reduce the complexity of  our system. It’s not often you need the full fidelity of every color in the rainbow for your organization's interface or brand. You can create color and space scales to intentionally limit the number of incorrect combinations in your design and code. By defining color scales up front, designers can help guarantee that their design will be accessible from a contrast perspective.

By reducing our units a 8pt grid, we establish a rhythm that allows elements typically line up in our layouts. We opted for 8pt because most device screens are divisible by 8.

Design placeholder asset exports early

Game developers use version control as a core workflow to design placeholder assets (like an image for a fire), and this is a great practice that we could adopt, too. By systematically working this way, you can discover unforeseen problems sooner than later.

You don’t need to wait until an asset is approved to export and use it. If you know the name and dimensions of an asset early on, you can export a placeholder asset that can help developers surface any implementation problems sooner than later.

When using Abstract, as the design evolves, Commit-by-Commit, your exported assets will automatically be updated in Inspect and available for programmable export with the Abstract SDK.

Start the handoff process with a Review Request

Our developer handoff process is as simple as a Review Request with a Collection. It’s an intentional touch point that helps our team identify potential problems like accessibility issues, internationalization and character limits, asset management, etc. — before the actual handoff. This is a major step toward simplifying the handoff process.

As a developer, I can assess a Review Request by walking through the Collections and using Inspect to make sure a design meets my team’s requirements before moving into the  implementation stage.

At Abstract, we typically leave Review Requests open until a Branch is merged. This allows designers to respond to possible development challenges without the overhead of creating more Branches.

Don’t push systems: Defer until you know

For most designers and developers, only about 70% of the system is well-defined at any given time. The other 30% is the frontier where weekly explorations happen. Over time, parts of the frontier transition into a state of maturity and new explorations begin. The circle of life.

Undoing systems is harder than adding new pieces, especially when you’re trying to do so at scale. Unlearning is harder than learning. That’s why pushing systems that aren’t yet mature can actually do more damage than good.

Your intuition may tell you that everything should be systematized, but don’t let yourself be fooled. Not every Symbol is a component and not everything that repeats should be a Symbol, component, or a function. These abstractions are convenient, but they often carry a hidden cost that you’ll pay when it’s time to change.

When it doubt, defer until you know.

What will developer handoff look like in the future?

In the near future, our tools will continue to bridge the gap between design and development. I imagine we’ll get to the place where the handoff process will be so seamless that we’ll no longer need a name for it. But realizing that future means we need to keep thinking ahead and refuse to be limited by old habits. For now, we need to ask ourselves: What does the ideal handoff process look like for my team and what will it take for us to get there?