How We Handoff Our Designs to Developers

Introduction

Creating captivating and user-friendly interface designs is one thing, but handing those designs over in a way that is comprehensive, easy to understand, and actionable for developers is another. We go the extra mile to ensure that the handoff process of our B2B SaaS product designs and design systems is as smooth as possible. Our methods and tools are tailored to help engineers grasp our designs and code them with ease, saving time and reducing potential bottlenecks. In this article, we delve into the nitty-gritty of our handoff process and the tools we employ to achieve our goals.

The Power of Design Systems

Let's start by talking about design systems. A design system is more than a style guide or a pattern library. It is a comprehensive, evolving document that contains the standards for design and front-end code. It includes everything from style guides, pattern libraries, component libraries, coding standards, design principles, and documentation. It is the single source of truth that groups all the elements that will allow teams to design, realize, and develop a product.

One of the core principles of our design work is consistency. It's something we strive for in every project we undertake. To achieve this, we employ design systems. Once we have collaborated with a client and confirmed the visual identity of a new product, we implement this style on the components. We then build a design system based on these stylings.

Our design systems are not just a collection of patterns and styles. They are meticulously organized and documented to facilitate easy usage and provide a clear roadmap for developers during the implementation phase. This practice helps maintain a consistent user experience across different parts of a product and reduces the design debt in the long run.

For a more in-depth understanding of what our design systems consist of, how we present them, and why they're valuable, we invite you to read our internal article on the topic.

The Role of Design Tokens

In our quest for seamless design-to-code transition, design tokens play a pivotal role. These are the basic atoms of a design system, representing the values for a design attribute in a semantic and platform-agnostic way. They can include anything from colors, typography, spacing, to animation timings, and more.

We use design tokens as a bridge between the designers and developers. They help us manage our clients' design systems more effectively and ensure that we do not stray too far from the frontend while designing. Moreover, design tokens allow us to set constraints for interface design, which are crucial for maintaining consistency and facilitating easier implementation.

For a more comprehensive explanation on how we use design tokens, read our internal article discussing design tokens.

Greatly Reduced Time to Implement

Instead of manually translating each design attribute from Figma to code, developers can automate this process with design tokens. This reduces errors and saves significant time, especially in large-scale or complex projects. In essence, design tokens allow developers to focus more on building functionality and less on manual, error-prone tasks of translating designs into code.

Types of Design Tokens

Design tokens often exist at multiple levels to support different degrees of abstraction and use:

1. Core Tokens: These are the most basic and foundational tokens in the design system. They define the fundamental values in a design language like colors, font sizes, and spacing. For instance, a core color token might be -color-primary: #3366FF;
   
2. Semantic simplified Tokens: These tokens use core tokens to define the meaning in a specific context. They are associated with a particular use-case or semantic meaning. For example, a semantic token for text might be -color-text-primary: var(--color-primary);, implying that the primary text color in the system uses the primary core color.
   
3. Semantic granular Tokens: These tokens use core tokens and semantic simplified tokens to define the colors of component groups: Action components, Feedback components, Input components, Navigation components and Generic UI components. The main reason of Semantic Granular Token existence is to group components and control all of them at once, for example if I want to change the color of primary buttons, but not of the rest of the interface. Here’s an example of a semantic granular token for a active primary buttons: -semantic.color.actions.primary.default.background: var(--semantic-primary-fg);
   
4. Component Tokens: These tokens are tied to specific components in the design system and dictate how the component should be styled. They typically use semantic and core tokens to define their values. For example, a component token for a button might be -button-background: var(--color-primary); and -button-text: var(--color-text-primary);, defining the background and text color for a button component.

Exporting Designs to Code

Having a design system and the necessary documentation is essential, but the ultimate goal is to translate these designs into code. This is where Style Dictionary comes in.

