It’s a portal merchants only open two or three times a year. I’ve been its only designer for three years. My job is to make them want to come back.
Edenred is known for meal vouchers. At the end of the chain are the shopkeepers and restaurateurs who accept them. The portal is their own space.
The problem: they rarely log in. Many see Edenred as a service that charges them fees, not as a partner that brings them customers.
I’ve been the product designer on the portal since the project started.
I focus here on two highlights: the user tests on invoice readability, which I prepared and ran, and the home page, where I built a dashboard so merchants can see straight away what Edenred brings to their business.
The November 2023 interviews with a good number of restaurant owners fed the portal’s different projects. They are the voices you hear on this page, on The onboarding journey and on Logging back in.
The portal brings together six areas: home, invoices, transactions, points of sale, billing entities and profile.
Every screen is in English: it’s the working language on the project.
A real slice of the product: browse the menu and open the profile.
When merchants open the portal, it’s almost always to find their invoices. Between the amounts, the fees and the statuses, there’s no way to understand at a glance what they owe and what they receive. The result: merchants who second-guess the numbers and call support, on the very screen that was supposed to be the simplest.
"When I have five minutes and I don’t feel like relaxing, I enter all the invoices into Excel."A restaurant owner, November 2023 interview
Merchants need that table to get an overview. It had to be made readable, and there everything was challenged: the number of columns, the labels, how much explanation to wrap around complicated figures.
Three versions of the table, differing on the number of columns, the labels and how much explanation to add. Rather than decide on my own, I showed them to real merchants: "Here are your invoices, tell me what you understand".
The three versions shown to merchants
Version 1, everything on one line: every figure gets its own column, and the detail slips in under the amount.
The tests sorted what helped from what cluttered. But above all, they pointed to the real sticking point: even then, prices and fees remained too hard to read.
In the moment, it’s frustrating not to validate the version you were hoping for. With hindsight, that’s the true role of a test: to diagnose, not to reassure. The table exists today in two versions, depending on the country’s billing model. It also opened the work still in progress: the payment flow and the invoice detail page.
Drag to switch from one to the other. Rather than one table that would half suit both billing models, I designed one for each case.
Merchants rarely visit, and when they do, it’s for their invoice. By default, logging in means coming face to face with fees. The interviews said something more: for them, Edenred is a perk they offer their customers, not a source of revenue.
We had to flip that impression right on arrival. Without even seeing a mockup, almost every merchant mentioned the same reference points: their revenue, their number of transactions, their average ticket.
The first figure on the screen is the one you owe.
without seeing a single mockup
Value first, fees second. Invoices haven’t gone anywhere: they just come after.
Turning the home page into a dashboard came quickly and was never in question. What we discussed was what to put on it. I could pour in everything we know about a merchant, since there’s no shortage of data, or stick to a handful of key figures.
I turned the home page into a dashboard built around those three figures. My part was shaping them: making them readable and meaningful at first sight, even for a merchant who only stops by once a quarter. The page is built in modules, so we can add others without redrawing it.
The home page now opens on what the merchant has earned. It’s no longer somewhere you only come to fetch your invoice.
A merchant rarely logs in, and that’s the whole difficulty of this product. Every screen has to be understood on the first try by someone who has forgotten everything since last time. It changed the way I decide what has to be read straight away.
This portal reminded me that a product gets built as you go. Some parts are polished, others are still open, like the payment flow and the roles and permissions.
The outcome figures for this project belong to Edenred, so I don’t publish them here. What gets measured on this page is how many times a merchant logs in per year, plus the volume of invoice disputes reaching support.
