A button can look perfectly consistent in Figma and still create confusion. Which variant fits this task? What happens when its label becomes longer in another language? How does it behave when someone navigates with a keyboard?
These questions changed how I thought about design systems. Creating a component is only part of the work. Helping people choose, implement, and maintain it makes that component useful.
Before Finacle, I designed human-in-the-loop workflows for an intelligent document processing SaaS product. That experience taught me to look beyond standard flows, to uncertain predictions, poor-quality scans, and situations requiring human judgement.
I carried that thinking into enterprise fintech. At Finacle, I led five designers working on a design system supporting banking workflows, including wealth management, forex, onboarding, and fund transfers. Our responsibilities covered components, documentation, accessibility, bug fixes, and monthly releases.
I began to see the system as a product with its own users and ongoing responsibilities.
The people building products are users too
A designer needs to find the right component. An engineer needs clear behaviour and states. A new teammate needs enough context to work independently.
Teams from other departments regularly approached us with requirements for banking clients. Could an existing component support their needs, or did we need to create something new?
Answering that question required more than a component library. It required a reliable way to understand requests and communicate decisions.
Turning a fragmented process into a clearer one
When I joined, that process was fragmented. Requirements were captured inconsistently, conversations happened across different channels, and timelines were unclear.
I worked with product managers, stakeholders, and teammates to understand where the process was breaking down. Together, we introduced clearer documentation and a shared tracker to:
- Capture requirements and check what was already available.
- Discuss feasibility and document decisions.
- Define realistic timelines.
- Track progress through a shared reference point.
This reduced confusion and repeated back-and-forth. Teams could see what was requested, what needed designing, and when to expect an outcome.
Improving the experience of requesting a component became part of improving the design system itself.
My managers recognised this work in their written feedback:
“Your effort in streamlining the requirement intake process has improved it significantly, especially considering multiple sources of requirements our project has handled, in catering to 8+ tracks of the product.”
They also highlighted how I supported collaboration within the team:
“Running daily standups and structuring these meetings to accommodate elaborate design discussions had helped improve the team deliverables and interaction within the team.”
That feedback reinforced the value of creating clearer processes and making space for meaningful design discussions.
Reusable needs to mean adaptable
An onboarding form and a forex transaction may share inputs and validation patterns, while requiring different information hierarchies. Consistency needs room for those differences.
For an input, we considered missing information, error recovery, clear instructions, and keyboard interaction, not just its default appearance.
I also added and modified components to support multiple languages and worked on right-to-left (RTL) screen design. Longer labels needed flexibility; different reading directions required attention to alignment, navigation, and directional elements.
Simply translating text did not resolve those decisions. Components needed guidance explaining how they should adapt.
Accessibility was part of this work. We worked towards WCAG AA requirements, considering focus, contrast, labels, and interaction states. Shared components could make accessible behaviour easier to reuse, while complete product journeys still needed their own checks.
The handoff is part of the experience
Once components were designed, reviewed, and tested, I documented them and collaborated with the development lead on handoff.
Our internal design system website brought together downloadable design files, code, and guidance for different usage scenarios. Teams needed to understand both what was available and how to apply it.
The workflow extended beyond completing a Figma file:
Each stage supported the next person. Documentation helped teams make decisions, code supported implementation, and the newsletter helped existing users understand what had changed.
A release creates an ongoing responsibility
Monthly releases brought refinements, bug fixes, and new requirements. Leading the team meant aligning decisions, supporting designers, and collaborating with product managers and developers while protecting consistency, accessibility, and maintainability.
The system’s quality depended on that collaboration as much as on its components.
The Finacle Design System received an Honourable Mention at the European Product Design Award in 2023. I’m proud to have contributed as design lead alongside the wider team, with my name included in the official award listing.
My biggest takeaway is that a design system earns its value through use. A large library means little if people cannot find what they need, understand it, or trust what they implement.
I now think about a design system through one question:
Does it help the next person make a better design decision?
That question moves the work beyond maintaining components. It gives the system a purpose and a reason to keep improving.
