Design System Architecture & Maintenance

Design systems are meant to reduce inconsistency, speed up delivery, and make adoption easier for designers and developers alike. At SharpSpring, the goal was to stabilize and prepare the system for broader adoption across teams despite limitations in tooling and performance. I split the system into multiple files for performance reasons, added visual file covers, and introduced a standardized format with separate component and spec pages.

Once Figma released variables, I shifted focus to consolidating and streamlining. I created tokens for colors, type styles, and spacing, eliminating the need for bloated variant sets. I also created a sticker sheet of higher-order components (“organisms”) designed to be broken down safely by designers, allowing for flexibility in content while retaining update paths for foundational atoms and molecules.At Constant Contact, I wasn’t on the design system team at first, but contributed significantly, designing a complex table component with sorting, column, and row variants that multiple teams adopted.

I later migrated design components to native mobile environments, reconciling design–dev inconsistencies between React, SwiftUI, and Kotlin. For example, SwiftUI’s lack of line-height support required manual padding and spacing adjustments to maintain visual parity.

SharpSpring's biggest challenge was technical debt and memory limitations. At the time, Figma couldn’t handle large monolithic libraries, and components were overly granular with unnecessary variants. I created a temporary multi-file system with strong labeling, documentation, and covers. Later, I cleaned up the system by using Figma’s variable release to collapse variant structures and tokenize styles, reducing component weight and speeding up performance.

At Constant Contact, cross-platform inconsistencies were the core issue. SwiftUI didn’t support certain typographic features, and spacing logic differed from the web system. I had to rebuild spacing rules and component structure in Swift and Kotlin, preserving consistency in feel, even when parity wasn’t possible. I created and maintained a mobile sticker sheet following a clear tokenized system and applied the breakable-organism approach I developed at SharpSpring.

One recent example is the Lead Magnet feature, a powerful acquisition tool with no prior design system support. I helped establish a miniature system within the product, aligning with our core “Rise” design system visually while accounting for the feature’s unique tech stack (non-React). I focused on creating reusable layouts and responsive data components with a clear visual hierarchy, helping teams move faster without reinventing everything from scratch. With more time, I would have extended this work to a full-feature kit of Lead Magnet tokens and component guidelines, aligning it more tightly with Rise and systematizing future design needs as the product evolves.

At SharpSpring, designers were able to work more fluidly without crashing Figma files, and adoption of core components improved as documentation and sticker sheets gave them flexibility and clarity. At Constant Contact, my table component became widely adopted and was praised for how easy it was to configure. Mobile parity improved after our system migration, and I was regularly pulled into conversations around design system decisions due to my clarity of documentation and thoughtful approach to structure.

Design systems work best when they empower, not restrict, teams. My approach is to make systems sturdy enough to scale, but flexible enough to adapt. That means setting strong foundations (tokens, taxonomy, naming) while building tools that fit the messy reality of actual product work. Whether I’m fixing broken padding logic in SwiftUI or building component logic that lets designers “break things” safely, I aim to make systems feel less like rules and more like a toolbox.