Login and account recovery

Each audience had its own login page, entirely separate from the others. That siloing caused constant confusion: a merchant is also, in everyday language, a "client" of Edenred. So they naturally headed for the Client area, which wasn’t theirs, and ended up stuck. As a result, the merchant portal recorded very few logins.

Generative research on small merchants showed that they devote little time and attention to meal vouchers, which are only a minor part of their business. In that context, even a little friction at the door is enough to put them off logging in.

We first tried to keep the three pages separate and signpost them better. We reworked the labels, the links, the way each space announces who it is for. Merchants still went through the wrong door: the word “client” speaks to them, and nothing tells them that Edenred calls “Merchant” the space that is theirs. In the end we brought the three entrances together on a single page that names all three audiences, so the merchant reads instead of guessing.

Rather than guessing on the user’s behalf, we chose to bring the three audiences together on a shared entry point that names them explicitly, and makes switching from one to another immediate. Each audience then leads to its own login. We explored this solution in a workshop. I mocked up the proposals and we merged what worked in each.

A Client / Employee / Merchant hub, fully responsive: three tabs aligned on desktop, and a dropdown menu on mobile to keep the choice clear.

Merchants only use the portal a few times a year. Between two visits, they forget their password, their username, sometimes the link itself. So I designed the login for that moment: someone coming back after a long time away.

The rarity of logins is the fact that structures everything, all the way to security itself: when merchants say they trust their browser, the email OTP is only requested again every 120 days.

I chose to handle every dead end inside the screen rather than send people elsewhere. The other path already existed: merchants called support or their account manager, and that is exactly what was overloading both. That one means five more journeys to design, with their messages and their states: forgotten password, forgotten username, expired link, account not yet activated, wrong code.

I designed the login around recovery, turning every blocking point into an exit rather than a dead end. Forgotten password, forgotten username, expired activation link, non-activated account, wrong code: each case has its own screen, its clear message and its way back.

My job was to turn a constraint (users who rarely return and often get stuck) into a journey where every blocking point has a way out.