Particle Design System
- Eric Wienke
- 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.
High-Level Elements
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.

Prioritization
Prioritizing in-flight projects
Re-skinning legacy products
IA and 12-column grid responsive layout
Usage guidelines
Most common components
Common page layouts
Challenges and Roadblocks
Lack of dedicated PM support
Emphasized building trust and alliances with engineering
Linear project plan not feasible
Re-prioritized components based on product roadmap instead of atomic system
Fast-tracked common layouts and flows
Partnered with feature teams to enable more outside contributions
“Kill-Flash” initiative
Oldest screens in the product had to be fast-tracked leading to reprioritization
Executive decision to move ahead product launch and launch in dark mode
Prioritized theming effort, created plugin
Partnered with Marketing to push the rebranding message
Highlights
Design Principles

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:
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.
Efficiency: Streamline and optimize workflows. Intelligently anticipate needs to help people work better, smarter, and faster.
Consistency: Consistent solutions to complex problems seamlessly integrated into the customer experience.
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.
Design Library (Sketch & Figma)
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.
Documentation
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
Storybook

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.
UI-Assets Pipeline
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.
Custom Plugins

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
API-driven Real Data plugin Populates designs with data from actual product Map design fields to any object
Data-Visualization Generator Automatically create complex charts by entering data
Theme Switcher Switch between dark and light theme within Sketch
Embedded Bug Reporting Automatically file Jira tickets for individual components
