The One Where We Re-Imagine Design Handoffs

Bridging the Gap Between Design and Development

Why alignment between designers and developers matters

Since 8020's founding in 2018, we've been lucky enough to help over 50 clients turn their visions into reality. We've worked with early-stage startups moving at breakneck speed and enterprise organizations moving at a more "meticulous" pace to build their websites. Sometimes, we act as both design and development partners, while other times we handle development only.

Through all of these experiences, we've been able to identify some core patterns of success — the small but impactful things that make a project run smoothly.

Many development agencies rush to get started with their projects and then solve problems along the way. But more often than not, the fastest way to finish a project in Webflow is to spend more time at the start —  and work hand in hand with your designers on it.

We strongly believe that when designers and developers are able to create a foundation for web design together, it results in a faster build, a cleaner final product, and more nimble future changes. So, in this episode of Insider, Matt Evans and Max Joles share a set of communication guidelines for building alignment between designers and developers during handoffs.

What is a design handoff?

In the Webflow development setting, a handoff can be defined as the moment where the project goes from the designer working on a file to the developer receiving it. When you work with external designers, this usually feels like playing hot potato. The designers only get involved in the creative process and then throw handover the design to the development team for building.

In practice, this approach doesn't always work. The limited amount of communication between the designers and devs can cause plenty of misunderstandings on how the final product should look and function. The lack of collaboration from the beginning will eventually result in a ripple effect —  from pushing back timelines and adding extra rounds of revisions to upsetting some peeps along the way.  

Max Joles and Matt Evans (brilliant devs at 8020) partake in some of the most common oversights we have encountered in design handoffs: (1) designs without feasibility in mind, (2) lack of unified file structure, and (3) inconsistencies among designs. Let's review a little bit of each one, shall we?

Design without feasibility in mind

Sometimes designers create stunning designs, but when they are sent for development, the designs don't easily translate into no-code and Webflow. Other times, web designs work well on desktops but do not function properly on mobile. Building with no-code has limitations, which need to be accounted for before letting the creativity run wild.

Lack of unified file structure

When designers do not have a system to document their assets, it is very hard for developers to comprehend the logic and structure of the design. Some of the worst feelings a developer can have surge when they are halfway down the build of a page and questions start to arise. Especially if you work in a remote work setting, consider that people sometimes work async and might have to wait hours for answers.

Inconsistencies among design file

Sometimes a design looks just perfect at a glance, but just as a developer opens the file and sees it with dev eyes, they can distinguish a bunch of small inconsistencies in the styles. Different fonts, colors, spacing — you name it! There are so many nuances involved in design that have to be coherent in order to be built in Webflow.

Key takeaways:

• Including a developer review phase before the official handoff can go a long way in preventing inconsistencies. If you want to go for the golden star, consider a refinement phase to check for responsiveness.
• Try to get designers and developers aligned early in the process. Designers have the creativity and flexibility to envision outstanding designs, and developers have the precision tools to bring those designs to life — the perfect duo!
• As developers, help designers understand Webflow as a tool. Show what's feasible to accomplish in Webflow, and what would require extra custom code —  or even a different platform.  

Good practices for design handoff

As a designer, it might be tempting to hand off a design and be over it. But, pulling the plug abruptly without first having a collaborative dialogue with the developers can backfire, big time. After all, a design that does not function properly for the web, can't be used.

Regardless if you are a designer yourself or work with them, we recommend having strong guidelines to hand off designs smoothly. The goal is to have a process so structured and collaborative that makes your developers dance while building in Webflow. Of course, following a timeline, and staying within budget matters too.

Next, we share with you a guideline with 8 steps that we as a no-code studio constantly follow at 8020 to ensure a smooth as butter design-to-build handoff.

1. Label your creative spaces and your production spaces

Design can be a messy process. We get it. Often, the beauty of a design is the result of rapid experimentation and sometimes even a fortunate accident. The designer's goal should always be to provide some helpful organizational strategies for it. Trust us, developers love to peek behind the curtain and see the designer's creative process.

