© Copyright Anirudh Bomadvar 2026

Home

ACS PUBLICATIONS – FUSION DESIGN SYSTEM

Overview

Fusion is a cross-platform design system created to support the modernization of ACS Publications products and establish a shared foundation across a fragmented publishing ecosystem.

At the start of this initiative, there was no unified design system or shared UI foundation across ACS Publications. Multiple internal teams and external vendors worked independently, often with broad creative freedom. This resulted in fragmented interfaces, inconsistent interaction patterns, duplicated effort, and significant usability and maintenance challenges across products.

One of the clearest examples of this fragmentation was buttons. Because multiple teams and vendors had been solving the same UI problem in parallel, there were more than 50 button variations in use, many with only slight differences in color, styling, or behavior. Similar inconsistencies existed across other components and patterns as well.

Fusion was created to establish a single, scalable foundation for design and development while also defining how the system would be built, maintained, released, and adopted over time. As a team of four within ACS Publications, we shaped the system around real workflows, real platform migration needs, and the realities of working across internal teams, vendors, and partnered products.

Public documentation site for the Fusion design system.

View the Fusion design system documentation

Goals for This Project

  • Create a single, unified design language to replace fragmented and inconsistent UI patterns across ACS Publications products.
  • Reduce duplicated component creation introduced by parallel team and vendor workflows.
  • Improve usability and accessibility consistency for authors, editors, reviewers, and internal users.
  • Establish a sustainable strategy for how the design system would be created, maintained, released, and adopted over time.
  • Build a stronger bridge between design intent and front-end implementation to reduce rework and drift.
  • Support platform migrations, future modernization efforts, and branching needs for ACS Publications partnered products.

The Problem

Before Fusion, ACS Publications products lacked a shared UI and implementation foundation. Similar interface problems were being solved in different ways across products, teams, and vendors, creating visual inconsistency, conflicting interaction patterns, and unnecessary maintenance overhead.

The fragmentation was not limited to aesthetics. Handoffs varied, implementation quality varied, and there was no clear operating model for how shared components should be structured, documented, maintained, versioned, or adapted for partnered products. Even basic interface elements like buttons had proliferated into more than 50 slightly different versions because multiple vendors and teams were making local decisions without a central system.

This made the challenge much larger than building a component library. The project needed to solve both a design problem and a systems problem by creating consistency across interfaces while also defining how the design system would actually function inside ACS Publications as a working product and shared resource.

Research & Strategy

The work began with auditing existing components and patterns across the ACS Publications ecosystem. We used design system methodologies such as atoms, molecules, and related systems thinking approaches to break down interfaces, identify duplication, and determine which patterns should become reusable system elements. As part of that effort, we also conducted a quantitative review of component usage and variation across products to understand how many versions of similar UI elements existed, where the greatest inconsistencies were appearing, and what opportunities existed to consolidate, standardize, or expand the system. This helped us identify not only what could be turned into reusable elements, but also what gaps existed in the current system and what new components or guidance would be needed to better support teams.

Strategy also involved understanding how vendors and engineering teams consumed design system work, how past handoffs had been handled, and where those workflows had created friction or inconsistency. We observed designers and vendor engineers in virtual sessions as they worked through the use of existing components and design assets, asking them to speak aloud about the steps they were taking, the decisions they were making, and the parts of the system that felt unclear or open to interpretation. These sessions gave us a more grounded view into how the design system was functioning in practice, including where implementation varied from intent, where teams were filling in gaps on their own, and where stronger definitions or documentation were needed to support consistency.

Because the design system had to work across internal teams and external partners, it needed to account for more than just Figma components. It had to support real implementation realities. That meant understanding not only the visual structure of the system, but also the workflows, expectations, and technical constraints that shaped how it would actually be used. The research made it clear that optimizing the design system was as much about improving adoption and reducing ambiguity as it was about organizing components. This broader understanding helped shape a system that could better support shared use, clearer handoff, and more reliable implementation.

I played an integral part in helping define the strategic foundation of the system, including framework selection, the flow for how the system would be built and maintained, how component development would work, how timely releases could be provided, and how the system would handle branching for ACS Publications partnered products. I also brought in lessons from large enterprise environments and from my previous design system experience at Nextpoint, including both the challenges and the wins that come with scaling shared systems. That experience helped inform an approach that was not only structurally sound from a design systems perspective, but also more realistic about the long-term needs of governance, adoption, and scale.

Before

Multiple teams and vendors had introduced 50+ button variations with slight differences in color, styling, and behavior.

After

Fusion standardized those patterns into a more consistent, accessible, and maintainable button system for ACS Publications products.

Before

Multiple teams and vendors had introduced 15 + Dropdown menu with slight differences in color, styling, and behavior.

