TigerGraph Design System
I owned the end-to-end strategy and rollout of TigerGraph’s first Design System to reduce UI fragmentation across products and make delivery more predictable for designers and engineers. This wasn’t a “component library” effort—it established the operating model: shared tokens, standards, documentation, and a contribution workflow that helps teams ship consistent UI in graph-heavy enterprise experiences.
Time
Jun–Aug 2024
Role
Design Lead
Tools
Lovable, Figma, Chat GPT
When UI inconsistency started costing real time and money
As TigerGraph expanded into multiple products, teams kept rebuilding the same UI patterns in slightly different ways. That fragmentation created hidden costs: design time lost to repeated decisions, engineering time lost to re-implementation and alignment, and QA time lost to preventable visual regressions. The problem wasn’t a lack of components—it was a lack of shared standards that could keep delivery fast and consistent across teams.
Business goal
Cut cross-team rework and QA churn by standardizing UI decisions—so teams ship faster at lower cost.
Research: we aligned on what was actually breaking
Before building the design system, we ran stakeholder interviews across product design, engineering, PM, and QA to pinpoint where time and cost were leaking today—and what would make the system actually adoptable.
Key finding
Fragmented libraries created decision paralysis
General chat assumes users can ask well; our opportunity is to make “good prompting” a UI default—start with a few task-shaped starters that match the page, not a blank box.Reuse felt risky, so duplication became the default
Because reusability wasn’t clear (what’s shared vs product-specific), designers avoided reuse and built “one-off components” inside individual files, which multiplied maintenance and drift.Missing state and behavior guidance broke handoff
Lack of guidance for states, behaviors, and edge cases (not just visuals) caused design-to-dev gaps—engineers had to guess, and QA repeatedly caught inconsistencies late.
Our challenge
Interviews made it clear: the cost wasn’t in designing UI—it was in repeated decisions and rework. To ship a design system under real delivery pressure, we had to solve four constraints at once.
Speed at scale
We needed the system in use fast without slowing product delivery. The MVP had to scale—otherwise we’d just create a new kind of debt.
Legacy constraints
Engineering wanted to build the system on top of Base UI to reuse and evolve existing components instead of rebuilding. It reduced rework, but also constrained modernization—so we kept what shipped and upgraded only what blocked consistency and scale.
Fragmented collaboration
Unclear cross-project reusability pushed designers to build components in local files, creating many “close-enough” variants. Alignment became ongoing cost: reviews, re-implementation, and QA churn.
Minimize disruption for existing users
Existing users were used to the old UI and behaviors. We had to upgrade the foundation while keeping the experience stable to avoid confusion and resistance.
Plan first. Ship faster.
Before we built the system, I laid out an MVP roadmap with clear scope, owners, and weekly milestones. It aligned design, engineering, and product on what we would ship first—and what we would intentionally defer—so the rollout didn’t compete with ongoing feature delivery. The shared tracker kept progress visible and decisions accountable, which reduced coordination overhead and helped the team move in sync.
Audit research, scaled with AI
We audited components across TigerGraph products to capture real use cases and understand how the same function was implemented under different workflows—what it looked like, how it behaved, and where it diverged. AI helped us synthesize the volume: it clustered similar examples, highlighted recurring inconsistencies (styles, state coverage, interaction behaviors), and summarized the different requirements teams had for the “same” component. The outcome of this phase was evidence—clear problem signals and shared understanding—so we could move forward with confidence.
From audit to standards
Once the audit mapped what was shared and what diverged, we shifted from “inventory” to “standardization.” We grouped similar components into families, defined what must be consistent across products, and what can remain flexible per workflow. Because the scope was a full component revamp, we also set a shared build standard and assigned owners—so multiple designers could rebuild in parallel without creating new drift.
Design Tokens as a single source of truth
TigerGraph ships across multiple products, so UI decisions can’t live inside individual components or files. We built design tokens as a shared semantic layer for color, spacing, typography, and states, so changes scale across products instead of being repeated component by component.
AI sped this up by normalizing naming and flagging duplicates and mapping conflicts, then we reviewed and locked the final taxonomy as the source of truth.
One design, two themes
With tokens in place, light/dark mode became a switch—not a second design. We designed once, and theme mappings handled color and contrast across products, so teams didn’t maintain two sets of UI.
It gave teams a reliable way to support different environments and preferences, while keeping the system clean and scalable.
Graph visualization, standardized
In the audit, graph visualization stood out as a system-level inconsistency: the same nodes and connections could look and behave differently across products, and labels often became unreadable at certain zoom levels.
We brought these graph primitives into the design system as first-class components, standardized their key states, and defined zoom-based rules for sizing and label display—so graph information stays legible and interactions stay consistent everywhere.
Built-in accessibility, not a patch
Accessibility was built into the system as “default behavior,” not a QA fix at the end. As we rebuilt components, we designed for responsive layouts, defined keyboard interactions and focus order, standardized focus states, and added screen-reader labels/roles—then verified color contrast with WCAG checks. To make handoff reliable, we also shipped accessibility annotations so engineers could implement the same intent consistently across products.
AI-accelerated documentation
A design system doesn’t land until teams can find answers on their own. We used Lovable to build the documentation site and populate it with usable guidance—all within a few days—covering what each component is, when to use it, edge cases, and accessibility notes. That speed removed tribal knowledge, made adoption easier, and closed the loop from building the system to getting it used.
Result
We shipped the first phase of the TigerGraph Design System as shared infrastructure across products—tokens, components, themes, accessibility, and documentation that teams could self-serve.
The impact showed up in day-to-day delivery: less repeated design work, fewer visual regressions, faster design–dev handoff, and a growing set of standardized components that teams could reuse with confidence.
Redundant Design Work
Visual QA Bugs
Standardized Components
Iteration & Learning
Building the design system taught me that the hardest part isn’t creating components—it’s creating the system that keeps them evolving.We introduced lightweight feedback channels, regular cross-team reviews, and update walkthroughs so the system could improve continuously as products shipped.
The biggest takeaway: a design system scales not through more components, but through clear ownership, simple processes, and documentation that teams actually use.
.say hello