Act as a senior product designer. Review the following brief or source material for [product]: [paste material]. Produce a decision-ready summary covering the user problem, target audience, business outcome, user outcome, scope, constraints, assumptions, unanswered questions and decisions required. Separate evidence from inference. Do not propose screens until the problem is clear.

Review this project context: [context]. Identify the assumptions being made about users, behaviour, technology, content, operations and commercial outcomes. Group them by confidence and potential impact. For each high-risk assumption, suggest the smallest useful way to validate it. Finish with the five questions that could most change the project direction.

Using this product context [context], define one primary user outcome, one primary business outcome and up to five supporting measures. Distinguish leading indicators from final outcomes. Explain what each measure would reveal, what could distort it and what baseline data should be recorded before design changes are released.

Create a stakeholder question bank for [project]. Organise the questions under goals, users, current evidence, constraints, risks, ownership and delivery. Prioritise questions that expose conflicting expectations or fixed decisions. Avoid generic questions that can be answered from existing documentation.

Create a focused research plan for [product/problem]. Include the decisions the team needs to make, what must be learned, existing evidence to review, suitable methods, participant criteria, sample size rationale, logistics, risks, outputs and a realistic timeline. Prefer the lightest method capable of reducing the important uncertainty.

Write a 45-minute interview guide for [audience] about [topic]. Begin with context and recent behaviour, then explore tasks, decisions, workarounds, expectations and difficult moments. Use neutral questions and follow-up probes. Avoid leading questions, feature pitching and hypothetical preference questions. Add interviewer notes explaining what evidence each section should uncover.

Create a moderated usability test script for [flow or prototype]. Include welcome and consent, warm-up questions, a realistic scenario, task wording, neutral prompts, observation points, success criteria and closing questions. Do not reveal the intended path. Include likely facilitator mistakes and how to avoid them.

Create a concise recruitment screener for a study about [topic]. Define essential participant characteristics, behavioural criteria, exclusions, balancing criteria and red flags. Write neutral screening questions with answer options and state which responses qualify or disqualify someone. Avoid revealing the preferred answers.

Analyse the following research notes: [paste notes]. Group observations into evidence-based themes without merging meaningful differences. For each theme, list supporting evidence, affected users, frequency, severity, contradictions and confidence. Do not invent quotes or treat a single comment as a general pattern.

For each observation below, create an evidence chain using: observation, repeated pattern, underlying need or cause, why it matters, and design implication. Label any inference clearly. Reject statements that merely restate the observation. Evidence: [paste evidence].

Turn these validated findings into opportunity statements: [findings]. Use a format such as “How might we help [user] achieve [outcome] when [context] without [constraint]?” Produce a broad version and a narrower testable version for each finding. Flag any opportunity that is unsupported by evidence or already assumes a solution.

Prioritise these findings: [findings]. Score each by user impact, business impact, frequency, severity, evidence confidence and implementation dependency. Explain the reasoning, identify quick wins versus structural problems, and recommend what to solve now, research next, monitor or deliberately defer.

Review this navigation structure or sitemap: [structure]. Assess label clarity, grouping, hierarchy, overlap, depth, orientation and likely user expectations. Identify where internal business language replaces user language. Propose a clearer structure, but preserve genuinely different mental models rather than forcing everything into one taxonomy.

Create a user flow for [user] completing [task] in [product]. Include entry points, required information, decisions, permissions, system responses, success, cancellation and recovery routes. Distinguish user actions from system actions. Call out assumptions, dependencies and steps that may create unnecessary effort.

Audit this flow for missing states and edge cases: [flow]. Check first use, returning use, empty, loading, partial data, validation, errors, permissions, unavailable content, offline or slow connection, cancellation, timeout, duplicate actions, long content, localisation and recovery. Recommend which states need dedicated design treatment.

Review this journey: [journey]. Identify steps that exist because of internal process rather than user need, repeated information, premature decisions, unclear dependencies and avoidable context switching. Propose a simplified flow and explain what can be removed, combined, deferred, automated or made optional without hiding necessary consequences.

