Design System Rebuild
Transforming the product experience of Sherpany's board meeting platform through a new design system, timed to a company rebrand.
Client
Sherpany
Year
Jan 2023 – ongoing
Role
Senior Product Design. System Manager. Bridge between design and engineering.
Stack
Figma · Tokens Studio · Style Dictionary · Storybook · Supernova.io
Context
Sherpany builds the platform executives use to run board meetings. By early 2023 the product carried four years of accumulated inconsistency. The same component often looked and behaved differently from one screen to the next, because the design library it came from had stopped being a system.
Primitives and product-specific components lived in one Figma file imported from Sketch, rules tangled with feature logic, specs that no longer matched what shipped. A rebrand was coming. Building it on that foundation would have shipped the inconsistency forward, not fixed it.
Problem
I was hired in January 2023 to prepare the product for a company-wide rebrand landing in May 2024. That was the brief on paper.
The real problem was what the users lived with. The design and the code had drifted far enough apart that the same component had different specs in each. The product looked inconsistent to the executives using it, and it slowed the teams building it, because every squad solved the same problems a different way.
So the work had two faces from the start. The visible one: turn a dated, inconsistent product into a coherent, rebranded experience without disrupting the people who open it every day. The structural one: rebuild the foundation underneath so the transformation would hold, and so the next rebrand would be trivial. Both mattered. The second was how I delivered the first.
Approach
The rebuild ran in four phases, each sequenced to ship visible value without blocking the squads working toward the rebrand deadline.
Phase one was typography and icons. Highest visual impact, lowest technical risk. The product got an immediate brand signal while the infrastructure work was still underway. Phase two brought the global colour system and light theme, completing the visible transformation and laying the semantic token layer that turns future rebrands into a values-only change. Phases three and four moved into components: high-frequency elements first, the buttons, inputs, and patterns touching most workflows, then the complex systems, navigation, tables, filtering. Each phase kept the squads unblocked. That was the constraint everything else was built around.
Underneath the sequencing were three decisions.
The first was whether to refactor or rebuild. Refactoring felt safer, but the legacy was deep enough that fixing it in place would have taken longer than starting over. With one window before the rebrand landed, I chose to rebuild. The hardest part wasn't the work. It was making that call early in the role, before I'd earned the trust to make it.
The second shaped everything that followed. When I built the token architecture, I didn't start from a design-led ideal and ask engineering to adopt it. I started from what production actually used. Tokens mirrored the code, not the other way around. Instead of handing engineering a new language to learn, design adopted the existing one and gave it structure. That closed the gap at the foundation instead of patching it at the component level.
The third was governance. A new system without new ways of working would drift again within a year. I introduced a branching workflow in Figma, locked the master and production files behind review, and required merges to pass a design review step. The goal was making consistency the default path, not the disciplined one.
Work
I separated the design system from the product library so each had a clear boundary and a clear owner. The system holds primitives, tokens, and core components. The product library holds the feature-specific compositions built from them.
The token system was built from scratch in Tokens Studio, piped through Style Dictionary, and aligned one-to-one with production variables in Storybook. Semantic tokens sit between primitives and components, so when the rebrand lands it changes values at the semantic layer without touching a single component.
What the infrastructure bought was product transformation you can see.
Outcome
| Metric | Before | After |
|---|---|---|
| Components in sync with code | ~40% | 100% |
| Components | 40 | 54 |
| Token layers | 0 | 3 (primitive · semantic · component) |
| Figma libraries | 1 mixed | 4 (core + rays + specialized + squads) |
| Rebrand scope | Full rewrite | Semantic layer only |
| Conflicts | 34 | 0 |
The result users and squads felt: one visual language across the product for the first time, and faster delivery on top of it.
The design system introduced and driven by Francisco unified our app's visual language, improved usability, sped up development, and made fixes scalable across the entire product.
Daniel Vieira · Squad Lead · Squad Atlas · Sherpany
Reflection
Rebuilding a system is a political project as much as a technical one. The token decision, matching production instead of leading it, was the one that earned trust fastest, because engineering saw design solving a shared problem instead of creating a new one.
Images by @stefano-gemmiti 👍
Other Projects
