Settle

What made this hard

The information is not missing — it is published, accurate and free. That rules out the obvious product, which would be another list. It also means the design has to earn trust against GOV.UK without impersonating it, and has to be useful to someone whose situation may not match the sequence I experienced. The hard part is establishing whether hidden ordering really is the cause of the pain, or whether the pain sits somewhere else entirely — appointment availability, language, or simply not knowing who to ask.

Research & discovery

Research status — Live. Survey open, interviews being recruited from it, competitive review underway. Findings will replace this section as they land.

Who

Three methods, all with students who arrived within the last twelve months so the memories are still specific: a short survey distributed in an international-student group, targeting 20+ responses; five 15-minute interviews recruited from that survey, each reconstructing one person's actual day-by-day sequence and the moment they got stuck; and a competitive review of GOV.UK's post-arrival guidance, UKCISA, university welcome pages, Monzo and Starling onboarding, and Student Beans and UNiDAYS as student-specific products.

Investigated

Three hypotheses, each written so it can be proved wrong. H1: most students do not know the correct order of tasks on arrival — falsified if fewer than half score the order as unclear. H2: the bank account is the most painful task, and the cause is proof of address rather than the bank — tested against the stress ranking and the free-text reasons. H3: students trust peers over official sources, so the product has to read as advice rather than policy — tested by comparing where information actually comes from against how much it is trusted.

Still open

Whether the dependency map below survives contact with real arrivals. It is modelled from GOV.UK, UKCISA and university guidance rather than from anyone's lived sequence, which makes it a hypothesis and not a finding — halls residents, students with family already in the UK, and anyone arriving mid-year may have a completely different critical path.

Next test

Close the survey, run the five interviews, and either confirm the ordering hypothesis or follow the pain wherever the data actually puts it. If H1 fails, the product changes rather than the framing.

Key decisions

1. 01

   Model the tasks as a dependency graph rather than a list — the unit of design is the edge between two tasks, not the task itself.

2. 02

   Show the next unlocked step, not everything at once. A blocked step states what unlocks it, so a dead end becomes a direction.

3. 03

   Attach a 'take with you' list to every appointment. Nobody should be turned away from a counter for a document nobody told them to bring.

4. 04

   Explain GP, NI number and council tax once, in plain English, at the point they first appear — UK-specific vocabulary is a barrier before the admin is.

5. 05

   Write in the voice of a friend who has done it, with the official source linked underneath: trust without pretending to be GOV.UK.

What I explored

The provisional journey map runs seven stages across 30 days, each with what it requires, where it typically fails and a pain rating, drawn from published guidance ahead of arrival. The three rated highest — the proof-of-address letter, the bank account and the eVisa account — are the ones the dependency map marks as blockers, which is the pattern the research is designed to confirm or break.

Scope & context

• Product scope

  7

  Core tasks in scope for v1

• Product scope

  3

  Falsifiable hypotheses going into research

• Product scope

  3

  Methods — survey, interviews, competitive review

• Company-reported traction

  685,565

  International students in UK higher education, 2024/25

  HESA, published January 2026 — context for the problem, not a figure about this project

Evidence

What exists today is the study design and the problem model: a dependency map, a seven-stage journey map with pain ratings, three falsifiable hypotheses with their measurement criteria, and a scope boundary. No outcomes are claimed because none have been measured yet. This page is deliberately published in that state — it shows how I work before I have answers, which is the part of the process a finished case study usually hides. It will be updated as findings land.

What I would improve next

The honest risk is that I have modelled this problem from documentation rather than from anyone's experience, including my own. A dependency graph drawn from official guidance describes how the system is supposed to work, not how it fails. The study is built to attack that: the hypotheses are written to be falsifiable, the interviews reconstruct each participant's actual sequence rather than checking mine, and the survey asks what was hardest before it asks about ordering at all.

With more time

With longer than four weeks I would widen past the single persona — students arriving with dependants, mid-year arrivals and undergraduates all have different critical paths — and test whether the dependency model holds outside one university's processes. I would also want to know whether a product like this should exist at all, or whether the right intervention is the university sending the right thing at the right time.