CASE STUDY

Creating an Atomic Design System

I led the production of an enhanced design system at SoPost, which adhered to the principles of the atomic design framework. This involved conducting thorough audits of existing colours and components, and subsequently creating brand-new, accessible tokens and components to elevate the system's overall performance.

THE PROBLEM STATEMENT

During my time at SoPost, I took the lead in addressing a critical issue: the absence of an effective design system. It became evident that the existing setup posed significant challenges -

  • Components were scattered across multiple Figma files, making them challenging to locate and utilise.

  • The naming conventions were unclear and confusing.

  • Components weren’t accessible and didn’t meet WCAG accessibility standards.

  • The Design System Figma file lacked a structured page organisation, further complicating our workflow.

OBJECTIVE

  • Provide a better consistency in the product and brand

  • Build a product that is adaptable and maintainable

  • Generate a future-friendly foundation to extend over time

  • Enable faster iterations on features and deliverables

  • Construct a more agile experience with early feedback and visual direction

  • Allow more focus for user experience 

  • Create a shared vocabulary between design and development teams

ATOMIC DESIGN METHODOLOGY

In order to address the naming convention challenges at SoPost and establish a more intuitive design system, I researched Brad Frost’s Atomic Design framework. This methodology breaks components down into smaller, more manageable units, from atoms to molecules, organisms, pages and templates.

Atoms serve as the foundational building blocks, representing the smallest components such as buttons. Molecules combine atoms to form larger, more complex elements like dropdown menus. Moving up the hierarchy, organisms consist of both molecules and atoms and can be thought of as sections on a page, such as a navigation bar. Our templates were predefined layouts for pages and emails within a campaign. They provided a consistent structure for organising content and interactions. Finally, pages encompassed the entire user interface, comprising various templates, organisms, molecules, and atoms to deliver a cohesive and intuitive user experience across the software ecosystem.

By adopting this framework, I was able to systematically organise our components, making them easier to locate and utilise. To further enhance usability, I implemented alphabetical ordering for each component category. This structured approach not only streamlined our design system but also empowered our team to work more efficiently and maintain consistency across our designs.

CREATING A TOKEN LIBRARY

The first step was to establish a better token library in the design system. Tokens are all the values needed to construct and maintain a design system. They consist of colours, text styles, shadows, corner radius and spacing values. This section will specifically outline the process undertaken for creating effective colour and corner radius values, offering insight into my approach to handling tokens.

IMPROVING COLOUR ACCESSIBILITY

One of the primary concerns with the previous design system at SoPost was the inadequacy of the colour palette, which failed to meet accessibility standards. This deficiency resulted in usability issues for users with visual impairments. Since colours are integral to all components, addressing this issue was prioritised to ensure improved accessibility across the system.

I conducted comprehensive testing of all existing colours using the Stark accessibility checker plugin within Figma. Subsequently, I developed new colour palettes that met AA WCAG standards and compiled a colour pairing chart for user reference, facilitating clear understanding of compatible colour combinations.

In addition, I conducted thorough testing of all colours and colour pairings for different types of colour blindness (see primary colour palette example below). This exercise proved invaluable in illustrating the importance of not relying solely on colour to convey messages in design. I noted to include a combination of colours with text, icons, or patterns when creating components to enhance the user experience for all individuals, ensuring inclusivity and accessibility across the board.

CORNER RADIUS VALUES

To ensure consistency and scalability across components, I introduced corner radius tokens into the design system as variables. These tokens standardized the use of rounded corners across the entire design ecosystem, providing flexibility while maintaining a unified look and feel.

PROCESS

  1. Research and planning: I began by auditing the existing UI components to identify the various corner radii being used across the product. This allowed me to consolidate multiple inconsistent values into a streamlined set of corner radius tokens.

  2. Token creation: I defined a range of corner radius tokens (e.g., small-radius, medium-radius, large-radius), each corresponding to a specific pixel value. These were implemented as variables in both design and code, making it easy for both designers and developers to apply and modify as needed.

    • Example Tokens:

      • small-radius = 4px

      • medium-radius = 8px

      • large-radius = 12px

  3. Component integration: I provided clear examples of how each token could be applied to different UI components, such as buttons, cards, and modals. This ensured that teams could visualise and understand the purpose of each token, and how it would impact the overall design.

  4. Collaboration with engineering: I worked closely with the engineering team to implement the corner radius tokens as variables in Storybook, ensuring a smooth transition between design and development. This integration allowed for a consistent application of the radii across platforms and made future updates easier to manage.

AUDITING EXISTING COMPONENTS

