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

Up your slash game by following these simple guidelines

Design Tools

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 ( / ).

Look at that sexy dropdown/Toggle control on the right!

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:

1. Recognisable name

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.

Consult the ‘good’ design system examples on the web to get started

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.
Active elements and its naming
Common state callsigns

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.

2. Manageable Properties


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:

[Name] / [Type] / [Size] / [Colour] / [State]

Name, Type, Size, Colour, State
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.

3. Established Case Rules

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.

What we're using

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.

Looking for a new challenge? Join Our Team


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.
Like 1 like
Gavin Chiemsombat
I'm a full-time Product Designer (and a Front-end enthusiast) at OOZOU in Bangkok, Thailand
Share:

Join the conversation

This will be shown public
All comments are moderated

Get our stories delivered

From us to your inbox weekly.