overview
Nexus is Heritage Auctions' internal enterprise application, a complex, multi-department platform used by 1,000+ users across auction management, lot cataloging, client management, invoicing, imaging, shipping, operations, and more. Each department has distinct workflows and needs, making consistency and scalability non-negotiable requirements for any design system supporting it.
When I joined Heritage Auctions, the design system for Nexus was low-fidelity, fragmented, and misaligned with engineering components. It lived in Axure — legacy tooling that lacked the structure needed to support modern workflows. As the team transitioned to Figma, designers were effectively starting from scratch on every project. UI was frequently recreated, patterns were inconsistently documented, and multiple solutions emerged for the same problems. This slowed designers down, complicated handoff to development, and made it difficult for stakeholders to understand designs, compare solutions, and provide meaningful feedback.
Two months into the role, I recognized the opportunity and proactively took ownership of the problem. Having recently completed a course on building scalable design systems in Figma, I proposed establishing the first comprehensive design system for Nexus and built it from the ground up.
That was December 2021. I have owned and evolved the system ever since.
MY Role
Design System Owner
TEAM
Design Team
(5 designers initially, now 11)
Engineering Team
TIMELINE
Nov 2021-Jan 2022 (initial build)
Ongoing ownership
Dec 2025–Jan 2026 (full refresh)
Design Systems
Component Architecture
Governance
Enterprise UX
The Challenge
Nexus had grown organically, and the design infrastructure hadn't kept pace. Four compounding problems made the existing system unsustainable:
Challenge 01
A Fragmented Library
The Axure component library was low-fidelity, inconsistently structured, and poorly documented. Designers didn't trust it or use it. Every project effectively started from scratch.
Challenge 02
No Single Source of Truth
With no Figma system in place, UI was recreated constantly. Multiple solutions existed for the same problems, and there was no mechanism to align on the right one. Inconsistency compounded across every project.
Challenge 03
Design & Engineering Misalignment
The existing library bore no meaningful relationship to what engineering had built. Naming conventions, component behavior, and interaction patterns differed between design and development, creating friction at every handoff.
Challenge 04
A System That Couldn't Scale
With a growing team, expanding product surface, and no governance in place, the same problems that made the Axure library unusable were guaranteed to repeat unless the new system was built to prevent them.
Research & Discovery
Although this was a design system project, I approached it like any other UX project: I had real users (designers and developers) who were experiencing real problems. My goal was to understand those problems deeply before proposing any solutions.
1
Component audit
Reviewed the Axure library to understand gaps, inconsistencies, and technical debt
2
Designer workflow analysis
Observed how teams were currently designing, duplicating patterns, and recreating components
3
Developer interviews
Identified integration challenges, naming conventions, and handoff concerns
4
Benchmarking
Compared structure, documentation, and component architecture across Material, eBay, and Spotify design systems
5
Best practices review
Used Mizko's guide for building scalable, future-proof Figma design systems
Benchmarked Systems
Material Design
Structure · Tokens · Docs
eBay Design
Component Architecture
Spotify Design
Governance · Patterns
Mizko's Guide
Figma best practices
Five insights shaped the direction of the system:
1
Designers needed clarity
They didn't trust or use the Axure library because it lacked structure, consistency, and documentation. Adoption would only happen if the new system was self-explanatory.
2
Developers needed alignment
They needed naming conventions, props, and interaction patterns that matched what engineering was building, not a parallel system requiring constant translation.
3
Teams needed a single source of truth
With no Figma system in place, every project started from scratch. The inefficiency wasn't a habit problem; it was a structural one.
4
Migration required reimagining, not porting
Axure components were too rigid and low-fidelity to translate directly. The transition required rethinking components using Figma's strengths: variants, auto-layout, constraints, and tokens.
5
Structure, documentation, and governance were non-negotiables
To prevent the same problems from repeating, the new system would require clear naming conventions, usage guidelines, and a contribution process that kept it maintainable over time.
System Architecture
The system initially adopted the atomic model — a well-established framework that provided a clear starting point during the build. It gave the team a familiar structure during the transition from Axure and ensured components were built with composability in mind from the beginning.
Component Strategy
I rebuilt all components from the ground up using Figma best practices — variants, auto-layout, and semantic naming — ensuring they were flexible and resilient rather than static replicas of Axure widgets. Every decision was made with scalability in mind: components needed to adapt to real product use cases, not break under them.
Close alignment with engineering was non-negotiable. I consulted developers throughout to ensure component behavior, states, pixel values, and constraints matched what engineering had built. Rather than designing independently and reconciling later, this close collaboration meant design adjusted to reflect engineering's reality from the start, establishing a shared vocabulary and preventing misalignment from surfacing at handoff.
The system launched with color, typography, spacing, and iconography tokens, approximately 15 components with variants, and 5 foundational patterns. This initial scope focused on the highest-frequency use cases, providing a manageable foundation that could evolve alongside the product.
Usability Testing
I conducted usability testing with designers to validate that the system was working as intended; components behaved as expected, assets were easy to locate, and the library was intuitive to navigate. This ensured the system solved the problems designers were actually experiencing before it was widely adopted.
Because the design system launched alongside the team's transition to Figma, testing happened against real active work rather than hypothetical scenarios. Designers were building new designs in Figma while a separate initiative gradually migrated existing Axure designs over time. During daily standups, I built in regular check-ins where designers could surface issues, creating a lightweight but consistent feedback loop.
Figma File Structure
Alongside the design system, I established the file and project structure for all of Nexus in Figma to replace the disorganized Axure library with a consistent, predictable system.
Because Nexus is a large enterprise application with 1:1 designs maintained for every screen in the product, the volume of design files is significant. A clear, standardized structure was essential to keep designs findable as the library grew. I organized projects by entity, mirroring how Nexus itself is structured. Each entity project contained three standardized files, keeping designs easy to locate regardless of who was looking:
Documentation & Guidelines
Approximately one year after the initial build, I introduced standardized documentation for each component. The existing system had components but no consistent guidance on how to use them, which meant designers were still making independent decisions that led to inconsistencies over time.
Each component page was updated to include usage guidelines, do/don't examples, behavior rules, state definitions, and accessibility considerations. Documentation was written for the actual users of the system, not as abstract reference material.
This documentation layer was fully revisited and expanded during the 2025–2026 refresh, aligning with the updated component architecture and incorporating lessons from years of real-world usage.
Governance
As the design team and product surface grew, the way designers interacted with the system had to evolve. What worked for a team of five didn't work for a team of eleven. Because I had built the system from the ground up, I had deep context on how components were architected, what patterns existed, and why decisions had been made. Centralizing updates through me ensured that context was preserved and that every addition met the same quality bar as the original system. The governance model needed to protect that consistency while giving designers the autonomy to move quickly on their own work, without me becoming a bottleneck.
That balance evolved through four stages, each a direct response to a specific pain point:
Direct requests
The team was small and working with a brand new system, which meant gaps surfaced constantly. When a designer encountered a missing component or pattern, they'd send me a screenshot and I'd build it. This worked well early on. The team was learning the system, and close communication meant I could catch nuances and build components correctly the first time. As the team and backlog grew, however, real-time requests became impossible to keep up with.
Parking Lot
To manage the growing volume of requests without sacrificing quality, we introduced a shared parking lot where designers could log needs as they came across them. I reviewed and addressed items quarterly or as bandwidth allowed. This decoupled requests from my immediate availability and gave the team a reliable place to log needs without expecting an instant response. Over time though, the parking lot addressed the volume problem but not the consistency one. There was no formal process governing how new patterns and components were designed before they were submitted, which meant quality and approach varied across requests.
Pattern Creation Process
Rather than continuing to funnel all new work through me, I formalized a process that empowered designers to create patterns themselves while maintaining the quality bar the system required. The process ensured nothing was added to the system without proper vetting:
Designer checks the DS to confirm no existing component addresses the need
Designer raises the need in weekly design collab to catch any parallel work across the team
Once confirmed, designer creates the pattern to meet their specific need
Pattern is reviewed with the design team for alignment
Pattern is reviewed with a developer for feasibility
Designer implements the one-off in their file and leaves a Jira comment tagging me to backfill the component into the DS
This gave designers autonomy without bypassing the system and ensured every addition could potentially address multiple designers' needs, not just the one who requested it.
Jira Tickets
As the team continued to grow, we formalized design debt tracking through a dedicated Jira queue. A "design system update" label was introduced, allowing designers to create tickets that I filter and address as bandwidth allows — following the same pattern creation process established in Stage 3. This gave full visibility into the Design System backlog, made prioritization easier, and integrated system maintenance into the team's existing workflow rather than running it as a parallel process.
Over time it became clear that the atomic model was creating friction in practice. Designers would encounter builder components like grid rows, columns, and cells in isolation, with no context for how they related to the full component. The hierarchy was technically correct, but it wasn't how designers actually navigated the system.
During the refresh, I restructured the architecture into five layers that better reflected how the team actually works: Tokens, Components, Patterns, Templates, and Documentation Assets. Everything related to a component now lives on a single page: variants, documentation, builder components, and usage guidance together. Hidden components remain accessible but are no longer surfaced in a way that creates noise.
Four years of ownership gave me a clear picture of where the system was creating friction and Figma's updated functionality gave me the tools to fix it. The refresh was both a technical upgrade and a usability overhaul. It also became an opportunity to standardize tokens and spacing across the system, moving away from values that were purely product-matched toward a more deliberate, systematic foundation.
Want to see the component improvements in action?
Rollout & Adoption
A system refresh is only as good as its adoption. I treated the rollout as a designed experience in itself.
1
Team Walkthrough
I facilitated a full walkthrough for all designers covering major changes, hierarchy updates, and clear definitions of each system layer. Written guidelines covered what could and couldn't be detached.
2
Hands-on Workshop
I created a pre-built modal using updated components and patterns with specific variants and properties applied. Designers recreated it from scratch for hands-on practice before launch & everyone rated their comfort 4 or 5 out of 5 by the end.
3
Adoption Rules
I provided explicit guidance on when to replace components during active file work versus when to leave existing instances to avoid breaking Jira links.
4
Initial Adoption Support
I established a dedicated Teams channel for questions during the initial adoption period, giving designers a quick, low-friction way to get help as they got used to the updated system.
5
Ongoing Practice & Feedback
Once the initial period ended, we shifted to quarterly check-ins where designers flag components they're less familiar with for group practice — covering both lingering gaps from rollout and newer additions designers haven't had time to explore. Next, I'll be reviewing Figma system analytics quarterly to assess adoption and proper usage (e.g. detachment rates), and introducing designer surveys for formal qualitative feedback.
Impact
The Nexus Design System is now the foundational layer of how the Heritage Auctions design team works — and the difference from where we started is observable at every stage of the process.
Designers report significantly less time spent recreating components or searching for the right pattern. The consistency of the system means that UI in design reviews looks and behaves like the real application. Stakeholders who weren't familiar with low-fidelity design concepts were surprised to find designs indistinguishable from the live product, allowing reviews to focus on decisions rather than UI differences.
Design-to-development handoff has improved meaningfully. Shared naming conventions, aligned component behavior, and a system that maps directly to engineering's library have reduced the back-and-forth that previously slowed delivery.
The refresh rollout produced an immediate confidence signal: all 11 designers left the hands-on workshop rating their comfort with the updated system at 4 or 5 out of 5. A pre-refresh analytics snapshot has been taken and will be compared against future usage data to track component adoption, correct usage, and detachment rates over time.
Learnings
Building and owning a design system over multiple years taught me that a design system is never finished. It's a product with users, feedback cycles, and evolving needs. The most important thing I did wasn't building the right components in 2021; it was staying close enough to how designers were using the system to know when it needed to change.
Governance was the hardest thing to get right. In the early stages, I underestimated how much the process needed to scale alongside the team. Each time the system started to feel like a bottleneck, it was a signal that the governance model had outgrown itself, and that recognition became the trigger for the next evolution.
The refresh also reinforced that documentation and education are as important as the system itself. Launching better components without a structured rollout would have left designers uncertain about what changed and why. The workshop format that gave designers hands-on practice before the system went live was the single most effective adoption decision I made.