That being said, although it's fun to look at the mood boards and experimental feature concepts, it isn't so fun when the creative process and production-ready pages mix up and become indistinguishable. A very simple way to solve this is to separate pages for exploration and inspiration from pages that are ready for production. After the creative storm dies down, move your final design into a production-ready page, tidy it up, and add a label that it's ready to go.

2. Get on the same page with the devs

As a designer, you might work on a 42-inch retina display, but chances are when your customers open your website, they won't be. Designing on an appropriate desktop resolution and setting up guides to contain your content will ensure your designs translate properly to Webflow and ultimately to the customer.

We recommend designing on a desktop artboard no greater than 1400px and creating a global column or grid style with a max width between 960px and 1200px. Similarly, we recommend designing on a smaller mobile resolution, like 375px. Starting with the right resolutions and utilizing consistent containers will ensure the designs behave the same way on the web.

3. Use typography styles

How words relate to each other in a sentence is grammar. How words relate to each other on a page is typography. Grammar and typography are a set of rules that help us present our ideas in a cohesive way. Without them, the message is lost.

As developers, the first thing we do when building a website is to create the classes that define how the text will appear throughout the site. We create a stylesheet that defines how headings, body copy, subtitles, button text, and links, behave on various devices. Then, we re-use these styles (read rules) across the entire website, only breaking them in specific cases specified in the design.

Luckily, design programs make it easy to define your typographic rules from the start. We recommend creating a dedicated stylesheet for typography before you begin designing your pages. For each typographic element, create a mobile version, showing how it scales on mobile. Using saved styles consistently will make the design handoff a breeze.

4. Leverage global color styles

"Did they mean to use #f1f2f3 here or is this actually supposed to be #f4f4f4?"

Avoid making the developer play the hex code memory game, by creating and saving global color styles at the beginning of a project. Every major design program allows you to save color styles and apply them throughout the design. Before designing your first pages, create a basic color stylesheet with all of your frequently used colors saved and save them as global styles. These color swatches and styles will be created in the exact same way in Webflow ensuring ongoing consistency between design and development.

5. Define predictable spacing units

Just like typography, creating a set of rules in advance that define the space between elements in your layout is critical. There are numerous ways to manage spacing systems in a design program — nudging something until it "feels right" is usually not the best one.

When designing websites internally at 8020, we create a table that outlines our vertical spacing sizes and how they scale on different devices. Both designers and developers use this table as a reference when creating layouts. It can also be helpful to create "spacing components" in your designs for the fixed spacing sizes your define in advance.

In any case, defining a set of common spacing units in advance and communicating them to a developer is a must.

6. Use components and variants extensively

All websites tend to have the same basic building blocks — buttons, forms, links, navigation bars, footers, etc. The arrangement will differ per page, but the blocks will not. Since the building blocks will be used repeatedly it's best to create them once and re-use them every else. When design and development align on the basics, the final product tends to emerge easily.

A simple way to ensure designers and developers are aligned on the basics is to create a dedicated style sheet for common components. This style sheet should include common components like buttons with designs for relevant states (ie. hover, focused, active, etc). A well-designed component stylesheet will communicate styling for all states, variants, and mobile behavior.

7. Fill in the gaps with communication

Every minute dedicated to communication in the design phase results in thirty-seven minutes saved later in the project. This is a completely unscientific claim, but we'd be willing to bet it's true. The longer ambiguity or miscommunication lingers in a project the more costly it becomes.

A simple loom video in a comment, outlining how an interaction should behave, saves a developer hours trying to track down and wait for answers. Clearly marking which pages are ready for production will avoid that awkward "Oops sorry, that wasn't actually supposed to build" conversation.

As a general rule, before moving on to a new page, ask yourself "If I was seeing this for the first time, is there anything that would be unclear?" The developer probably doesn't know that the careers link in the footer should open your external applicant tracking system in a new tab. Season your design file with comments, sticky notes, and videos like you're the god damn salt bae.

