Three Things to Keep in Mind for Naming Conventions of Your Design System

The highly-anticipated updates to Figma would introduce a new way of interacting with multiple states of a component -- dubbed variants -- by grouping your components into multiple states divided by a slash ( / ).

Or if you’re starting on UI design and want to prepare for larger-scale projects (where you are not the only one working on a file,) here are the basics:

There’s no need to divide text sizes by H1 - H6 or change ‘popup’ into ‘panel’ if your team is unfamiliar with it. Limiting your design system into development’s terms is somehow putting beginners and non-technical designers into a steep learning curve and could overwhelm them from adopting your design system. Suppose your team is comfortable with ‘Normal, Header, Super, Uber’ then, by all means, go for it.

It is also quite useful to quickly compile your own team’s Component Wiki or Cheat Sheet outlining common and recommended names (or in this case: per client project). Everyone could then catch up on your common naming and search for what they want when needed.

Tip: If you’re working with front-end developers, you could also ask them to give you access to their UI system tools (Storybook for example) so you could borrow familiar names for both design and development teams.

Like adjectives in English, properties have to represent themselves in a certain way for them to be easily accessible. Try naming simple elements using these quick templates:

Contrary to adjectives in English, remember to keep these properties interchangeable. Preview it on your ‘working file’ to optimize it for better accessibility. For example, in Figma, you would need to group some properties to have them present all options in the same folder. This way, designers would have an easier time previewing and selecting overrides for each element.

Interchangeable components should keep scalability in mind. If you're building it right, there should be no problem further expanding the naming convention down the line, even though the UI structure would become more complicated.

Remember that the perfect design system doesn’t exist; everything can be progressively revamped, redesigned and improved.

The next best item for your teammates is consistency in helping them navigate through the treacherous terrains of your (perhaps) half-baked labyrinth of a design system. Having an organisation-wide ruleset for naming stuff could be a big help for everyone.

Create guidelines for your naming conventions. Revise them frequently. Let everyone know that in order to be well-organised, you need contributions from the team to keep an eye out for rough edges so that the guidelines are kept neat and tidy. It’s preferable to have a standard naming convention ruleset from the start and have everyone comply.

There’s no point in having a Title case naming on one project and Camel case on another. 

For our team, we prefer to use Title case naming convention with one spacebar gap before and after a slash (Name / Property 1 / Property 2 / ... ) as it is easier to eyeball and maintains comfortable breathing room within a layered list.