Four applications. One action that cannot wait.

A prioritization problem, not a calendar problem: a mobile-first overview that starts with Budapest's overdue translation, then lets Priya see every document without losing her place.

Project
FutureMBBS design challenge
Role
Product design and front-end
Submission
Process case study + working prototype
Platform
Mobile-first responsive web app
FutureMBBS desktop overview in a flat Safari window with the mobile overview overlapping its right edge in an iPhone Safari frame

One action hierarchy across Safari and iPhone. Safari 26 mockup by DesignBolts under CC BY 4.0; iPhone 16 Pro frame via Apple Developer Resources.

60-second brief · Submission, at a glance

The brief asked for an overview. I built the decision system behind it.

Priya doesn't need four progress cards. She needs one named next action, why it matters, and what remains everywhere else.

More information looked reassuring. The missed deadline made one defensible next action the priority.

Evidence1 overview, 5 required states, every document named, 3 rejected structures, 3-step onboarding.

Part 1 · Problem analysis

Problem breakdown, assumptions, questions, and the evidence treated as fact.

Part 2 · Solution exploration

Three structures tested on real data, with why each rejection failed.

Part 3 · Design & build

A mobile-first overview, working state changes, and three-tier tokens.

Optional bonus · Onboarding

Three screens teach phases, lead time, and next-action priority.

Chapter 01 · Part 1 · Problem analysis

The real problem was not remembering dates

Priya applies to Riga, Budapest, Pilsen, and Zagreb: same four phases, different deadlines and exceptions. A reminder can say something is late; it can't rank what matters across four applications.

  • Knowledge gap: unfamiliar phases and lead times at the start.
  • Overview gap: four timelines make the whole situation hard to see.
  • Priority gap: a missed document must outrank reassuring progress.
  • Reminder gap: notifications only help once priority is clear.
Decision cost

Risk-first feels less reassuring than progress-first. I accepted that because hiding the missed deadline would be calmer and less useful.

Proof

On March 10, the right first answer isn't a percentage. It's Budapest's translation, due March 1, nine days overdue.

Explore this decision's evidenceThe real problem was not remembering dates
Registration openOriginal 01 · Priority 02

Riga

All 5 documents submitted

Exam registration · Mar 20
9 days overdueOriginal 02 · Priority 01

Budapest

Certified translation missing

Documents · Mar 1
In progressOriginal 03 · Priority 03

Pilsen

Translation in progress

Documents · Mar 31
Not startedOriginal 04 · Priority 04

Zagreb

All 5 documents open

Documents · Apr 15

What I assumed for the prototype

  1. One priority queue beats four separate home screens.
  2. March 10 stays fixed, so every reviewer sees the same overdue state.
  3. 14 days is a demo due-soon threshold, not a validated rule.
  4. Local task completion demonstrates the interaction, not a real submission.

Questions before production

  1. Missed deadline: what can the product safely recommend?
  2. Deadline data: where from, and how fresh?
  3. In-progress work: owned by student, translator, or advisor?
  4. Can applicants read their status in under ten seconds?
Chapter 02 · Part 2 · Solution exploration

Three tidy structures failed Priya

I tested each direction against the real March 10 state. All three could show the data; only one said what to do next without making Priya hunt.

  • University-first: ownership was clear, urgency depended on card order.
  • Phase-first: comparison was fast, a document became a red dot.
  • Generic dashboard: counts scanned well, investigation stayed with Priya.
  • Urgency-first: names the action, then restores university and phase context.
Decision cost

Urgency-first breaks the neat symmetry of four equal applications. The screen becomes opinionated, which is the job.

Proof

The hierarchy answers the brief in order: what to do next, then where every application stands.

Explore this decision's evidenceThree tidy structures failed Priya

University-first cards

Budapest's late translation could sit below Riga's completed documents.

Rejected: ownership over urgency

Phase-first matrix

The certified translation became a red dot, not the thing to submit.

Rejected: comparison over action

Generic status dashboard

"8 documents open" is analytics, not a document, university, or deadline.

Rejected: status over decision
Do this now

Recover Budapest

Certified translation · due Mar 1 · 9 days overdue, packaged for support without inventing policy.

What follows

Work by urgency

Every open document stays named; status and deadline set order.

Where I stand

Compare journeys

All four phases stay visible, including Zagreb's no-exam exception.

Chapter 03 · Part 3 · Design & build

One screen, built around the next decision

The core deliverable is a working mobile overview on Priya's data, coded so reviewers can complete tasks, expand each university, and watch priority recalculate.

  • Overdue: Budapest's translation, 9 days late.
  • Due soon: Riga's exam registration, Mar 20.
  • In progress: Pilsen's translation active, letter not started.
  • Done / future: Riga's documents, plus later payment and visa phases.
Decision cost

A coded prototype took longer than a static screen, but state is the design problem here. A happy-path image would hide whether the hierarchy survives change.

Proof

Completing Budapest promotes Riga's exam registration; reopening a document restores its correct phase, not a false completion.

Explore this decision's evidenceOne screen, built around the next decision
futurembbs

Try Priya's real state

Open the product, complete the late translation, then inspect every university.

Launch full screen
FutureMBBS deadline overview showing Priya's overdue Budapest translationOpen the interactive prototype
Chapter 04 · Optional bonus · Onboarding

