Particle Design System

  • May 14, 2024
  • 6 min read

Updated: May 24, 2024

Led a team of designers and technologists to create a new design system for a complex, data-heavy enterprise application.

Role

  • At first individual contributor, later team lead (6 people)
  • Primarily responsible for process, governance, prioritization, and advocacy
  • Contributed to guidelines, components, and website

Background

  • When I joined AppDynamics, the product was a hodgepodge of legacy UI with wildly inconsistent UX, a mix of different front-end technologies, and no clear guidelines for how to design for it.
  • There was no common design library available to designers, so they shared screens and copied and pasted from each other.
  • The UI in the current product looked dated and was glitchy.

Objective

Create a new design system from scratch for a complex enterprise application to increase efficiency and consistency.

Actions

  • Got executive buy-in and sponsorship to spend resources on building out a new design system from scratch.
  • The system consisted of reusable components (in Sketch, later Figma), UX guidelines, and Sketch plugins to speed up design and maintain consistency
  • On engineering side, the effort was supported by a dedicated team to code the components
  • Evangelized the design system in the company. Did several road shows in front of engineering, marketing, sales and executive leadership.
  • Established a dual-track strategy for supporting both legacy products and new product
  • Scaled design system team with internal and external additions

Impact

  • Launched system with over 40 components, with well-documented guidelines, design principles, use cases and variations, adopted by 15+ product teams. The initial version of the system was rolled out to internal teams within 8 months.
  • Changed the overall UI theme of the AppDynamics product (covering about 110 distinct screens and workflows) to match the new design system guidelines.
  • Increased designer efficiency by about 10x for common use cases
  • Increased consistency and reduced UI development tech debt
  • Reduced design/engg hand-off time by 75%
  • More than doubled accessibility score from <40% to over 80% through components

Process

I started by cataloging the existing UI as best as I could and examined the primary use cases. Then I identified and prioritized the components needed to build new screens for the most common use cases. In parallel, I prepared to socialize and evangelize the need for a proper design system, which surprisingly turned out to be one of the easier challenges because there was a shared understanding of the benefits of a well-engineered system among the engineering organization and leadership. Eventually, we formalized a four-person team dedicated to designing the system, where I took the lead design role. The other team members were my manager, a visual designer, and another senior designer.

We collaborated on the new components as a team, and I initially focused on forms, data grids, data visualizations, and layout patterns because these made up a large chunk of the existing application.

Shortly after the initial release of Particle 1.0, I took over as Director of Design Tech from my previous manager and continued to lead the team. In that role, I continued to evangelize the system to the broader company, train people on how to use it, and spearheaded a cross-functional accessibility initiative.

The system consisted of design libraries (first in Sketch, later Figma), extensive documentation on a custom-built website, interactive component previews using Storybook, a UI assets library managed by our team, and custom plugins for designers.

  • Prioritizing in-flight projects
  • Re-skinning legacy products
  • IA and 12-column grid responsive layout
  • Usage guidelines
  • Most common components
  • Common page layouts
  • Lack of dedicated PM supportEmphasized building trust and alliances with engineering
  • Linear project plan not feasibleRe-prioritized components based on product roadmap instead of atomic systemFast-tracked common layouts and flowsPartnered with feature teams to enable more outside contributions
  • “Kill-Flash” initiativeOldest screens in the product had to be fast-tracked leading to reprioritization
  • Executive decision to move ahead product launch and launch in dark modePrioritized theming effort, created pluginPartnered with Marketing to push the rebranding message

Highlights

Our broad, overarching design principles borrowed from Salesforce, whose Lightning design system I admire much. The main feature of these principles is that they serve as a decision-making tool because the tenets are ordered by priority, meaning that when you're in doubt which of a couple of design ideas is best, you can use these principles as a rubric. Our four principles are:

  1. Clarity: Draw out the most critical insights for users and show that upfront, but give them the ability to see how the system reached that solution.
  2. Efficiency: Streamline and optimize workflows. Intelligently anticipate needs to help people work better, smarter, and faster.
  3. Consistency: Consistent solutions to complex problems seamlessly integrated into the customer experience.
  4. Beauty: Demonstrate respect for the user's time through intentional and elegant craftsmanship in both function and form.

