Quick links WorkAboutChat →
Based in ParisSenior Product Designer
← All work

Visual — hero

Professional work · Accor

ALL Accor Business

Role
Senior Product Designer
Company
Accor
Scope
B2B administration, web
Stage
First pilot, ~20 companies
Period
2025–2026, product still evolving
Reading
4 min
B2BAdministrationProduct systemsResearchFigmaFigmotionMiro / FigJamClaude Code / Codex

Taking over an MVP just before it becomes real.

I joined ALL Accor Business as the first pilot was getting close. The MVP was there, but it had already been handed from one designer to another. Some of it had been stabilised, engineering was moving, yet the product still told different stories depending on whether you looked at Figma, the roadmap or what had actually been built. There was no long onboarding period. I had to learn the business rules quickly, understand what already worked, decide what could wait and make sure the important journeys were solid before real companies started using them.

(01) Starting point

Work out what is real before redesigning it

The first job was to reconnect the source of truth. I went through the key journeys, checked them against the product and brought back shared rules where screens had drifted apart.

There were plenty of things I could have redesigned. A few weeks before pilot, that would mostly have created another delivery problem. I focused on the places where ambiguity could break the experience or slow the team down.

Walkthrough · 0:52

One manager, six everyday tasks

A quick look at what an admin actually handles: members, company structure, points and the core admin jobs. Pick a step to jump to it, or let it play.

  1. 01

    Read the account at a glance

    0:00

    The dashboard opens on what the company holds: Reward points, money already saved, current and upcoming stays. The points statement turns the balance into a history the manager can search.

    • Value before detail: points first, then savings in euros.
    • Every figure leads to the list behind it.
  2. 02

    Create a voucher for an employee

    0:04

    Points become a voucher on a single screen: pick an amount, find the beneficiary by name, check the value, create.

    • Point presets instead of a free amount.
    • Estimated value in euros on every line.
    • The button stays disabled until the voucher is complete, and one sentence says what is about to happen.
  3. 03

    Follow the team's stays

    0:16

    Ongoing and upcoming stays are summed up at the top, with their total and the points they will earn.

    • Hotel, dates, employee, status and amount on one row.
    • Search by what a manager knows: hotel, booking or employee.
  4. 04

    Invite a team member

    0:20

    Invite by email, CSV/Excel file or a shared link. The side panel keeps the team list in view behind it.

    • Role and entity are optional: an invitation never waits for the company structure to be set up.
    • The new member shows up straight away, as a pending invitation.
  5. 05

    Organise people by entity

    0:33

    Teams, departments or functions become entities, each with a key contact and a member count.

    • One main contact for the company, used by every entity without its own.
    • Edited in place, from the list.
  6. 06

    Buy and assign a card

    0:38

    The three ALL Accor+ cards side by side, volume discounts stated upfront, then each card assigned to an employee before confirming.

    • Assignment happens in the order review, not as a separate chore afterwards.
    • The new card tops the list, its expiry shown as time left.
0:00 / 0:52

(02) The core

Make the core dependable

Inviting a member or managing a group looks simple until the states, permissions and repeated admin work start piling up. A lot of the useful work sat in those details: missing states, action hierarchy, table behaviour, bulk actions and edge cases.

That gave us a better base without pretending we had time to rebuild the whole product.

At that stage, every change needed a reason: save admin work, remove uncertainty for engineering, or create a rule we could reuse later. Pure polish could wait.

(03) After release

After release, the job changes

Once the pilot started, the product did not freeze. New capabilities kept arriving, along with more states and more business rules.

That gave me room to move beyond stabilisation and shape parts of the experience that were still very bare, while staying selective about where custom UI was actually worth the maintenance cost.

Dashboard: points and savings read first.
VisualDashboard: points and savings read first.

I stayed close to the Accor design system and only stepped away from it when there was a practical benefit. Hotel imagery is a good example: recognising a familiar property can be faster than reading another line of metadata.

Team stays: the hotel picture helps recognise the place.
VisualTeam stays: the hotel picture helps recognise the place.

New commercial features also had to fit the product instead of taking it over. Subscription cards needed to explain an offer inside an admin space without turning the whole experience into a shop.

Subscriptions: cards assigned by employee, expiry shown as time left.
VisualSubscriptions: cards assigned by employee, expiry shown as time left.

The same restraint applied to motion. I used it when a state change or hierarchy benefited from it, not because the page needed more movement.

VisualBookings: elements arrive one after another, in reading order.

(04) Pilot

Then the pilot starts giving better answers

Once the basics held up, interviews became more useful. The remaining questions were no longer all interface problems. Some were about the offer, some about language, some about who owned a benefit or how a business rule worked.

That distinction matters. If the concept is unclear, another tooltip is not always the answer.

1Problem

The offer wasn't understoodOne page, three readings: booking engine, loyalty scheme, travel tool.
Numbers without meaning“Up to 10%” was remembered, never turned into money.
Three cards, one visible difference: priceSame perks side by side. People chose on price.
The product assumed everyone books for themselvesIn 5 of 8 companies, someone books for the others.
Vouchers: who owns what?Company or traveller, who sees the code, what happens when someone leaves.

2What we recommended

Say what it does, and what it doesn'tScope first, then the chain: add a colleague → they book → points → perks.
Show the saving, in euros€250 a night → up to €25 back → up to €150 a year per traveller.
Describe each card by who it's forA traveller profile per card, not a list of perks.
Make the limit part of the setupSaid before sign-up, not discovered after subscribing.
Show the owner at every stepOwnership and exit rules in the flow, not in an FAQ.

3What we did

Pushed back, with evidenceLanding rebuilt with UX contentThe business had set its own vision for the page. We disagreed; the interviews showed what it cost. New page: scope up front, a worked savings example.
RedesignCards summarised by traveller type“For occasional travellers who stay at ibis” · “For teams travelling across Europe” · “For frequent trips to Asia”, plus a card recommended from the company's own stays.
Decision kept, made explicitThe limit, built into onboardingStated on the landing, at sign-up and in the onboarding wizard, as how the product works.
My proposal, not shippedA voucher you can followTwo separate balances, a visible voucher path, a masked code for admins, a clear choice when someone leaves.

The pilot was not a finish line. It was the moment the MVP became something we could learn from and keep building with a much clearer idea of what needed to change next.