Our Rules on Naming and Structuring a Design System

For me, I often found this the most challenging part of setting up a system.

In short, design systems are unique to system they’re designed for (deep bro). 

So for the most part there is no right way to name individual elements, however I’ve now been a part of a fair few systems and I can share how we’ve scaled them up, created them from scratch and kept order in design.

This is how we do it.

Understanding Atomic Design

If you’re setting up a design system from scratch, before you jump in, make sure you’ve grasped Atomic Design as a principle of design. (In fact I would thoroughly recommend you go through this list of principles of design before tackling the task of creating a design system.)

Atomic design is broken up into 5 key sections:

1. Atoms - the smallest most basic building blocks of all user interfaces. 
2. Molecules - simple groups of atoms that together form an element of UI.
3. Organisms - complex components comprised of multiple molecules, Atoms and organisms. 
4. Templates - Wireframes showing how the components work in a layout. 
5. Pages - Taking those templates and applying content to give specific context.

How I see a using a design system is essentially Lego for a job. You use pre defined blocks and pieces to create new innovative masterpieces. You learn to know how each block can and should be used.

As design system creators, we’re going to build those Lego pieces. They will be our atoms, molecules and organisms.

Software

Design systems is not locked to specific software, it is a principle and methodology of product design. Design software itself is constantly leap-frogging each other with feature sets and pricing. I’ve jumped about them all at some point. Right now, I’m settled in Figma and feel it works best for designing out products, systems and libraries. Sketch, Adobe XD, Framer & Invision users will still find they can create Design Systems, but for me, Figma does it the most seamlessly. 

Naming conventions

A design system needs to work as quickly as possible, meaning, someone needs to be able to jump in and find the component they need with as little friction as possible.

Basic Rules we follow: 

• Be consistent 
• Keep it simple
• Be clear
  

Rules we’ve found that help us: 

• Use forward slash to break things up 
• Never use underscores or hyphens 
• Don’t use adjectives 
• Capital letters after a forward slash
• Don’t use numbers
  

Golden rule:

Type / Identifier / Use

Naming atoms

Do not put all your atoms in a page called atoms. That’s like writing all your friends contact details under the page name ‘people’ in a phone book - not helpful in a rush.

Create a page per type of atom. I’d suggest rolling with: Colours, typography, Logos, Icons, Grids, Illustrations. Whilst some designers put buttons and inputs in here, for us they are molecules or components as they are made up a group of atoms (a button uses a colour, typography, icons).

Icons

Icon / Lego Brick / 24

Atom group / Identifier / Use

Typography

Typography / H1 / Left

Atom group / Identifier / Use 

Naming components (molecules & Organisms) 

This is where the starting labels become more specific to the project you’re working on, not every system shares the same components. Think logically and broadly when creating your component names, remember to keep them simple and clear. Examples: Buttons, Inputs, Navigation, Cells.

Inputs

Input / Text / Active

Component group / Identifier / Use

Buttons

Button / Primary / Text Icon

Component group / Identifier / Use

Navigation

Navigation / Top / Default

Component group / Identifier / Use

And it's that simple

*For us that’s as simple as it should be.

We’ve been exposed to some which are 8 categories deep and while some more category types may be needed that point the system can feel so daunting and so complex that it gets mistreated, messy and ultimately is about as useful as saving a file name DesignStuff_New_V2_final_Real_FINAL4.

If it needs more categories, just keep it so simple and try to introduce these new categories at the end of the rule, as this is the only place you should find variations in a system.

Button / Primary / Text Icon / Auto / Disabled

Component group / Identifier / Use / Variation / Style

We work collaboratively wherever and whenever we can, so if you want to know more on our approach or you’ve got some tips & tricks we can use, get in touch with us.