SMBC Design System
A scalable design system built from scratch for SMBC’s enterprise loan digitization platform, unifying foundations, components, and documentation into one shared product language.
Role
Product Designer
System strategy, foundations, component design, documentation, and handoff support for SMBC’s loan digitization platform.
Client
SMBC
Sumitomo Mitsui Banking Corporation, with the work focused on enterprise financial-services product consistency.
Scope
Enterprise Loan Digitization
A scalable UI kit and rulebook for a growing platform that needed one shared design language across teams.
Fragmented UI Needed One Shared System.
When I joined the SMBC Loan Digitization project, the product had grown rapidly without a shared design language. Teams were building screens independently, creating inconsistency across buttons, typography, color usage, and interaction patterns. The brief was to unify the experience and make the platform easier to scale.
The work was not just to make screens look consistent. It was to create a repeatable operating model for interface decisions.
The system had to support financial-services product work where clarity, state coverage, documentation, and handoff quality matter as much as visual polish.
Reduce visual inconsistency across a growing product surface.
Define foundations before component production.
Cover full component states, variants, and edge cases.
Create documentation that designers and developers could adopt independently.
Pen And Paper Made The System Easier To Align.
Before opening Figma, I mapped the system on paper: the relationship between foundations and components, the phases of work, and the dependencies that needed to be resolved. This low-fidelity approach helped align stakeholders early and reduced the risk of rework later.
Unify The Platform
The first problem was fragmentation. Buttons, typography, color usage, and screen patterns had grown independently, so the system needed to create one consistent product language.
Think In Low Fidelity First
Paper sketches mapped relationships between foundations, components, dependencies, and phases before Figma production, helping teams align early and avoid expensive rework.
Make Adoption Practical
The component library and documentation had to be clear enough for designers and developers to use independently, with purpose, anatomy, behavior, and usage rules defined together.
Research Sketch
Fragmented UI across a growing platform.
The source sketch captures the starting condition: a rapidly expanding product with inconsistent buttons, typography, and color usage because teams were building screens independently.
Process Overview
Mapping foundations, components, and dependencies before Figma.
The process sketch shows how low-fidelity thinking made the system easier to plan: foundations first, components second, then documentation and governance.
Tokens Gave Every Component The Same Starting Point.
I established the core foundations the rest of the system would inherit from: grid structure, spacing scale, type hierarchy, and color relationships. These decisions were translated into Figma tokens so downstream components could remain inherently consistent.
Responsive Grid
12 columns
The foundation layer included a 12-column responsive layout grid with 70px columns and 30px gutters.
Spacing Scale
4px / 8px
A predictable spacing system gave downstream components consistent rhythm and layout relationships.
Typography
Open Sans
The type system used six defined styles to support dense enterprise interfaces without visual drift.
Color System
Brand + semantic
Primary greens, eight neutral tones, and thirteen semantic secondary colors were defined with transparency rules.
Foundation Sketch
Design tokens were planned before component production.
The sketch establishes the core decisions the rest of the system inherited from: grid, spacing, typography, color, and responsive layout rules.
Foundation System
The final foundation layer translated planning into reusable rules.
The high-fidelity foundation artifact shows the system language becoming practical: columns, gutters, type styles, brand greens, neutrals, and semantic colors.
Rough Sketches Became A Production-Ready Component Library.
After the foundations were locked, I moved into components. Buttons, inputs, radio buttons, dropdowns, and workflow patterns were explored as systems of states and variants before becoming reusable Figma symbols with auto-layout.
Button Hierarchy
3 levels
Three button hierarchy levels clarified primary, secondary, and supporting actions across product workflows.
Input Anatomy
Annotated
Text inputs included anatomy guidance and state coverage so forms could scale across complex loan journeys.
Selection Logic
Reusable
Radio buttons and related controls documented selection behavior for predictable component reuse.
Workflow Progress
Multi-step
Progress trackers supported longer financial-services workflows where users needed clear journey status.
Component Sketch
Components were explored as systems of states, variants, and edge cases.
Buttons, inputs, radio buttons, and dropdowns were sketched first so interaction logic could be clarified before pixel-perfect production.
Component Library
A complete, production-ready component library.
Each component included full state coverage: default, hover, focus, active, disabled, and error, with reusable Figma symbols and auto-layout support.
The Rulebook Made The System Self-Serve.
I created a standardized documentation template for every component. Each page covered purpose, anatomy breakdowns, behavioral states, usage guidelines, and explicit do’s and don’ts so designers and developers could adopt the system independently.
Documentation Sketch
The rulebook structure was designed as carefully as the components.
The documentation sketch shows how the system moved beyond visual assets into repeatable guidance: purpose, anatomy, states, usage, and decision rules.
Documentation System
Do’s, don’ts, anatomy, and behavior made the system self-serve.
Every component received a standardized documentation template so designers and developers could adopt the system independently across the platform.
Documentation template
Purpose, anatomy, behavior, usage, and exceptions.
One System, One Language, Across Every Team.
The SMBC Design System became the single source of truth for the loan digitization platform. It reduced visual inconsistency, reduced design-to-development handoff friction, and enabled new screens to be assembled from existing components while the system stayed governed with clear ownership.
Single Source Of Truth
Foundations, components, and documentation were organized so teams could make consistent product decisions from one system.
Handoff Clarity
Full state coverage and anatomy guidance reduced ambiguity between design intent and implementation behavior.
Scalable Governance
Clear ownership and repeatable documentation helped the system remain maintainable as the platform continued to grow.
Next