Edenred · The product for restaurant owners

The design system

A whole portal built inside an existing system

Inside Edenred’s design system, I built the part specific to the Merchant hub: its components, its screens and all their states. I created the ones that were missing and challenged the ones that existed in other products without quite fitting.

The design system 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

The design system components board, with their measurements: buttons, fields, badges, data tiles, dropdown, toggles and selector

The design system components board, in mobile format

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 having built its variants, its states and how it behaves at every screen size.

Table & banner

The two components that carry the management screens: the table carries the data, the banner says what’s happening.

Table

On mobile, I chose to redraw the table rather than shrink it: columns on desktop, stacked cards on mobile.

Anatomy3 statusesDesktop / mobile3 uses

The column header block, with its sorting — Header

The selection block: the row checkbox — Selection

The content block: reference and date, on one or two lines — Content

The status block: paid, unpaid, partially paid — Status

The actions block: open the row, and the contextual menu — Actions

The assembled invoices table on desktop: selection, date, status, amount and actions — **Assembled.** The invoices table on desktop.

The same invoices table on mobile: each row becomes a card — **On mobile.** The rows are redrawn.

Banner

Five registers for everything a screen needs to signal: information, warning, error, success, neutral. On desktop the banner sits on one line; on mobile, the actions move below.

5 registersDesktop / mobileActions & dismiss

The navigation

Header

Signed in and signed out, across four screen widths.

4 widthsDrop order

The signed-in header across five widths: entity, language, help and account drop in a decided order, down to the compact menu version

Footer

Four widths, from desktop to mobile: I chose to fold everything rather than drop anything.

4 widthsLinks & socials

The footer across four screen widths: legal links and social icons fold without losing anything

Side menu

It is collapsed or expanded on desktop. Its mobile version is longer: it picks up what the header no longer has: 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 Zeroheight page for the Dropdown component, Design tab: the field in the middle, seven numbered markers around it and their key below — **The anatomy of the component.**

The same Zeroheight page further down: a grid of twenty Dropdown states, empty or filled, idle, focused, disabled and in error, then a Do and Don’t pair about error text — **The twenty states of the same component** and, below them, the best practices. This one says an error message replaces the helper text instead of adding to it.

The states

A whole journey, state by state

The flow I’m showing is short: updating your bank details, five screens.

This screen uses the Header, Menu and Table components shown above.

1Empty

No account on file. No status badge, one sentence explaining what this is for, one primary button.

Bank details screen with no account on file, desktop version

Bank details screen with no account on file, mobile version

2Form

I announce the constraints before typing: accepted formats and size.

Blank bank details form, desktop version

3Error

The IBAN and the file are both invalid. Each has its own message and the button stays inactive.

Form with invalid IBAN and non-compliant file flagged at the same time, desktop version

Form with invalid IBAN and non-compliant file flagged at the same time, mobile version

4Partial success

The bank details are accepted. The user knows where they stand before they even submit.

Form with the certificate accepted and the submit button active, desktop version

Form with the certificate accepted and the submit button active, mobile version

5Confirmation

The request is sent. The status moves from active to "pending update". The change isn’t effective yet, and the screen says so.

Submission confirmation with the status switched to pending update, desktop version

Submission confirmation with the status switched to pending update, mobile version

My rule of thumb

I learned more from asking how a component behaves when things go wrong than from drawing it straight away. That question brings out every case nobody had thought of.

Day to day, I add to the design system what it’s missing for the portal. I propose a variant rather than working around the component in my mockup. I also flag the gaps between the documentation and production.