Problem
Teams were solving the same interface problems in different ways.
Puckboard needed a shared language for components, interaction patterns, documentation and scalability. Without a reusable system, designers and engineers spent extra time rebuilding decisions that should have been dependable product infrastructure which led to increasing tech debt.
Process
How the work moved from ambiguity to direction
Audited the product surface
Mapped repeated patterns, inconsistent states, accessibility risks, and the places where teams were already improvising local solutions.
Prioritized foundational components
Focused the first release on the elements that appeared most often and carried the most interaction complexity.
Documented usage guidance
Created practical guidance that helped teams choose the right component, understand states, and ship with less back-and-forth.
Iterations
What changed as the team learned
Before
Component work lived in scattered files
Design decisions were difficult to trace, which made it harder for new teammates to understand what was current.
Created a central reference point
After
The system became a product team workflow
Components, documentation, and contribution expectations were packaged together so adoption felt practical.
Reduced repeated design decisions
Design principle
Design systems are for the people
A strong design system is more than a component library. It gives teams a shared foundation for working faster, making clearer decisions, and creating more consistent experiences for users.
Nimbus brought patterns, styles, components, documentation, and design tokens into one source of truth. By pairing primitives like
blue/700 with semantic tokens like brand-primary/background, designers and engineers could speak the same language and apply the
system with more confidence.
Challenge
Turning broad feedback into focused decisions
This project came with a steep learning curve, especially as we brought the full design team into the process. With a two-month timeline and varying feedback across the team, we shifted from broad walkthroughs to focused 1:1 feedback sessions. This helped us gather more actionable input, prioritize decisions based on impact, and keep the system moving forward while ensuring Nimbus reflected the needs of the people using it.
Documentation
Creating a shared source of truth for every teammate
Documenting component decisions from design through development
To support adoption and cross-functional alignment, we created documentation that served as the source of truth for designers, developers, and new team members.
I owned the Confluence documentation and broke down each component's anatomy, states, usage guidance, and descriptions. This helped clarify how components should be used, reduced ambiguity during handoff, and made it easier for new designers to onboard into the system with confidence.
Rollout
Building confidence through hands-on onboarding
Helping designers learn Nimbus by using it
Because Nimbus introduced a significant shift in how our team designed, rollout was just as important as the system itself. To support adoption, we led an interactive onboarding session for the full design team, including a Figma playground where designers could explore the new components by recreating existing product pages.
We also hosted office hours and Q&A sessions to answer questions, gather feedback, and help the team feel confident using the system in their day-to-day work.
Impact
Results and signals
4 → 1 day
Design turnaround
Reduced the time needed to move design work through the system.
357 → 73
Components
Consolidated the system into 700 variants and more than 1,400 supported combinations.
469 → 73
Icons
Reduced duplication and made icon selection easier across the product.
Light + dark
Accessible themes
Delivered full accessibility in both light mode and dark mode.
Additional outcomes
Strengthening the system around the components
Looking ahead
What I would do with more time
I would establish a recurring contribution and governance cadence, use Enterprise analytics to measure component adoption and detachment, and continue partnering with engineers to track accessibility and implementation quality over time. This would help Nimbus keep evolving with the product while preserving the clarity and trust the team had built together.
Learnings & Reflection
Building confidence through systems thinking
Building Nimbus helped me grow beyond individual screen design and think more deeply about scalable systems. I gained a stronger understanding of how components, variants, properties, and tokens can improve consistency, flexibility, and efficiency across a product.
This project also strengthened my confidence in navigating ambiguity. With a tight two-month timeline, I had to learn quickly, apply new concepts in real time, prioritize feedback, and make decisions that balanced quality with momentum. It showed me how impactful design systems can be when they are built not just for consistency, but to help teams work better together.