Veloe
Standardizing a Design System Across Multiple Digital Products
Overview
Veloe's product ecosystem had grown across multiple digital products, B2C and B2B, each maintained by a different squad, and each had accumulated its own version of what should have been shared components. There was no single source of truth for how a button, a form state, or a card should look or behave, which meant every product was solving the same visual and interaction problems independently, and inconsistently.
I led the structuring and scaling of Veloe's Design System over a 7 month engagement, working as the sole designer on the project alongside one DevOps partner. The objective was twofold, standardize the components and tokens used by designers and developers across every product, and build a practical culture of adoption, so the library became something teams actually used, not just something that existed.
Business Context
Three business pressures made this project necessary. Visual inconsistency between products was becoming visible to users moving between Veloe's B2C and B2B experiences, undermining a sense of one cohesive platform. Feature delivery speed was suffering, since every squad was rebuilding basic components instead of reusing shared ones. And onboarding new designers and developers was slower than it needed to be, with no standardized library to ramp up on, each new hire had to learn each product's own undocumented conventions from scratch.
A Design System wasn't a nice to have here, it was infrastructure that every other product team's velocity depended on.
Why This Was Hard
Multiple squads, multiple standards, no single source of truth
Each product team had organically developed its own patterns, and none of them fully matched. Consolidating this wasn't a matter of picking one existing standard and enforcing it, most needed to be rebuilt or reconciled from scratch.
Adoption resistance
A Design System only works if teams actually use it instead of their own established habits. Getting squads that had been working independently for years to change how they built interfaces required more than documentation, it required convincing people the change was worth the short term friction.
No standardized tokens in the existing library
The library that did exist lacked standardized tokens, which meant even where components existed, applying them consistently across products wasn't actually possible yet. Tokens had to be defined before consistency could be enforced at scale.
My Role and Ownership
I worked as the sole designer on this project, partnering closely with one DevOps team member across the full 7 month engagement. My ownership spanned:
Organizing and documenting existing components, auditing what already existed across products before deciding what to keep, consolidate, or rebuild.
Mapping components scattered across Veloe's products, working directly with each product's designers to identify every variation in use.
Running weekly workshops with product teams, teaching the importance of the Design System and providing practical instruction on how to use it, not as a one time training, but as a recurring touchpoint throughout the project.
Selecting which components would be adopted globally across teams, defining every component's states, and creating the token system that underpinned them.
Running QA on everything built, alongside other designers, before any component was considered ready to publish.
Owning publication and communication of every Design System update, using the weekly team sessions and a dedicated group as the channel for rollout.
Approach and Key Decisions
Decision 1 (Audit and document before building anything new). Before proposing any new component, I organized and documented what already existed across Veloe's products. This gave the project a real baseline instead of starting from assumptions about what needed to change.
Decision 2 (Map components with the people who built them, not around them). Rather than auditing products from the outside, I mapped scattered components together with each product's own designers. This surfaced context a purely visual audit would have missed, and started building buy-in from the same teams who would later need to adopt the system.
Decision 3 (Teach adoption weekly, not once). I structured a recurring weekly workshop with product teams covering both the importance of the Design System and practical instructions for using it. Treating adoption as an ongoing conversation, rather than a single launch announcement, was central to overcoming the resistance built up from years of independent team habits.
Decision 4 (Define tokens before enforcing consistency). Since the existing library lacked standardized tokens, I prioritized building the token system alongside component selection, rather than after. This meant consistency was structurally enforced through the tokens themselves, not left to each team's discretion.
Decision 5 (Select for global use deliberately, not exhaustively). Instead of trying to standardize every component that existed, I selected which components would be adopted globally across teams, defining clear states for each. This kept the system focused on what teams actually needed shared, rather than becoming bloated with edge cases.
Decision 6 (QA as a shared responsibility, not a solo gate). Every component built went through QA together with other designers before publication, catching inconsistencies and usability issues before they reached product teams, rather than after adoption had already started.
Decision 7 (Treat every update as a communication event). Each new version was published alongside deliberate communication of what changed, delivered through the same weekly sessions and group channel already established for training. This kept the Design System visible as an evolving product, not a static deliverable teams would forget about after initial rollout.
AUDIT > TOKENS > COMPONENTS > ADOPTION
Components and tokens were selected for global use across Veloe's B2C and B2B products, with every state defined, QA'd alongside other designers, and published to teams through the weekly sessions.
Outcomes
Adoption of the Design System increased by more than 50% among Veloe's designers and developers, a direct measure of the workshop and communication strategy working, not just the components existing.
Teams developed a clearer understanding of why a Design System matters, and greater respect for the process behind creating and evolving one, shifting the culture around shared components, not just the components themselves.
Delivery speed increased across every team and product using the system, as squads spent less time rebuilding basic components and more time on product specific work.
Key Learnings
Workshops taught me to communicate across professional profiles
Running workshops taught me how to lead discussions and communicate across multiple professional profiles. Presenting the same material to designers, developers, and stakeholders with different priorities and vocabularies sharpened how I structure and deliver a message so it lands with each audience.
Ops focused projects live or die on planning
I learned how essential it is to break an initiative like this into clear phases with defined scope, since a Design System touches every team at once, and without structure it's easy for the work to sprawl without ever reaching adoption.
A Design System should be treated as a product, not a deliverable
It needs its own phases, research, evolution, and ongoing management, the same discipline applied to any product Veloe ships to its users, applied instead to the system its own teams build with.
Closing Statement
Leading Veloe's Design System taught me that Ops work is still design work, just aimed at the people building the product instead of the people using it. Getting adoption right meant treating consistency as a habit to build, not a rule to enforce, and treating the system itself as a product with its own roadmap. It's a discipline I now bring to every product I help scale, not just the screens, but the standards that hold them together.