Gift cards, from the sales site to the dashboard
B2C and B2B dashboards and consumer sales sites for Italy’s leader in credit cards and loyalty: around 500,000 cardholders supported.
The problem
The management dashboards showed every available figure and nothing decisive: corporate clients couldn’t read their loyalty programme performance without help from sales.
My role
I designed three connected products end to end: the B2C dashboard where cardholders activate and manage their cards, the B2B dashboard where corporate clients follow their programmes, and consumer sales sites such as MyGiftCard, ordering the data around the decisions people actually make. Alongside it I introduced leaner working methods between design, marketing and engineering.
The impact
Fewer support tickets and less rework on screens after release. Corporate clients now read their own loyalty programme performance without going through sales, and onboarding calls got shorter. The redesigned product sites convert better than the previous version, and the shared UI library cut new-campaign launch time from weeks to days.
From the first interview to the release
Both ends of a ticket
Interviews with real cardholders and with Epipoli’s internal customer care.
Three questions first
With sales, the three questions every corporate client actually asks.
Three products, one structure
Cardholder area, business dashboard and sales sites, mapped together.
Flows, screens, one library
One task per screen, and a UI library shared by B2C and B2B.
Fewer tickets, less rework
Support tickets went down, and so did rework on screens after release.
Research: the people on both ends of a ticket
I interviewed real cardholders, to see how they actually activate a card, check a balance and top it up, and Epipoli’s internal customer care team, who answer when one of those steps goes wrong. Hearing the same journey from both sides showed which moments turned into support requests.
On the business side, I worked with sales on the questions corporate clients kept asking them. That set the brief for all three products: the answer people come for goes first, and every step that produced a ticket either goes or gets its help in place, before the error.
Three products, one structure
Each audience got its own product and its own navigation, built from the same components, so a change to the library reaches all three.
- Activation
- Card code
- Identity document
- Card active
- Cards: active and expired
- Balance and top-up limit
- Card details, behind an explicit action
- Transactions, by month
- Wallet: balance and every top-up
- Cards, by branch
- Top-ups: by hand or by template
- Operators
- Notifications
- Help
- Services first: activate a card, check the balance
- Gift cards of the big brands, price from
- Business: the range is the navigation
- Prepaid, gift, multibrand and welfare cards
- Activation and help in the same bar
One UI library shared by the three products: same components and visual language, flows designed around each audience.
Card activation: one task per screen
The flow a cardholder follows to activate a MyGiftCard. Each step asks for one thing: the 16-character card code, then the identity document required by anti-money-laundering rules, then a confirmation that leads straight to the card instead of ending the journey. Help sits next to the field it explains, before any error, and what you need is listed before the form starts. Desktop and mobile share the same components.
- Step 1
Card code
16 characters, with the help box before any error.
- Step 2
Identity document
Why it’s needed and what to have ready, before the form.
- Step 3
Card active
The journey doesn’t end here: one button opens the card.
- Step 4
Your card
Balance, top-up and transactions, on the first screen.
B2B dashboard: bulk work, without surprises
The dashboard companies use to manage the cards they distribute: a wallet with the available balance and every top-up, the list of cards by branch with actions on the selected rows, and bulk top-ups entered by hand or uploaded as a template. Every page opens with a line that says what it is for, the total to top up stays in view while you work, and cards that can’t be topped up remain in the list, disabled, so nothing disappears.
- Step 1
Wallet
Start from the money available to spend.
- Step 2
Cards by branch
Select the rows to act on.
- Step 3
Top-up
By hand or by template, with the running total in view.
- Step 4
Confirm
One commit, then the wallet shows what went out.
Schematic reconstruction, not a screenshot
Sales sites: services first, then the shop
The sales sites share the design system of the dashboards. On MyGiftCard, the consumer shop, the services people come back for, activating a card or checking the balance, sit above everything else, and the gift cards of the big brands follow, each with its starting price and one buy action. On MyGiftCard Business, the site for companies, the navigation is the product range itself, from prepaid cards to welfare cards, with activation and help in the same bar.
Alternatives compared: every figure, or three questions first
How the business dashboard should open, decided with sales and the client.
Every available figure
The way the old dashboards worked.
- Complete, but nothing decisive
- Clients needed sales to read their own programme
The three questions first
Each view opens on what clients actually ask; everything else moves to a second level.
- Headline figure, trend, detail: the same order in every view
- Every page opens with a line that says what it is for
Corporate clients now read their own programme performance without going through sales, and onboarding calls got shorter.
Key decisions
Start from the questions, not the data.
I worked out with sales the three questions every client actually asks, and built the dashboard to answer those; everything else moved to a second level.
One hierarchy, repeated.
The same pattern in every view (headline figure, trend, detail), so learning one screen means learning all of them.
One design system, two distinct experiences.
B2C and B2B share components and visual language, but the flows are designed around each audience: consumer sites are built for choosing a product fast, business platforms for control and reading data.