Define UX Invariants
๐จโ๐ผ Time has passed since the restraint decision in Exercise 2. The team now has
enough product evidence to justify a narrow login implementation for returning
hosts, but that does not mean we can afford to regress the product's core UX.
๐งโโ๏ธ This app continues from the constrained response you ended Exercise 2 with.
The planning artifacts are already in place in
docs/planning.๐จ In this step, do not implement login yet. First, inspect the existing product
and create a dedicated
planning
artifact for the UX constraints that a narrow host-login implementation must
protect.
Your notes should cover:
- The critical user flows that matter most before login is added.
- The invariants that must not degrade as host login is introduced.
- The degradation signals you would watch for when judging whether login hurt the experience.
Requirements:
- Include the core flow for creating a schedule.
- Include the core flow for a returning host getting back to manage/finalize a schedule.
- Include the core flow for submitting availability.
- Name the parts of the experience that must stay fast, simple, and clear.
- Call out the key signals that login would be hurting finalized-plan rate, create-flow speed, or attendee completion.
๐ฐ Keep this grounded in observable UX, not abstract architecture. Think in
terms of steps, screens, decisions, ambiguity, and how quickly a user can
complete the job they came to do.
๐ By the end of this step,
docs/planning/ux-invariants.md should give the
team a short, concrete artifact that makes future login-related regressions
easier to spot before anyone starts building.