Teach the system before the first surprise

Each screen teaches one thing before the overview makes sense, then hands Priya into the same visual language without repeated button labels.

  • Screen 1: four applications moving through the same four phases.
  • Screen 2: two-week translation and six-to-eight-week visa lead times.
  • Screen 3: the urgency-first next-action card using Budapest's overdue task.
  • The overview stays mounted underneath, so replaying onboarding never wipes progress.
Decision cost

Onboarding delays the first task, so I kept it to three replayable screens instead of a forced first-run wall.

Proof

It explains parallel journeys, lead time, and priority without a second interaction model.

Explore this decision's evidenceTeach the system before the first surprise
  1. 01

    Four applications. One plan.

    Compare the same four phases across every university.

  2. 02

    Plan for lead time.

    Translations take about two weeks; visas take six to eight.

  3. 03

    Start with what matters.

    See one next action first, then the complete university picture.

Chapter 05 · Craft & architecture

The system is small enough to inspect

An alternative submission format was pre-approved: this page replaces the process board; the working product replaces the static design file. The architecture lives in components, responsive rules, and a three-tier token chain.

  • Variants: overdue, due soon, in progress, done, upcoming share one set of components.
  • Layout: grid and flex rules absorb content change instead of fixed frames.
  • Tokens: primitives feed semantic roles, which feed component values.
Decision cost

I documented only the components and tokens this product uses, not a speculative system around one flow.

Proof

One data model drives mobile, tablet, and desktop without changing the action-first order.

Explore this decision's evidenceThe system is small enough to inspect
Primitiveteal-500 · space-4 · radius-lg
Semanticcolor-brand · color-danger-surface
Componentaction-overdue-bg · card-padding
AtomsStatus pill · document toggle · primary and text buttons
MoleculesAction row · phase state · context note · reset confirmation
OrganismsPriority action · university journey · onboarding · overview
Chapter 06 · AI usage

AI made me faster; it did not choose the answer

I used Copilot through analysis, concept comparison, build, and review. Its value wasn't more options. It made each option's consequences easier to inspect.

  • Brief parsing: dates, states, and exceptions into one checklist.
  • Concept testing: three structures run through Priya's real data.
  • Build: typed fixtures, components, and state transitions.
  • Review: false recovery claims, weak focus, single-width layouts.
Decision cost

AI can make weak reasoning sound finished, so I kept the supplied data beside every concept and cut suggestions that invented policy. These are condensed build records, not transcripts.

Proof

Each record shows the prompt, what AI accelerated, and the decision I kept human-owned.

Explore this decision's evidenceAI made me faster; it did not choose the answer
Decision record 1

Parse the brief into facts, states, and edge cases before any interface.

AI accelerated
Structured 4 journeys, 5 states, Zagreb's no-exam exception.
I decided
Kept Budapest's missed deadline visible, not averaged away.
Decision record 2

Attack university-first, phase-first, urgency-first with real data.

AI accelerated
Made each structure's cost concrete, not abstract.
I decided
Rejected the tidiest two because neither named the action fast enough.
Decision record 3

Audit the prototype for misleading state and false claims.

AI accelerated
Found destructive replay, silent updates, a completion contradiction.
I decided
Removed invented policy; added a support handoff for the overdue task.
Chapter 07 · Validation & limits

The first clean version still broke trust

Accessibility, usability-under-stress, responsive, and trust reviews on the working product mostly changed behavior: honest recovery language, reversible state, preserved onboarding progress, and one reading order at every width.

  • Accessibility: Moved focus on state change, added live announcements, respected reduced motion.
  • Usability: Made actions reversible and made due-soon outrank in-progress.
  • Responsive: One reading order across mobile, tablet, and desktop.
  • Trust: Removed an invented recovery promise; kept every document named.
Decision cost

This still proves an interaction model on fixture data, not university policy or applicant outcomes.

Proof

The product handles the awkward data without hiding it, survives completion and reopening, and states its remaining assumptions instead of presenting them as facts.

Explore this decision's evidenceThe first clean version still broke trust
Read what I would validate before productionPriority rules, recovery policy, submission states, and deadline provenance

Priority is an unvalidated rule

Rank uses status and date only, untested with real applicants.

Recovery policy is unknown

The product packages details for support; only the university decides.

Submission needs more states

Real service needs submitted/received/accepted, not local completion.

Deadline trust needs provenance

Production dates need a source, freshness, and conflict handling.

1

Core overview

One mobile-first screen answers what's next and where Priya stands.

5

Required states

Overdue, due soon, in progress, done, and far-future work.

3

Rejected structures

University-first, phase-first, and generic dashboard, tested and discarded.

3

Onboarding steps

Parallel journeys, lead time, and next-action priority.

Evidence boundaries
These numbers describe coverage inside the challenge, not validated product impact. Inspect the related decision

Try the awkward data, not a polished screenshot.

Complete the overdue document, replay onboarding, and inspect every journey.

Open prototype

What this submission demonstrates

Problem framing

Knowledge, overview, and priority, not one generic reminder problem.

Information architecture

The structure earns its order against Priya's awkward March 10 data.

Design engineering

A typed, responsive, stateful product, not a clickable happy path.

AI judgment

AI accelerated the work; this case records what I kept, rejected, and fixed.