Guides for Designers

Good Housekeeping

• Avoid generic frame names, such as Frame 201.
• Follow the naming conventions where appropriate.
• When using a frame to group items, name it Layout
• Do not use groups; frames provide more functionality in controlling their child elements
• Follow the guidelines for setting up page structures consistently
• Use version history in addition to branching, as it provides a solid rollback should issues arise, particularly when collaborating with others
• Where possible, use the design tokens, shared styles and component libraries

• Remove any files or assets no longer needed. Figma allows archiving projects so they remain available initially. Clearer organisation profiles and files make searching and working easier
• Remove any unused styles manually or with a plugin
• Keep Figma and component libraries up to date when prompted

 

• Finally, if any information is missing from this document, please suggest a change through the contribution process

Naming Conventions

Following the same naming conventions in Figma files creates a consistent experience for people working on files collaboratively. It is also generally good practice to keep files tidy and maintainable.

General

• Name all layers relevantly, not with defaults like "Frame", "Layer", "Rectangle"
• Use UK English for language
• Reset the layer names of text to match the content. Hit delete on a layer name to reset it or run this plugin
• All layers should:
• Start with a capital letter on each word, for example "Primary Button"
• Use spaces to break up words
• Use spaces between hyphens, for example, "User - Logged Out"

Components

• Name nested frames that control composition descriptively. In most components, use these two defaults:
• Layout - Used for any frames that structure or position elements
• Content - Used for frames where the elements inside are editable text or images
• Name frames that have a collection of nested components, for example lists or table columns, descriptively or use "Collection" as a fallback
• Use "+" instead of "&" or "And", for example "Primary Button + Icon"
• When updating an existing component, NEVER delete it and start a new one. Always update the original
• To make components private, use the "." prefix, not "_". Find out more about private components and styles in the Figma docs
• Create components in the correct files:
• Web - Create all components in their own file within the web project
• React Native - Create components in a single library file

Reserved Words

• Layout - Used on layers and frames that are only for structural use
• Content - Used on layers and frames that contain editable text or icons
• Collection - Similar to layout, but when the same elements are grouped as a preset e.g. lists
• Label - A default for any text that can be edited as ** Content **, if no other text makes sense

When To Make A Component

When working through designs, the need for a new component or a variation of an existing component may arise. Always run through the component pre-check to make sure that there is a need for something new.

If a need for a new component exists, work through the process outlined in the component contribution documents. If it is only a requirement for one squad or project, build it locally with the approach that this UI element may be promoted in the future.

Components in Figma

When working on a project and a need for a component update or creation is identified, there is some additional work required.

In the local project file, work with local components in the short term.

Meanwhile, also prepare the required information for the creation of the component:

• Proposal
• Annotations
• Documentation

Once the component is ready to be released by the development squad, a matching Figma component should also be prepared.

The Figma component can then replace local file components and be used for future projects.

The reason for the separation is that local components and final build components can vary due to limitations in Figma. Library components should always match the developed components as closely as possible.

Component Files

Never add comments to live component files.

These files serve as points of reference for the wider digital squad, and additional comments can lead to confusion.

Depreciated Components

When components are depreciated, the following

• "_/<Name>" - The component should have "_" as a prefix to hide it from the library
• ❌ Suffix - Add the icon as a suffix so it stands out in the layer panel
• Depreciated Layer - Add an absolute layer into each instance named "Depreciated"
• Updated Description - Update the component description with a note on deprecated, include any specific notes too

Using Version History

Although Figma autosaves work, it is also a collaboration tool. Moving in and out of files and other projects appears in the version history. Save work regularly. The following icons provide a quick visual reference to the file's state.

When To Save

• When work has reached a stage that may need to be referred back
• When projects are ready for publishing, reviewing or sharing
• When jumping into a colleague's file to help or collaborate
• Before branching off a file

Writing Good Commits

• Make titles short and transparent about the change
• Describe the changes being saved. Bullet points provide the most concise format
• Keep descriptions short. It saves expanding the view in the version history panel

Icon Key

• 🛠 In Build - Used when developing an idea
• 🚦 In Review - Used when putting a component up for review with teammates
• 💾 Published - Used when a component is approved and ready to publish