VISA DIGITAL BENEFITS PLATFORM • SYSTEM DESIGN FOR CONFIGURATION OF CARD BENEFITS
Visa Digital Benefits Platform (VDBP) is an internal enterprise tool used by issuing banks and Visa administrators to configure cardholder benefits and packages at scale. When I joined the project, the system had a foundational problem: no organizational structure. Every variation of a benefit—different region, different card tier, different coverage limit—required creating an entirely new benefit record from scratch. Over time, the benefits library had become an unnavigable pile. Teams at issuing banks like Bradesco were slowing down, making errors, and losing confidence in the system.
My role was to design a way out of that. The critical constraint: we couldn't start over. The system was already in production. Issuing bank teams at major global banks — Bradesco, BBVA, and others — used it daily. They knew its quirks, had built workflows around it, and couldn't afford retraining on an entirely new product. The new features had to feel like natural extensions of what they already knew, not a replacement.
Benefits configuration sits at the intersection of policy, money, and operational risk. A misconfigured benefit isn't an abstract UX failure—it can break cardholder entitlements across an entire region. That reality shaped every design decision: the goal wasn't just to make the system easier to use, it was to make it harder to break.
Before any design decisions, I had to understand the system deeply enough to redesign it responsibly. VDBP was already in production — real banks, real cardholders, real consequences for errors. That meant discovery had to be rigorous: not just what users wanted, but what the system actually did, what could safely change, and what couldn't.
I ran workshops with the product team, conducted research through a UX research partner, and mapped the system from the ground up — documenting what existed, what was broken, and what the design needed to preserve even as it improved. All of that thinking lived in FigJam before it ever touched Figma.
The first thing I needed was a shared, definitive answer to a deceptively hard question: what is VDBP, exactly? The answer turned out to be more complex than anyone had written down.
VDBP is an enterprise configuration tool. Issuing banks use it to define cardholder benefits — what a benefit covers, who qualifies, when it expires, how much it costs, which regions it applies to, and which card products carry it. Benefits are grouped into Packages. Packages are assigned to BINs — Business Identification Numbers, the first four to eight digits of a card number — which is the actual mechanism that connects a benefit to a cardholder.
Every benefit and package is its own distinct object in the system, with its own lifecycle: created, configured, submitted for approval, approved or rejected, published, and eventually expired or replaced. That lifecycle — and the relationships between objects — was the design surface I had to work with.
Two personas emerged from research, and their needs were in productive tension with each other.
Carolina is a Card Products Analyst at Bradesco Bank in São Paulo. She's process-oriented, not deeply technical. She creates and manages benefit records daily — searching for references, configuring attributes, submitting for approval. Her frustration: the system made routine work unpredictable. "I know the benefits process inside out. The system is what slows me down. I spend half my time searching for records I've already created."
Ricardo is a Card Products Manager, also at Bradesco, overseeing the full LatAm portfolio from Rio de Janeiro. He reviews 20-40 benefit approvals per week. His frustration: every approval required opening the full record, navigating away from the queue, and relying on memory to compare. "By the time I've opened a record, found what I need to compare, and navigated back, I've lost my place in the queue. I'm approving on incomplete information."
Carolina needed a system that made creation faster and less error-prone. Ricardo needed a system that let him evaluate records without losing context. Both needed to trust that changes they made wouldn't quietly break something downstream.
I mapped Carolina's full configuration journey across six stages: Trigger, Search & Research, Create, Configure, Submit for Approval, and Package & Assign. At every stage I documented her actions, emotional state, pain points, and design opportunities.
The emotional arc was the real finding: Carolina started neutral, became frustrated during search, resigned herself to making errors during creation, grew anxious at configuration, and felt uncertain at submission. She was relieved when approved — but immediately nervous about putting the benefit in the wrong place. Not one stage in the journey produced confidence.
That arc became the design brief. Every solution had to address a specific stage in that journey and move the emotional state in the right direction.
From research and the journey map, I synthesized ten core pain points — the specific, concrete failures in the current system that the redesign needed to fix. Then I translated each into a "How Might We" question, reframing every problem as a design opportunity.
The pain points ranged from structural ("no hierarchy — everything is a flat list") to procedural ("admins afraid to touch existing records — don't know what will break") to interpersonal ("no clear way to communicate rejection reasons back to Carolina — errors created back-and-forth email loops"). The HMW questions that came from them shaped the solution framework directly: they became the design brief that the new features were measured against.
To design new features for an existing system without breaking it, I needed to understand the system's underlying grammar — not just how it looked, but how it was structured. I developed the Objects / Attributes / Actions (OAA) framework to map what already existed and what needed to be added.
Existing Objects included Benefit, Card Type, Budget, Qualification, Supplier, Package, and Link. Existing Attributes covered everything from internal name and status to region, benefit type, cost structure, and approval state. Existing Actions were limited: Cancel, Add Link, Save Draft, Submit, Duplicate, Create Extension.
The new objects, attributes, and actions I proposed were mapped against the existing ones — not to replace them, but to extend the system in ways that felt coherent with what was already there. New Objects included Base Benefit (with extension children), Benefit Spend Tiers, Coverage, and Language Version. New Actions included Add Tier, Add Redemption, Upload Document, Navigate via Section Sidebar, and Duplicate to Section Scheme. Every addition was designed to be invisible seams, not visible breaks, in the existing product.
The product proposition was simple once the research was clear: as an issuing bank admin, I need a reliable way to create and organize similar benefits, to do benefit extensions, add-ons, and overrides, so that I can eliminate duplicate benefits, seamlessly extend benefits to cardholders, and keep our list of benefits more organized.
From that proposition, I mapped eight pain points directly to design solutions — a concrete decision for every documented failure:
Every variation requiring a new record → Base/Extension model with inheritance. Benefit disappears after submit with no status visibility → Approval Stage as a first-class three-step status wizard on the record itself. No hierarchy, flat list, admins afraid to touch records → Benefit Designation (Base vs Extension) labels on every record, Related Benefits showing connections before any change is made. Package contents invisible → Coverage making each tier's geographic and card-type scope explicit. Library unsearchable → Benefit Type Group for categorization, reducing total record count. Expiring benefit forces entire package rebuild → Tier End Date letting individual tiers expire independently. Required fields not marked → Section Sidebar surfacing the full form structure before the user begins. No standard intake format → Structured sections and required fields setting the standard for a complete record.
The project ran from September 2022 through February 2023, across three phases. Phase 1 addressed the Parent-Child / Base-Extension model — the foundational structural change. Phase 2 tackled Tiers — the spend and coverage tier system that let individual variations expire independently. Phase 3 redesigned the Benefits & Packages Menu — the navigation surface that had to surface hierarchy without overwhelming users who already knew the flat version.
Each phase ran discovery, lo-fi, usability testing, accessibility review, high-fi, and engineering review in sequence. The phases overlapped deliberately — Phase 2 low-fi ran concurrently with Phase 1 usability testing, so findings from one informed the other. A six-week engineering freeze in December 2022 was used to complete Phase 2 high-fidelity work, so implementation could begin immediately when the freeze lifted.
Before designing anything, I had to understand what I was actually designing for. VDBP is a many-to-many system: a single benefit can belong to multiple packages; a single package can contain dozens of benefits; a card product can carry multiple packages; and each of those relationships carries its own rules, states, and constraints. Change one thing in the right place, and it cascades correctly. Change it in the wrong place, and it quietly breaks something three levels away.
To get my head around this—and to give myself a framework that could hold up as the system grew—I organized everything into three categories: Objects, Attributes, and Actions.
Objects are the primary entities in the system: benefits, packages, tiers, card types, and the eligibility rules that govern them. Each is a discrete thing that can be created, configured, and related to other things.
Attributes are the properties that define an object: a benefit's coverage limit, geographic scope, currency, time period, approval state. But here's where it gets interesting—objects frequently become attributes of other objects. A benefit, itself a complex object with its own properties, becomes an attribute of a package. A card tier, which has its own rules and constraints, becomes an attribute of a benefit. The system is nested, and the nesting goes deep.
Actions are what users do: create, edit, add, approve, reject, publish, expire. But actions don't just happen and disappear—they leave state behind. An approval action transforms the approval state attribute of a benefit. A rejection creates an audit trail that becomes part of the object's history. Actions crystallize into attributes.
This framework wasn't just conceptual. It directly shaped how I organized the interface: what belongs in a menu view versus an overlay versus a detail page, what needs to be visible at a glance versus discoverable on demand, and where the guardrails needed to live.
The parent-child model was the project's founding premise—it existed before I was assigned to it. What I had to do was make it real in the interface, and solve every edge case that came with it.
The core idea: instead of creating a new benefit for every regional or tier-based variation, admins define a base benefit once. Child benefits inherit the parent's attributes automatically—coverage rules, eligibility logic, geographic constraints—and can selectively override only what needs to change. A grandchild benefit inherits from its parent, which inherited from its grandparent. The hierarchy is live, not copied.
This is where the Objects/Attributes/Actions framework became essential. Inheritance means that an attribute set on a parent object propagates silently down the tree. The interface had to make that propagation visible and trustworthy—users needed to know which attributes they owned and which they had inherited, and what the downstream consequences of changing either would be.
The risk was real: build the extension model wrong, and existing packages break. Cardholders lose benefits they're entitled to. Banks file complaints. We had to design the system so that extensions could only modify what was safe to modify—certain attributes were editable, others were locked at the parent level—and so that adding or removing a child benefit couldn't silently invalidate the package it belonged to.
That meant designing explicit guardrails, clear inheritance indicators, and conflict messaging that told admins exactly why something was blocked and what to do about it. Not every edge case was glamorous work. Most of it was grinding through scenarios until we were confident nothing could fall through.
The old model had no inheritance, no hierarchy, no shortcuts. If a benefit needed to work slightly differently for Brazilian cardholders versus Mexican ones, an admin created two separate benefit records—full stop. Multiply that across dozens of banks, hundreds of card products, and thousands of regional variations, and you get a library that nobody can navigate and everyone is afraid to touch.
The costs were real: duplicated work, slower approvals, and a growing risk that nobody knew which benefit record was the authoritative one.
We aligned on five outcomes:
The benefits and packages menus had to do real work. At Bradesco and other issuing banks, admins were processing approvals at volume—they needed to scan a list and know immediately what required attention, what was safe to publish, and what was stuck.
I added hierarchy and approval state as first-class information in the menu view. Base benefits and extensions are visually distinct. Status badges—Saved Draft, Pending Approval, Published, Expired, Rejected—are scannable at a glance. In Objects/Attributes/Actions terms: the menu surfaces the most decision-critical attributes of each object, so the action an admin needs to take is immediately obvious.
This was one of my ideas, and it became one of the most-cited improvements in user feedback.
Previously, reviewing a benefit or package meant opening the full detail page, locating the relevant data, making a judgment, then navigating back. For teams processing dozens of approvals, that context-switching added up fast.
The overlay pattern lets an admin see everything needed to make an approval decision—status, history, relationship hierarchy, key attributes—without leaving the menu. The action is available exactly where the object is being evaluated. Approve, reject, or flag for edit, all in place. Users reported that this alone sped up the approval workflow by 15–20%. At the volume Bradesco operates, that's meaningful.
In a many-to-many system with parent-child relationships, package inheritance, and approval states all operating simultaneously, it's easy to lose your bearings inside a detail view. The sidebar was my solution to that.
On benefit detail pages, the sidebar shows where you are in the object hierarchy—base or extension, which parent it belongs to, which packages include it. On package pages, it surfaces tier-level summaries and breaks down cost and responsibility between Visa and the issuer. It answers the question every admin needs answered before touching anything: "What is this object, what does it belong to, and what inherits from it?"
Benefits are governed by layered rules: eligibility tiers, coverage limits, currencies, time periods, regional constraints. Each of these is an attribute of the benefit object—and each can be inherited, overridden, or locked depending on where the benefit sits in the hierarchy. The design had to support that depth without making simple tasks feel complicated—and without giving admins enough rope to hang themselves.
Benefits needed to support multiple markets and supporting documentation. Additional language support and attachments were designed as first-class sections so admins could manage localized content and required documents without losing context.
Unhappy paths mattered as much as happy ones. Partial completion, missing documents, validation failures—enterprise workflows hit all of these. The UI needed to surface what went wrong and what to do next, clearly and without drama, so admins could resolve issues without losing their place or their nerve.
Packages are where benefits become "real" for cardholders—and where the many-to-many complexity becomes most acute. A package is itself an object, but it's also a container for benefit objects, each of which carries its own attribute set, inheritance chain, and approval state. The UI needed to show not only which benefits were included, but how they were inherited or cascaded from parent packages, and how optional bundles and cardholder choices affected the final structure.
Adding benefits isn't just selecting from a list. The system enforces rules to prevent conflicts—a child benefit can't be added if its parent is already included, because the child's attributes would be redundant or contradictory. These constraints were made visible in-context so users understand why something is blocked and exactly how to proceed, rather than hitting a wall with no explanation.
As VDBP matured, operational features were added to support real-world maintenance. Renewal reminders and email settings are one example: the product needed to handle time-based states and notifications without forcing admins out of their workflow.
The system got significantly more complex during the project—more tiers, more states, more edge cases—and the interface absorbed that complexity without becoming brittle. The Objects/Attributes/Actions framework held up. The guardrails held. The overlays worked. The sidebar kept people oriented when the underlying model was genuinely hard to reason about.
Most of all: we didn't break anything. In a system where a bad configuration can affect real cardholders at a major bank, that's not a small thing.
Before an admin publishes a change that cascades through packages and assignments, they should be able to see exactly what will be affected. A clear "what will change?" preview—before committing, not after—would make an already-safe system feel trustworthy in a way that's immediately legible. That's the next layer I'd go after.
LinkedIn
Dribbble
Medium
Behance
