The problem
A completed all-supported year currently renders as a flat list: a section per return type, then one row per period, each reading "Saved". For three return types over twelve periods that is 36 rows saying the same word, and the reader must scroll the panel to see whether the year is whole.
Observed live, on a run that succeeded: "success is not easily visible". The run had in fact saved all 36 targets. Nothing on screen made that legible without counting.
The live-progress rendering during the run was reported as working well. This is about reading the result.
The proposal (from live feedback, deliberately not yet concrete)
A compact grid — return type on one axis, period on the other — with colour-coded cells for saved / not filed / needs review / waiting. One glance gives coverage, gaps and exceptions together.
Two things it would fix beyond legibility:
- The count and the evidence stop being separate claims. Today the summary states a count and the list states rows; a grid is the count.
- It gives blocked and review states somewhere to live that is not prose. See the repeated-blocked-reason issue filed alongside this — four identical sentences under four presets is partly a symptom of having nowhere structural to put a state.
Constraints
DESIGN.md and PRODUCT.md set the posture: dense, scannable, evidence-before-confidence, CA-facing. A grid fits that; a decorative dashboard does not. Read both before designing, and prefer existing shared components over new patterns.- Colour alone must not carry the meaning. Any cell state needs a non-colour affordance too.
- The panel has a ~320px floor. A twelve-column grid at that width needs deliberate handling, not a horizontal scroll bar bolted on.
- "Not filed" is a legitimate positive outcome, not a gap. It must not read as failure.
Not yet scoped
This is a proposal, not a specification. It wants a sketch and a decision before implementation — including whether the grid replaces the list or summarises above it.
The problem
A completed all-supported year currently renders as a flat list: a section per return type, then one row per period, each reading "Saved". For three return types over twelve periods that is 36 rows saying the same word, and the reader must scroll the panel to see whether the year is whole.
Observed live, on a run that succeeded: "success is not easily visible". The run had in fact saved all 36 targets. Nothing on screen made that legible without counting.
The live-progress rendering during the run was reported as working well. This is about reading the result.
The proposal (from live feedback, deliberately not yet concrete)
A compact grid — return type on one axis, period on the other — with colour-coded cells for saved / not filed / needs review / waiting. One glance gives coverage, gaps and exceptions together.
Two things it would fix beyond legibility:
Constraints
DESIGN.mdandPRODUCT.mdset the posture: dense, scannable, evidence-before-confidence, CA-facing. A grid fits that; a decorative dashboard does not. Read both before designing, and prefer existing shared components over new patterns.Not yet scoped
This is a proposal, not a specification. It wants a sketch and a decision before implementation — including whether the grid replaces the list or summarises above it.