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.