University-first cards
Budapest’s late translation could sit below Riga’s finished documents.
Four applications. One action that can’t wait.
Priya, the applicant in my demo, needed to know what to do first. I designed and built a mobile-first overview that opens on Budapest’s overdue translation.
Problem
Remembering dates was never the problem.
Priya is applying to Riga, Budapest, Pilsen, and Zagreb: four phases, different deadlines. A reminder tells her what’s late, not what matters most.
Proof
On 10 March, the first answer is Budapest’s translation, due 1 March: nine days overdue.
My assumptions and open questions
- Knowledge gap: she starts out not knowing the phases or the lead times.
- Overview gap: four timelines make the whole picture hard to see.
- Priority gap: a missed document has to outrank reassuring progress.
What I assumed for the prototype
- One priority queue beats four separate home screens.
- 10 March stays fixed, so every reviewer sees the same overdue state.
- 14 days counts as due soon. It is a demo threshold, not a validated rule.
- Ticking a task off shows the interaction. It does not submit anything real.
Questions before production
- After a missed deadline, what can the product safely recommend?
- Where does deadline data come from, and how fresh is it?
- Who owns in-progress work: the student, the translator, or an advisor?
- Can an applicant read their status in under 10 seconds?
What I found
Three tidy structures failed Priya.
I ran three structures against Priya’s 10 March state. Each showed the data; none told her what to do next.
Phase-first matrix
The certified translation turned into a red dot instead of the thing to submit.
Generic status dashboard
“8 documents open” is analytics. It isn’t a document, a university, or a deadline.
What I decided
Urgency first: name the action, then the context.
The overview opens on the one thing that can’t wait, then every open document in order of urgency, then all four journeys.
What it cost
Risk-first feels less comforting. I chose it: hiding the missed deadline would feel calmer and help less.
The notes behind this
- Every open document stays named; status and deadline set the order.
- All four journeys stay visible, including Zagreb’s no‑exam exception.
- The overdue task is packaged for support, without inventing policy.
What I decided
Teach the system before the first surprise.
Three short screens teach the four phases, the lead times, and why one action comes first.
What it cost
Onboarding delays the first task, so it stays three screens and can be replayed.
The notes behind this
- The overview stays mounted underneath, so replaying onboarding never wipes progress.
What shipped
One screen, built around the next decision.
I coded the overview on Priya’s data, so you can finish tasks, open each university, and watch the priority recalculate.
What it cost
Coding cost time a static screen wouldn’t, but state is the design problem here.
Proof
Complete Budapest, and Riga’s exam registration moves up; reopen it, and it comes back.
See the token chain
- Every action is reversible; focus moves and changes are announced on every state change.
- One data model gives one reading order on phone, tablet, and desktop.
- Five states share one set of components: overdue, due soon, in progress, done, upcoming.
Every value is named three times: what it is, what it means, and where it is used.
teal-500 · space-4 · radius-lgcolor-brand · color-danger-surfaceaction-overdue-bg · card-padding
Looking back
Next, applicants test the priority rule.
Next time I’d test the priority rule, which ranks on status and date only, with real applicants before building more.
Beyond the brief
The brief asked for an overview; I built the decision behind it, coded it, and reviewed it for accessibility and trust. That review caught a recovery promise the product had no basis for, so I cut it and added a support handoff. GitHub Copilot wrote the fixtures, components, and state transitions; I chose what it built and cut every suggestion that invented policy.
See what the review cut
