I made the delivered price part of choosing a book.

The lowest item price leaves a question open

In the specimen below, a new book costs PLN 39. Delivered, it costs PLN 50.99, and its estimated arrival runs past Friday.

A second seller charges more for the book. Its arrival range is earlier. I invented both offers around a real title so that the decision could be inspected.

I built this independent concept for a buyer who already knows the edition and needs it by a particular day, and the design keeps that edition in view while they compare condition, seller and the amount payable for the delivery method they’ve picked. The comparison can also end honestly: none of the available offers may meet the requirement.

My evidence is a small anonymous inspection of Empik, on desktop and at a 390-pixel phone width. It covered:

• search
• one art-history book and the offers from its sellers
• the delivery information
• the basket

I had no customer interviews, internal analytics or orders, so what this case offers is a working proposal and an evaluation plan without a measured conversion result.

I narrowed the work to a comparable offer

The first brief reached from discovery all the way to checkout. Finding a book and paying for it go wrong for different reasons, and if I’d changed both at once, I couldn’t have told which change helped. So the working prototype covers one decision. The question is which seller to buy from, with one book and one copy held constant.

In this model an offer is four things: the requested edition, the copy’s condition, a seller and a quote for the chosen delivery method. Its price is the book amount plus that delivery charge. The fixture has no membership, app coupon or payment promotion, which keeps every example answerable, though a production version would need the real rules for each benefit and fulfilment group.

The title, Susie Hodge’s name and the hardcover binding come from the inspected product, while the seller identities, prices, fees and arrival ranges in the prototype are all fictional. The record points to that page and doesn’t invent an ISBN. Matching editions for real would take a verified identifier and catalogue reconciliation before another seller’s copy could join the same comparison.

With courier delivery by Friday, two new copies qualify. Book Table has the lower item price. Its delivered total is higher: PLN 62.99 against Paper Window’s PLN 56.99. Book Table also has the earlier estimated window. The list shows the arithmetic and keeps the timing difference beside it, so “cheapest” can’t stand in for every buying preference.

A used copy only becomes eligible once the buyer accepts that condition. The requirement changes in the open, and the edition stays the same.

Open Index has an attractive item amount and an incomplete delivery quote, so it can’t enter the qualifying ranking. The missing information stays beside that seller with a next step. It’s never converted into a free delivery fee.

A larger interface has to earn its place

A comparison list makes differences visible. It also gives people more to read. Someone buying from a seller they already know might only need a clearer summary on the product page.

I kept that smaller intervention in play as a serious alternative and held it to the same decision requirements, since liking how the list looks would be a poor reason to choose the more expensive integration.

Changing a choice should change the explanation

Switch to collection, and the charge, the wording of the date and the available sellers all change. In this proposal, delivery belongs to the offer itself.

If the selected offer still qualifies, it stays selected. If it stops qualifying, the summary asks for a new choice and the seller’s row explains the mismatch.

On a phone, each row becomes a complete vertical record. A few implementation decisions sit behind that layout:

• The price keeps its own place beside the seller; arrival and the reason for exclusion follow in reading order.
• Native selects and buttons support keyboard operation.
• Result changes use a polite announcement.
• No overlay or sticky purchase control covers the comparison.

All four still need verifying, and none of them amounts to a claim of universal accessibility.

Synthetic critique can challenge the rules

I asked an AI reviewer to test the rules from four deliberately different positions:

• a buyer working to a deadline
• a buyer on a budget who’s willing to collect a used copy
• a buyer unfamiliar with marketplaces
• someone changing delivery by keyboard

These were constructed perspectives; no persona research took place. The reviewer received the mechanics and the fixture answers. It never observed people using the interface.

It challenged the deadline wording, the incomplete quotes and the lost context when a choice stops qualifying. I changed the prototype in response:

• The conservative date rule now sits beside its control.
• Incomplete quotes carry their own label.
• After a selection is cleared, the previous seller stays marked.
• The collection limits and the reset destination are explicit.

These changes answer a review of specified mechanics. Comprehension and trust still need observed tasks with people.

A separate AI review looked at the actual desktop screenshot. It found a visual conflict: excluded low totals carried the same weight as qualifying ones. I reduced their emphasis, put a compact exclusion beside each affected total and gave disabled choices a distinct label. The restriction now sits close to the amount that could attract attention, and whether buyers notice it is a question for the human study.

I would compare correct decisions before conversion

Before anyone counts orders, I’d want to know whether buyers make the right choice. The plan starts with the interface as it is.

First, six sessions with the current interface

The next research round would begin with six moderated baseline sessions. I’d recruit Polish-speaking people who’ve recently bought books online, across purchase frequency and digital confidence. Their tasks would ask for a specified edition, a delivered total and a choice for a given deadline, and a pilot would check the wording first. No one would be asked to pay. A simulated basket would replace any task that approached a transaction.

Those sessions should establish whether the comparison problem recurs. If the current interface already supports correct decisions, I’d reduce the proposal. If catalogue ambiguity causes the failures, the first intervention belongs in edition identity, because a clearer list can’t repair an unreliable catalogue or a missing delivery quote.

Then a comparison with the proposal

Only after that baseline would I run a directional comparison with 12 new participants. A faithful reconstruction of the current interface and the proposal would use matched scenarios of equivalent seller and delivery complexity. Four balanced sequences would vary which version and scenario each person sees first. That reduces some order effects. Learning stays a limit of the study.

What counts as a correct decision

The answer key would accept the intended edition and condition, a qualifying delivery choice and the correct total. It would equally accept the correct recognition that no offer qualifies. I’d record assistance and arithmetic errors separately. Each task would be timed from reveal to final answer, with its completion status beside it, so a fast wrong choice would remain a failure.

The gate for going further

My provisional design gate is that at least 10 of 12 participants explain the knowable total and the edition and condition choice correctly, with no unresolved false promise about price or arrival. Two people repeating the same serious misunderstanding would send the design back for revision.

These are local criteria for the next design decision, and they wouldn’t estimate population preference or establish a commercial effect.

A production experiment needs reliable quotes and an owner

A real test would need Empik’s participation. It would also need an agreed implementation and authoritative order data. My first job would be an audit of the events from product entry through comparison, basket and checkout to the paid order, including retries and orders from several sellers. GOV.UK’s completion guidance is a useful discipline here, for deciding where a transaction begins, where it ends and what enters the denominator.

The first experiment should isolate the selected offer summary from any change to search, promotions or checkout. Microsoft’s experimentation guidance supports a falsifiable hypothesis, suitable assignment and data-quality checks. For this proposal, that comes down to three rules:

• Eligibility is decided before rendering.
• Each visitor keeps a persistent assignment.
• Every eligible assigned visitor stays in the analysis, including people whose comparison failed to load.

A candidate primary measure is the share of eligible assigned visitors with a paid physical-book order within seven days of first eligibility, and the analysis would wait for those outcome windows to mature. Contribution per eligible visitor, cancellations and delivery-related contacts would constrain a commercial decision, alongside quote errors and page responsiveness. Seller distribution and any displacement of app or Premium purchases would need owner review.

I haven’t set a sample size or duration. Both depend on a baseline and an acceptable commercial loss, and neither is available. The owner would need to agree both before launch, then define a staged rollout and rollback triggers. A readable comparison still wouldn’t be fit for release if quote accuracy failed or the commercial guardrails worsened.

If complete quotes can’t be supplied, I’d carry the smaller product summary forward and defer the full list.