Draft UX

Requirements do not imply an interaction. Handed the same Approved requirements, the same component kit, and the same locked look, two competent runs shipped opposite answers — one removed the rows on click and offered six seconds of undo, the other held the list frozen until the call returned — and each wrote up its own answer as the one the requirements forced. Whichever one gets built is a decision. This skill makes it the user's decision, felt in the browser before it is spec'd, and puts it where the build reads it.

1. List the moments

From the requirements and the existing brief, write one line per moment — an action whose outcome is not implied: <trigger> → <what the user should be able to feel>. Every moment carries its branches: what happens instantly, what happens while the system is working, what happens on success, what happens when it fails, and how the user gets back out.