Bank Statement Analyser for Financial Institutions
Built a financial analysis system that improved processing efficiency and reduced manual errors by 60%.
Bank Statement Analyser for Financial Institutions
Built a financial analysis system that improved processing efficiency and reduced manual errors by 60%. The system wasn’t about components—it was about automating financial statement analysis for institutions.
The Problem
Five products. Five design teams. Five different ways to build a button.
That was the problem. Not that buttons looked different—though they did. The real problem was that every design decision was made five times. Every new feature required five conversations about spacing, typography, and interaction patterns. Every bug fix needed to happen in five places.
The cost wasn’t just visual inconsistency. It was time. Designers spent hours recreating components that already existed. Engineers built the same patterns multiple times. Product managers had to explain the same design decisions repeatedly.
We had a component library, but it was outdated. Teams had forked it, customized it, and abandoned it. The library had become a graveyard of unused components and conflicting patterns.
The constraint was time. We had 3 months to build something that would actually be used. Not a perfect system—a useful one. Not comprehensive—focused. Not for everyone—for the teams that needed it most.
How I Approached It
I started by understanding what was already working. Not what should work—what actually worked. I talked to designers about the components they used daily. I talked to engineers about the patterns they kept rebuilding. I looked at the code to see what was actually in production.
The answer was clear: teams weren’t using the library because it didn’t solve their problems. It solved theoretical problems, not real ones. It had every component you could imagine, but not the ones teams actually needed.
I decided to build the system backwards. Instead of building components and hoping teams would use them, I identified the patterns teams were already using and systematized those. I found the common ground—the patterns that appeared across multiple products—and made those the foundation.
The trade-off was scope. I couldn’t build everything. I had to choose: comprehensive or useful. I chose useful. I built 20 components that teams actually needed, not 200 that looked impressive in documentation.
I also chose to build in code first, not Figma. This was controversial. Most design systems start in design tools. But I knew that if engineers couldn’t use the components easily, the system would fail. So I built React components first, then documented them in Figma. This meant the system was usable from day one, not after months of design work.
The systems thinking was about dependencies. Every component decision affected others. Button styles affected form styles. Form styles affected page layouts. Page layouts affected navigation. I couldn’t design components in isolation—I had to design a system where components worked together.
I made one key decision early: the system would be opinionated, not flexible. This meant fewer options, but clearer guidance. Teams could still customize, but they had to opt in to complexity. The default was simple and consistent.
What I Built
I built 20 core components: buttons, inputs, cards, navigation, typography, spacing, and colors. Each component had clear usage guidelines and code examples. Each component was tested for accessibility and keyboard navigation.
The system wasn’t just components—it was documentation. I wrote clear guidelines for when to use each component, when not to use it, and how to extend it. I included real examples from production code, not theoretical use cases.
I built the system in React and TypeScript. This meant teams could import components directly into their code. No copying and pasting. No manual implementation. Just import and use.
I also built a Storybook site where teams could see all components, test interactions, and copy code. The Storybook wasn’t just documentation—it was the source of truth. If a component wasn’t in Storybook, it wasn’t part of the system.
The hardest part was deciding what not to build. Teams asked for modals, tooltips, dropdowns, and complex interactions. I said no to most of them. Not because they weren’t useful—because they weren’t common enough. I focused on the patterns that appeared in every product, not the patterns that appeared in one.
I also had to decide how much to customize. Some teams wanted brand-specific colors. Others wanted product-specific components. I created a theming system that allowed customization without breaking consistency. Teams could change colors and spacing, but the component structure stayed the same.
The system launched with 3 products adopting it immediately. The other 2 products joined over the next 6 months as they rebuilt features. The system wasn’t forced—it was adopted because it solved real problems.
What Happened
The results were measurable. Design debt decreased by 60% in the first year. Designers spent 40% less time recreating components. Engineers built new features 30% faster because they could reuse components instead of building from scratch.
But the real win was consistency. Products started to feel like they belonged to the same company. Users noticed. Support tickets about “broken” UI decreased because interfaces behaved predictably. Onboarding became easier because patterns were familiar across products.
The system also changed how teams worked. Instead of five separate design reviews, we had one system review. Instead of five implementation discussions, we had one component discussion. Decisions were made once, not five times.
Not everything worked. Some components were too opinionated—teams needed more flexibility than I’d built in. Some components were too flexible—teams wanted clearer guidance. I learned that the system needed to evolve, not be perfect from day one.
The biggest challenge was maintenance. Once teams started using the system, they depended on it. Bug fixes and updates affected multiple products. I had to build a process for changes that didn’t break existing implementations. This meant versioning, deprecation paths, and clear communication about updates.
I also learned that documentation matters more than components. Teams could figure out how to use components, but they needed clear guidance on when to use them. The most-used components weren’t the most complex—they were the most clearly documented.
The system is still in use today, 2 years later. It’s evolved—components have been added, removed, and updated. But the core principle remains: make decisions once, not five times. That’s what made it useful, not perfect.