Vianney Bertrand
Let's talk
MenuLet's talk

Case study · Working prototype

Compare a hotel's purchases with Accor's negotiated prices.

From an invoice, the tool proposes products from Accor's catalogue and calculates possible savings. I redesigned the flow with buyers and sales people so they could check the proposed products, correct the comparison and choose when to validate it. I then delivered a React prototype taken over by the developer.

Client
Accor
Role
Product designer · Design engineer
Period
May–June 2026 · Four weeks
Benchmark view: a dense table where each line stacks the invoiced product and the catalogue product, with badges showing the type of catalogue proposal, supplier, prices, the saving of each line in euros and as a percentage; invoice and catalogue totals in the footer
The benchmark view as delivered. Invoice above, catalogue below in every cell, the saving of each line in euros and as a percentage; the total follows in the footer. Invented demonstration data.

The starting point

Accor negotiates prices with suppliers. To convince a hotel using its invoice, sales people need to show credible savings. The existing tool is difficult to scan; one sales person uses it only to turn invoices into spreadsheets, then compares products manually.

The product manager has already built a clearer prototype. The brief calls for mockups and a design system. Over four weeks on site, I met two buyers and a sales person, designed and coded a React prototype on the target stack, then handed the repository to the developer. The interviews made checking proposed products central to the flow.

01Invoice review

Correct the invoice before comparing

The extracted invoice data is used to compare products and prices. I placed the original invoice on the left and its extracted lines on the right, with values editable in each row. Comparison starts only after this review.

The source stays in view while the user makes corrections. This arrangement replaces checking in another tab or in a window overlaid on the tool.

Review screen before comparison: on the left the preview of the original invoice, on the right the table of what was read from it, reference, product, quantity, unit, weight, unit price and total per line, with the invoice total at the bottom and the button that launches the comparison
The invoice and its reading on the same screen. What was read is used to compare products and prices, so you correct it first, here, with the invoice in view.

02Reading the table

Compare products in the same columns

The product manager’s prototype displayed products as cards. I chose a compact table: invoiced information sits above the proposed product’s information in the same columns. Prices and quantities can be compared without moving between cards.

Both buyers interviewed preferred a dense view so they could scan more lines at once, as in their spreadsheet. This preference guided the table’s organisation.

Six table rows in close-up, with two markers on the first: the top line is the invoice, the bottom line the catalogue. In every cell, the invoiced value above, the catalogue value below, with supplier, reference, quantity, unit price, amount and saving
Both products in the same columns: the invoice above, the product proposed by Accor below.

03Choosing products

Correct a proposal without distorting the result

A proposed product may not be suitable. The buyer can choose another alternative or keep the line without assigning it any savings. When the catalogue is more expensive, the difference remains visible. The comparison retains both products without equivalents and less favourable prices.

The interviews reframed the problem: a readable comparison can still be misleading if the products are not equivalent. One buyer preferred the tool to acknowledge that no alternative was available rather than force an unsuitable match.

Keeping a line without a suitable equivalent: it stays in the benchmark without an assigned saving.
Find less favourable lines
Finding the lines where the catalogue is more expensive and those outside the catalogue.
Change the comparison criterion

Identical, listed or lower-priced products: profiles re-rank alternatives already found, and totals update accordingly. The product manager clarified that this change should use precomputed results. I dropped the idea of rerunning the search each time the criterion changed.

Switching criteria. Everything is already computed: lines re-rank with no wait and the total says at once what the choice is worth.
When the buyer sources an alternative

In the 16 June test, the buyer explained that he sometimes has to ask a supplier for a price himself. The prototype lets him add this proposal to an existing line’s alternatives, then select it for comparison. This completes an invoice line; it does not create a purchase absent from the invoice.

Prototype limitation: the added alternative can be lost when rows are reset, including when switching profiles. This behaviour needs to be addressed during integration.

04Sharing the comparison

Export work in progress, validate when finished

Exporting and finishing are different actions. I let the user choose at export: keep an editable benchmark or validate it. Once validated, the result becomes read-only and tools that could change the comparison disappear.

During the test, the buyer rejected automatic validation on export: he often revisits a comparison after exporting it. Validation must reflect the point when he considers his work finished.

Export and keep working

“Still working on it” exports a copy. The benchmark remains editable.

Export and validate

“I’m done” validates the result. The benchmark becomes read-only.

The “I’m done” path: after export, the badge changes to “Validated (read only)” and comparison profiles disappear.
The three application states
The three entries of the personal space. Validating is a deliberate act, and it is what separates work in progress from what went to the client.
Flag a difference for renegotiation

A line can be flagged for renegotiation with a comment for the category manager or client. The flag remains editable in a validated benchmark: it communicates information without changing the figures. Annotation persistence remains a limitation of the deliverable.

The flag and its note. For the category manager who will renegotiate the line, or for the client to whom a gap is explained.

Delivery and observed outcomes

The head of sales validated the direction early in the mission. The web developer took over the repository handed over the day before I left, with the backend and real data still to integrate. Before this mission ended, the same client had commissioned a second prototype: Drink Menu Compliance.

One recorded user test was conducted with a buyer, and his feedback was integrated the next day. His reaction concerns a prototype with fictional data, not production usage: “If it’s that simple every time, it’s brilliant.”

The structure handed to the developer

React 19, TypeScript and Vite, using the client’s design system tokens. Eleven test files cover calculation logic. Five decision notes, error states and open issues accompany the repository. A single data-access module shows the developer where to connect the real engine.

A single module talks to the backend. The contract tells the developer where to plug in the real engine; the prototype's automatic comparison is marked as scaffolding.

The limits

Fictional data, simulated comparison, no backend or real authentication. A per-line confidence score was not built. Annotations and added alternatives have persistence limitations. Only one user test is documented, with no field sales person.

What I would do differently

I would put the prototype in front of a field sales person by the second week. The documented test was conducted with a buyer, later in the mission.

Discuss this project →

← Back to home