Vama Design System
2024 – 2025 / Design System
/ Background
Vama is an integrated payments and communication platform, redefining convenience and productivity for modern digital communities.
I was brought into the team as part of a larger initiative to restructure the product development workflow to focus on scalability, consistency, and efficiency.
/ My Role
As the design systems lead, I architected the foundations and principles of the new Vama Design System (VDS), the creation and structuring of our components, tokens, and documentations, and coordinated the communication and usage of the VDS within a product team of over 50 members.
Motivation to implement:
Prior to the my joining, Vama was developed with a very fragmented design mindset, where components were designed purely as visual references that were implemented without any underlying architecture or governance (e.g. buttons were coded per-page with different and disconnected properties and structures).
As the product started scaling up in width and depth, multiple issues started surfacing that was directly hindering product development:
/ Massive build-up of component-related bug tickets due to localized issues and the fact that fixes are not transferred to other similar components
/ Sluggish design-to-dev handoff timelines as each new screen have their components re-implemented as a unique design artifacts
/ Increasing visual inconsistencies across screens and flows, leading to constant push-backs and questions in stakeholder approvals and slower development cycles.
This was poised to be a cascading issue that needed to be fixed in order to support our MVP scaling and launch, we needed a proper and suitable design system infrastructure to drive this change.
I then organized a 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 (and a few rocky back-and-forth), 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:
The VDS was envisioned to be built in 2 phases:
-
An initial more lightweight and tech-focused system that can produce quick display of business and development value
-
A follow-up expansion that fully unlocks the system’s scaling and efficiency values
This was based off the state of the current product and team, where it is the stakeholders’ first time seeing the impact of a design system, developers being unfamiliar with design systems and tokens, and the large amount of present design and tech debt. 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.
Hence the VDS was focused on also being simple and direct.
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.
Across the different phases of VDS implementation, the main change in content is on how we decided to manage documentation:
/ In phase 1, we focused on exposing very direct tech-focused documentation, aiming at providing clear blatant information and guidance for developers as part of accustoming them to the new system
/ In phase 2, we transitioned to more of a usage/context based documentation that provided shorter but 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
Design side:
Contribution and maintenance started as a singular effort from me for 2 reasons:
/ Need to rapidly grow the initial VDS requires focused effort, which was easier as a single designer, especially when I had the most expertise on it within the team at the time
/ With phase 1 focusing on developers’ onboarding, having a single source of truth for answers and guidance proved beneficial in rapid familiarization for the developers
As the VDS matured, we then transitioned to a more collaborative model where all designers have the ability to contribute new components or updates based on their respective domain requirements, and I took up a reviewer role to ensure that all changes are valid and of our VDS standards
To facilitate a collaborative VDS workflow, we made use of Figma’s native tools:
/ We used version history for version control, saving snapshots of major/minor updates for easy trackback and referencing
/ We used branches for managing individual contributions, where the main branch is only for reference and usage, while changes are made in the branches and merged after a review by me or the design lead
Developer side:
/ Component implementation makes use of the provided guidelines and dev-mode for the developers to reference, we hadn’t figured out an optimal way to include Code-Connect into this process due to drastically different code structures between platforms, however that is a high priority integration for the future
Token implementation has went through a lot of iteration and evolution as we figured out the most balanced approach between designers and developers
/ We currently have a model where tokens are created as variables in Figma’s native collection, they are then exported via the Token Variable Export plugin which we use to populate CSS sheets with. These sheets are then version-grouped within a shared Google Drive. Each platform’s developers have their own script that will pull the token values from the drive and auto-update their codebases with.
/ This might seem convoluted at first, but with the structure set-up, it is actually very simple and smooth, and most importantly frontloads most of the maintenance effort on the design side, reducing implementation friction.
In a perfect world I would have wanted the token list to live as a separate repository in our product GitHub, which would fully streamline handoff and version-control and be more native. However the stakeholders were at the time hesitant about designers having code-base access, so after multiple conversations, this would be hopefully be a future change
Communications side:
/ Within the design team, I set up weekly DS syncs that provides a open platform for all designers to voice requests, changes, or just ask questions
/ I have also set up a design team chat channel that allow us to better manage smaller questions and interactions, while also maintaining a trackable history for reference
/ For cross-functional communications, I created a VDS channel that includes all developers, products, and designers, opening a channel for direct troubleshooting
All of these contribute to transparency in information and conversations, as well as accelerating adoption and improving the popularity of the VDS among stakeholders
Adoption and growth:
To ensure that these systems are being adopted and actively being used, the most important thing was to gain trust: trust in the design team as well as trust in the VDS itself.
I achieved this through constant engagement and reflections with the developers to identify implementation or understanding pain-points, and to propose solutions to make their usage easier and more enjoyable.
For the design team as well as the development team, I regularly organized workshops to provide tutorials and education not just to learn our current systems, but to allow them to understand further considerations. This contributed to the teams growing in their aptitude for using design systems and understanding product design better as a whole.
Impact that lasts:
Over the current lifespan of the VDS, it has already provided tangible returns that directly contributed to business values and objectives:
Component library used in 100% of new features post-adoption:
/ This reduced development overhead for designing new features as components can be re-used in the new screens
42% reduction in UI bugs
/ More component usage means less chance of UI bugs, leading to less development effort needed for such issues, allowing for more valuable feature-implementation time
Improved stakeholders’ satisfaction:
/ Design team lead as well as all development team leads had reflected that the VDS was aiding in transparency and efficiency of their day-to-day workflows, proving growing design maturity and an overall better product development cycle
These quantitative and qualitative data show the worth of a well-made design system, and it helps with pushing for future iterations as we work toward a more extensive and comprehensive VDS that contribute real business values.