Problem
/applications/[id] — the reviewer's application detail page — reads poorly at every viewport. It is the page reviewers spend the most time on, and the one where the product's core job actually happens.
Context worth knowing before redesigning
There are now two detail pages, and they are diverging. /my-applications/[id] (the applicant's read-only view) was added recently and is also max-w-5xl. Both render the same underlying answers. A redesign should cover both, or they will drift into two different treatments of the same content.
The status control was just reworked. #364 merged (PR #499), replacing the six-item dropdown with next-available-status quick actions plus a reverse "move back" control. Any redesign starts from that as the current state, not the old dropdown.
The page width is already ticketed. #514 covers the container-width rule across the app, including this page's max-w-5xl. Coordinate rather than changing the width independently.
Known specifics
Findings from the 2026-08-10 audit that apply to this page:
CardTitle renders a <div>, so the page has an h1 and no h2 — the heading hierarchy is broken- The "Status" card duplicates its own label: a card heading reading "Status" wrapping a form control also labelled "Status"
ApplicationAnswersList renders every answer identically regardless of question type — long answers, single choices and multi-selects all get the same treatment, which is what makes a long application hard to scan
The answer list itself is deliberately resilient — it renders from the snapshot's questionLabel and value and never consults the live question. That behaviour must survive the redesign; it is what keeps submitted applications readable after their questions change.
Scope
Coordinate with
Problem
/applications/[id]— the reviewer's application detail page — reads poorly at every viewport. It is the page reviewers spend the most time on, and the one where the product's core job actually happens.Context worth knowing before redesigning
There are now two detail pages, and they are diverging.
/my-applications/[id](the applicant's read-only view) was added recently and is alsomax-w-5xl. Both render the same underlying answers. A redesign should cover both, or they will drift into two different treatments of the same content.The status control was just reworked. #364 merged (PR #499), replacing the six-item dropdown with next-available-status quick actions plus a reverse "move back" control. Any redesign starts from that as the current state, not the old dropdown.
The page width is already ticketed. #514 covers the container-width rule across the app, including this page's
max-w-5xl. Coordinate rather than changing the width independently.Known specifics
Findings from the 2026-08-10 audit that apply to this page:
CardTitlerenders a<div>, so the page has anh1and noh2— the heading hierarchy is brokenApplicationAnswersListrenders every answer identically regardless of question type — long answers, single choices and multi-selects all get the same treatment, which is what makes a long application hard to scanThe answer list itself is deliberately resilient — it renders from the snapshot's
questionLabelandvalueand never consults the live question. That behaviour must survive the redesign; it is what keeps submitted applications readable after their questions change.Scope
/applications/[id]for scannability — answers are the primary content, status and metadata are secondaryh2per section/my-applications/[id]so the two views stay consistentCoordinate with
SectionCard, currently in progress; the cards on this page are candidates