DKB — Co-Branding &
White-Label Department

The challenge: one platform, six brands, three platforms

Every partner gets their own branding — colours, logo, card design, and sometimes custom features. But the underlying platform must be consistent, compliant, and maintainable. Without a design system, that means duplication: six brands × three platforms = 18 parallel design maintenance chains, all drifting apart over time. Compliance changes cascade manually. Every partner update requires rebuilding rather than re-theming.

The design system was the infrastructure that made scalable, consistent partner delivery possible.

Token-based architecture

We built a three-layer token system as the foundation. Tokens define design properties — colour, typography, spacing, radius, shadow — as named variables, customised per partner at the brand layer, not the component layer.

• Global tokens — base palette, spacing scale, type scale. Platform-agnostic primitives.
• Semantic tokens — map global values to roles: primary, surface, on-surface, error, interactive.
• Partner tokens — override semantic tokens per brand. One structured swap, not a manual redesign.

A new partner rollout became a theming exercise, not a redesign exercise. This was the central efficiency gain.

Component library — three platforms

Managing a design library across Web, iOS, and Android means balancing platform conventions with cross-product consistency. Each platform has its own interaction patterns and native metaphors — ignoring these produces designs that feel wrong and are hard to build. Ignoring cross-platform consistency produces a fragmented user experience.

• Core components defined once, with platform-specific variants — not three separate systems
• One designer took full ownership of the library — their most significant growth in the team
• Versioning and cross-platform review rituals kept all three systems in sync over time
• Documentation standards reduced back-and-forth with engineering on implementation decisions

Impact

• Significantly faster new partner rollouts — theming replaced manual per-brand redesign
• Fewer consistency issues in production — cross-platform reviews caught drift before release
• Engineers had reliable, well-documented specs — reduced ambiguity and rework on implementation
• New team members onboarded to the design language faster through the shared library

Multiple products under one roof

This is not a single app with a few variants. The Co-Branding department runs several fully distinct product streams simultaneously — each with its own partner relationship, feature roadmap, compliance requirements, and release cadence. They share a platform and design system underneath, but each is a real product with real users and real business stakes.

Mobile banking — branded variants

Each partner's mobile app is a fully branded experience — the same platform and component library underneath, a distinct product on the surface. My work covered both the core cardholder journeys shared across all partners and the partner-specific features and brand applications.

Core cardholder journeys

Beyond the visual branding, my main design focus was on the core UX journeys every cardholder goes through — regardless of which partner they're with. These are the highest-stakes flows in the product: where users make decisions about money, credit, and account management under regulatory constraints.

• Credit card application — multi-step onboarding with compliance-mandated checkpoints and clear progress
• Card activation — first-use flows for physical and virtual cards across platforms
• Transaction management — list, filter, category, dispute, and receipt management
• Card management — PIN, block/unblock, Apple Pay / Google Pay setup, travel notifications
• Revolving credit — instalment setup, repayment planning, and balance visibility

IC work alongside leadership — intentionally

My role was not just to lead the team — I stayed hands-on as an individual contributor on the most complex design problems in the department throughout the engagement. This was deliberate: the best way to set a quality bar is to do the work, not just review it. It also kept me close enough to the real constraints — compliance edge cases, engineering limits, tight timelines — to make better strategic decisions.

Complex workflow design

The most demanding IC work involved multi-step workflows with significant branching logic — chat-back flows for dispute resolution, complex card management states, multi-step onboarding with compliance-driven branching, and edge cases that required careful state mapping. These required tight IA, clear error and loading states, and close collaboration with engineering to stay buildable and compliant.

Search & filter design

Transaction filtering in a credit card product is deceptively hard. Users need to combine date ranges, amount ranges, categories, merchant names, and card types across potentially thousands of transactions. The design challenge: make this powerful for the analyst, invisible to the casual user who just wants to find yesterday's coffee.

• Layered filter system: quick chips for the most common use cases, advanced panel for power users
• Progressive disclosure: complex filters surface when needed, not displayed by default
• Active filter state permanently visible — with clear individual-filter removal affordance
• Collaborated closely with engineering on filter persistence, URL state, and deep-link sharing

How the IC and Lead roles connected

• IC work gave me direct knowledge of the real design challenges — not a filtered, management-level view
• This made feedback to the team more useful: I could point to specific problems and show alternative approaches, not just give abstract direction
• Design system changes were validated on real IC work first — not in isolation from actual product problems
• Staying close to implementation built credibility with engineers: decisions were grounded in technical reality, not just visual preference