FactSet: Fusion Design System
Maintained two 100+ component pattern libraries.
Problem
When I joined FactSet, the UX team had just launched a new site to host our two pattern libraries, nonresponsive and responsive. The nonresponsive library had over 100 components already in use across more than 30 applications, but it was outdated, and neither library had complete or reliable documentation. I was tasked with maintaining both and writing documentation for every UI component in Markdown, along with the API for each one in JSON. Without that, engineers across dozens of applications had no single, trustworthy source of truth for how components actually worked.
Design Goal
The responsive library eventually became the Fusion initiative, which set out to replace the outdated nonresponsive system with something modern and get it fully integrated across our applications. A dedicated Fusion Design System team formed inside Visual Design, and my job was to move new components from concept to finished, production-ready pieces. We acted as gatekeepers for the library. Everything new had to funnel through us to keep the system consistent. For every component, we broke it down by theme, density, and state in Figma, built it properly using tokens, atoms, and variants, and only then sent specs to engineering.
Fusion eventually merged with UI Standards, the engineers who handled design-system requests specifically, into one team. We started running daily standups together and working more closely in JIRA. We also built in daily design jams and API jams while building new components, which gave us a much clearer read on what engineers could actually build and gave them a clearer picture of how each component was meant to function.
Both of our libraries now have complete, up-to-date information for all of our components.
Challenges
Acting as the gatekeeper for a library used across 30+ applications meant every decision had real weight. A component wasn't just being designed once. It was being designed to work correctly across every theme, density, and state it might be used in, for every team that would eventually pull it into their own application. Getting that level of consistency right required a lot of upfront structure in Figma, using tokens, atoms, and variants deliberately rather than just designing one-off screens. Merging with the engineering side added another layer: aligning daily with UI Standards meant constantly translating between what was designed and what was actually buildable, and making sure neither side was operating on assumptions about the other.
Component - Menu Item:
Challenges: Number of variants / Piecing together Menu
Chart - Donut Chart:
Challenges: Individual pieces / Scalability
Pattern - Wizard:
Challenges: Screen repositioning / Scalability
Component - Accordion:
Challenges: Additional slots / Chevron placement
Takeaways
Running daily design jams and API jams taught me that a design system only works if design and engineering are actually building a shared understanding together, not handing specs back and forth. Documenting every component's API in JSON, not just its visual states in Markdown, also taught me that a pattern library's real value is in that reliability. Engineers across dozens of applications need to trust the documentation completely, or they'll stop relying on the system altogether and start building their own workarounds.
Conclusion
Both pattern libraries ended up with complete, up-to-date documentation for every component, something neither library had when I joined. Fusion itself moved from a concept-stage initiative to a real system embedded in daily engineering workflow, with design and engineering operating as one aligned team rather than two groups working in sequence.