How I built scalable Figma components for Korea's leading SMB super-app — serving 2M+ merchants processing ₩65 trillion in transactions.
Korea Credit Data (KCD) operates CashNote, the #1 business management super-app for Korean SMBs. Backed by Morgan Stanley and valued at $1B, CashNote helps merchants track sales across 8 credit card companies, manage tax invoices, monitor delivery apps, access loans, and connect with other business owners.
I joined to solve a critical infrastructure problem: as the product scaled from dashboard to super-app, design consistency was breaking down.
Product Designer
Design Systems & Mobile UI
Jan 2024 – Oct 2025
1 year 10 months
Cross-functional collaboration
Engineering, Product, QA, Data
Figma, Auto Layout, Variants
Design Tokens, Flutter
Confidentiality Note: Due to NDA constraints, specific screens and proprietary data have been abstracted or recreated. Metrics and methodologies are shared with permission. This case study focuses on process and systems thinking rather than pixel-level deliverables.
CashNote isn't just an app — it's the operating system for Korean small businesses. To design for it, I needed to understand its complexity.
Through user research and analytics, we identified three primary personas that represent the majority of CashNote's user base.
"I just need to see if today's sales match what I expected. Quick glance, that's it."
"I need to track which suppliers I've paid and manage my tax documents for the accountant."
"The loan marketplace saved me weeks of paperwork. I could compare rates in minutes."
CashNote grew from 1.2M to 2M+ users during my tenure. Five feature teams were shipping independently, and the seams were showing.
Each team had created their own button styles. Primary buttons alone had 12 different implementations.
Engineers spent hours per feature deciphering design specs. No consistent naming or documentation.
Fixed-width designs broke on different screen sizes. Designers rebuilt layouts for each device.
Data cards, transaction cards, summary cards — all slightly different. No shared foundation.
Contrast issues, undersized touch targets. Users with vision impairments struggled.
Same components rebuilt across teams. No single source of truth.
I analyzed design systems from comparable fintech apps to understand industry standards and identify opportunities for differentiation.
| App | Design System | Auto Layout | Dark Mode | Motion |
|---|---|---|---|---|
| Toss | TDS (Toss Design System) | ✓ Full | ✓ Yes | ✓ Lottie |
| Kakao Pay | Kakao Design System | ✓ Full | ○ Partial | ✓ Lottie |
| Naver Pay | Naver Design System | ✓ Full | ✕ No | ○ Basic |
| CashNote (Before) | None (Ad-hoc) | ✕ None | ✕ No | ✕ None |
Korean fintech leaders had invested heavily in design systems. CashNote was falling behind not just in visual polish, but in development velocity. Without a system, we couldn't compete on feature speed or consistency.
Before building anything, I needed to understand the full scope of the problem — and get buy-in from stakeholders.
Catalogued every UI element across 50+ screens
5 devs on pain points in design-to-code workflow
Mapped which components were rebuilt most often
Identified highest-traffic screens for prioritization
"Every feature feels like starting from zero. I spend more time asking designers 'what's the padding here?' than actually coding."
"I know I'm rebuilding the same card component someone else made, but I can't find it. So I just make a new one."
"The inconsistency isn't just ugly — users get confused. Different buttons do different things depending on where you are."
The audit revealed that 68% of components had inconsistent implementations. Buttons were the worst offender, but the real issue was structural: there was no shared foundation for spacing, color, or typography.
I followed a phased approach — starting with foundations, building components, then rolling out with documentation and training.
Established the atomic elements everything else would build on.
Built the high-impact, high-frequency components first.
Tackled the CashNote-specific patterns that required domain knowledge.
Made the system usable by others — not just buildable by me.
Shipped the system and helped teams adopt it.
Kept the system alive and responsive to new needs.
Built with Figma Auto Layout for responsive behavior and clean handoff to Flutter development.
Responsive containers displaying revenue data with real-time updates. Supports daily, weekly, monthly views with trend indicators.
Virtualized list components handling 10K+ daily transactions. Type indicators, timestamps, amounts with overflow handling.
Every component built with proper fill/hug behavior. Nested frames maintain structure across screen sizes without manual adjustment.
Consolidated from 47 to 8 variants. Size, state, type, and icon combinations as Figma variants with consistent touch targets.
The atomic pieces that everything else builds on. Documented in Figma with usage guidelines.
Semantic naming mapped to brand palette. Includes dark mode tokens for future implementation.
Financial-first hierarchy. Large display for amounts, clear labels, subtle metadata. Optimized for quick scanning.
4px base unit. Consistent rhythm across all components. Mapped to Flutter padding/margin values.
Hierarchical naming aligned with Flutter widget structure. Engineers find components without guessing.
Every interactive element has defined states to provide clear feedback and meet accessibility requirements.
CashNote's users range from 25 to 65+, with varying levels of vision and tech literacy. Accessibility isn't optional.
All text meets minimum 4.5:1 contrast ratio. Large text (18px+) meets 3:1.
7.2:1 ratio on primary buttons
All interactive elements meet minimum 48x48px touch target size, with 8px spacing between targets.
Clear focus indicators for keyboard navigation. 2px offset ring with primary color.
All components include proper aria-labels and semantic structure for TalkBack/VoiceOver compatibility.
A design system only works if engineers can implement it accurately. I embedded myself in the development process.
Every component includes pixel-perfect specs: padding, margins, border radius, colors with exact values. No ambiguity.
Component names match Flutter widget naming. Auto Layout properties map directly to Row/Column/Expanded patterns.
Joined PR reviews to catch design drift early. Built relationships with engineers and learned implementation constraints.
Screen recordings of interactive prototypes for complex flows. Engineers see intended behavior, not just static screens.
Standing meeting with lead engineers. Surfaced implementation blockers early, iterated on component APIs together.
Guidelines updated as we learned. When a pattern didn't work in code, we revised the design system together.
The design system rolled out across CashNote's 5 feature teams over 6 months. Here's what changed:
"Before Alan's system, every new feature felt like starting from scratch. Now I can grab a component and know it'll work. My implementation time dropped significantly."
"The naming convention aligned with Flutter was a game-changer. I don't have to guess what 'Card-v2-final-FINAL' means anymore. It just matches our code structure."
"Having Alan in code reviews meant fewer back-and-forth cycles. He understood what was easy vs. expensive to implement, so his designs were realistic from the start."
The hardest part wasn't Figma — it was getting 5 teams to adopt shared patterns. I spent as much time in stakeholder meetings as in design files. Buy-in requires showing value, not mandating compliance.
When users are looking at their money, every pixel matters. Alignment, consistent spacing, and professional typography aren't aesthetic choices — they're trust signals. Sloppy UI = "is my money safe?"
Setting up proper constraints takes 3x longer upfront but saves 10x downstream. Components that "just work" at any size eliminate entire categories of bugs and redesign requests.
The best design decisions came from understanding Flutter constraints. Attending code reviews taught me what's easy vs. expensive to implement. I became a better designer by learning to think in widgets.
I initially built components without guidelines. Big mistake — people used them wrong. Now I write usage notes before marking anything as "done." Documentation is part of the deliverable.
When 5 teams use your components, breaking changes break everyone. I learned to treat the design system like a product — with changelogs, deprecation warnings, and migration guides.
I'm exploring product design opportunities in fintech. Currently based in Seoul, open to relocation.