...
Free Figma accounts are required in order to make comments. Your Ferguson email address is recommended 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.
...
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.
...