In the ever-evolving landscape of design and development, a well-structured and meticulously maintained design system is a cornerstone for success. At the heart of this system lies a seemingly humble yet profoundly significant element: proper naming conventions. These conventions are the linguistic glue that binds the entire design ecosystem together, from UI components and typography to color schemes and layout grids. They might appear inconspicuous at first glance, but their importance cannot be overstated. A thoughtfully crafted naming convention is akin to a universal language spoken by designers and developers alike, facilitating seamless collaboration, enhancing clarity, and ultimately driving efficiency in the creation of cohesive, user-friendly, and visually appealing digital experiences.
When thinking of names for any part of your design system, keep in mind that they should generally be:
- Logical: Describe the component clearly, using a name that represents it. For example, the name Accordion describes the component visually and even how it works when a user interacts with it.
- Scalable: Find names that allow for possible variations or additions to the component that could come in the future. For example, when categorizing text style sizes, it’s often best to use T-shirt sizing (S, M, L, XL) as there is always the possibility of adding more sizes in the future. Typically the main size will be M, so both smaller and larger sizes can be introduced as needed.
- Simple: Keep names short and basic. 1-2 words is often enough for a component, and if more details are needed this can be done through the use of forward slashes to represent further categorization. Use names that are commonly understood and avoid long or unique names that require someone to look it up or ask what it represents.
- Standardized: The best component names are the ones used over and over again by most people in the industry. Button is a great example. It has become so standardized, it’s very hard to find any other name for this component. If you need help finding the most standardly-used component names, sites like UI Guideline or Component Gallery are great resources. They gather the most common component names used in the best design systems.
States: The different states of a component need names, too. It’s important to follow the same best practices above and find names that are logical and standard, or otherwise clearly defined. The most common names for component states include:
| Enabled | An interactive component/element that the user can usually click on or interact with. |
| Hover | A visual cue to show users that they are hovering over the component concerned. |
| Focused | Triggered when a user has highlighted an item, using an input method such as a keyboard or voice. |
| Pressed | A visual indicator for the user to confirm that the component has just been clicked. |
| Disabled | The opposite of the ‘enabled’ state. It, therefore, indicates that the component is inactive and therefore not clickable. |
| Visited | Mainly used on links to indicate which links the ser already clicked on. |
| Error | Concerns mainly form components to indicate input errors to the user visually. |
| Validated | Indicates to the user that what they filled is correct and complete. It is a feedback on an action just completed. |
| Read-only | Somewhere between an ‘enabled’ and ‘disabled’ state. User can’t interact with the component, but it’s essential to display the component to indicate it has been properly activated. |
Colors: While it seems counterintuitive, colors should not take the name of the actual color itself (blue, red, green), but one that represents its function. If your product or company were to undergo a full rebranding, for example, it’s likely the colors will change, forcing you to rename every single color token. Plus, using the actual colors as names doesn’t give design system users any indication of when, where or how to use that particular color. Instead, the most common names for colors include:
- Branding: primary, secondary, tertiary…
- Functional: success, warning, informational…
- Greyscale: grey-000, grey-100…
Casing: While choosing a casing style really only concerns naming on the code-side, it can still influence the structure of component names and might be reflected somewhere in documentation or in design. There are 4 common casing styles for naming on the code-side:
| camelCase | No spaces and each word is capitalized except the first one. Most commonly used for variables and functions in JavaScript. |
| PascalCase | All words are capitalized including the first one and all spaces are removed. It is commonly used for C# and Java. |
| kebab-case | Replace the spaces with a hyphen ‘-‘ between each word and make sure all words are lowercase. It is commonly used for CSS and HTML5. |
| snake_case | Very similar to the kebab-case, the only difference being the use of underscore ‘_’ to separate each word. It’s commonly used for database programs such as SQL databases, but also with PHP or Phython. |
Breaking down a component’s name: Most components typically have several types, variations, states and even themes. It’s important to clearly organize the name of components to reflect these differences, using a forward slash to break it down:
[Category] / [Component] / [Type / Variant] / [State] / [Theme]
E.g.: Actions / Button / Primary / Hover / Dark
