Naming conventions v2

Introduction

Standardised naming conventions enhance clarity, streamline collaboration, and facilitated system evolution.

In design systems, naming conventions are pivotal for ensuring consistency, clarity, and efficiency. Clear names, such as "error-red" for a colour, immediately indicate its function, streamlining communication among designers, developers, and other team members.

Standardised naming expedites the design and development process by reducing the need for continuous reference or clarification. It guarantees that references to specific elements are universally understood, facilitating smoother integration as the design system expands.

This shared language bolsters collaboration across teams, ensuring everyone understands each component's purpose. Such conventions prevent accidental duplicates, which can clutter the system, and aid in managing component evolution, especially when deprecating old elements or introducing new ones.

Principles

1. Using atomic design classification - hierarchical structure (atoms, molecules, organisms, etc.)

2. Simple and descriptive - consistent naming rules (descriptive, clear, no abbreviations)

3. Consistent letter casing - maintain sentence case for for component and lowercase for properties on design level, code should follow language default

4. Singular name - avoid the use of plurals in choosing a name (button not buttons)

Naming schema

A naming schema provides consistency, clarity, and ease of reference. By following a set pattern or rules for naming, it becomes easier to identify, manage, and search for items.

In design systems, it's a foundational aspect that helps ensure clarity, efficiency, and successful collaboration across large and diverse teams. It brings method to the potential chaos and lays the groundwork for a design system's long-term success and adaptability.

Structure: [ category ] / [ component ] / [ style ] / [ variant ] / [ size ] / [ state ]
An example would be components/button/standard/primary/small/hover

[ category ] represents the broadest classification (components, organisms, etc.).
[ component ] type represents the specific component being referred to (button, checkbox, toggle, input, etc.).
[ style ] describes the general appearance or behaviour of the component (standard, iconOnly, textOnly, etc.).
[ variant ] specifies the purpose or use-case for the component (primary, secondary, tertiary, information, success, warning, etc.).
[ size ] denotes the component's dimensions or scale (small, medium, large, etc.).
[ state ] describes the current interaction or status of the component (default, hover, focus, active, disabled, etc.).

Variants

States

Atomic design

States

(add different states)

Base Design System

Classification

There are three different classification used

Atomic design

Atomic design is a methodology developed by Brad Frost for creating design systems in a systematic and hierarchical manner.

The idea behind atomic design is to break interfaces down into their smallest parts, which can be combined and recombined to produce any number of UI variations. Atomic design breaks down UI components into the following levels: atoms, molecules, organisms, templates and pages.

This classification is to be used on the design level, within Figma and code as this allows for scalability as more complex components are designed and developed.

Functionality

Ideal for external documentation as it’s easier to find component based on the functionality they add to the overall design, it is easily found in popular design system documentation such as Shopify, Material design and others.

This classification separates the components into categories such as Inputs, Navigation, Layout etc

Context of use

This classification method separates components by features, pages or user journeys to allow for more accessibility within complex components templates for instance, a card component could be further extended as a template for specific use on FX and on loans but with different layout arrangement and content.

The classification method will only be used to classify templates further into feature groups e.g by Onboarding, FX, Loans etc.

Component breakdown

By Atomic design

Atoms

These are the basic building blocks, analogous to atoms in the physical world. In terms of web interfaces, atoms can be HTML tags, such as labels, inputs, buttons, or other elemental parts like colour swatches and typographic styles. They are not useful on their own but when combines, they become the foundation of your UI.

Molecules

Molecules are groups of atoms bonded together and are the smallest fundamental units of a compound. Think of them as UI components, like a form label + from input + button = search form.

Organisms

Organisms are relatively complex UI components composed of groups of molecules and/or atoms and/or other organisms. They form distinct sections of an interface, like a product grid or a site header with a logo, primary navigation, and search form.

Templates

At this level, you’re essentially laying out the structure of a page. You’re positioning organisms (or groups of organisms) in a layout, showing content structure without focusing too much on the actual content.

As a template, these components are further broken down into their area or context of use such as onboarding, fx , loans , payment , all etc. see table below

Pages

Pages are specific instances of templates. Here, placeholder content in templates is replaced with real content, thus forming a complete page. This level allows for testing the effectiveness of the design system’s hierarchy and seeing how the design system works in practice with real content.

By Functionality

Inputs or Form

All components that allow to for data input from text fields to file upload including buttons and links.

Navigation

Components that aid navigation from one page or view to the other.

Media

These components aid display of various types of media content, such as images, videos, audio files, or documents. It provides a structured and interactive way for users to view and consume media within an application.

Feedback

These component set provide a way to inform the user on the status of processes or a action, also give more information on other visual elements

Data visualisation

These components are responsible for presenting data in a clear, organized, and visually appealing manner

Layout

These components defines the structure and organization of content on a page. they provides a framework for positioning and arranging other components on a page.

Rules of use

1. Follow the naming schema

2. Be consistency - use consistent names across components

3. Be clear and meaningful - clear to the last detail

4. Avoid reusing component names in your properties e.g itemsList

5. Use simple pronounceable names

6. Remove your emotion or moods

7. Use positive words