Design > Development Handoff

Owned by Rachael Mink
Last updated: Feb 05, 2021 by Drew Palko
3 min read

Purpose Statement

This document serves as a general guide for the design handoff process. Not every handoff will be identical. A good general rule of thumb is this: Designers and Developers should aim to keep things clear and consistent throughout the handoff process.

General Procedure

A design is complete when we have written approval from the Product Owner on the Jira ticket. Once designs are approved by the Product Owner, and tickets are created for IT, the design will be broken out into pages in Figma to match the tickets. The Designer will be available for questions (see the Communication section below for more information) from Developers until the designs are built and released. The UI Kit will be updated when necessary (new components and updates to existing components).

Communication

Communication on the Jira ticket should be reserved for the following:

  • new requests

  • new functionality

  • questions based on requirements

  • questions based on functionality

Communication using Figmaโ€™s Comments should be reserved for the following:

  • questions about specific elements/comps

  • questions about styles

Communication should be placed on both Jira and Figma if you are unsure of where it should go.

All comments in both Jira and Figma should include tags.

Free Figma accounts are required in order to make comments. Your Ferguson email address is required when creating your account. Youโ€™ll be added to the Ferguson organization in Figma when using your Ferguson email.

Communication should happen in a timely manner between Designers and Developers. Each morning the Designer should review and respond to any questions that were specifically addressed to them from the Developers no later than 9am ET. If an answer is not available at the time, the Designer should respond that they received the question and give an estimate of when they can provide an answer.

Epic: Figma links to the page that tells the story (sectioned out by logical sections)

Story: Figma links to individual pages that are green-checkmarked

(SCREENSHOTS OF THIS SETUP WILL BE COMING SOON)

Documentation

Just-in-time documentation - The goal is to provide the least amount of documentation that is required by IT. This is done by providing more documentation than we think is needed and fine tune/lean it over time.

UI Standards Documentation should be utilized when possible.

Epic documentation will live in Confluence. Story documentation is the ticket itself.

Design Changes

  • All components in the same state within comps on a page in Figma should match from comp to comp. If they are going to be different, the Designer should create a new page.

  • When comments are created in Figma, the Designer must respond to the comment before resolving it

  • Once designs are handed off to Developers, any changes to designs in Figma must be commented by a Designer. These comments can be resolved by the Developers.

  • Designs that are in progress and not yet approved should have an empty checkbox beside them in the page title. Designs that are approved and ready should have a green checkbox beside them in the page title.

  • A star icon should be used in the page title for the page that is the single source of truth (epic)

Unapproved Design Elements

  • Out-of-scope elements should not be included on delivered comps (green-checkmarked pages)

  • Any future states should be a separate page in Figma

Naming Convention

  • Designers should be consistent and clear across the board on all files

  • When a Figma page is tied to a ticket, that pageโ€™s title should include the ticket number

  • The Figma file name should be named after the Epic

  • When possible, name layers based on potential css properties or element

Handoff Artifacts

  • Jira Ticket

  • Figma link(s) to comps/prototypes

  • Documentation (not always)

  • Bullet points of design changes/decisions included on Jira tickets alongside links to designs/prototypes

Software

Switching or Introducing New Software: The team wanting to switch or introduce new software must consult with other teams they are collaborating with before any changes/additions can be made. All aspects of the software must be considered from various teams: cost, versioning, archiving, sharing, collaborating, etc. Once the switch is approved, training must be provided to make sure other teams know how to work with each other in the new software. Procedures and documentation must be updated to include any new ways of working with the software.

Figma Tips & Tricks