Selected work shown. Internal names, implementation details, and unpublished concepts have been omitted or generalized.
THE FAILURE CONDITION
Canonical components had become unreliable enough that production required 90 defect patches
Bose.com was shipping from a monolithic design library containing more than 2,000 components. When shared components created visible issues, production overrides corrected individual pages without repairing the source. The site kept moving, but design and implementation drifted further apart—and each patch increased the cost of future change.
A customer-facing inconsistency surfaced on Bose.com.
A production override corrected the individual instance.
We traced the failure back to shared component logic.
The repaired source could support future use without the patch.
THE FIRST MOVE
I repaired the sources causing visible defects before expanding the system
As Product Design Lead and design-system owner, I worked with design, engineering, and content partners to trace recurring defects back to their canonical components. I prioritized customer-facing failures, clarified intended responsive behavior, and aligned component specifications with production implementation.
Within three months, the team had eliminated all 90 defect-related overrides. The sequencing mattered: restoring production integrity created the stability and credibility needed to address the deeper system architecture.
THE SYSTEM BEHIND THE FIX
The defects exposed a monolithic system that was difficult to trust or maintain
The immediate failures were only one symptom. The overloaded Figma library mixed current components, legacy assets, explorations, and unmerged work. Memory warnings, local component detachment, inconsistent naming, and unclear contribution paths made the dependable source difficult to identify.
Defined by what it lacked.
Named for its actual purpose.
Clarifying names, anatomy, and supported behavior made components easier to find and understand without publishing Bose's internal component structure.
THE OPERATING MODEL
I turned remediation into a more durable way to evolve the system
Separate shared layersI restructured the library around clearer inheritance, publishing boundaries, and ownership instead of asking every team to depend on one unstable file.
Modernize component logicI rebuilt priority legacy components with clearer properties, variables, responsive behavior, and supported configuration paths.
Make safe use explicitI introduced clearer patterns and governance so teams could adapt the system without detaching components or recreating shared behavior.
The goal was not a perfectly tidy Figma file. It was a dependable product foundation that different teams could use, implement, and extend without reopening the same production failures.
One example: reducing repeated navigation variants
I designed and handed off a lighter navigation model that consolidated six category-specific variants into one component, with content switched through variables while interaction behavior remained centralized.
One shared structure changed category content through variables instead of duplicating the same interaction model across six variants.
AN INITIATIVE IN MOTION
I prototyped a reusable alternative to repeated campaign-layout correction
Campaign assets combined background, product imagery, and copy into fixed compositions that required manual repositioning across responsive containers. I separated those layers in a coded prototype, tested responsive behavior, and documented authoring controls for implementation.
THE OUTCOME
The immediate defects were removed, and the system became safer to evolve
The verified result was the elimination of the 90 defect-related production overrides. Beyond that immediate recovery, the system had clearer inheritance, more maintainable component logic, and more explicit paths for teams to use and evolve shared assets.
Continuity after handoff: At the end of my tenure, I documented the major initiatives still in motion and assigned a point person to each workstream so the system could continue evolving rather than becoming a loose backlog.
Takeaway: Restoring a design system is an exercise in sequencing. Fix the customer-facing failure first, then change the architecture and operating model that allowed it to recur.