Guides for Designers

Using Figma consistently across the team makes it easier to share and collaborate. This document is specific for designers whilst other guides in this section can be referenced by any member of the product teams.

Good House Keeping

  • Make sure all layers, frames are named to be clear to understand, don’t leave default names e.g. Frame 201. Follow the naming conventions where appropriate. If you are using a frame to group items together name it layout.
  • Don’t use groups. Frames provide more functionality in controlling their child elements.
  • Follow the guidelines for setting up page structures consistently.
  • Make use of the version history in addition to branching as it provides a solid rollback should you run into issues, particularly collaborating with others.
  • Use shared styles instead of customisation. Although you may know hex codes off by heart, using shared styles creates a more consistent experience and documents easier to manage.


Example of using styles

Example of using styles

  • Remove any files or assets no longer needed. Figma allows you to archive projects so they are not completely removed initially. The clearer our organisation profile and files are the easier it is to search and work.
  • Remove any unused styles manually or with a plugin.
  • Keep Figma and your component libraries up-to-date when prompted.


Screenshot of updating components

Screenshot of updating components


  • Finally, if things are missing from this document please submit suggestions on our teams Figma channel.

Naming Conventions

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


  • All layers should be named and relevant, not the defaults of “Frame”, “Layer”, “Rectangle” etc.
  • Use UK English for language.
  • The layer names of text should be reset to match the content. You can hit delete on a layer name to reset it or run this plugin.
  • All layers should:
    • Start with a capital letter on each work e.g. “Primary Button”
    • Use spaces to break up words
    • Use spaces between hyphens e.g. “User - Logged Out”


  • Nested frames created to control composition should be named descriptively. In most components you will use the two defaults:
    • Layout - Used from any frames used to structure or position elements
    • Content - As above the elements inside will be the text or images that are editable
  • Frames that have a collection of nested components e.g. lists or table columns should be named descriptively or “Collection” as a fallback
  • Use “+” instead of “&” or “And” e.g. “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 “_”. You can find out more about private components and styles in the Figma docs
  • Create components in the correct files:
    Web - All components should be created in their own file within the web project
    iOS Native - iOS components should be in the iOS library File
    Android Native - These components should be added to the Android 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
Example of naming frames

Example of naming frames


  • Collection : Similar to layout but when the same elements are grouped together 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

As you work through designs you make come across the need for a new component or a variation of an existing component. It is always worth running through the “Component Pre-Check” to make sure that there is a need for something new.

If there is a need for a new component that you can work through the process outline in the Component Contribution documents. If it is only a requirement for your team or project that you should build it locally with approach that this UI element may be promoted in the future.

Components in Figma

If you are working on a project and you have identified there is a need for a component update or creation there is some additional work.

In your local project file you can work with your local symbols in the short term.

Meanwhile you should 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 team, a matching Figma component should also be prepared.

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

The reason for the separation is that your local components and final build component can vary and we always want our library components to match the developed components as closely as possible.

Component Files

We should never add comments to these live component files. These files are used as points of reference by the wider digital team and additional comments can lead to confusion. Create a branch or raise an issue in the #compound slack channel.

If styles are missing them create a branch with your proposed adjustments.

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 on 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 depreciated, include any specific notes too
Depreciated Component Example

Depreciated Component Example

Using Version History

Although Figma autosaves your work it is also a collaboration tool. Diving in and out of files and other projects will be marked on the version history. It is a good idea to save work regularly and the following icons make a quick visual reference to the state of the file.

Screenshot of version history

Screenshot of version history

When To Save

  • When you have got to stage in your design that you may want to refer back to
  • When projects are ready to be published, reviewed or shared
  • When you are jumping into a team mates file to help or collaborate
  • When you are about to branch off a file

Writing Good Commits

  • Make your titles short and clear as to the change
  • Describe the changes that you are saving, bullet points are the most concise way
  • Try and keep the descriptions short, it saves expanding the view in the version history panel

Icon Key

  • 🛠 In Build - When developing out an idea this is a good marker
  • 🚦 In Review - If you are putting a component for review with team mates
  • 💾 Published * When a component has been approved and ready to publish