Seatfrog Upgrades · Q4 planning
Five customer questions to answer. Three journeys to answer them in. You and the designer do the designing. The engineers come in afterwards to cost it and help set the order.
Take as long as you need on each part. Nothing here is on a clock.
Answer the five customer questions across three journeys, and build clickable prototypes of the answers.
Show them the prototypes, get each idea costed, let them change your order, then work out what you need from other teams.
The one rule for part one
We already know the current experience isn't good enough — that's the brief. So don't open the live app and improve it. Work out what the customer needs at each step, then design the screen that does that job, even if it looks nothing like what exists today.
Two practical consequences. First, if a better answer means throwing away a screen we have, throw it away. Second, when this goes to Liz's team, say plainly that it's a deliberate rethink — otherwise it reads as someone who couldn't match the existing design.
Send this before part one starts
If you design for two days without any sense of what things cost, you'll fall in love with something unaffordable and only find out in part two. Worse, an engineer might have known a cheap way to do it — but by then you've already committed to a shape.
Fifteen minutes of their time, in an email, fixes most of that. It also means the first thing they're asked isn't "price this finished thing we made without you".
Question one is the one that changes what you design. Nobody volunteers it, so you have to ask for it.
What you're solving
These five are the Q4 priorities from the opportunity tree. Three of them sit in journey 1 and can look like the same thing written three ways. They aren't. The quote next to each one is what a customer actually said, and it shows you a different problem each time.
Counts are how many of the five interviewees raised that specific point.
How might we help customers judge whether an upgrade is a fair deal?
Is this even a good price?
Raised by 5 of 5The problem: they have no way of telling whether £35 is good or terrible. There's nothing to compare it against — no sense of what it usually goes for, or what they'd pay at the station.
How might we make the value of first class obvious before they bid?
I'm not clear what I get with first class.
Raised by 3 of 5A different problem: this isn't about the price at all. They don't know what the thing is. You can't judge whether a price is fair when you don't know what you're buying.
How might we make the fee feel fair, not a penalty?
Why am I paying a fee on top?
Raised by 4 of 5A third, separate problem: here they had accepted the price, and then a new charge appeared near the end. The complaint isn't the £3 — it's that it turned up late, which makes the whole thing feel like a trick.
How might we help customers judge whether they can win?
How likely am I to win this bid?
Raised by 4 of 5The problem: they're trying to work out their chances from the number of bids showing, which tells them almost nothing. So they either bid blind or don't bid at all.
How might we make bidding clear enough that customers don't feel they have to bid late to win?
I've got a budget — I'll hold my bid to the end to keep it low.
Raised by 3 of 5The problem: people have invented their own theory of how to win, because we never explained it. That theory costs us money — a bid that arrives in the last minute is one we nearly didn't get.
This is five interviews, so it points in a direction rather than proving anything. Say that yourself when you present it, before someone else says it for you.
For each of the three journeys, write out the steps a customer actually goes through, from start to finish. Not the screens you have — the steps they take. Journey 1 starts with a notification arriving and ends with them back looking at results. Journey 3 doesn't end at payment, it ends at the ticket barrier on the day.
This is the bit that stops you only fixing one screen. That was the criticism of the last round of work: it looked at one place in the app and left everything either side of it alone. If a journey you've written down is only one screen long, you've written it wrong.
Then read the five customers' questions out loud instead of summarising them. And keep the live app closed.
Finished when: three journeys written out as a list of steps, and each of the five questions sitting under the journey that will answer it.Take one journey. Decide which two or three steps in it really carry the customer's question, and design those properly, from scratch.
Build three versions, and make sure they differ in one clear way you can name out loud. Three versions of the same idea with different colours teaches you nothing when you put it in front of a customer — three genuinely different answers to the same question teaches you a lot.
Use real content: real routes, real prices, real operator names. Fake content hides problems.
For each journey, name the thing you're borrowing from a company outside rail, and why it works there. "Like Airbnb" isn't an answer. "Airbnb shows you the full price including fees before you commit, so the fee never feels like a nasty surprise" is an answer.
Finished when: three versions per journey, and you can say in a sentence what each version is testing.Put all three side by side and read them as though one customer did all three in a week. Do they contradict each other? Have you accidentally designed the same thing twice in two different ways? Is there one idea underneath all three?
Something to test rather than assume: we sell the seat and the certainty, and the price comes second. If you and the designer can't both defend that, find the sentence you can. The CEO will ask what the thread running through it is.
Finished when: you can describe what the app is like after Q4 in five sentences.Put the work in the order you think it should happen, with your reason next to each item. Useful reasons: it answers the question the most customers asked; it makes the work after it easier; it doesn't depend on anything we don't already have.
Separately, list anything that needs something you don't control — photos of the cabins, video, menus, permission from an operator, a change to how payments work.
Take this into part two as your suggestion, and say that out loud when you show it. If you present it as settled you'll get polite nods instead of the better order you're actually after.
Finished when: there's a written order the engineers can disagree with, plus the list of things you need from elsewhere.Reference for part one
"Is it worth it?"
Notification or email arrives → opens the app, hasn't searched yet → sees the list of trains → looks at what first class actually is → back to the list
Aim forA customer can see what they're buying, and what it costs in total, before we ever ask them to bid. Today they can do neither.
"Can I win?"
One question, the biggest loss. Go deep here rather than wide — this is where the quarter is won or lost.
Picks a train from the list → opens the auction → tries to work out their chances → waits, sometimes 16 hours → auction closes → wins or loses
Aim forA customer knows where they stand without guessing from a bid count, and without sitting on the app until the auction closes.
"How does it work?"
Explanations currently live on a separate page full of text. People don't read those — they have the question while they're looking at the screen.
Confirms → pays → waits for the result → gets told they won or lost → travel day → the ticket barrier
Aim forA customer never has to leave the screen they're on to find out what's happening, and knows exactly what they've got before travel day.
Prototypes, not slides. The designer drives. Before each journey, read out the customer's question and the number of people we lose there — so what's being costed is a problem, not a screen somebody liked.
Say up front that these are deliberate rethinks rather than tweaks, so nobody spends the session asking why it doesn't match the current app.
The answers to the email you sent before part one. Do this before costing anything. If there's a cheaper way to do something, you want to hear it while the idea can still change shape. And anything that turns out to be much more expensive than you assumed gets said out loud now, rather than quietly buried inside an estimate.
For each one: rough size, which parts of the system it touches, and whether it's risky. Anything that touches pricing needs a named risk and a way to spot it going wrong.
Expect estimates to come back bigger than they need to be — they didn't design these, so uncertainty gets priced in. When something comes back large, ask "what would make this small?" Usually there's a smaller version of the same bet.
Show your suggested order with your reasons. Then ask them to move things. Three reasons that beat your ordering: something has to be built first for something else to work; doing one thing early makes later things much cheaper; something depends on content or permission that won't arrive in time.
Land on the order, and on the list of what you're not doing this quarter, with a reason for each. That list is what makes the rest of the plan believable.
Say this before you show your order: "This is a suggestion. Tell me what's wrong with it." Then ask each engineer for one thing they'd move.
One question. Everyone writes their answer down before anyone speaks, so the first person doesn't set the tone.
"It's 20 December. Everything we planned shipped. The number hasn't moved. What happened?"
Each answer becomes either something you change in the plan, or something you start measuring now. Most of them will point at something outside the room — which is what the last step is for.
Straight off the back of step 5: who outside this room has to do something, what exactly, by when, and what stops happening if it slips. Named people, named dates.
That last part is what turns a wish list into something the CEO can actually decide on.
The thing most likely to sink this
Most of the good answer to "is it worth it?" needs real content from the train operators that we don't currently have: video of the carriages, proper photographs, menus, lounge rules — per operator, kept up to date, owned by someone with a name. A competitor can copy a layout in a fortnight. They can't copy content the operators have signed off. So treat it as a commitment with an owner and a date, not something you discover in October.
Things to watch for
| If you notice | What's actually happening | What to do |
|---|---|---|
| Yourselves opening the live app "just to check" | The old design creeping back in as the starting point. It only takes one look for the next hour to become a tidy-up. | Close it. If you need to know how something works today, say it out loud from memory — that's usually enough, and it keeps you designing from the problem. |
| You and the designer agreeing quickly, all day | The main risk of a two-person session. Two people who already agree end up somewhere lovely and still narrow. | Sketch separately before you discuss, every time. And show the prototypes to one outside person before part two — Ben would be useful, because he'll challenge whether the numbers say what you think they say. |
| An hour spent on a single screen | It's the comfortable screen. Meanwhile the steps either side of it stay undesigned. | Ask "which other steps in this journey does this change?" Then move to the weakest step in the journey. |
| Ticking off the five questions one by one | Five questions turning into five separate features. That's the narrow thinking coming back in a new form. | Reread the three quotes in journey 1. They're three different problems, but one screen that shows the product, the total price and the fee together could answer all three at once. |
| Engineers agreeing with your order | Either you got it right, or you presented it as already decided. | Ask each of them for one thing they'd move. Silence here is a warning sign, not agreement. |
| Ideas that are mostly animation and polish | Making it look nicer standing in for making it better — and the "premium and exciting" outcome is parked anyway. | Ask "would you still build this if it didn't change conversion at all?" If yes, it's a brand decision, which is fine if you say so. If no, name the number it's meant to move. |
The proposal needs two halves: a much better version of the product, and a realistic order for building it.
Part one gives you the first half. Part two gives you the second, plus the honest list of what you're not doing — which is the bit that makes the ambitious half believable.