01Problem framing, people, product direction, and boundaries
Provide a requested feature, mixed qualitative and quantitative evidence, conflicting user and organizational needs, an assumed solution, a fixed constraint, a wider journey and a product owner who must decide. Ask what the product should address and what it should not.
Confirm: The person distinguishes user need, business aim, policy intent, opportunity, problem, constraint, requirement, assumption and solution; identifies affected and excluded groups; examines current behavior and alternatives; states evidence provenance and limits; maps the task across channels and organizational boundaries; frames a specific product problem and intended outcomes without inventing market proof; proposes principles and non-goals that guide design; defines the product boundary and its handoffs to the wider service; expresses hypotheses and the smallest decision-worthy slice; makes desirability, viability, feasibility, accessibility, security, privacy, sustainability and operational tradeoffs visible; and leaves value, priority and proceed-or-stop authority with the product owner.
02Journey, information, interaction, content, and visual system
Provide a cross-channel journey with dead ends, internal terminology, several user types, dense information, inconsistent controls, a brand system, responsive constraints, permission differences and failure cases. Ask for one coherent product model rather than a screen set.
Confirm: The person maps the current and intended journey, touchpoints, evidence, handoffs, support and offline seams; organizes information around user language and decisions; defines navigation, orientation, entry, return and completion; models product state, permissions, actions, feedback, loading, empty, error, interruption and recovery; works with content owners on hierarchy, labels and comprehension; uses typography color space imagery and motion purposefully without relying on them alone; composes responsive layouts that preserve task order at narrow width, zoom and large text; reuses established patterns where evidence and context fit; identifies where specialist interaction, service, graphic, content or accessibility depth is required; and keeps visual polish subordinate to product meaning and behavior.
03Inclusive prototypes, research, feasibility, risk, and decision evidence
Provide an uncertain concept, sensitive data, a new workflow, a difficult integration, several access needs, cost and time limits, a high-fidelity mockup and pressure to validate the preferred option. Ask what to prototype, with whom and what result would disconfirm it.
Confirm: The person states the hypothesis and decision threshold before choosing fidelity; explores materially different alternatives rather than decorating one answer; selects paper, clickable, coded, service or technical prototypes according to the uncertainty; uses realistic content, data shape, permissions, latency, errors and cross-channel behavior where they matter; protects prototype access and personal information; collaborates with researchers on representative participants and valid methods; includes disabled people and cognitive, language, device, connectivity and assisted-support needs; involves engineers and specialists early enough to change the direction; separates participant observation, finding, interpretation and product decision; documents limitations and conflicting evidence; discards weak options; and never treats prototype code, preference, stakeholder approval or one research round as production proof.
04Implementation, design system, release learning, and continuity
Provide an accepted concept with incomplete behavior specifications, an existing component that only partly fits, implementation divergence, specialist risks, a release deadline, ambiguous product signals and an absent designer. Ask how the slice reaches users and improves safely.
Confirm: The person transfers flows, state, content, layout, visual assets, tokens, components, variants, semantics, keyboard and focus behavior, motion, responsive rules, data and service dependencies, errors and acceptance examples at the useful level; pairs with engineers content quality and accessibility owners rather than throwing over frames; compares existing components with the actual need before reuse or extension; records rationale and governance for design-system change; reviews real implementation across target browsers devices and access paths; distinguishes design fidelity, technical completion, release, adoption and outcome; defines signals and observation windows with product and analytics owners; avoids causal claims the evidence cannot support; feeds learning into the next priority decision; versions product principles, patterns and accepted divergence; and lets another team reconstruct, test, evolve or retire the product.
