Enterprise Systems · RFP Enablement · Design Lead
Role
Design Lead
Platform
Web · Banking Platform
Scope
White-label RFP System
Organisation
Mastercard
System model
Configurable architecture
4 layersClient
MastercardPartnerBank platform
Role
Design LeadInfluence without authority
Timeline
2023 – 2024Ongoing system evolution
Cross-functional
Product · Eng · SalesEnterprise alignment
Scope
White-label DBPRFP enablement
PartnerBank is Mastercard's white-label digital banking platform, deployed into enterprise RFP cycles with major financial institutions. Product demos were a critical lever in winning these deals.
But the underlying system was optimized for visual consistency. Every new banking prospect required manual visual adjustments and design effort, slowing demo turnaround during the exact moments when sales responsiveness mattered most.
Enterprise RFP cycles are time-sensitive and highly competitive. The team faced a clear trade-off, preserve system simplicity, or introduce modular customization to keep up with sales motion.
The platform could stay simple or get fast. The team had to pick which one it was optimising for.
Considered
Keep the template model exactly as it was. One codebase, one look, no configuration surface to maintain.
Why not: Simplicity here was a false economy: the cost did not disappear, it moved into manual personalization on every single RFP, at the worst possible moment in the deal.
Chosen
Decouple brand from architecture, make personalization configurable, and let the effort compound across deals.
Why it won: Customization at the brand layer did not compromise system integrity once properly modularized, and it materially improved sales responsiveness.
Customization at the brand layer would not compromise system integrity, if properly modularized, and would materially improve enterprise sales responsiveness.
01
Structural Audit
Identified the structural constraints baked into the existing system that blocked rapid customization.
02
Decouple Layers
Separated the core UX architecture from the brand and visual layers, two systems instead of one.
03
Modular Components
Standardized banking modules into reusable component configurations swappable across deals.
04
Token-Based Theming
Introduced design tokens so each brand could be re-skinned via configuration, not redesign.
Each layer has one job. Brand changes never touch UX logic; demo configuration never breaks core components. Decoupling is what made the system fast.
Stable, opinionated patterns for accounts, transactions, transfers, and statements, unchanged across deals.
Banking primitives, account card, transaction list, CTA block, hero, composable into any screen layout.
Color, typography, radius, and elevation tokens that re-skin every component in one configuration pass.
Sales-facing layer that assembles brand tokens + component selections into a deal-ready demo for any prospect.
Problem
Every screen was tightly coupled, changing one element for a prospect required manually re-editing multiple interconnected pieces, with no way to reuse work across deals.
Decision
Decomposed every screen into independent units: header, account card, transaction list, CTA block, each with variants and props. Screens became compositions, not one-off templates.
Tradeoff
Required upfront investment in component architecture that wasn't immediately visible to stakeholders. Took two sprints before the compounding benefit became apparent in demo build times.
Impact
New deals could compose screens from the existing library rather than starting from scratch. Primitive count grew from 8 to 31 components over six months, each reused across multiple prospects.
Problem
Each prospect's brand identity was applied by hand, editing hex values, font references, and spacing across dozens of component files. It was effectively a redesign for every deal.
Decision
Centralized brand identity into a single token configuration: color, typography, radius, elevation. Any prospect's visual identity could be applied to the entire component library in a single config pass.
Tradeoff
The token schema had to be comprehensive enough to cover edge cases across all components, which required more upfront definition work than stakeholders expected. Some bespoke brand requests couldn't be tokenized and still required manual overrides.
Impact
Prospect onboarding dropped from multi-day design effort to a configuration pass. Sales could request a re-skinned demo for a new bank on short notice without design being a blocker.
Problem
The two slowest steps, brand application and component selection, were the ones that gated the sales team during live RFP cycles. Any delay in this zone directly impacted deal competitiveness.
Decision
Built a configuration layer that combined brand token application and component assembly into a single pass. Sales could specify prospect parameters; the system produced a deal-ready demo configuration without requiring per-deal design cycles.
Tradeoff
The configuration engine introduced a new layer of system complexity that required engineering time to maintain. Some highly bespoke prospect requests still fell outside what the engine could handle and required custom work.
Impact
Per-RFP design effort reduced substantially. The team could respond to enterprise demos on compressed timelines that were previously impossible, which sales cited as a meaningful differentiator in several competitive RFPs.
01 / Component Modularity
Every screen was decomposed into independent, reusable units, header, account card, transaction list, CTA block, each with variants and props. Composition replaced replication.
Primitives
Account Card · Transaction List · CTA Block
Composition
Page templates assembled per RFP
02 / Brand Token Layer
Color, type, and spacing tokens were centralized into a single brand layer. A new prospect's visual identity could be applied to every component in the library through a configuration pass, no component-level redesign required.
Tokens
Color · Type · Radius · Elevation
Effort
Manual redesign → config swap
03 / Demo Configuration Engine
The configuration engine collapsed the brand-application and component-selection steps, the two phases that previously gated the sales team, into a fast, repeatable configuration pass.
Compressed
Brand config + component selection
Result
Sales got a deal-ready demo faster
A single banking card component, themed through three different token configurations. No structural change. No new design work. Just configuration.
Brand · A
•••• 4287
Premier · Debit
Brand · B
•••• 9120
Private · Credit
Brand · C
•••• 7503
Everyday · Debit
Brand token skin. Colour, type, radius, and elevation come from one config file. Swapping it re-skins every component in a single pass.
Stable core UX. Accounts, transactions, transfers, and statements never change across deals. Prospects evaluate a proven flow, not a prototype.
Swappable modules. Screens are compositions of banking primitives with variants and props, so a new prospect composes instead of rebuilding.
Deal-ready output. The configuration engine assembles tokens and components into a demo sales can show without a design cycle.
Before
Linear effort per RFP.Every new bank started from the same template and required hands-on visual edits, design effort scaled 1-for-1 with deal volume.
After
Compounding effort.Every new bank inherits the system. Brand + component configuration replaces manual redesign, and every improvement benefits every future deal.
Enterprise deals close cross-functionally, but the system's new flexibility materially strengthened Mastercard's competitive positioning in high-value RFP cycles.
Per-RFP demo turnaround
Illustrative reduction in design effort.
Before
~ 10 days
After
~ 3 days
M.01
~70%
Reduction in per-RFP design effort, measured against the prior template workflow.
M.02
Template → Config
Shifted the platform from a rigid template to a reusable configuration model.
M.03
Faster Sales Loop
Materially improved demo responsiveness during high-stakes enterprise negotiations.
Customization and consistency aren't a trade-off, they're a layering problem. The system became fast the moment we stopped treating brand as a property of components and started treating it as a layer above them.
What it changed in how I work
I stopped treating brand as a property of components and started treating it as a layer above them. Once that layering clicked, the customization-versus-consistency argument dissolved: each layer got one job, and the system got fast without getting fragile.
What I'd do differently
Scope the token schema with engineering before promising it to stakeholders. Making it comprehensive enough to cover every component took more upfront definition work than anyone expected, and that surprise cost credibility the architecture then had to win back.
What still needs proving
How far tokenization stretches. Some bespoke brand requests still fall outside the schema and need manual overrides, and the model only holds if those stay the exception rather than quietly becoming the norm.
3 brands on a shared commerce foundation.
₹1.98Cr revenue across two 0→1 products.
50+ components / 28 templates shipped.