1Empty
No account on file. No status badge, one sentence explaining what this is for, one primary button.
← All projects
Edenred · The product for restaurant owners
The design system
Designing inside an existing system
Inside Edenred’s design system, I built the whole merchant portal part: its components, its screens, their states. The ones that were missing, I created. The ones that existed and did not hold up, I challenged, including when they served other products.
The system itself existed before I arrived: the foundations, the tokens, the base components. I didn’t write its rules. I learned to design within them, and to spot the moments they needed extending.
Merchant portal · Components, screens and states designed inside the Edenred system
Components
Variants
Documentation
Responsive
The product
The Edenred merchant portal is where merchants and restaurant owners track their transactions, invoices and points of sale. Every component on this page was designed for that product.
See the Merchant portal project →The components
Components documented down to the last state
My test for calling a component finished: someone else can pick it up without coming to ask me a question. That means its variants, its states, and how it behaves at every screen size. Here is a selection.
Table & banner
The two components that carry the management screens: the table carries the data, the banner says what’s happening.
Table
I chose to redraw the table rather than shrink it: columns on desktop, stacked cards on mobile. Three statuses (paid, unpaid, partially paid) and one shared anatomy declined for invoices, transactions and stores.
Anatomy3 statusesDesktop / mobile3 uses
Banner
Five registers for everything a screen needs to signal: information, warning, error, success, neutral. I kept the same pieces in all five: icon, title, description, actions, dismiss. On desktop the banner sits on one line; on mobile, the actions move below.
5 registersDesktop / mobileActions & dismiss
The navigation
Everything that navigates: the header, the footer, the menu. I asked all three the same question: what stays when the screen narrows and in what order the rest lets go.
Header
Signed in and signed out, across five screen widths. The whole question was one of order: what goes first, and what holds on to the end.
5 widthsDrop order
Footer
Four widths, from desktop to mobile. I chose to fold everything rather than drop anything: the links move under the copyright, then everything centres.
4 widthsLinks & socials
Side menu
Expanded and collapsed on desktop, then the mobile version, longer: it picks up what the header let go along the way, help, language, account.
The documentation
What someone else has to be able to pick up
This is what a component looks like when someone else can pick it up without coming to ask me.
The states
A whole journey, state by state
The journey I’m showing is short: updating your bank details, five screens. The heart of it is in the last four, the ones that describe what happens when things don’t run straight.
Here they are end to end, on desktop and on mobile.
This screen uses the Header, Menu and Table components shown above.
2Form
I announce the constraints before typing: accepted formats, 2 MB maximum.
3Error
The IBAN and the file are both invalid. I wanted them flagged at the same time rather than one after the other. Each has its own message and the button stays inactive.
4Partial success
The certificate is accepted. The user knows where they stand before they even submit.
5Confirmation
The request is sent. The status moves from active to "pending update". The change isn’t effective yet, and the screen says so.
My rule of thumb
What taught me the most wasn’t drawing components, it was documenting them. Writing "here is how it behaves when" forces you to find every case you hadn’t thought of.
Day to day, I grow the system. I add the states it was missing for the portal and I propose a variant rather than working around it in my mockup. I also flag the gaps between the documentation and production.