Prototype set · drafts to test with customers, not a decision · 22 Oct 2026 · owner: Aaron
Where should a customer tell us when they're travelling?
An internal page for anyone at Seatfrog. It shows one customer problem, four ways we might solve it, and what we don't yet know. Nothing here is built or approved. If you want to react, comment on the Notion page or message Aaron.
The problem: search takes a route and a date, so results list the whole day and the customer scrolls to find the train they already hold a ticket for. The set: one results list, one journey, one task ("find the 18:00"), built four ways that differ only in where the time is captured: nowhere, on the search form, on the results list, or never (a coarse jump instead). This page is the presentation, not the prototype: every variant links to its clickable build, and the screens below are those builds embedded live.
1 axisWhere the time is asked for. The list, the rows, the prices and the time sheet are byte-identical across files; the build fails if they drift.
1 task"You hold a ticket for the 18:00. Find it and tap Upgrade." The 18:00 is the 25th of 28 trains, four screens down in control.
3 mechanismsTrainline's time sheet, Citymapper's "Leave: now" pill with Omio's "view earlier", Airbnb's filter chips used as a jump.
0 real pricesTimetable shape is real. Every upgrade price is invented and says so above the device.
The problem, in plain words
HMW make it easier to search for a journey by time
What happens today
You search by route and date. There is nowhere to say what time you're travelling. Results list every train with an auction that day from the earliest onwards, three or four to a screen. To reach an evening train you scroll past everything before it.
Most people searching already hold a ticket, so they know the exact time. We make them hunt for it anyway. And because they never tell us, we only learn which train they wanted if they pick one.
What we know, and from where
About 82% of people who start a search already hold a ticket. Gated search test, Apr to Aug 2026.
21% of people who reach results don't pick a train (314,090 to 248,786). Amplitude, iOS, six months, directional.
Power users pick a train 96% of the time; everyone else 78%.
One screen recording of the app, 22 Oct 2026, showing the scroll.
What we don't know: how far people scroll, how often "Can't see your train?" is tapped, and whether the drop is worse for later trains. Those three decide whether this is a finding problem at all. See the open questions below.
The same list, four ways
Axis: where the time is captured
King's Cross to Edinburgh, Fri 23 Oct, 28 LNER trains. Each phone below is the live prototype at the moment under test. Tap inside it: they work. Open the full-size build from the link beside each one; that is what goes in front of a customer.
Mechanism. None. This is what ships today, rebuilt from the 22 Oct recording with the kit's single-CTA row.
H
Hypothesis. None to test. It is the baseline the other three are measured against: how long it takes, and how many scrolls, to reach the 18:00.
A
Assumptions. That people scroll rather than give up. We have one recording and no scroll-depth data. Ask Ben for both before reading any result against this.
Mechanism. Trainline's outbound time sheet: Now / Depart / Arrive and a wheel. Results open on the nearest train, ringed, with the rest still there. Asking before the list means the list can be built around the answer. It is also the only variant that captures the searched time as data.
H
Hypothesis. If people are asked for a time before they see results, most will give one and land on their train without scrolling, because they already know it.
A
Assumptions. That the field gets used. It is optional, and an optional field on a form people rush through is often skipped. Watch the skip rate before the landing behaviour. Same renderer as D, so A against D is a clean test of placement.
Mechanism. Citymapper's "Leave: now" pill sits on the results screen, so the time is changed where the consequence is seen. Omio's "view trains before 08:00" keeps earlier trains one tap away instead of hidden. Search is untouched.
H
Hypothesis. If the time control sits next to the list, more people will use it than a field on the form, because the need to narrow the list is felt only once the list is in front of you.
A
Assumptions. That hiding 24 earlier trains behind one button reads as help, not as the app losing trains. That is the kill condition from the Aug set's variant C, and it applies here. Captures the time too, but only for people who tap.
Mechanism. Airbnb's filter chips, used as a jump rather than a filter: one tap scrolls to Evening, nothing is removed, and the selected chip follows the scroll so it never lies. Three taps of effort at most, no wheel, no form.
H
Hypothesis. If the list has coarse jumps, people will reach their train about as fast as with a precise time, because they only need to get close and read the last few rows themselves.
A
Assumptions. Captures no time at all, so it answers the customer question and not the data team's. If E wins, the data capture has to come from somewhere else. This is the cheapest build in the set.
Control in one sentence
Nothing is asked; you scroll the day.
A in one sentence
You are asked the time before you see the list.
D in one sentence
You set the time on the list, and the list moves.
E in one sentence
You tap a part of the day and the list jumps.
Distinctness, checked: four sentences, four different first actions. A and D share one renderer on purpose, so what separates them is only where the time was asked.
What nobody has answered
Stated as prominently as the proposal
Question
Why it decides something
Who settles it
How far do people scroll on results today, and how often is "Can't see your train?" tapped?
If most people select within the first screen, this is not a finding problem and none of these should be built.
Ben, Amplitude, directional
What share of searches already hold a ticket for a specific train?
About 82% held a ticket in the gated search test (Apr to Aug 2026). Whether they know the exact time is assumed, not asked.
Ben, same test
Is the results drop (21% don't pick a train) worse for later-in-the-day trains?
If it is, scrolling is implicated and A or D is the bet. If it is flat, the drop is about what the rows say, which is a different HMW.
Ben
Does the data team want searched time at all, and alongside what?
Only A captures it reliably. If the answer is "yes, essential", E and control are not candidates.
Data team
Can the live results screen carry a second row of chrome?
D and E both add a strip above the list on a screen that already has a banner and a floating button.
Liz's team
Read before approving
Drafts to test, not final design; Liz's team owns production. Upgrade prices are invented. The rows use the App Kit's single green CTA, not the live two-button row with watchers and bids, so the row is simpler than the app's (App Kit note, 2026-07-27). The light body is a local derivation because the kit has no on-light tokens (gap 4). Tokens are provisional and the font is a system fallback. The Risk-free banner and the floating "Can't see your train?" button from the live screen are not rebuilt here; they would take space from every variant equally. The Aug 29 set in Upgrade Availability - Add Time to Search tests a different axis (what results do with a time set on search) and is still valid; A here is that set's variant A on new content.