I conducted a comprehensive audit of the software by taking screenshots and creating visual site maps. For clarity, I’ve included a video showcasing the navigation hierarchy, with each level highlighted in distinct colours. This method provided an overview of the entire flow, allowing me to see all of the existing components within the software ecosystem. I replicated this process for every page and email within a campaign.

Through this exercise, I made several insights:

  • Some components were absent from the current design system.

  • Components were outdated, both within the existing design system, in Storybook and in the software itself.

  • Components had accessibility issues.

To address these findings, I categorised each identified component as an atom, molecule, organism or template. This approach allowed me to prioritise the foundational elements (atoms), which served as the building blocks for other components within the system.

CREATING A COMPONENT LIBRARY

IMPROVEMENTS TO BUTTONS

To address the identified issues within our software ecosystem, I prioritised the foundational atoms such as buttons, checkboxes, and toggles. In the previous design system, there were notable accessibility issues regarding button colours and states. With this in mind, I’ve conducted an in-depth breakdown of how I tackled buttons in this case study.

The problem:

  • The existing default and hover states of the primary button did not meet AA WCAG standards.

  • There was little use of tertiary buttons. The primary and secondary buttons were overused on complex pages, which obscured the information hierarchy.

  • Destructive buttons were not only inaccessible but also lacked the use of icons, which are crucial for clear communication.

I collaborated with the engineers to address these issues. Together, we refined the button types, colours and states and introduced icons to enhance the visual clarity of destructive actions.

The solution:

  • The primary button was refined to feature a darker blue hue, along with an updated hover state incorporating a gradient effect to make it more accessible.

  • Similarly, adjustments were made to the secondary button. Originally, it featured a light blue background with blue text, which also posed accessibility challenges. To rectify this, the secondary button was redesigned into a ghost button with a primary blue border, and text.

  • A distinct tertiary button was introduced and used for tertiary actions, to improve information hierarchy.

  • The updated destructive button included a state with an icon. We also recognised there were actions in the software where a destructive-outline button was required for actions that were less destructive.

PROJECT MANAGEMENT PROCESS

Created tickets in Jira:

I added tickets for all identified atoms required in the enhanced design system to a Jira board. These tickets were categorised to maintain visibility and track progress effectively.

Collaborative Effort:

Recognising the scale of the task, I sought the support of fellow designers to assist in adding atoms to the design system. This collaborative effort ensured timely progress and alignment with our project objectives.

Atom Creation:

We created each atom to align with the new, accessible colour and text styles, as well as the specified shadow and corner radius values. Furthermore, we ensured that appropriate auto-layout was applied using the specified spacing values.

Development of Variants:

We developed variants for different states, such as default, hover, disabled, and focus. This approach ensured a dynamic user experience across various interactions, enhancing usability and engagement.

Additionally, we added other variations for specific components, such as size adjustments and the addition of labels or icons. This provided our design team and developers with enhanced flexibility in implementing designs.

Inclusion of Examples in Design System:

To promote exploration and understanding, we included examples of the components within the design system. This allowed designers and developers to interact with the components, experimenting with different states and variations.

Iterative Process:

We continued this process to create molecules, organisms, templates, and pages, focusing initially on the most frequently used components. This approach ensured that our design system's foundational elements were systematically addressed, making them readily accessible and usable for our team members.

Communication and Maintenance:

I established a weekly Design System meeting to facilitate communication of updates and ensure alignment between designers and developers. This forum also provided an avenue for feedback. This proactive communication enabled developers to seamlessly integrate new token styles and components into Storybook, maintaining consistent naming conventions.

THE RESULT

  • Developed a robust, adaptable design system that became the foundation for future projects.

  • Fostered consistency, efficiency, and collaboration across three multi-disciplinary teams: product design, engineering, and solutions.

  • Achieved 100% integration of the design system within the design team's workflow and 80% within the engineering team’s workflow.

  • Held 12 monthly meetings with key stakeholders over a year to drive the development, adoption, and ongoing refinement of the design system.

  • Created a dedicated Slack group for collaboration, discussions, questions, and feedback, ensuring seamless communication and continued evolution of the design system.

  • Developed comprehensive documentation to ensure ongoing maintenance and ease of onboarding new team members.

  • Received positive feedback from design and engineering teams, noting improved efficiency, and consistency in product development

DEMO

This demo video showcases the intricacies of our Figma file structure, providing insight into the organisation of atoms, molecules, organisms, and templates. Moreover, it highlights the dynamic nature of our design system, allowing for seamless state changes within pages, enhancing user interaction and experience.

Next

Campaign branding