Singapore Gulf Bank

From 0 to 1

How to quickly start and manage a banking app design project.

SGB App Screens

Due to the confidentiality agreement, some content has been modified

About

SGB Logo

SGB is a digital bank licensed by the Central Bank of Bahrain — the first to offer fully remote onboarding to retail and corporate clients across East Asia, Southeast Asia, and the Middle East.

Goal

Goal Icon

Make cross-border banking feel as simple as banking at home. Hide the regulatory weight, surface the status, replace silence with clarity. Trust earned through transparency, not promises.

Setup

Team & Timeline Icon

My Role: Sole Product Designer (Founding)

Team: 10+ PMs, 10+ outsourced FEs

Timeline: Q2 2024 – Q2 2025

Three hard calls

Designing inside hard limits

Constraints × UX

Context: Restricted-region users, vendor-locked KYC SDKs, locked crypto APIs, SWIFT-only rails, layered compliance rules — none of it can be changed.

Decision: Treat every constraint as a UX problem, not an engineering one. Where the system can't bend, the language, framing, and fallbacks do the work.

One product, every user type

Inclusivity × flow

Context: Different countries, different user types — crypto trader, cross-border SME, offshore allocator. Different KYC requirements, different fields, different review timelines. One app has to serve all of them.

Decision: One flow, smart branching. The complex user gets guidance; the simple user gets speed.

What MVP really means

Prioritization × trade-off

Context: 500+ screens App, 7 web modules, design system — solo, in 12 months. Can't polish everything.

Decision: Ship now, polish later. CS as safety net. Invest in design system over pixel-perfect v1.

Key Steps

Visual direction illustration

Visual direction

  • Build a user persona
  • List out branding keyword
  • Mood board workshop.
  • Competitor Research.
  • Design page sample.
Interaction illustration

Interaction

  • User Research
  • Competitive Analysis
  • Regulatory Compliance
  • Define Core Interactions
Component library illustration

Component library

  • Research
  • Component sorting
  • Design specification
  • Adaptation and development
  • Component library iteration

Visual direction

Visual direction process — User Persona + Keywords + Research + Mood board → Page samples

Interaction

Onboarding as a case study — designing the best experience inside fixed constraints.

1. Invisible country gating

Problem: Some regions can't be onboarded — and compliance forbids naming which ones.

Design: Region check runs after email verification. Restricted users see a soft "we can't currently offer service — CS will follow up" and are quietly logged as future leads. A "no" turned into a "not yet."

2. Outsourced SDK fails often

Problem: Passport OCR & liveness SDK can't be modified. Glare and angle break it.

Design: Pre-shot guidance, live preview, retry-friendly errors, manual fallback after 5 fails.

3. Making 15 feel like 6

Problem: A 15-step KYC flow can't be shortened. Every step a user counts makes the journey feel heavier.

Design: Email verification stays outside the progress bar — users treat it as standard. The bar appears only when the real complexity begins: 3 stages, 6 visible steps. 15 underneath, 6 above.

4. Funding with no margin for error

Problem: New bank, no SWIFT code — transfers route through an intermediary. Fixed reference string. $100 minimum to activate. The screen is dense with critical instructions; one wrong field kills the transfer.

Design: Tier warnings by priority — not every notice gets equal volume. The two copy modes map to different banks' input formats.

SGB — Onboarding Flow

SGB onboarding flow diagram
Onboarding interaction screens

Component library

Why it mattered

Atoms are universal. Composition is contextual. The same tokens and primitives served both platforms — only how they were composed changed. App composed them into cards, web into tables. One library, two contexts, one brand.

What I built

A three-layer system, informed by research: Shopee for multi-language patterns, Maribank for financial primitives, TDesign for functional taxonomy. Atomic (button, input, label) → Functional (PIN, OTP, beneficiary picker) → Scenario (transaction history, payment detail). 8px grid. Brand-color tokens.

Engineering pairing

Dev started with Vant — Chinese-first defaults, mobile-only, no RTL. SGB needed five+ languages including Arabic, plus a corporate web portal Vant wasn't built for. I pushed for Vuetify mid-build — multi-language by default, RTL native, desktop-ready.

Component Library
App pages display
SGB App Pages
Corporate Portal on laptop

Corporate Portal

The Corporate Portal was 7 modules built on a vendor-provided core banking system. Most of the interaction logic — payment flows, approval chains, audit logging — came pre-built. My job wasn't to invent these flows. It was to make them feel like SGB.

That meant translating vendor scaffolding into our component library, choosing which capabilities deserved primary navigation, and holding visual + interaction consistency with the retail app.

What was given vs what I designed

What was given

  • Vendor core banking platform · pre-built modules · approval logic
  • Pre-built modules with vendor default UI
  • Maker–Checker pattern (regulatory baseline)

What I designed

  • Brand language across all 7 modules
  • Component-level consistency with retail app
  • Information architecture — placement & hierarchy across 7 modules
  • Flow integrity — walked every vendor flow end-to-end, fixed where routing broke user expectation

Website pages display

Website pages display

Outcome

v1 launched on schedule. The product is now live across multiple Asian markets, with the first wave of retail and corporate users onboarded. Early CS feedback shaped v2 priorities — most notably the cross-border identity edge cases noted above, addressed in subsequent updates.

Wrap up

3 Design Principles

  • 1 · Design inside the limits. A lot couldn't be changed — vendor SDKs, locked APIs, banking rules, a 15-step KYC. Instead of fighting them, I designed around them. If the flow can't be shorter, make it feel shorter. Break it into stages. Show progress. Tell the user what's happening at every step.
  • 2 · Design for the hardest user. Three user types, one app. I built the flow around the hardest case — the user with the strictest checks and longest wait. If the flow works for them, it works for everyone else.
  • 3 · Solo doesn't mean alone. I was the only designer, but not on my own. PMs were thinking partners — we worked through flows together and they fought for more time and headcount when scope grew. CS caught users when v1 wasn't perfect and looped their feedback straight back to me. I designed the product. The team made it work.

What I'd do differently

  • 1 · Lock branding before flows. The app shipped before the brand was defined, and visual consistency had to be patched in later. Next time I'd set the visual direction in week one — even rough is fine.
  • 2 · Protect time for user testing. Tight deadlines pushed me to design straight from specs. Real users surface things specs can't predict — for example, a Hong Kong resident with a Mainland passport got blocked at sign-up because the system treated nationality and residency as one value. 3–5 user sessions before lockdown would've caught patterns like this. We addressed it in a post-launch update. Next time, that window is non-negotiable.

Click and Drag

Spline preview

See More Works