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, didn’t need a better calendar. She needed to know what to do first. I designed and built a mobile-first overview that opens on Budapest’s overdue translation and still shows every document without losing her place.
Problem
Remembering dates was never the problem.
Priya is applying to Riga, Budapest, Pilsen, and Zagreb: the same four phases, different deadlines, different exceptions. A reminder can tell her something is late; it can’t tell her what matters most across four applications.
- 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.
Proof
On March 10 the right first answer isn’t a percentage: it’s Budapest’s translation, due March 1, nine days overdue.
My assumptions and open questions
What I assumed for the prototype
- One priority queue beats four separate home screens.
- March 10 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 each structure against Priya’s March 10 state. Each one could show the data; none told her what to do next without making her hunt for it.
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.
- 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 it cost
Risk-first feels less comforting than progress-first. I took that on purpose: hiding the missed deadline would feel calmer and help her less.
What I decided
Teach the system before the first surprise.
Three short screens teach what the overview depends on: the four phases, the lead times, and why one action comes first.
- The overview stays mounted underneath, so replaying onboarding never wipes progress.
What it cost
Onboarding delays the first task, so she can replay it.
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.
- 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.
What it cost
Coding it cost time a static screen would not have. I paid it, because state is the design problem here.
Proof
Complete Budapest, and Riga’s exam registration moves up; reopen a document and it goes back to its phase.
See the token chain
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 put the priority rule in front of real applicants before building more: it ranks on status and date only. A real service also needs submitted, received, and accepted states, a source for every deadline, and the recovery policy from the university.
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
