The handoff between Designers and Developers is vital to the success of any project. There may be multiple points where designs are passed to development, and experience shows that successful handoffs are best achieved through ongoing collaboration. When collaboration starts early, remains organic, and is consistently practiced throughout the process, it fosters more creative solutions and better risk mitigation.

While each project will have its own unique collaboration needs based on the team, timeline, and budget, there are some common guidelines that can serve as a starting point—outlined here in the Devsigner Handoff guide.

Table of Contents

Starting Smart

Blue-sky thinking is an exciting phase in any project, but it's also the time to start considering foundational elements. For instance, if you're exploring three-column layouts, you'll want to ensure that your grid system is divisible by three to achieve equal column widths.

Cloud Graphic

If you're aiming for an edge-to-edge experience in the browser, consider how it will affect text line length and readability.

And what about themes? Will they be applied at the site level, page level, or component level? How about motion? Are you planning to incorporate large, dynamic animations, or will the focus be on subtle micro-interactions?

Let's not forget about the canvas either. As concepts iteration starts, define a max-width for the content and design against that size. Designing at say 1280px when the max content width will be 1600px, misrepresents the size of fluid typography, requires image sizes to be remapped, and opens the door for misinterpretation.

The takeaway here is that a Designer who can articulate this level of thinking and ideation, will enable a Developer to begin understanding the system's vision and make informed architectural decisions.

Accessibility

Making your website usable for all users, regardless of how they need to access the content, is a crucial part of the design process. Here are some key considerations Designers should keep in mind to help ensure foundational accessibility, and facilitate an effective handoff to Developers.

Aa
3.76 ratio

Color Contrast: Ensure that text has sufficient contrast against its background to be easily readable by users with visual impairments. Use a contrast checker in your design tool to confirm that your color choices meet, at a minimum, the WCAG 2.1 AA accessibility standards.

Readable Typography: Choose fonts that are legible at various sizes, and set sufficient line height and letter spacing to aid readability. Best practices align with setting line height to approximately 1.4 to 1.6 times the font size, and using 16px as the minimum font size.

Keyboard Accessibility: Ensure all interactive elements (buttons, links, form fields) are easily navigable and operable using a keyboard, while designing clear and visible focus indicators to help users track their location on the page.

Responsive Design: Ensure the design can adapt to all screen sizes, while keeping the source order consistent. This will help maintain accessibility and a smooth reading flow for screen readers.

Forms and Labels: Ensure all form fields have clear, descriptive labels that are properly associated with their inputs, to help screen readers convey the correct information.

Proper consideration and documentation of these elements will allow Developers to establish and maintain accessibility standards throughout the development process.

Breakpoints

Breakpoints ensure the design is responsive across different devices. While the number of breakpoints considered to be best practice will vary widely based on who you ask and what day of the week it is, two or three breakpoints are typically sufficient. If your design requires more, be sure to convey that information early, as it will have an impact on development effort, QA, and maintenance of the Design System.

Here's an example of commonly used breakpoints, and a three-column grid that changes layout based on them. Note that 1025 is used for Large, to allow Tablets in Landscape to use the mobile version of a navigation system.

Modern CSS : Container Queries

Container Queries offer new possibilities for more creative designs, allowing elements to adjust based on their parent container’s size rather than the viewport. This offers more flexible and responsive designs, where components adapt to the space they are given, regardless of the overall screen size.

Note that Container Queries achieved Baseline 2023 status late in the year. If your project team has a skilled CSS Developer, it's highly beneficial to start early discussions on how Container Queries could enhance your project.

Colors

When it comes to colors, each value will be defined as a CSS Custom Property in development, so it’s crucial to establish a naming convention that is both intuitive and flexible enough to accommodate future additions.

Common naming conventions use prefixes like --brand, --core, --primary, and --theme. Suffixes like -100, -200, -300, etc., are often used to indicate variations of a specific color.

Naming conventions that align with a company's brand are also widely used and can be especially helpful for Content Editors if colors are exposed within a CMS's UI.

