When I joined Paystand in 2021, my first ask was simple: Is there a design system? The reaction? Pure comedy—blank stares all around. So, I dug through old Figma files and found a dusty, outdated component library from 2018. Clearly, Paystand needed a proper design system.
The real challenge wasn’t building it—it was convincing leadership to invest in it. After months of trust-building, I finally got the green light. Using the Atomic Design methodology, we audited inconsistencies, categorized components, and established design tokens. We built a component library in Figma, but resource constraints halted full implementation.
To ensure long-term adoption, we set guidelines for future development. The design system broke silos between design and development, making collaboration seamless. Developers felt empowered to contribute, designers understood dev challenges better, and Paystand gained a unified, scalable design language that improved efficiency across products.
I joined Paystand as a UX consultant on August 9, 2021. My first project was to revamp the Receivables page of Paystand’s Accounts Receivable (AR) software.
For those unfamiliar with receivables, think of them as invoices you send to clients or vendors to get paid. When you place an order, the merchant creates a sales order. Once the order is shipped and received, that sales order transforms into an invoice, which the merchant sends out to collect payment.
The first thing I asked was whether there was a component library I could use. The reaction? Pure comedy—everyone looked at each other as if I had just asked for their bank account passwords. So, I took matters into my own hands and dug through their Figma files. Eventually, I found something that resembled a component library—last updated in 2018. While many components were missing, it was still a decent starting point. However, Paystand had evolved significantly since then, and what it really needed was a complete overhaul.
The idea of building an entire design system from scratch was thrilling. But I knew the real challenge wasn’t just creating it—it was convincing everyone that we desperately needed one. So, I spent the next six months making the case for a design system and bringing it to life through cross-team collaboration.
They say starting is half the battle won. But for me, there was an even bigger battle before I could start:
The Convincing.
Convincing one leader? Not that hard. If she says yes, great! If no, I just have to stalk her (professionally, of course) until she gives in. But convincing three—the Heads of Engineering, Product, and Marketing? Now that felt like climbing Everest in flip-flops.
This meant:
Determined, I put together a presentation designed to dazzle, persuade, and (hopefully) guilt-trip them into lending me their resources.
Some of the key questions I addressed in that presentation are:
After a 30-minute deep dive into why a design system was critical, I remember the engineering head looking at me and saying:
"I get where you're coming from. I see the value. But I’ve seen too many consultants walk in, promise big, and disappear in a month or two. So, I’d rather not invest in this right now."
Translation: You won’t be here in two months, so why waste resources?
I think, I managed to convince them that we needed a design system. What I didn’t manage to do? Prove that they could trust me—and that I wasn’t just another consultant who’d vanish in a few months.
By the way, at the time of writing this case study, it has been 3 years, 5 months, and 22 days since that conversation. Safe to say, I stuck around.
Overall, I knew what I have to do next:
For the next six months, I focused entirely on engaging with people, building trust, and reinforcing my presence. When I met with the leadership team again, the consensus was clear—everyone agreed that we needed a design system.
A team was formed, consisting of one developer, one brand designer, one product manager, and myself.
Our first meeting was all about getting to know each other, aligning on our goals, and brainstorming the best way forward. I introduced the fundamentals of a design system so that everyone has some idea about it. At this point of the process, I introduced the team to the Atomic Design Methodology and how we will be using it throughout the creation of our design system.
I believe in documenting problems and keeping them visible at all times. I use Notion to dump all my problems, goals, and sometimes even their solutions. To kick off the project, I conducted a workshop (virtually, via Meet) where we brainstormed problem statements.
Honestly, this wasn’t difficult—today, you can simply Google or ask ChatGPT for common challenges of not having a design system. Though these software do help in creating a foundation, every company is different. Hence, you should carefully discuss this with your team.
For Paystand, some key problems we identified:
A robust design system that streamlines collaboration and ensures consistency.
All the above problems we were facing due to a lack of a uniformed design language.
So the ultimate goal for us was to:
Before solving a problem, it’s always wise to assess what already exists. I had no intention of reinventing the wheel. So, my first task was to explore the components, layouts, grid styles, and other assets available in Figma (originally created by a design agency) and compare them with what was actually implemented in the product.
To my surprise, I found many components actively used in the product but missing from Figma. It quickly became clear that developers had been playing the role of designers for a long time. Instead of reusing existing patterns, each developer created their own version whenever they built something new. This led to significant discrepancies between design and the actual product.
To map out the inconsistencies, I:
- Captured screenshots of all patterns from the product and compiled them in Miro.
- Categorized components using the Atomic Design methodology—Atoms, Molecules, Organisms, Templates, and Pages.
- Documented design tokens, such as colors, typography, spacing, shadows, borders, and button styles used across the product.
Ideally, this inventory-building process should be a collaborative effort. But given the time constraints and available resources, I had to move fast—and sometimes, working solo is the quickest way to push things forward.
Once I had a comprehensive inventory, I presented it to the team. I walked them through the existing components and patterns, explaining what they were, why they were used, and, most importantly, the inconsistencies across the product. In essence, it turned into a Design Patterns 101 session, followed by a reality check on the chaos we were dealing with.
The numbers spoke for themselves:
26 different button styles
85 colors scattered across the product
16 components with multiple inconsistent styles
54 different fonts from just two typefaces
An interface inventory exercise helps us spot inconsistencies and understand what our UI is made of. It shows what to keep or remove and helps create a shared design language for the team.
It also helps us plan the design system, deciding which components matter most. For example, if we use a lot of forms, tables, or cards, we know to prioritize them first. This way, we focus on what’s really needed.
At this stage, the big question was whether to build the component library from scratch or repurpose existing designs. Personally, I prefer designing from scratch, and my initial instinct was to scrap everything and start fresh.
However, after assessing the number of components needed and the time required to design and develop them, it became clear that refining existing components was the smarter choice. The next challenge was deciding which components to keep and finalizing a design language given all the components were quite old.
We used three key criteria:
From this point, my focus was on building a master component file, consolidating all selected components, and organizing essential design tokens—colors, typography, spacing, and more.
Even with a solid foundation, many components from the product were still missing in the Figma file. So, our first task was to build those missing components and redesigning the existing one using the theme we finalized using the below process.
The process involved:
1. Competitive research – Studying competitor designs to understand industry standards and user expectations
2. Creating a mood board – Gathering inspiration for design direction
3. Finalizing versions – Selecting the best design options
4. Testing for aesthetics and usability – Ensuring designs are both visually appealing and functional
5. Iterating and refining – Continuously improving based on feedback
Not just the missing components, but even the basic tokens—like colors, typography, and spacing—weren’t sufficient for a data-intensive product.
Thankfully, the marketing team had already established most of the primary and accent colors, so we only needed to build on that foundation. Using the same research → design → development process, we defined the following key tokens for our component library:
Up to this point, we had designed all the components that were actively used in our product. However, there were still many components missing from the library. Given the time constraints, we collectively decided to build them gradually rather than all at once.
Along with designing components and tokens, consistent naming conventions were crucial for smooth design-to-development handoffs. Without a clear system, collaboration could become messy, leading to confusion and inefficiencies.After multiple discussions with developers, we agreed on the following naming conventions:
Button/Primary, Button/Primary/Hover, Input/TextFieldColor/[Category]/[Variant] | Example: Color/Primary/Blue-500Typography/[Element]/[Size] | Example: Typography/Heading/H1,
Typography/Body/SmallWhile I was designing the components, a developer was building them in parallel. To effectively manage the entire design system, we researched various tools that could help streamline our workflow. After conducting a cost-benefit analysis, we decided to use Storybook due to the below reasons:
While we were working on the design system, the developer building the components got pulled into other revenue-generating projects. Without any developers actively contributing, we had to limit the project to building just a component library in Figma.
To ensure that our efforts didn’t go to waste, we discussed the situation with the PM and dev lead and established a few ground rules for the future:
Even though we couldn't implement everything as planned, laying down these foundational rules ensured that the design system would still have a long-term impact.
Building the design system was just the beginning—the real challenge was implementing it. To make adoption smoother, we decided on two approaches:
Approach 1: New Projects
Approach 2: Updating Existing Products Gradually
It’s always tough to quantify the impact of a unified design system unless you compare old vs. new workflows in action. So, rather than throwing around random numbers, I’ll focus on the real impact this project had:
It broke the silos between design and development.
Developers felt more comfortable talking to designers, sharing feedback, and actively contributing to design improvements.
Designers gained a deeper understanding of development challenges and learned how to collaborate more effectively.