Style Dictionary is a tool that we use to export CSS and JS stylesheets. It allows us to transform design tokens into actual code, saving a significant amount of front-end development time. This tool takes input files with design tokens defined, processes them, and then generates output files in various formats and languages, including CSS, JS, Swift, and Android XML. We use Style Dictionary to export Design Tokens from Figma to CSS + JS.

Here's a simplified workflow of how we use Style Dictionary to export Design Tokens from Figma to CSS + JS (please skip if you’re not a developer):

Define Tokens: Design tokens are defined in JSON files. These can be structured according to the levels of abstraction (core, semantic, and component tokens).

Transform with Style Dictionary: Style Dictionary takes these JSON files, processes them, and outputs them in various formats. For example, you can generate a CSS file with custom properties, a JS module with constants, or even native code for Android and iOS.

CSS Output:

JS Output:

Use Tokens in Components: Once the tokens are available in the desired formats, developers can use them to style and build components. This ensures design consistency, as changes to the tokens will propagate across all platforms and components.

Share generated CSS + CS files with clients. After all of this is done, we have ready-made CSS + JS files for our clients that they can use to develop our designs faster and with more consistency. This of course doesn't mean that the frontend is now magically coded, but at least it's a start.

This approach allows for a single source of truth for design attributes and facilitates a smoother transition from design to development. It also provides a more maintainable and scalable way to manage design across multiple platforms and technologies.

The result is a more streamlined design-to-code process, and the generated code is consistent and based on the agreed design principles. As a result, it reduces the possibility of errors or inconsistencies that may arise when manually writing code from design specifications.

Documentation

Documentation forms the backbone of any well-planned design handoff. It's not enough to have a stunning design if developers are left guessing about how it should be implemented. That's why we provide detailed annotations about the main components, explaining their purpose, behaviour, and states.

Additionally, we utilize tools such as Storybook, an open-source tool for developing UI components and pages in isolation. Storybook serves as a playground for developers, allowing them to interact with components outside the context of the entire application. This, in turn, speeds up the development process and ensures consistent component implementation, thereby enhancing overall product quality.

For larger organizations, we offer assistance in choosing the best design system documentation platform that suits their needs. Options include Zeroheight, Supernova, Specify, or Storybook. Each platform has its strengths, and the choice depends on the specific requirements of the organization, such as:

• Zeroheight: This tool is a design system documentation tool that is more efficient than generic documentation tools. It provides direct (read-only) access to your design system via an integration. It syncs any design system changes automatically, saving time and effort.

• Storybook: More developer-friendly than Zeroheight, Storybook allows developers to contribute rendered code snippets, which are interactive and self-contained. It's an excellent option if you want your design system to include rendered code snippets. It fosters close collaboration between designers and developers, although its integration with design tools like Figma is not as seamless as Zeroheight's.

• Supernova: A newer entrant in the field, Supernova provides a fantastic design system management solution for both designers and developers. It combines the seamless feel of Zeroheight and the developer-friendliness of Storybook. Its standout feature, "blueprints," automatically converts design system styles and components to code. Supernova integrates with design tools like Figma similarly to Zeroheight.

• Tokens Studio: This tool helps convert common styles into design tokens. As the design changes, so would the tokens, and developers can either re-import them with ease or set up a two-way sync. It's especially useful for solo makers and small product teams who don’t particularly need a complete design system management solution.

Figma's "Dev Mode"

Figma recently introduced "Dev mode" which is a great extension to the product design platform that we use. It clearly displays all the necessary information for devs to easily implement the designs, test components and view changes.

"Dev Mode in Figma design gives developers everything they need to navigate design files and transform designs into code. With Dev Mode, designers and developers stay on the same page, making sure important details aren’t lost in the handoff process."

Conclusion

At Outframe, we believe in providing more than just design files. We take it upon ourselves to ensure that our designs are easy to understand and implement. From the use of design systems and design tokens to detailed documentation and use of tools like Style Dictionary, we aim to make the handoff process as seamless and efficient as possible.

If you're interested in experiencing this smooth transition from design to code, feel free to get in touch with us. We'd be more than happy to help you with your next project.