Setup & Structure

The workspace for Phoenix Group in Figma terminology is an organisation, below this there are teams, projects and files.Projects and files are set up into different groupings depending on their structure.

File types

Figma has two types of files: Design and Figjam.

These files can be grouped and organised within Figma teams using projects, which act like a folder in a file system.


Teams are based on the business function either a brand, component library or explorations. Within each team are projects.


Each brand team is set up roughly the same:

  • FigJam Collaboration files for this team.
  • Project Files - Projects are grouped logically based on the teams needs. Projects will contain files specific to a task. The example below illustrates the projects within the Standard Life team.
  • Sketch Archive - This should be used for reference only.

Projects can be set up to only invite certain members, if you can’t find a project it is worth checking you have access.

Files & Pages

Files are the core of where the work is carried out and clearly labelling pages in a structured way makes them easy to navigate.

Aside from Cover and Graveyard, you may have multiple pages of the same type.


Every file within Figma can be branched to work away from the main file. Our branching documentation covers our strategy to using branches in our projects.

Project Team Files

  • πŸ“˜ Cover - Cover file contains the project thumbnail.
  • πŸš€ Exploration - Indicates that these are only at idea stage. In some instances you may opt to make this a branch.
  • πŸ•Ή Prototype - Indicates a page contains a prototype. In some instances you may opt to make this a branch.
  • 🚦 In Review - Displays that files are under review by stakeholders.
  • πŸ›  Annotations/In Build - Files specific for development reference. It’s good practice to include the Jira ticket name in the page title e.g. πŸ› Β Jira-PG123 Annotations. We have further documentation available on creating annotation files.
  • πŸ’Ύ Published - Designs that have been built and published to a live site/app.
  • πŸ”¬ Research - Supporting notes and exploration can be contained here. UserTesting should be used as much as possible for capturing research.
  • ☠️ Graveyard - When files are no longer needed they can be moved to this page should they need to be referenced later.


The emojis should be used as prefixes to your pages as a visualy indicator for example

  • πŸš€ Mailbox Redesign
  • πŸ•Ή Mobile - New User Flow
  • πŸ›  JR123 - Dropdown User Story


The above emojis will change based on the status of the development of a page over time. The page title may also adjust for additional clarity. For example:

  • πŸš€ Mailbox Redesign - Ideas
  • 🚦 Mailbox Redesign
  • πŸ’Ύ Mailbox Redesign - Live

Component Files

  • Overview - Cover file contains the project thumbnail.
  • Platform - If a component differs per platform there should be a page per platform; Web, iOS and Android. No icon needed, this page should ALWAYS match the file name to reduce hierarchy in the asset naming.
    • Compositions - Drag and drop layouts using the parent component
  • Test Suite - Instances laid out to quickly test changes to master files

Web v Native Component Libraries

Our approach to the structure of our web and component libraries differs between the web and native platform.

  • Web - Each component has its own dedicated file to make it easier to manage and branch for component contributions
  • Native - iOS and Android components are located in their own dedicated files, because they are less likely to change

Because our Native applications are built on top of the Ionic Framework, our changes will be tied to their major releases.