Icons: Creating a Flexible Set
This feature was implemented as part of the Atlas Design System in Travelport.
Icons in user interfaces (UI) are visual symbols that help users navigate and interact with digital interfaces efficiently. They provide quick, intuitive cues for actions or information without requiring lengthy text descriptions, especially when UI space is limited.
In design systems, a flexible and balanced icon set is crucial. Icons appear in various screen areas, making it important to get their size, balance, and consistency right for both organisational teams and end users.
Challenge: Revamp the icon set in the design system to achieve optical balance, scalability, stylistic consistency, and seamless component integration.
The icon set in the Atlas Design System was created many years ago. As the system matured, the icon set became dysfunctional, unorganized, and visually imbalanced, especially when icons were placed in close proximity.
Objective: Modernise the icon set, streamline the process of adding requested icons, and enhance the ease of searching and finding icons in both Figma and development documentation.
Picking a new icon set
Given the high volume of icon requests and our small systems team, I chose Material icons as our primary icon set for several reasons:
Icons8 requires a paid subscription, limiting icon access to only the systems team.
Material icons offers a public repository, allowing designers to view, download, and test icons before requesting their addition to the Design System.
Material provides an extensive icon library. When an obscure icon is needed, designers or the systems team can create original icons that match Material's style.
Naming icons
The first step in revisiting the icon set was to review the naming convention. The existing names lacked a consistent pattern, with related icons often having contrasting names. Additionally, many icons had specific contextual names assigned years ago, limiting their flexibility. This inconsistency made it difficult to maintain and expand the icon set effectively.
To address this issue, we conducted a comprehensive audit of all icons to identify commonalities and establish a consistent naming convention for the icon set. The examples showcase how various styles and common traits of icons were grouped together. This audit revealed many inconsistencies in the existing naming conventions.
Before: When searching for a close icon using its identifiable "x" shape as the search keyword, no viable options appear in Figma's assets panel.
Establishing a naming convention
Icons typically have a primary identifying feature that users search for first, though some icons may have multiple searchable features. By introducing a clear and flexible naming convention that makes it easy to add new icons to the library consistently:
Family: The main identifying feature of the icon
Shape: If the icon is enclosed in a shape like a circle
Feature: The secondary identifying feature of the icon
Style: Detailing if the icon is filled or outline in style
The new icon naming convention.
After: As consumers search the system, they can see related actions through 'tags' in the component description, regardless of the icon's name. These tags also appear in the development documentation.
In this example, when users search for icons in Figma, results with "Plane" as the primary family or feature tag appear first. Related plane icons are shown with lower priority.
Users can also search using "tags" in the component description, regardless of the icon's name. Rather than memorizing exact icon names, users can search with broader keywords that relate to the icon's purpose. These tags are available in both Figma and the development documentation.
Finding icons
Locating specific icons or discovering potentially useful ones was challenging for system users when using search tools in both design and development environments. Using the close icon and it’s related icons as an example we can see in the before
Before: When searching for a close icon using its identifiable "x" shape as the search keyword, no viable options appear in Figma's assets panel.
After: As consumers search the system, they can see related actions through 'tags' in the component description, regardless of the icon's name. These tags also appear in the development documentation.
Visually imbalanced icons
In the previous Atlas icon set, icons often appeared visually imbalanced—this was especially noticeable when icons were placed side by side.
In the example below, icons on the left appear inconsistently sized despite sharing a standard 24 × 24-pixel frame. The revised icon set on the right demonstrates improved optical balance, creating a more unified visual appearance.
Using a method called ‘keylines’ helps create consistent visual weight between all icons no matter the icon shape.
The icons on the left lack optical balance compared to those on the right, particularly the search icon.
Icon keylines
A keyline is a set of guides that maintains visual weight among icons. It consists of four basic shapes that ensure consistent proportions across all icons. In Atlas, this keyline shape sits in a frame of 24 x 24 pixels.
Icon keyline
Trim area and live area
The live area contains the main shape of the icon. This ensures aligned visual weight and consistency across all icon shapes and sizes. If possible, the icon should not extend outside the trim area.
Keyline example highlighting the trim area and live area of the frame.
Keyline grid
A keyline grid is a set of guides that maintains visual weight among different icons. Most icons are made of four basic shapes. Creating icons with these shapes in mind using the keyline grid ensures consistent proportions across all icons.
In the example below, the circle, square, and horizontal and vertical rectangles all have the same visual weight. Following this pattern ensures that icons of all shapes and sizes look visually consistent throughout our products.
Keyline grid consisting of four basic icon shapes.
Note the passport icon which is a rectangle shape happily fits in the vertical rectangle keyline.
Figma icon structure
The structure of the icon layering in Figma dictates many essential use cases for the icon set.
Scaling icons
Inheriting color where the icon colour is fixed
Consuming the icon in the Design System development library
Scaling icons
The Atlas icon set previously maintained two separate icon sizes: 24 x 24 pixels and 16 x 16 pixels. Managing these sizes independently created extra complexity and doubled the workload when adding new icons to the set. To streamline this process, an icon component was created to control icon sizes dynamically. Now the design system needs only one set of icons at a base size of 24 x 24 pixels, which the component can scale up or down in size as needed.
Creating a component serves as a control mechanism to govern the icon size between small, medium, and large options. Consumers can also scale the icon to a custom size.
Cohesive layer naming
Certain areas in the design system have defined colour patterns—for example, a button's icon colour matches its label colour. In the old icon set, when users changed an icon, it would reset to its original colour token rather than inheriting the defined colour. The new icon set resolves this through a cohesive layer naming structure that enables proper colour inheritance.
The notification icon on the left failed to inherit the white colour from the original icon above, while the notification on the right correctly inherited the colour token.
The icon structure is now flatter. Each icon nests within an icon component that controls its size. The icon itself has no individual shapes—it's a single flat element. The icon shape layer uses the generic name "vector," which is descriptive yet versatile enough to apply across the entire icon set.
This solved our previous issue in two ways:
Using identical layer names for all icons enables Figma to establish relationships between them and automatically inherit the previous icon's colour
The flat layer structure allows development to work with a single-shape
The icon structure contains multiple layers and shapes, with the main layer named 'bell' to match the icon's shape. This layering approach was common across icons in the old set.
This structure created two main problems:
The colour inheritance issue
Developer consumption
Conclusion and findings
The Design System has been using this icon approach successfully for over a year, yielding several key benefits:
Designers outside the systems team can easily contribute to the icon set thanks to the clear, systematic approach.
Token application issues have decreased significantly since icon colour tokens automatically inherit in UI components, saving designers valuable time.
Icon maintenance has become much simpler—using a single scalable set through the icon component allows for more effective management.
Users can find icons more efficiently by searching with broad, intuitive terms instead of memorising specific icon names.