Design system file cleanup

PROBLEM: There were two different design system Figma files which created confusion and a lack of trust with users and viewers of the files.

Design System Figma file created by agency

File #1: Figma created by agency

File #2: MUI for Figma template

Company background

“iCIMS is the Talent Cloud company that empowers organizations to attract, engage, hire, and advance the talent that builds a winning workforce.”

  • Enterprise SaaS company focused on talent acquisition and internal mobility

  • More than 4,000 customers across all products

  • Products include:

    • Applicant Tracking System

    • Career Sites

    • Candidate Relation Management

    • Employee Onboarding

    • Opportunity Marketplace

Design system background

  • React Material-UI (MUI) at the core

  • iCIMS theme for MUI referring to Style Dictionary tokens

  • iCIMS specific components

  • A11y + i18n support

  • Storybook examples

  • Color tokens and components in Figma

  • zeroheight documentation site

File #1

  • Created by contractor

  • Every designer had edit access

  • Some components left in “unapproved” status

  • Style tokens not aligned with MUI theme structure

  • Low adoption of variants feature

File #2

  • Previously purchased Figma template for MUI components

  • Every designer had edit access

  • Published before style tokens were updated

  • Components had variants we didn’t use

Initial research

  • I held informal interviews with designers (4) and engineers (3) to understand needs

    • What works in the files and what doesn’t?

  • Used Figma statistics to measure component usage within Figma designs

  • Used internal tool to measure component usage within code base

(example of Library Analytics in Figma)

Interview findings

  • Most designers and all engineers weren’t sure which file was supposed to be the source of truth

    • General consensus was that Storybook was the real source of truth

  • Designers had issues with disappearing components from file #2

    • Some expressed that having the file open to all designers causes too many problems

  • Everyone expressed confusion with the extra variants in file #2 that weren’t in Storybook or file #1

  • Everyone assumed component usage guidelines were incomplete

Goals

After taking the time to do the discovery work, the next step was to establish the goals of the project.

Project goal: Establish a stable foundation file for our design system style tokens and components in Figma.

  • Clean up and migrate to new file to make it our (only) Design System file

  • Identify, prioritize, and create a backlog of components and patterns that still need to be defined in our Design System

  • Usage documentation revisited for each component

The team + my role

For the 3 week effort, there were 3 dedicated designers.

The Design System Engineering (DSE) team had 5 software engineers.

There was 1 manager and 1 director involved to help dedicate resources to the initative.

Then there was me — my role was to plan, lead, and help out the designers with the effort. I effectively acted as the product manager, the scrum master, and a product designer.

Execution plan & process

Plan

  1. Start from a fresh MUI Template file

  2. Add “Deprecated” label to the two other files

  3. Update Color & Typography tokens

  4. Update/add Icons

  5. Then work on the remaining MUI components in priority order

  6. Move custom iCIMS components to this new file

Plan

  1. Utilize Figma’s branching feature (which was brand new at the time)

  2. Publish components after each work item is done

  3. Remove variants we don’t use

  4. Light theme only

  5. Create engineering tickets to update code components (where applicable)

  6. Create backlog tickets for complex tasks that need further research and decisions

Prioritization of work

  • Components prioritized by usage in Figma library analytics

  • Kanban Jira board used to organize work

  • 3 max “In Progress” per designer

My hands-on contributions to the initiative

  • Updating Color tokens

  • Updating the Paper component

  • Reviewing Figma branches

  • Creating code alignment tickets for the DSE team

  • Weekly updates to leadership

Deep dives into clean-up decisions and outcomes

Project summary

Within the three week time frame, a new Design System file in Figma was successfully published! The two deprecated files were unpublished shortly after.

Reviewed and updated:

  • 38 out of the 48 MUI components (79%)

  • 3 out of the 10 custom iCIMS components (30%)

The remaining components had Jira tickets associated to them (created in the planning stage).

Design System Engineering (DSE) work item tickets were made for any style tokens or components that needed alignment with Figma.

(example of alignment ticket in Jira for DSE team)

Outcomes

Designer outcomes

  • We were able to shift to a locked down DS file, but branching allows for reviewable contributions from anyone

  • Gained three designers with comfortable knowledge on how to contribute to the Design System

  • Identified a need to hold weekly Design System Office Hours

  • Built up backlog of outstanding Design System work items which helped advocate for a dedicated DS designer

  • (Slightly) updated component usage guidelines

Engineering outcomes

  • Less questions from product engineers on why code components didn’t match the design

  • More trust in the Figma file as the single source of truth

  • More color tokens added to Style Dictionary

  • Revealed issues with the reliability of component library releases

What’s next

… Design Systems are always evolving

  • Executing on Design System backlog tickets created

  • Complete low priority components

  • Evaluate existing components periodically for relevancy and usability

  • More themes! “Dark”, “Candidate”

  • Explore patterns and standard page layouts

  • UX copywriting guidelines

  • Improve/add visual test cases in Figma