The order is important: when looking at two competing design solutions, the one that's more clear wins, even if the other is more consistent.

Problems:

  • “Sticker sheets” are hard to maintain
  • No version control – hard to update mocks
  • Complex components are difficult to create/manipulate, especially without detaching symbols

Solution: Modularized Component Library

  • Component library made from interchangeable building blocks
  • Switch out building blocks instead of detaching symbols
  • Version-controlled (Abstract + Sketch, Figma)
  • Controlled updates – designers can choose to opt out
  • Embedded specs/red-lines
  • Source of truth for engineering

The design system's Sketch library is an invaluable asset for designers, and we painstakingly took care of the smallest details to make the symbols as easy to use as possible. The library grew so big that we split it up into 14 different files to ensure snappy performance. We built the library following best practices in a modular fashion, with well-defined overrides, allowing designers to create complex combinations of components with little effort and without the need to detach symbols from the library. We also provided common page layouts to help designers get started on designs without reinventing the wheel.

The library is managed and version-controlled using Abstract, allowing us to control the assets tightly. We also used Abstract for getting feedback on designs from the product designers, UI engineers, and product managers, as well as for our team-internal approval workflow.

A design system is only as good as its documentation.

Problems:

  • Hard to find and share information if spread out over various systems
  • Component status not readily available
  • Designer and PMs can’t “try out” implemented components

Solution: Company-wide custom website and Storybook

Built customized CMS for Designers, PMs, Engineers and Executives

  • Design Principles
  • Brand Guidelines
  • Component Inventory and Status
  • Component Usage Guidelines
  • Governance Model and Contribution Guidelines
  • Standard for documenting and interacting with components in isolation
  • Reflects implementation, not just design specs
  • Multiple stories per component for different configurations
  • Answers most questions about functionality of components

Storybook has become a standard for documenting and visually testing components in isolation, and all our components are available in Storybook, often using multiple stories to showcase different configurations. Storybook has become the quasi source of truth for the design system because it reflects the actual implementation and not just the design specifications. We can answer most questions about the functionality of components by pointing people to Storybook, and the number of questions we are getting has dropped dramatically as a result.

Images, icons, and CSS styles – all managed by Design.

Problems: Friction between Engineering and Design

  • Relying on engineering to add and update assets to the code base adds friction and overhead
  • Difficult to try out style changes

Solution: Design-managed repository

  • Bitbucket repo for icons, images, CSS/Sass mix-ins, TypeScript constants
  • Managed and maintained by Design team
  • Utilized by Engineering in production
  • Easy to update – Engineering pulls in most recent version automatically

My team also created and maintains a library of UI assets used by UI engineers in production code. That includes icons, images, CSS and Sass mixins, and Typescript constants used in Angular. All style related information is abstracted away into variables, which allows our team to modify styles without the help of engineering. It also set us up for theming, which is another initiative we're driving.

Problems: common pain points for designers

  • It takes a long time to create realistic mocks without placeholders
  • It’s unusual to get realistic data from PMs – edge cases and scale often not considered
  • Editing data visualizations to reflect data is painful and very time consuming
  • No easy way to switch between light and dark theme in Sketch
  • Hard to keep track of bugs and change requests

Solution: Four productivity-boosting plugins

  1. API-driven Real Data plugin Populates designs with data from actual product Map design fields to any object
  2. Data-Visualization Generator Automatically create complex charts by entering data
  3. Theme Switcher Switch between dark and light theme within Sketch
  4. Embedded Bug Reporting Automatically file Jira tickets for individual components