Skip to main content

Ignore parts of the token name for variables and styles

The community would like to simplify the names that consumers of tokens using the Figma UI see. Today, we can ignore the first part of the token name for styles, but this does not yet exist for variables.

Additionally, there is a request to have a setting to select how many levels of a token name might be ignored when creating styles and variables using Figma using the plugin.

Example - the token name is ob.s.typography.app.heading.H2 and the user would like 3 levels to be ignored in the styles: (1)ob.(2)s.(3)typography, so it would create a style like "app.heading.H2"

User Story

As a design system architect,
I want to selectively ignore parts of token paths when exporting from Tokens Studio to Figma,
so that the consuming users in Figma do not encounter irrelevant nested groups, making variable names more readable and manageable.

Detailed Description

Tokens Studio users often export their tokens to Figma styles and variables to be used by cross functional team members.

However, the current export process introduces deep structures with unnecessary prefixes that are not relevant to the end-users in Figma. This results in long and less readable styles/variable names.

To address this issue, the following features are needed:

  1. Token Path Manipulation During Export:

    • Provide an option to ignore specific parts of the token paths (as available for styles) during the export process to Figma. This ensures that the exported styles/variables do not include unnecessary nested groups that complicate the user experience.

  2. Simplified Variable Naming:

    • Allow for the removal of prefixes or parent groups that are only relevant within Tokens Studio but not needed in Figma. This simplifies styles/variable names, making them more intuitive and user-friendly for design system consumers in Figma.

  3. Customizable Export Settings:

    • Offer customizable export settings within Tokens Studio to define which parts of the token paths should be ignored or included. This flexibility ensures that different teams or projects can tailor the export process to their specific needs.

Example Scenario

  1. Tokens Studio Setup:

    • Tokens are organized with prefixes for internal management, e.g., ob.s.brand.primary.

  2. Export to Figma:

    • During the export process, the prefixes ob.s. are ignored, resulting in Figma styles/variables like brand.primary.

  3. Figma User Experience:

    • Designers using the Figma styles/variables see a simplified structure without unnecessary nesting, making the variables easier to find and use.

Status: ๐Ÿ’ก Requests4 comments

Log in to comment and vote

Comments4

  • webmaestro

    โ€ข

    Nov 22, 2024

    This feature would be HUGE for our org. Indeed, we chop off (in Figma) the first 2-3 levels of our token taxonomy after exporting from TS into Figma Variables. Even if Figma one day makes its styles panels resizable, our (sometimes) long taxonomy would be problematic for our end-users.

    - - - - - - - -

    Now, Iโ€™ll add something moreโ€ฆ though this might warrant a totally different feature request (if so, let me know):

    For styles (which we utilize for semantic typography tokens in Figma), we actually reformat the style names slightly as well. Again, this is in Figma after exporting from TS. Example:

    Actual token: sds/semantic/typography/title/primary/1

    Renamed in Figma: typography/title/primary-1 (note the reformat to โ€˜primary-1โ€™ on the end)

    We do this b/c testing found that this is slightly more readable/intuitive. People preferred seeing โ€œprimary-1โ€, โ€œprimary-2โ€, etc. under a โ€œtitleโ€ folder than just โ€œ1โ€, โ€œ2โ€, etc. under a โ€œprimaryโ€ folder.

  • Chris Kerr

    โ€ข

    Apr 19, 2024

    This would be quite helpful I think. Given Figma's limited real estate in their non-resizable properties panel and given some of the token structure is not always required to identify the scoped styles like text, it could make usage of styles easier for the design team. Also given the flexibility in how tokens are named, limiting to just the first prefix might not offer the flexibility needed to deliver the current functionalities intended outcomes

  • Denis Sereda

    โ€ข

    Apr 17, 2024

    With fine-grained settings per category? :-)

  • Sam - Tokens Studio

    โ€ข

    Apr 16, 2024

    @Keegan Edwin maybe add this as a comment on the roadmap item to see how the community who is beta testing this can chime in?