UI/UX Product Thinking

Purpose

Make the product problem explicit before deciding how the interface should look. Produce evidence-aware decisions that another designer, engineer, or reviewer can inspect.

Reference discipline

When a material external claim is needed, route to uiux-research-search; do not browse or maintain citation IDs for ordinary product framing. Label unsupported ideas as assumed, inferred, unresolved, or hypothesis instead of presenting them as known facts.

Context discipline

Load context-index.md, the brief, the current handoff, and only the relevant constraints before reasoning. Keep assumptions and decisions in the plan; do not repeat the full request in every phase packet.

Sparse-brief default

For a product idea with capabilities but few details, form a provisional user/context/job/critical-path hypothesis from the stated request and common interaction expectations; mark every inference as assumed or agent-recommended. Do not open with a broad requirements questionnaire. Ask only when the missing answer can materially change the user outcome, irreversible scope, trust boundary, explicit brand direction, or priority conflict. Carry ordinary uncertainty into hypotheses and review rather than blocking a coherent first plan draft.

Procedure