After

Fusion standardized those patterns into a multifunctional dropdown.

Design Direction

The design direction focused on building a system that was usable, maintainable, and grounded in real product delivery. This meant making decisions not only about components, but about the full lifecycle of the system: how teams would use it, how developers would build from it, how releases would be managed, and how the system could adapt across different products and partner needs.

Because our team was also actively involved in platform migrations, we were able to act as end users of the system ourselves. That allowed us to refine Fusion based on real usage and optimize it around how ACS Publications products were actually being designed and migrated, rather than treating it as a static artifact. Every design system is different in how it gets used, and we shaped Fusion to feel like ACS Publications’ own rather than a generic imported framework.

To accelerate the work while still creating a scalable foundation, we made deliberate framework choices that supported both design consistency and implementation practicality. The system was built to support design, engineering, governance, and ongoing product evolution together.

Impact

  • Created a stronger shared foundation across ACS Publications products where previously there had been fragmented interfaces and inconsistent implementation.
  • Reduced component duplication and clarified how similar UI problems should be solved across teams and vendors.
  • Helped transform 50+ inconsistent button variants into a more standardized and maintainable component approach.
  • Established a clearer operating model for design system maintenance, handoff, documentation, releases, and branching considerations.
  • Supported platform migration work by giving teams a system they could actively use, test, and refine in real product scenarios.
  • Created a more practical and scalable foundation for future modernization across ACS Publications and partnered products.

My Role

Product Designer, one of four core team members

As part of a four-person ACS Publications team, I helped shape Fusion as both a design system and an operating model for how shared UI would work across products. My role went beyond designing components. I played an integral part in selecting frameworks, defining maintenance strategy, structuring the component audit, and helping determine how the system would support design, development, releases, and long-term adoption.

Methodologies & Responsibilities

  • Design System Strategy: Helped define the strategy for how the system would be created, maintained, and evolved over time rather than treating it as only a component library.
  • Framework Selection: Played an integral role in evaluating and selecting the frameworks and foundations that would support the system’s structure and long-term scalability.
  • Component Audit: Audited existing products and patterns using methodologies such as atoms and molecules to identify duplication, inconsistency, and opportunities for standardization.
  • Vendor & Handoff Analysis: Evaluated how vendors consumed design system work and how past handoffs had functioned in order to create a more realistic design-to-development pipeline.
  • Component Development Flow: Helped shape how components would be developed, documented, implemented, and released in a timely and sustainable way.
  • Branching Strategy: Worked through how the design system could support branching and variations for ACS Publications partnered products without losing cohesion.
  • Platform Migration Application: Put the system into practice through active platform migration work, using that experience to refine and optimize the system based on real usage.
  • Enterprise Design System Perspective: Applied lessons from large enterprise companies and from previous design system work at Nextpoint to strengthen the ACS Publications approach.

Key Features Designed

  • Core Component Library: Standardized buttons, form controls, tables, navigation, modals, and alerts.
  • Layout & Page Templates: Reusable layouts for dashboards, editorial tools, and administrative interfaces.
  • Interaction Patterns: Shared behaviors for filtering, sorting, pagination, bulk actions, and system feedback states.
  • Accessibility Foundations: WCAG-aligned components including keyboard navigation and focus management.
  • Tokenization & Theming: Design tokens for color, typography, spacing, and elevation.

Learnings & What I’d Do Next

This project reinforced that every design system is shaped by the organization that uses it. Strong systems borrow from established best practices, but they only succeed when they are adapted to the realities of the teams, workflows, products, vendors, and delivery constraints around them.

It also reinforced that maintenance strategy matters just as much as component quality. Framework decisions, release practices, handoff expectations, branching models, and adoption workflows all influence whether a design system becomes a trusted product or just another library that teams work around.

One of the most valuable parts of this work was being able to act as both creator and user. Using the system in platform migration efforts made it easier to identify pain points early and improve the system based on real implementation needs.

If this work were expanded further, I would focus on:

  • Adoption Measurement: Track component reuse, implementation drift, and how consistently teams and vendors apply the system.
  • Coded components: Continue refining how the system ships coded updates and maintain ready-to-use components.
  • Branch Governance: Strengthen branching guidance for partnered products so flexibility does not reintroduce fragmentation.
  • MCP Workflows: Make it easier for teams to migrate designs to code using Figma MCP.
  • AI Readiness: Continue optimizing the system around agentic usability.

Tools

Design & Research

Figma, FigJam, Miro, Dovetail, Flowbite, Tailwind CSS, SharePoint, Zeroheight, Hotjar, Google Analytics

Communication

Microsoft Teams, Figma, Jira, ClickUp