Rewrite the following interface copy for [audience] completing [task]: [copy]. Make the language specific, concise and action-oriented. Preserve legal or operational meaning. Remove internal terminology, vague claims and unnecessary reassurance. Provide a recommended version, a shorter alternative and notes explaining significant changes.

Write error messages for these scenarios: [scenarios]. Each message should explain what happened, what remains safe, what the person can do next and where relevant how to prevent recurrence. Use specific language, avoid error codes as the main message and do not imply the user caused a system failure.

Create content for empty, loading, partial, no-results and success states within [feature]. For each state, define what the user needs to know, the most useful next action and any reassurance that is genuinely necessary. Avoid celebratory language for routine actions and avoid dead-end empty states.

Review this screen content: [content or screenshot description]. Identify the primary decision, essential supporting information, secondary details and content that can be removed or deferred. Recommend a hierarchy using headings, labels, progressive disclosure and concise summaries. Explain any information that must remain visible for informed consent or confident action.

Create three distinct visual direction briefs for [product and audience] based on these brand attributes and constraints: [inputs]. For each direction define visual principles, typography characteristics, spacing and density, imagery approach, colour behaviour, motion tone and what to avoid. Do not name fashionable styles without explaining how they support the product experience.

Review these screens or feature descriptions: [screens]. Produce a component inventory grouped into foundations, primitives, controls, navigation, content, feedback and composite patterns. Identify duplicate patterns, inconsistent variants, missing states and components that should remain feature-specific rather than becoming global.

For this interface [description], define responsive behaviour for content order, layout changes, navigation, controls, tables, imagery, sticky elements and long content. Explain what should reflow, stack, collapse, scroll, remain fixed or disappear at narrower widths. Protect task priority and reading order rather than simply shrinking the desktop layout.

Compare this feature [feature/screens] with the following design-system rules: [rules]. Identify inconsistent components, spacing, typography, states, interaction patterns and naming. Separate justified exceptions from accidental divergence. Recommend the smallest changes that restore consistency without weakening the feature’s usability.

Critique this interface or flow: [description]. Review clarity, hierarchy, task focus, navigation, consistency, feedback, error prevention, recovery and cognitive effort. For each issue, state the evidence visible in the design, the likely user consequence, severity and a specific recommendation. Do not comment on visual taste unless it affects comprehension or use.

Review this interface description against accessibility fundamentals: [description]. Check contrast intent, text resizing, keyboard order, focus visibility, labels, instructions, error identification, target size, colour dependence, motion, semantic structure and screen-reader reading order. Flag what cannot be verified without code, content or assistive-technology testing.

Assess this flow for cognitive load: [flow]. Identify unnecessary choices, information that must be remembered, ambiguous labels, competing actions, unfamiliar patterns, interruptions and decisions requested too early. Distinguish essential complexity from accidental complexity and recommend ways to externalise memory and stage decisions.

Review this mobile flow: [description]. Assess thumb reach, target size, spacing, keyboard behaviour, viewport changes, sticky elements, interrupted sessions, orientation, long content, loading conditions and recovery. Highlight desktop assumptions that may fail on mobile and prioritise issues affecting task completion.

Create a design QA checklist for [feature]. Cover journey logic, component consistency, responsive layouts, long and missing content, loading and error states, permissions, accessibility, localisation, analytics, browser or device risks and acceptance criteria. Separate checks that designers can complete in Figma from checks requiring a built product.

Turn this design description into developer handoff notes: [description]. Document components, variants, content rules, interaction triggers, validation, states, responsive behaviour, accessibility intent, analytics events, dependencies and acceptance criteria. Highlight decisions that are still unresolved instead of silently choosing an implementation.

Summarise this design review transcript or notes: [notes]. Record decisions made, evidence considered, rejected options and reasons, unresolved questions, owners, dependencies and next actions. Separate final decisions from suggestions and assumptions. Keep the summary brief enough to be used as a project record.

Create a case-study outline from this project evidence: [evidence]. Structure it around context, challenge, diagnosis, strategy, key decisions, collaboration, implementation, outcomes and lessons. Emphasise the reasoning and constraints behind the work. Do not invent metrics, user quotes or personal ownership that the evidence does not support.