Stu Ford — Product Design Lead
Boden × Harper
01 — Research tooling · 2026

Mapping, testing and launching a try-before-you-buy service

The problem

Validate a seven-day, three-channel service before a line of it was built — inside a one-hour session, and convincing enough that people reacted to it rather than described it.

Tested with 20 users Across two rounds, desktop and mobile
My role
  • Mapped the service end to end — nine stages, five parties, front and backstage
  • Ran the live service as a customer, through a retailer already using it, to find the gaps first
  • Translated the partner's designs into Boden's design language, using our UI kit
  • Coded a device rather than linking screens — three working apps and a clock the facilitator could move, specced with our UX Researcher
  • Fed into the discussion guide, then played findings back to Harper's Head of Product as well as our own teams, and worked with Research, BAs and developers to get the changes built
Outcome
  • Boden's first AI-built prototype — the practice, and the coded UI kit, grew out of it
  • The service launched on schedule, with the problems we found already fixed
  • A reusable framework — cross-channel studies we could not previously run are now routine
  • A stronger, more confident relationship with the third party
Channels
  • Web
  • Email
  • SMS
Built with
  • Figma
  • Claude Code
  • Netlify
When April – August 2026 Boden with Harper, a third-party service partner
01 — Understanding it

I mapped the service, then ran the journey myself

I mapped it end to end

I blueprinted the journey first — nine stages, five organisations, front and backstage. Confidence drops at exactly the two points the customer can see nothing — checkout, and the final charge. And most of what happens to them is triggered by a system nobody at Boden owns.

Service blueprint across nine stages: customer actions, emotional state scored per stage, touchpoints by party, a line of interaction, frontstage activity, a line of visibility, backstage systems including Shopify, the returns portal, Ometria and Snowflake, and a pain points row.
Emotional state is scored per stage, so the dips are visible rather than argued about.

Then I became a customer

The service already ran for other retailers, so I placed real orders through one of them — my own money — and logged every message for the whole trial. It turned up problems before any Boden customer would have hit them.

  • The service partner is never named on the confirmation, in account pages or in the emails — the first you hear of them is when they take your money.
  • A £1 authorisation charge with no warning that it is coming.
  • "Refund" used for money that had never been taken.
Research board: a message-by-message log of a real order placed through a retailer already running the service, a day-by-day comms diary, captured journey screens, and where the service is signposted.
Every message from a live implementation, logged by day and sender.
What participants said later

"Who is Harper? I thought this was Boden." — the exact gap those orders had already predicted.

02 — Exploration

What I tried first

A Figma prototype with five linked mobile screens and a tangle of blue connector lines running between them.
Not taken forward.

A Figma prototype per channel

Brittle. Linked prototypes at this scale break in ways that are easy to ship into a session — one change could take it down mid-study.

Five of the emails laid out flat and side by side for review — order confirmation, order confirmed, shipping confirmation, more pieces on their way, and try-on period started — each annotated on its own.
Answered the wrong question.

Test each message on its own

Every email reviewed in isolation. They all read fine that way — which was never the question. What we needed to know was whether someone four days in could tell what had happened and what was coming.

The device home screen: Mail with eight waiting, Messages and Browser live, and five apps deliberately dead.
This is what shipped.

A device that isn't a phone

One coded simulator, home screen, three working apps. OS-agnostic on purpose — so nobody is really reacting to someone else's operating system.

03 — The brief, and the artefact

What the prototype had to do

I specced it with our UX Researcher: half the list is what the study had to cover, half is what a facilitator needs in the room. Code rather than Figma meant changes were quick, safe and version-controlled — so we could always answer the question that quietly ruins qualitative research: which version did this participant see?

  • OS-agnostic — familiar enough that nobody was thinking about the device.
  • Notifications that fire on action, not on a timer.
  • A way to skip forward in time, so a seven-day journey fits inside an hour.
  • An admin panel to jump to any stage without working through everything before it — a facilitator ask, and the feature they used most.
  • Auto-fill disabled, so nobody revealed their own address or card details to an observer.
Try the real thing
Open Browser, place a trial order, then check Mail and Messages. Settings opens the admin panel the facilitator used. Best full screen — open the prototype in a new tab →
04 — Findings and delivery

What we found, and what shipped

The problems were not where the service was complicated. They were where it was unfamiliar.

The comprehension study board: twelve questions scored Yes, Somewhat or No for each participant — from whether they recognised Harper or Try Before You Buy, through charge expectation and trial terms, to whether each cancellation email was understood.
Twelve comprehension checks, scored for every participant. Row one — whether anyone recognised Harper or Try Before You Buy — is where the first finding below came from.

An email from a company they had never bought from read as a scam. We introduced the partner in Boden's own order confirmation — named as our trusted partner, with the exact address their email would come from — so the first contact was expected instead of alarming.

“Just add a button to the mini bag”

It sounds like a small ask, and everyone agreed it was. But space in the mini bag is at a premium — everything in it has to earn its place — and it is the last thing a customer sees before deciding whether to go through with an order. It is a fixed height, and the OS and browser take a slice of that before the page gets any of it — the status bar at the top, the address bar at the bottom. So rather than add the button, I worked out what it would cost first.

Before — one button
The mini bag as it was, at real viewport height: two products, a delivery message, subtotal and a single Checkout button.
With Try Before You Buy added
The same bag with a Try Before You Buy button and a line of supporting copy added below Checkout.
After the rework
The reworked bag: a smaller uppercase title, product detail merged onto fewer lines and set in grey, stock messaging absorbed, and the delivery message reduced to a single slim band.

The products are what the panel is for, so that is what I protected. Everything around them gave a little instead — and where I did touch a product, it was to let the name and the price come forward.

  1. Heading reset in our new heading face. It holds the same presence at less size, so the padding around it could come down too — height off the top of the panel without losing the balance.
  2. Colour and size dropped to the secondary text colour, and down a size. They sit below the product title and the price in importance, and were being set as though they didn't.
  3. Delivery threshold banner scaled back. Smaller, progress bar removed — but switched to our success green, so what survived still reads as good news rather than just less of it.
  4. Bottom padding under the payment marks cut. Worth a few pixels on its own; worth having when there is this little to go round.

The button went in. The panel came out of it with more room for products than it had before anyone asked for one.

Research prioritised the two rounds, the BAs turned that into requirements both teams could build from, and I worked with the developers through the build. The service launched on schedule, with the problems we found already fixed.

The customer win

Customers never met any of it.

Everything we found was fixed before launch, rather than reported afterwards by someone it had already happened to.

The internal win

We came out of it with a foundation, not just a prototype.

Because it is configured rather than rebuilt, the next cross-channel study starts from something that already works.

05 — Unprompted

The reference Customer Service now uses

Demoing the journey to the Customer Service team made something obvious: there were far more messages in this service than anyone on a call could hold in their head, and an agent hearing "I got an email saying…" had no way to place which one, or where it put that customer in their trial.

Nobody asked me to solve that. But building the prototype had already left me with every message in sequence, so I turned it into a reference they could work from — the flow end to end, with a visual of each of the seventeen emails beside it.

Page one of the reference: the Harper Try Before You Buy email journey, grouped into the happy path, the three outcomes at the end of seven days, delivery and cancellation exceptions, and payment problems, with a colour key. A per-email page from the reference: Order Confirmed, email 02 of 17, with its subject line, when it is sent, what the customer needs to do, and a thumbnail of the email itself.
Two pages from the reference — the whole journey grouped by where it falls in the trial, then one page for each of the seventeen emails.
Next case study — 02

From rebrand to repo →