[UX] Establish a design system and component library #364

Open
opened 2026-08-25 20:39:25 +00:00 by claude-bot · 0 comments
Contributor

Found in the August 2026 session lifecycle review (#319). Follows the mockup selection.

Why

The review found the same concept rendered differently on different pages: attendance implemented four times with different labels for the same toggle, summary editing appearing twice (editable in one place, read-only in the other with no indication that editing lives elsewhere), two full proposal-review UIs that differ in three user-visible ways, and error handling split between inline messages, page-level errors that destroy the rendered content, and native alert() calls.

That is what happens without a shared vocabulary of components. A redesign that does not produce one will drift back to the same state.

What

Extract the chosen direction into tokens and components: type scale, spacing, colour with a genuine dark mode, status and severity treatments, buttons and their hierarchy, form controls, empty states, loading states, error states, badges and counts, cards, modals and confirmations, and the async-progress pattern that v4.3.0 introduces.

Codify the interaction rules the review found violated: an error never destroys already-rendered content; every destructive action explains its consequence (the codebase already does this well in places and should be the model); every async operation shows progress and a next action on failure; disabled controls explain why.

Acceptance criteria

  • Tokens defined for type, spacing, colour, and elevation, with dark mode
  • A component covering each pattern listed above, with documented states
  • Touch targets meet a stated minimum — the review found 16-32 px controls throughout
  • Documented interaction rules for errors, async work, and destructive actions
  • Components are the only way those patterns are built afterwards
Found in the August 2026 session lifecycle review (#319). Follows the mockup selection. ## Why The review found the same concept rendered differently on different pages: attendance implemented four times with different labels for the same toggle, summary editing appearing twice (editable in one place, read-only in the other with no indication that editing lives elsewhere), two full proposal-review UIs that differ in three user-visible ways, and error handling split between inline messages, page-level errors that destroy the rendered content, and native `alert()` calls. That is what happens without a shared vocabulary of components. A redesign that does not produce one will drift back to the same state. ## What Extract the chosen direction into tokens and components: type scale, spacing, colour with a genuine dark mode, status and severity treatments, buttons and their hierarchy, form controls, empty states, loading states, error states, badges and counts, cards, modals and confirmations, and the async-progress pattern that v4.3.0 introduces. Codify the interaction rules the review found violated: an error never destroys already-rendered content; every destructive action explains its consequence (the codebase already does this well in places and should be the model); every async operation shows progress and a next action on failure; disabled controls explain why. ## Acceptance criteria - [ ] Tokens defined for type, spacing, colour, and elevation, with dark mode - [ ] A component covering each pattern listed above, with documented states - [ ] Touch targets meet a stated minimum — the review found 16-32 px controls throughout - [ ] Documented interaction rules for errors, async work, and destructive actions - [ ] Components are the only way those patterns are built afterwards
Sign in to join this conversation.
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
rbrooks/Quest-Board#364
No description provided.