For color values, HEX (e.g., #RRGGBB) is typically the default choice. However, CSS now supports a broader range of color syntaxes, enabling access to wide-gamut colors and making palette generation and color adjustments easier.

Among these new options, OKLCH, part of the CSS Color Module Level 4, is emerging as the preferred notation for its accuracy and flexibility. If you're unfamiliar with OKLCH, consider reading OKLCH in CSS: why we moved from RGB and HSL by Evil Martians, and Relative Color Syntax — Basic Use Cases by Chris Coyier.

Spacing

Nothing impacts a Design System more than spacing, as every element requires some form of positioning between surrounding elements. Because of this, it’s crucial to invest time upfront in defining a strategy that considers the following:

Naming Convention

Choosing a naming convention can be challenging, particularly when it comes to ensuring consistency and clarity. A practical approach is to align with CSS Logical Property naming, using the prefix--spacing-inline for horizontal values and --spacing-block for vertical values. Developers should be familiar with these terms as they align with CSS standards.

The more complex aspect is defining the suffix convention for each specific value. Common patterns include:

Each of these patterns has its pros and cons. However, experience shows that T-Shirt Sizing is both intuitive and flexible. For example, a vertical spacing system might look like this:

This approach not only supports easy adjustments, but also allows for intuitive additions, such as needing to slot in --spacing-block-s-plus for a spacing value of 25px.

Whatever naming convention is chosen though, ensure it's standardized for both horizontal and vertical values, to provide clarity and minimize potential errors.

Base Multiplier Approach

As you establish your spacing values, especially in relation to a vertical rhythm, you might want to consider the Base Multiplier Approach. This approach utilizes a base value (e.g. 8px), from which variables are defined by multiplying the base value by a multiplier.

For example, the value of --spacing-block-s might be calc(8px * 1.5), creating a value of 12px, and --spacing-block-m might be calc(8px * 2) for a value of 16px.

While this approach can help provide a consistent rhythm across your design system, it can sometimes feel too prescriptive and less creative.

Also note it may be difficult to represent what's happening in your design tool of choice, so you'll want to be sure to clearly document the base value and what the multipliers are.

Remapping Values per Breakpoint

Designing for mobile-first can help validate spacing values early, and indicate how many breakpoints will require remapping. The key here is to remap the values though, not the variable names.

For example, --spacing-block-m might be used for both Small and Medium Screens, but the value then remapped for the Large Screen breakpoint. This method not only results in a leaner CSS codebase, but one that is also more readable and maintainable.

Keep in mind that remapping values is often specific to vertical spacing, as horizontal spacing typically doesn't need to change. Some exceptions though, are for larger layout controls, like spacing at the edges of the browser. For these instances, it's beneficial and more clear to handle as their own unique variables, such as --page-gap or something similar.

Finalizing Your Spacing Strategy

As your spacing system starts to solidify, remember to communicate with your Developers often, and keep these final considerations in mind:

Grid

Establishing a Grid System

As mentioned in Starting Smart, a grid system should accommodate common layout options, particularly those with an even or odd number of columns. The most recognized layouts are based on 2, 3, 4, and 6 equal columns. This is why typical grid systems are based on 12 or 24 columns—both numbers can be evenly divided by these layouts, making it easier to align content of other components.

Single Grid vs. Component-Specific Grids

The idea of using a single grid for every component in the system is common, but it's worth considering whether this approach is ideal for your project. Depending on the content, you might not need a 12- or 24-column grid for everything, and each component could instead have its own simplified grid. Either approach can be valid, as long as you choose one and stick with it. Mixing and matching grids later on can lead to visual inconsistencies and coding challenges.

Adapting Grids for Different Screen Sizes

Once you've chosen your grid approach, ensure that it translates well across all screen sizes. For instance, if you're using a 12-column grid, you probably won't need all 12 columns on small screens. A typical approach is to simplify the grid to 2 or 4 columns on small screens, which streamlines development and reduces the amount of code needed to layout components across all screen sizes.

For medium screens, using 12 columns is common, but you could also base it on 6 columns. The key is to keep the math simple and ensure that the columns are equally divisible, avoiding transitions like 12 columns on large screens to 5 on medium screens, which can create layout issues.

Managing Grid Gaps

As mentioned in Spacing, setting up a --grid-gap variable to control spacing between grid columns and rows is essential. This variable's value can be remapped based on breakpoints, and you'll need to decide whether the spacing should be fixed or flexible depending on the browser width.

Leveraging CSS Grid for Creative Layouts

It might surprise some, but CSS Grid has been fully supported by browsers since 2020. Despite this, truly creative layouts remain rare. If your team has a skilled CSS Developer, it’s worth collaborating to explore new layout possibilities that fully utilize CSS Grid’s potential.

Handling Inset Content

Grids are column-based, and a common design choice is to inset content, such as starting content in column 2 instead of column 1. However, consider what the design is trying to convey. Is it purely for visual interest, or is it meant to establish hierarchy between components?

If it's for visual interest, ensure that the alignment difference works well with components that aren't inset. If it's to convey hierarchy, consider whether an inset is the best solution, as it will affect equal column layouts. For example, on a 12-column grid, insetting content by one column on each side leaves you with 10 columns, which eliminates your ability to use 3, 4, or 6 equal column layouts.

Max-Width vs. Inset Content

If your design system uses a grid, the goal should be to utilize all 12 columns for content layout, with insets used sparingly for visual interest. When it comes to establishing hierarchy between components, a system of max-width values is often a more effective and consistent approach .

Consider how insets affect content scaling. In the below example, centered content that's inset on a grid will start to scale once the browser edges hit the 1200px grid width. In contrast, centered content with a max-width won't scale until the browser edges hit the element's width. Understanding this behavior is crucial, as it impacts the user experience and requires more code to update column spans per breakpoint.

Typography

Fluid System

Modern typography systems should allow font sizes to scale fluidly based on screen width. This approach ensures text is appropriately sized for the user’s device while simplifying the CSS required to implement the system.

Among the various CSS methods to achieve fluid typography—such as calc(), clamp(), and min()—the clamp() function offers the most control, as long as you're using a formula that accounts for minimum and maximum viewport widths and font sizes for each element.

To set up this system, establish minimum and maximum font sizes for key elements like h1, h2, h3, h4, h5, h6, p, and li. The minimum size should correspond to the smallest viewport width (e.g. 320px), and the maximum should align with the project’s defined maximum content width (e.g. 1600px). For consistency in body text, the p and li tags should typically share the same font size values.

With the correct formula, this will allow you to define an element, like a p tag for example, to have a minimum font size of 24px on 320px width screens, a maximum font size of 56px on screens 1200px and wider, and adjust fluidly between those sizes based on the screen width. Here's what that looks like:

The Wonder of Fluid Typography

Content Editor Flexibility

To achieve an accessible page structure while meeting SEO requirements and design needs, Content Editors should be able to choose appropriate heading tags and optional class names within a CMS. However, if certain components require restricted options, ensure these limitations are clearly documented and communicated early.

For setting up class names, a common convention is:

Classes for font weight (e.g., bold) or style (e.g., italic) are typically unnecessary, as these should be handled with the appropriate HTML tags.

Base Font Size

The base font size (typically 16px) should be mapped to the p tag, as this will be the most frequently used size across the site. For any optional paragraph sizes, set up specific classes like .p-intro to manage these variations.

Line Height and Bottom Margin

Line heights should be set with unit-less values (e.g., 1.25), to allow them to adjust based on the fluid font size. Typically, these values won’t need to be adjusted across breakpoints, but if they do, be sure to document this clearly.

For defining bottom margins, determine whether the margin should remain a fixed value (using a defined spacing variable) or be related to the font size (using em units). As an example, setting the bottom margin to 0.5em, would result in a value of 21px when the font size is 42px, and 36px when the font size is 72px.

If the em approach is chosen, it’s recommended to discuss it with a Developer, and prototype early to validate the behavior. Additionally, you'll need to determine how to clearly represent this within your chosen Design Tool.

Scale Generators

Type Scale Generators can help define font sizes based on a specific ratio. If you think your project could benefit from this, two reliable tools are Baseline's Type Scale Generator and Modular Scale, which allows you to customize your ratio.

Other Considerations

Images

Images often make up a significant portion of a web page’s file size, directly impacting performance and server costs. Over-specifying image variations, such as defining unnecessary sizes in the srcset attribute or providing 2x images for non-high-resolution originals, can lead to inefficiencies and increase maintenance complexity.

Unfortunately, Developers often take this type of overly broad approach to image handling. However, with early and close collaboration between Design and Development, a clear Image Strategy that prioritizes performance and minimizes maintenance can be created.

To do so, address critical questions like these at the beginning of your project.

To get more specific, if the Design System intends to allow multiple sizes and aspect ratios, it’s vital to establish some guardrails and work with a Developer to ensure feasibility. These guardrails will play a key role in a Content Editor being able to meet the intention of the Design System, so consider them carefully.

For example, define scenarios where a Content Editor might not need to choose a size, just the image itself. This can help not only simplify the options available in the CMS UI, but also the development of the Image component. Also, look to group scenarios based on specific options, as it might make sense to create multiple Image components to keep choices available in specific contexts clear.

Ultimately, the goal is to create a performant, intuitive, and maintainable solution, that uses only the image resources needed. There’s no one-size-fits-all solution, but collaborating early on these types of core questions, will help set your project up for success.

Components

When designing components, consider these key points to keep development on track and able to address potential challenges early.

Devsigner Handoff

This guide was created to help Design and Development teams work together more effectively and efficiently, by covering key aspects of the handoff process. As new technologies emerge and best practices evolve, additional updates and sections may be added, but will always be rooted in actual experience. Companies and teams are encouraged to revisit this document periodically, and reach out with questions or interest in adding me to your team.