On this page
One experience together
Heartland One was an initiative to break down the company’s siloed culture and encourage collaboration across teams.
Our team saw how that siloed culture affected our work. We were working in silos, making it difficult to collaborate across products and create consistent experiences that could scale. That separation stood in the way of us releasing excellent products. We were rebuilding the same components over and over again, experiences varied across each of our products, and accessibility clearly needed more attention.
I saw a shared design system as a way to address those challenges while supporting Heartland One’s broader goal. That work became Vega.
My vision was to bring our different perspectives together to create one inclusive product experience—one that worked for more people and gave teams a shared direction to build toward.
To put that vision into motion, I built the initial wireframing kit, explored the visual direction and built support with leadership and peers. As more people joined to shape it, my role expanded into facilitation, roadmaps and product ownership. Together, we developed a shared foundation that helped teams create consistent, accessible and higher quality experiences for our customers.
Vega grew beyond its beginnings at Heartland into a shared system adopted across Global Payments.
Starting with reusable components
The first step was to give people a way to explore ideas together without getting caught up in visual details. I created the Paladin Wireframing Kit so we could assemble workflows from reusable components rather than start each design from scratch.
We began with the button, then worked through text size, the color palette and other shared elements. While the ideas were still young, the kit gave product leaders, stakeholders and the team something concrete to work with. We could focus on how a product should work before deciding how it should look.
Working through concepts together let development begin while the design was still taking shape. We typically moved from whiteboard to code in a couple of weeks, compared with the month or two it had previously taken to get development started.
Developing a shared visual direction
Alongside the wireframing work, I worked with marketing and branding to explore how the Heartland brand could carry through into our products. Marketing and product weren’t developing the visual direction together.
I created the Paladin landing-page mockup to make the proposed direction tangible. It gave both teams something they could review and shape together, bringing them into a shared conversation about the brand and the product experience.
That collaboration established a shared visual direction for Vega, grounding the system’s components in the Heartland brand.
Choosing a shared starting point
With the visual direction taking shape, we needed a way to begin building Vega’s high-fidelity components. I made the case to our VP for purchasing Pegasus, an existing Figma design system, and she helped secure the budget to get started.
We studied how its components were constructed and used what we learned to build our own. An outside starting point also meant we weren’t asking everyone to adopt one team’s existing work. That reduced resistance and gave teams a stronger sense of ownership.
The work got Vega’s reusable, scalable component library underway. The designers and I applied the Heartland palette and visual direction we had explored through the landing page, and used the Paladin Wireframing Kit to identify components we needed to carry into Vega.
Turning the library into working components
I had begun researching technologies before we purchased Pegasus, and that research continued as the design library developed. I compared other design systems, platform guidance and fintech products to understand different approaches and what would meet our needs.
I also looked at technologies already used elsewhere in the company. Compatibility mattered: I wanted other teams to be able to implement Vega within their existing environments. I recommended an approach to our VP, who supported the direction.
A couple of weeks into the design work, she brought in the engineering Tiger Team to begin the codebase. They evaluated the technologies and began implementing the system, turning the components we were designing into working elements teams could use in their products.
My research covered reusable web components, more efficient styling, a sandbox for developing, testing and documenting components, and connections between design data and development tools. I also studied atomic design and discussed it with our VP. She brought in an outside expert to explore the approach with stakeholders and leadership.
Bringing the work together
As design and engineering progressed, the plugin and documentation work began developing alongside them. Our VP brought in a specialist to help develop the Figma plugin, and a UX writer joined to support documentation.
The specialist introduced Notion as a way to organize the work. We began developing user stories together, bringing designers, the specialist and the writer into those discussions. As these efforts grew, I took on more responsibility for coordinating them and helping the team decide what to work on next. I also completed company-sponsored product owner training to support those growing responsibilities.
I investigated the Figma API and shared it with the specialist, who proposed using it for the plugin and connecting design tokens with the codebase. I also explored CMS options for publishing documentation on our intranet. WordPress was ruled out by IT security, so we moved to Jekyll, with teammates developing the website’s design, content and functionality.
Vega was growing beyond a Figma library into working components, supporting tools and guidance. Bringing those efforts together became a larger part of my role and marked my progression into leadership and product ownership.
Releasing Vega and supporting adoption
The Figma library was ready before the rest of the system. We released it as Vega Beta so designers could begin using the components while we continued developing the technical library, plugin and documentation. Once the libraries and guidance were available, we introduced Vega 1 at a company town hall.
The response was enthusiastic, but some engineering teams initially pushed back on adoption. The Tiger Team made itself available for questions and support, and I encouraged teams to work through roadblocks together. Our shared work continued through adoption: making the libraries available was a starting point, and helping teams put them into practice came next.
My own product team was building a merchant payments platform with Vega from the ground up. Using the system in that work exposed gaps in the components and rules of use as we moved beyond the web into applications and different hardware. Those gaps gave us concrete needs to work through as the system developed.
What started with a button at Heartland grew into a multinational design system adopted by teams across Global Payments. Within my own portfolio, Vega shipped across eight products spanning payments, ACH and billing. Beyond those products, adoption extended to teams in the United States, Ireland, India and elsewhere in Asia.
That expansion brought new demands: different languages and reading directions, software platforms, hardware, interaction methods and accessibility needs. We were developing a shared foundation that had to accommodate those differences while keeping the customer experience consistent.
From one to together
Vega became more than a living product. It became a community. As we came together to shape it, we built new relationships and strengthened existing ones, connecting people across teams through shared work.
I learned that consistency depends on making room for those differences. We built Vega together, and through it, we became more connected in how we worked and what we created.
Many perspectives, one shared purpose—a community we built together.
