Skip to content

Collaboration

A design system requires tight and frequent partnership across multiple disciplines. Currency outlines some its best practices and approach to collaboration.


Introduction

Collaborate, don't hand off

The idea of "handoff" can be misleading. Designs are never finished. We learn new information, reconsider previous decisions, and iterate on existing work. Designers and engineers should collaborate to design and implement great experiences. Throughout this iterative process, handoff occurs any time designers need to transfer ideas for development. This can happen repeatedly and iteratively. This document provides best practices for conveying and extracting design information for implementation.

See Dan Mall’s "Hot Potato Process"      compared to a traditional waterfall method:

The hot potato process includes passing work back and forth between a designer and engineer much more frequently than a waterfall method

Collaboration begins at the start of the design process. Designers should discuss ideas with engineers to get insights into development cost and implementation. Engineers should ask for clarifications where needed and provide feedback. Each substantial iteration of a design or implementation is an opportunity to share your work and collaborate. Don't focus on the idea of "handoff" too much; work together, communicate, and solve problems together.


Best practices

Figma file organization

A Figma file is usually the primary "handoff document". Clear labels and file organization helps others navigate and find information.

Organize and name groups appropriately

Organize your pages

Name pages appropriately and archive old pages or organize your file so its clear what design is the final/approved version.

You can also use Figma's Version History      to clean up your pages but preserve old content:

  1. Select the drop down menu next to the file name.
  2. Select "Show Version History".
  3. Select the + icon on the top right side panel - this will create a new version or (snapshot in time) of the entire file.
  4. You can now delete pages you no longer need but still access them in Version History.

Prototype interactions

If you are working on an interactive design, make a prototype to detail functionality and interaction (hovers, interactive range sliders, graphs that animate, etc).

Review interactions with your engineering partners for feedback and clarification. For example, in the above example the new monthly payment is shown before the slider stops moving, which may not be possible.

Currency components

Make sure it's clear when Currency or other reusable components are being used. Components should be labeled or otherwise annotated.

⚒ Engineers: If you're not sure if a Currency component is being used, ask your designer. If the existing component doesn't match how it's being used in design, let your designer know and open a Currency request if needed.

Spacers and spacing

Spacers are visual blocks that convey which Currency unit of spacing is being used between elements.

🎨 Designers: Make sure all spacing between elements is accounted for by spacers. As you move through your design do NOT delete these spacers. You may put them in a group at the top of the layer stack and toggle them on and off as you see fit.

Layout and grid

The layout of elements on a page can have a lot of detail, especially when you consider flexible elements and responsive behavior. Care and collaboration will be needed to make sure design intent is implemented and responsive cases are handled well.

Here's the high level workflow for a team when implementing a new layout:

  1. Designer begins to design an experience in Figma. Using the Figma grid overlay, Currency spacers, and Currency components as much as possible.
  2. Designer begins to loop in an engineer during the handoff.
  3. Engineer asks about responsivity, columns.
  4. Engineer starts to implement with layout toolkit Currency (base-styles classes, CenteredContainer, CSS Grid rules).

Text annotations explain layout

Figma files should aim to explain the layout of elements using text annotations. This helps guide the layout of containers to the grid.

🎨 Designers: Consider the following questions when preparing a Figma file for handoff:

  • How do elements lay out on the grid? Is the visual element itself aligned to the grid, or is there a container around it? Is there spacing around the element?
  • Are elements flexible or fixed-width? Elements can be flexible by using percentage sizes, or by being aligned to grid columns. How is the size of the element determined and how is it responsive? How does it behave on a wide viewport, versus a narrow one?
  • If an element is aligned to the grid, how many columns does this element span? This should be clear using the Figma grid overlay, but annotate if not.
  • Is it clear how much spacing exists between elements? Is the spacing using grid gutters, a spacing unit (from our spacing system), or both? Are all spacers on so engineers can see the spacing?
  • Are any elements centered within a container or aligned to another element? Are any elements sticky?

Review and collaborate on designs

Once a designer has taken a first pass in Figma, they should review with their engineering partner(s):

  • Review the annotations explicitly with the engineer. Discuss any questions that may arise.
  • Is the page's content within a standard max-width container (implemented using <CenteredContainer>)? What elements are aligned to the grid?
  • Discuss how the layout behaves responsively at above and below the wide breakpoint (768px). How should elements stretch/flex/stack? How do elements work on mobile? Walk through any specific interactions.

Review and collaborate on implementation

To hammer out details, engineers should collaborate with their design partner(s) and do multiple rounds of review as they iterate.

  • Do elements line up the way they are expected to?
  • Does the responsive behavior work properly at different viewport sizes?
  • Do things look ok with different types of dynamic content (e.g., few items vs many items, long text vs short text)?