Fubon Financial Holdings
Design System
Designing for coherence across four distinct businesses
A shared foundation, clearer interaction rules, and room for different business needs.
OVERVIEW
The project at a glance
We expanded Fubon’s mobile-focused design system for web and app products across four financial businesses. To address different business needs and unclear component guidance, we developed flexible components, shared interaction rules, and resources for design and implementation.
Challenge
Each business needed different components, and designers, engineers, and PMs each struggled to use the system.
Solution
A shared core with flexible components, behavior guidelines inside Figma, and intent-based naming.
What I did
Defined usage and interaction rules, advocated intent-based naming, and taught the team how tokens work.
Taipei Fubon Bank website, before and after adopting the design system.
BACKGROUND
Extending a mobile-first system across the group
Fubon's design system was built for the bank's mobile app: a Figma UI kit, a guidelines website, and sample code. The life insurance, property insurance, and securities businesses had no components to work from, and none of the four had support for websites. Our team was commissioned to extend the system across the group. To scope the work, we interviewed PMs, designers, and engineers, and collected feedback from all four businesses on 41 components over five rounds.
Only the bank's app was covered. The other three businesses, and every website, had no components to work from.
PROBLEM
One library, four businesses, different ways of working
Businesses pulled components in different directions
Each business needed the same component to do different things. With no place for variation, teams built their own versions.
Components lacked clear definitions
Components showed what to build, but not when to use them, how they behave, or what each variant is for. Similar variants had names that didn't state their purpose.
Resources sat apart from the work
Designers have to switched between Figma and the guidelines website to check every component.
Engineers received incomplete code that didn't match the spec, so they rewrote it.
PMs had no standard for reviewing designs from internal teams or vendors.
STRATEGY
Three principles to guide the system
These principles connected the needs we identified with decisions about architecture, interaction, and delivery.
Consistency & flexibility
Preserve a shared identity while supporting different needs.
Clarity
Make selection and behavior easier to understand.
User-friendly
Make the system easy to access and apply to everyone.
DESIGN
How we put the strategy into components, rules, and names
Consistency & flexibility
A shared core with room to adapt
We kept foundation and semantic tokens centrally governed while allowing subsidiaries to create component tokens for their own needs.
I taght the team how these layers work together and helped establish the token library—giving component-specific changes a defined place without changing shared semantic definitions.
Centre: shared and centrally governed. Edge: where each business may extend.
Adapt the composition, preserve the structure
We built configurable components with optional sections and replaceable content slots. Designers could adapt a Dialog to different tasks while retaining its shared layout and action structure.
Clarity
Name components by intent, not appearance
I advocated for intent-based names, and the team adopted intent as the primary naming logic across the library and here's the reason:
Designers across four businesses must follow this system. An appearance-based name leaves them to decide what a button means, so the same-looking button can carry different intents in different products. Customers who use more than one Fubon app would then learn what a control does in one app and find it behaves differently in the next.
Appearance names
Intent names
Transfer
Schedule for later
Back
⋯⋯⋯⋯⋯⋯
Solid Button
⋯⋯⋯⋯⋯⋯
Outlined Button
⋯⋯⋯⋯⋯⋯
Ghost Button
Filled background
Border, no fill
Text only, no container
Appearance names describe how a button looks. Switch to intent names to see what each one is for.
Clarity
Define when components are used and how they behave
To create a more cohesive experience across different products and platforms, I documented usage scenarios, interaction behavior, and constraints alongside the visual specifications, so teams could apply shared rules to new product flows.
Here is how the Drawer guideline covers all three.
Example: Drawer
Usage and Scenarios
Terms
For content users must read in full and agree to. Supports scrolling and pairs with Agree / Disagree actions.
Interaction Behavior
Right on desktop, bottom on mobile
Opens from the right on desktop to keep the page visible. Slides up from the bottom on mobile for one-handed use.
Constraints
Always leave a way out
Provide a close button, a cancel action, and tap-to-dismiss on the backdrop, so users are never trapped.
Drawer guideline, translated from the Fubon library. Every component page follows the same three-part structure: scenario, behavior, constraint.
DELIVERY
Make the system usable in everyday work
User-Friendly
Put guidance where designers use components
Designers requested guidance where they selected components. We placed usage explanations alongside the library, giving them access to the rules within their design workflow.
The documentation also used the Fubon design system itself.
Usage guidance now sits next to each component in the Figma library.
REFLECTION
Designing rules others can apply
Where it landed
What I learned
A component is only as consistent as its rules. Designers across four businesses would never sit in our reviews, so every name and guideline had to make sense without us there. That's why I pushed for intent-based names and written behavior rules.
Interviews also showed me that one system serves several roles. Feedback files surfaced what designers wanted; talking to engineers and PMs showed where the system broke down for them.
What I'd do next
Track adoption from the start: which components teams detach, where they build their own versions, and which guidelines they search for most.