admin-product-uxlisted

# Admin Product UX Model the operator's work before drawing the interface. Produce the smallest contract that prevents visual polish from hiding an incomplete workflow. ## Operating rule Do not begin with navigation, cards, or components. Establish: 1. actor and job 2. business objects and lifecycle 3. task flow and exception paths 4. permissions and scope 5. screen contracts and states 6. UX acceptance criteria Label assumptions. Ask only questions that materially change the workflow; do not invent business rules to complete a template. ## Workflow ### 1. Inspect before interviewing For an existing product, inspect routes, schema, types, API contracts, status enums, authorization code, current screens, and product documents. Disk beats memory and mockups. Trace at least one real workflow end to end. ### 2. Define the operational frame Record the primary actor, job, trigger, frequency, volume, risk, time pressure, success condition, and failure cost. Separate daily operations, monitoring, configuration, governance, and reporting; do not flatten them into one menu. Also record whether behavior is global, localized-global, or country-specific; language/locale, device, market, and trust assumptions need evidence and must not be smuggled in as fictional personas. Read [Discovery and domain](references/discovery-and-domain.md). ### 3. Model objects and lifecycle Define canonical nouns, relationships, ownership, states, valid transitions, guards, side effects, reversib