While the details are important, having a conversation before kickoff to build trust and consensus is key. Even the best designers go off-grid or get carried away creating whimsical designs that would better serve a Dribbble portfolio shot than an end user. The developer might see things the designer misses. They'll have questions like:

"I wonder if they meant for this section to have 127 pixels of bottom padding when the top has 120 pixels"

"Do they know that excessive animation and scroll-jacking are bad for users with accessibility concerns"?

Establish in advance some reasonable guides for development standardization and a willingness (or lack of) to hear developer recommendations on specific features.

8. Accounting for the small details

If you take the 7 above tips for your design handoff process, we could call it a win. Aligning the core styles, building blocks, and clear communication is often enough to get a project to the finish line with relative ease. However, rarely is the road perfectly clear. There are often small bumps that aren't enough to derail the process but can be an annoyance. It's not hard to reach your destination when you know you have the road ahead of you. It can however be daunting if the road is littered with speed bumps.

Key takeaways:

• Labeling is fundamental. Some Figma files look great, but then you see the layers, they are not labeled in a way that the developer can understand them.
• Good communication is the heart of async work. We strongly recommend scheduling a review round with the designer to ensure the design is web ready before starting to build in Webflow.
• Establish a good rapport with designers and developers. Sometimes, feedback regarding design can come across as a critique, but in reality, most of the time the developers are just looking for clarification.  
• Have a verbal or written agreement for addressing questions. It does not matter if you use Slack, email, or messaging pigeons. What's important is that you find a way to consolidate feedback and present it gently.

8020's design handoff cheat sheet

Just because we truly value our no-code community we are going to share with you one of our newest cheat sheets. This gold of a checklist was created by 8020's head of development Max Joles and has helped us manage design handoff transitions smoothly for both small and large projects.

Designer handoff Checklist

• Exploratory designs separated from final designs
• Design on appropriate artboard dimensions
• Create styles for global typography — for desktop, tablet, and mobile
• Create global color swatches for UI colors
• Basic accessibility considered
• Define and utilize consistent containers
• Define and utilize consistent vertical spacing
• Provide tablet and mobile designs for 2-3 key pages
• Create components for frequently used elements
• Provide designs for every state of an interactive element
• Provide designs + content for any element that might be interactive and have hidden content
• Ensure developer knows where to find dynamic content
• Prep assets for export by cropping, aligning, and using the ideal file type
• Add design notes for anything that may be unclear
• Include a frame with SVG versions of the logo
• Provide fonts in a folder with only font weights being used
• A written statement provided on how developers should handle design elements that can't be built natively or are not consistent with a design system
• Make a copy of the file at the time of handoff and use it as a reference

Certainly, even if you tick every single one of the boxes, it does not mean the handoff process will be flawless. But, it will reduce the back and forth between the designers, developers, and stakeholders. And just as importantly, it will make the developers you are working with very, VERY happy.

Key takeaways

• Nailing your designs from the beginning ends up saving a ton of time, money, and resources.
• Clearly organized designs speak for themselves. They can eliminate many hours of meetings, documents, scope amendments, and failed expectations.
• Rushing into the building phase of a project can feel productive at first, but isn't. Take a deep breath, avoid the rush to build, and thoroughly finish and review the designs first.
• Tidying designs translate to a tidy web. Future builds, maintenance, and revisions will be cheaper, quicker, and easier.
• Designing is a much more nimble and flexible medium to collaborate than development. It's easier to iterate, comment, and collaborate with tools such as Figma multiplayer. Take advantage of these tools and get your devs involved from the start.

In the end, we believe that the term "handoff" is misleading. We don't want to receive a design and say goodbye to the designer. We want to shape a strong and collaborative relationship to ensure a successful transition from design to build. Sadly, we have not found the ideal term for this perfect scenario we envision. We will definitely keep exploring it in future Insider episodes and let you know if we think of a more fitting analogy.

Stay tuned! The next episode of Insider comes out in two weeks. In the meantime, we would love to know: Do you have a better metaphor for design handoffs? Share it with us here.

See you pronto, no-coder!

‍