Driving efficiency for design and development at Felix with a cross-platform design system
Team
Christina Raganit (Product Design Lead)Head of Marketing (Supervisor)
Frontend Development Lead
2× Frontend Developers
Duration
May-September 2022 (4 months to develop MVP)September 2023–April 2024 (maintenance and improvements)
I was the first design hire at Felix Payment Systems, where I built a scalable design system that could support desktop, tablet, and mobile products while following the Felix brand identity. This design system now serves as the single source of truth for all product surfaces, streamlining efficiency for both design and development workflows.
Background
Felix Payment Systems is a fintech startup focusing on tech that allows smartphone devices to act as payment terminals without requiring extra hardware.
Their two primary products are Terminal (for payment acceptance) and Portal (for businesses to manage and view records of their transactions).
Promotional video for the Felix.Terminal app, depicting setup and payment acceptance flow
Problem
No source of truth for design, creating inconsistencies across Felix products
Early, I noticed a lack of clear design guidelines for foundations like spacing, color, and typography. These inconsistencies created noticeable visual misalignment across the different products at Felix.
Example: Inconsistent colors in the sale screens of the Felix.Terminal app
I spoke with the frontend development leads and encountered two primary issues:
Hardcoded values made the codebase challenging to maintain
Typography, color, and spacing were hardcoded across the codebase, making even simple changes require heavy refactoring.
Lack of foundational components resulted in more development time and effort
Without a component library, developers often duplicated existing components or spent time identifying reusable ones.
Design Challenge
How might I improve the design process so that the frontend developers have an easier time translating the mockups delivered by our design team into frontend code?
What I Did
I’m unable to share the original component guidelines due to an NDA, but I’ve recreated key pages for reference. For details on the full project, please reach out via email at [email protected]
Audited existing screens, gathering common styles and patterns
I audited existing design elements to catalog components and identify inconsistencies that needed resolution before standardizing styles.
Created tokens for spacing, colors, and typography
This removed the need for developers to hardcode variables, making maintenance easier and speeding up future prototyping in Figma
Created a component library and documented the attributes and behaviors of 20 core components
And yes, I wrote these before ChatGPT was a thing!
Wrote guidelines to writing better UX copy and error messages
Results
Sped up development by facilitating code reuse
Created consistency across Felix products
Streamlined new hire onboarding for design and developers
Enabled faster prototyping and design delivery
The design system documentation Christina wrote has been a total game-changer for the team, making UI development smoother and more efficient than before.
Jason Lee
Frontend Development Lead at Felix
I read the guidelines Christina wrote when I was being onboarded and I found them incredibly comprehensive, well-organized, and easy to follow.
Anurag Sharma
User Interface Designer at Felix
Design Process
Adopting Brad Frost’s atomic design framework
Early on, I adopted Brad Frost’s Atomic Design methodology, labeling components as “atoms”, “molecules”, and “organisms”. This was helpful for me learning about how to structure components.
"What the hell is a molecule? And why should I care?"
However, it didn't help developers understand how components were structured. They don’t need to know if a button is an “atom” or a form field is a “molecule”.
Rather than forcing the framework, I ended up documenting components in a way that made sense to the team. What made sense to them was an Anatomy of each component.
Reflection
If I were given more time to work on the project…
I’d dedicate more effort to accessibility for both design and development.
For design, I’d create clear guidelines for color contrast, keyboard and focus interactions, and screen reader considerations. For development, I’d host a workshop on accessibility considerations like keyboard navigability, heading levels, and semantic HTML and ARIA roles.
I’d improve upon the color tokens.
Currently, the color tokens in the design system are only the primitive values. I’d develop semantic tokens to make it clear how each color should be used across components for improved consistency and maintainability.
Learnings
Naming things is hard.
Choosing clear, consistent names for design system components is surprisingly difficult. Names need to make sense to both designers and developers, convey purpose, and scale as the system grows.
Accessibility needs early attention.
Focusing on accessibility early makes sure that every component, from complex forms down to the smallest button, is inclusive by default. This reduces the risk of a retroactive fix down the line which can be time-consuming and costly.