Vama Design System
2024 – 2025 / Design System
/ Background
Vama is an integrated payments and communication platform, redefining convenience and productivity for modern digital communities.
/ My Role
As Design Systems Lead at Vama, I architected and scaled the Vama Design System (VDS) to transform a fragmented design ecosystem into a unified, scalable infrastructure that enabled faster delivery, improved quality, and cross-team alignment for a 50+-person product team.
I led the definition, architecture, and rollout strategy of VDS: designing core principles, establishing component taxonomy and tokens, structuring documentation, and coordinating adoption across design, product, and engineering teams. I also shaped governance models and workflows to institutionalise the system as a shared source of truth.
Motivation to implement:
Before VDS, Vama’s design development was ad hoc: page-specific visuals without cohesive structure or shared architecture. This led to high UI defect churn, slow design-to-dev handoffs, and inconsistency in stakeholder approvals. These are symptoms of a larger scalability problem that threatened MVP expansion and future feature velocity.
Getting initial buy-ins:
Proper planning and alignment is essential to smoothly drive any DS-implementation. To secure the initial stakeholders’ buy-in, I went with a data and principle driven approach:
/ I built an audit map across the 3 existing product surfaces to identify high-level inconsistencies and issues
/ I defined possible solutions with fundamental principles to showcase how they can alleviate current and future issues
/ I drafted a rough workflow process based on balancing between new implementations and incremental back-updates for current designs
I then organized an open discussion-and-alignment session with product and development with the above data to iron out questions and issues that can arise from difference in perspectives, before presenting the final recommendation to our C-suites.
With this, we were able to secure initial buy-in from our C-suite stakeholders to implement the VDS concurrently with feature design and development.
Architecture and build:
VDS was planned in two phases to balance early value delivery with long-term scalability. Phase 1 focused on a lightweight, developer-friendly system to rapidly demonstrate impact and smoothly onboard them, while Phase 2 expanded documentation and usage guidelines for broader team adoption.
This was because it was the first time a DS was implemented in the product, so we needed an upfront display of tangible value to fully solidify the team’s buy-in as a whole to properly realize the potential of the VDS.
The VDS is made up of 3 libraries:
/ A foundational library that contains primitive tokens and references for basic colors, typography, and structure
/ A component library that contains all components as well as their tokens and documentations
/ An asset library that contains icons and other visual and non-visual assets like animations, logos, and audio
This gives sufficient content segregation to aid in easier usage of the VDS from not just designers, but developers and any other team members as well
A simple token structure was adopted, with a 3-tier vertical system of primitives, semantics, and component tokens, combined with multiple horizontal modes to support platform-scaling, as well as color theming.
This provides a robust and scalable infrastructure that allows us to expand on customization in the future while keeping the initial tokens to a minimal complexity.
An atomic system for managing components was adopted, using atoms, molecules, and patterns to establish component relationship and usage, for clarity and modularity.
Across the 2 VDS phases, the main change in content was on how we managed documentation:
/ In phase 1, we focused on exposing very direct tech-focused documentation, aiming at providing clear information and guidance for developers as part of easing them into the new system
/ In phase 2, we transitioned to more of a usage-based documentation that provided more robust guidelines that focused more on general usage, something that benefits the wider team
With the basic infrastructure of the content side of the VDS set-up, we then focused on planning how we were going to proceed with population and content creation:
/ Due to the large number of tech debt and a need for speed, phase 1 focused on adapting existing designs into more systematic values that adhere to the VDS structure, this involves balancing color, sizes and spacing from existing styles and components and materializing them into proper VDS components
/ More extensive branding and customization was saved for phase 2, together with a massive accessibility update, where we were able to make value changes at scale upon the foundations we set up in phase 1
As of October 2025, the VDS is home to over 70 components and 800 tokens, all fully documented and governed
Governance that evolves:
With the content-side set, I then focused on setting up a proper governance model as well as end-to-end workflow processes
In general, governance evolved with maturity. Initially, I owned all contributions to quickly build the system while minimizing ambiguity. As VDS usage grew, we transitioned to a collaborative model: designers could propose updates, and I reviewed changes to uphold standards.
We leveraged Figma’s native version history and branching for version control, and established weekly DS syncs and a cross-functional VDS channel to surface issues, educate users, and accelerate adoption. This governance model reinforced consistency and reduced decision overhead.
On the more technical side, component implementation made use of the provided guidelines and dev-mode for easier reference and translation. Making use of Figma’s native Code-Connect is a high priority integration for the future to further speed up design implementation.
Token implementation was done through exporting variables as CSS sheets that are version-grouped and shared via Google Drive, where developers make use of custom scripts to ingest the tokens and auto-updates their codebases
In a perfect world I would have wanted the tokens to live as a repository in our product GitHub, which would natively streamline handoff and version-control. However the stakeholders were hesitant about designers having code-base access, so after multiple conversations, this would be hopefully be a future improvement.
Adoption and growth:
Adoption hinged on building trust with design and development partners. I regularly engaged developers to understand pain points, refine token implementation workflows, and make the system easier to use. I also facilitated workshops to educate teams not just on usage but on design system thinking.
As a result, component usage became standard practice, reducing implementation friction and deepening shared understanding of product design principles across teams.
Impact that lasts:
Over its lifespan, VDS delivered measurable and organisational value:
/ 100% reuse in new features, reducing redundant design work
/ 42% reduction in UI bugs, freeing up engineering capacity for strategic work
/ Improved stakeholder satisfaction, reflected in smoother approvals and greater confidence in delivery timelines
These results demonstrate how a well-anchored design system can improve product quality, accelerate delivery, and elevate cross-team collaboration - aligning with business goals of scalability and sustainable growth.
Reflection to look forward:
Building the VDS reinforced that systems work is both a design and organisational problem. Establishing governance and shared language across functions was as critical as the tokens themselves.
Looking forward, deeper integration and functional evolution remains a priority to further streamline cross-functional collaboration.