FORGE UI 2.0 LAUNCH
Building Forge UI version 2.0, Honeywell software's official design system.
TL;DR
Overview
Forge UI is the official Design System for Honeywell Connected Enterprises, and is used in the context of Asset Management Software.
As our team prepared to launch Forge UI 2.0, the newest version of UI components in Figma and their coded counterparts, I ran into limitations from our current Figma file structure as well as received feedback from consumers on improving communication with Design System updates. This Design System strategy was created to enhance the sustainability of Forge UI's components and its usage with our UX consumers.
Goals
Create a scalable Design System file strategy in Figma
Enhance parity between Figma design and Storybook code
Create a version control strategy for Figma updates
Role
UX UI Designer Lead
Duration
Summer 2023
OPPORTUNITIES
Figma Files: Memory issues with 1.0 Forge UI Design System structure
Code Parity: Lack of parity between Figma and Storybook components
Versioning: No version control with 1.0 Forge UI Design System
FIGMA FILES
❌ What was contributing to the Figma file memory?
Too many UI components in one file
Hidden layers in the master UI components
Nested components included in the main library
Omni-complex UI components
Near duplicate UI components
✅ Fixing each Figma issue
Split the Design System into related chunks (I.E. Data Visualizations)
Audited and deleted all hidden layers in UI components
Created a 'Nested Elements' Figma file
Broke up large, complex UI components into multiple components
Combined near duplicate UI components using properties
2.0 Figma file structure
The new 2.0 Design System structure follows Brad Frost's Atomic Design approach; starting with smaller atoms that build into complex organisms, then lead to documentation in third-party apps.
Key takeaways - Figma files
Light Theme Component file memory decreased from 0.87GB to 0.35GB
File Memory Before
File Memory After
UI components perform faster in Figma and are easier to modify
Action Menu Before
Action Menu After
CODE PARITY
❌ Design and code are not one-to-one
Design tokens aren't consistent between Figma and Storybook
Inconsistent property (control) naming across design and code
UI components supported in Figma do not have Storybook counterpart
✅ Improve consistency between design and code
Collaborated with UI engineers to create Design Token nomenclature
UI Components in Figma given Component APIs to match Storybook
Status indicators added to Figma to show code-ready components
Key takeaway - Code parity
Improved communication with UI engineers and Design System adopters
Status indicators next to UI components
Status indicator meanings
VERSIONING
❌ Design System has no release cadence
Unscheduled Design System releases create roadblocks to adopters
No version control causes conflict between design and code
No publication description with each Figma update
✅ Establish a release cadence
Align Design System updates with product increment (P.I.) calendar
Use semantic naming with version control
Maintain a Design System change-log for version history
Key takeaway - Versioning
Version control improves Design System consistency in product designs
Change-log in Figma
CONCLUSION
Here's to the 2.0 Forge UI Design System
This project was tedious in finding resources to help form the right strategy for the new version of the Design System. It was rewarding to see what causes the nuances of Figma file memory issues, as well as what works well for other design systems.