AI-Assisted UX Methods

<context>Service blueprint or process description: [paste]</context> Identify all stakeholders and user types involved. For each produce: role title, key responsibilities, decision-making authority, interaction points with other stakeholders, and likely pain points. Format as a structured table. Flag any roles that appear in the process but are not accounted for in the blueprint.

You are a UX researcher preparing for stakeholder interviews. Based on this service blueprint [paste], identify all stakeholders and user types. For each describe their role, responsibilities, and where they interact with others. Then give me a prioritized interview order — who should I talk to first and why, based on their influence over the process.

Based on this service blueprint [paste], generate a comprehensive stakeholder map for [domain]. Drawing from industry norms, identify all roles typically involved — including ones that may not be visible in the blueprint but commonly exist in this type of organization. For each describe responsibilities, interaction points, and influence level. Flag any role gaps.

Using this service blueprint [paste], create a stakeholder identification document formatted for a PowerPoint presentation. List all stakeholders with their roles and responsibilities. Format each as a concise bullet list suitable for a project kickoff slide. Group stakeholders into: Primary Users, Internal Stakeholders, and External/Support Roles.

<context>Stakeholder type: [type] | Blueprint: [paste] | Stakeholder list: [paste] | Research notes if available: [paste]</context> Generate a hypothesis-driven UX persona. Include: role and context, 3 primary goals, 3 key frustrations, typical behaviors, and a representative quote. Label every attribute as a hypothesis. Add a 'To validate' section listing the 3 assumptions most critical to confirm in research.

You are a UX researcher building a research hypothesis persona. Based on this stakeholder list and service blueprint [paste both], generate a persona for [stakeholder type]. Include their role, goals, frustrations, behaviors, and context. Then add a section called 'Research questions to validate this persona' with 5 specific interview questions targeting the most uncertain attributes.

Drawing from industry patterns in [domain], generate a UX persona for [stakeholder type] based on this blueprint [paste]. Ground each attribute in how this role type typically behaves across the industry — not just assumptions. Include role summary, goals, frustrations, behaviors, and a quote. Add a research confidence score (Low/Medium/High) for each attribute.

Create a UX persona document for [stakeholder type] based on this service blueprint [paste]. Format it as a one-page Word document suitable for sharing with a client. Include: role description, top 3 goals, top 3 frustrations, key behaviors, and a representative quote. Keep language free of UX jargon so non-design stakeholders can engage with it.

<context>Workflow: [workflow] | Domain: [domain] | Comparable products: [list if known] | User type: [type]</context> Review how comparable products handle this workflow. For each: their approach, the underlying pattern, and the tradeoff it implies. Then evaluate the shared patterns against usability heuristics — which conventions are sound and which are merely inherited. Mark clearly which claims come from documented knowledge and which are inference, and list every specific interface claim I should verify myself before using it.

You are a UX designer running a competitive review of [workflow] in [domain]. Compare how [products, or 'the main players'] approach it. For each, describe the pattern and its tradeoff. Then give me the three approaches most worth borrowing and the three most worth avoiding, with reasoning. Tell me explicitly where you're uncertain about current interface details.

Research how comparable products currently handle [workflow] in [domain] and give me a structured comparison. For each product: approach, pattern used, and tradeoff. Prioritise current information over general knowledge, cite what you find, and evaluate the common patterns against standard usability heuristics. Flag anything you could not verify.

<context>User type to recruit: [type] | Study goals: [goals] | Participants needed: [number] | Disqualifiers: [list]</context> Write a recruitment screener and a short supporting survey. The screener needs qualifying questions, disqualifying criteria, and experience-verification questions that don't reveal which answers qualify. Then review your own output and flag any question that leads the participant, combines two questions in one, uses an unbalanced scale, or could be answered accurately by someone who doesn't fit the criteria.

You are a UX researcher writing a recruitment screener for [user type] for a study on [topic]. Include qualifying and disqualifying questions and a way to verify claimed experience without signalling the right answer. Then draft a supporting survey covering [topics]. Afterwards, critique your own questions for bias and rewrite any that fail.

Draft a recruitment screener for [user type] studying [topic], plus a short supporting survey covering [topics]. Ground the screening criteria in how this role typically works in [domain] — including ways someone might appear qualified on paper but not in practice. Flag leading, double-barrelled, or unbalanced questions.

Create a recruitment screener and supporting survey for [user type] for a study on [topic], formatted as a Word document the team can send out. Include qualifying questions, disqualifiers, and experience verification. Use plain, neutral language and number every question for easy reference during recruitment.

<context>Service blueprint: [paste] | Validation notes: [paste if available]</context> Condense this into a current state process map organized around user actions — not system logic. Format as: 4–6 high-level phases, each with step-by-step actions, decision points with labeled branches, and 1–2 pain points. Output clean markdown. Flag any step that is based on an assumption rather than documented input.

Based on this service blueprint [paste], create a simplified current state process map focused on what the user actually does — not what the system does backstage. Organize into 4–6 phases with step-by-step actions and decision points. Highlight the top 3 friction moments. Format so a non-designer stakeholder can follow it in a workshop without explanation.

Using this service blueprint [paste], generate a current state process map that reflects how [domain] processes actually operate in practice — including informal steps, workarounds, and friction points that don't appear in official documentation. Structure around user actions with clearly labeled decision points. Note where real-world behavior diverges from the stated process.

Based on this service blueprint [paste], create a current state process map formatted as a table in Word. Columns: Phase, User Action, Decision Point (Yes/No), Pain Point, Notes. Use plain language appropriate for a client presentation. Add a brief title and one-sentence description above the table for context.

<context>Interview notes: [paste] | Roles involved: [list] | Workflow name: [name]</context> Generate a swimlane diagram for this workflow. One lane per role. Show every action, decision point, and handoff in sequence. Include a CSV export format below the diagram with columns: Step, Role, Action, Handoff To, Notes. Flag any step where role ownership is ambiguous or where the trigger for a handoff is not clearly defined.

Based on these interview notes [paste] and this list of roles [list], generate a swimlane diagram for the [workflow name] process. Create a lane for each role. Show every action, decision point, and handoff in order. After the diagram, provide a CSV version I can import into a spreadsheet with columns: Step, Role, Action, Handoff To, Notes.

Using these interview notes [paste] and roles [list], generate a swimlane diagram for [workflow name]. One lane per role. Show all actions, decisions, and handoffs. Cross-reference against how [domain] workflows typically operate — flag any lane assignment that deviates from common practice, as these are likely to come up in stakeholder review.

Based on these interview notes [paste], create a swimlane diagram for [workflow name]. Roles: [list]. Format as a structured table with roles as columns and steps as rows. Mark handoffs with an arrow (→). Include a CSV-compatible version below with columns: Step, Role, Action, Handoff To, Notes. Plain language throughout — this will be reviewed with non-technical stakeholders.

<context>Pain point synthesis: [paste] | Workshop insights: [paste if available]</context> Convert each pain point into a How Might We statement. Rules: each statement must start with 'How might we', must not imply a specific solution, and must be narrow enough to act on. Group by theme. For each theme produce 2–3 HMW options so the team can choose the best framing. Flag any statement that accidentally implies a solution — those need rewriting.

You are a UX researcher facilitating a design ideation session. Based on these pain points [paste], convert each into a How Might We statement. Group by theme. For each theme generate 2 HMW variants — one broad and one narrow — so the team can choose the right level. After the list, recommend the top 3 HMW statements to prioritize and explain your reasoning.

Convert these pain points [paste] into How Might We statements using design thinking principles. Ensure each statement reframes a problem as a design opportunity without implying a specific solution. Where the pain point is systemic, generate an HMW that addresses the root cause — not just the surface symptom. Group by theme and flag the 3 highest-leverage opportunities.

Convert these pain points [paste] into How Might We statements formatted for a workshop facilitation deck. Group by theme. Present each as a clear, jargon-free statement the team can discuss and vote on. Include a brief facilitator note for each theme explaining why it matters. Format for a PowerPoint slide with no more than 4 statements per slide.

<context>Pain points or opportunities: [paste] | Business goals: [paste] | Constraints: [timeline, team size, technical limits]</context> Build a prioritisation matrix. Score each item on user impact, effort, reach, and evidence confidence, and produce a table with the scores, a Now/Next/Later grouping, and a one-line rationale per item. Mark every effort score as an estimate needing engineering confirmation. Flag any item whose priority depends on an assumption we have not validated, and list those assumptions separately.

You are a product designer prioritising a backlog of opportunities. Given these pain points [paste] and business goals [paste], score each on impact, effort, reach, and confidence, then sort into Now, Next, and Later. Explain your reasoning per item. Then give me the three items most likely to cause disagreement between design and business stakeholders, and how I should frame each one going into that conversation.

Prioritise these opportunities [paste] against these business goals [paste]. Score on impact, effort, reach, and confidence, and group into Now/Next/Later. Where an item resembles a common pattern in [domain], note how comparable teams have typically sequenced it. Flag items where the effort estimate is likely to be wrong without engineering input.

Create a prioritisation matrix from these pain points [paste] and business goals [paste], formatted for a PowerPoint slide a leadership team will review. Score each item on impact, effort, reach, and confidence. Group into Now, Next, and Later. Keep each rationale to one line, use plain business language, and add a summary slide note explaining the criteria used.

<context>Pain points: [paste] | Future state map: [paste] | Metrics already tracked: [paste if any]</context> Define success metrics for this work. For each: the metric, the user outcome it represents, baseline, target, and instrumentation approach. Separate outcome metrics from activity metrics and label which is which. For every metric, state how it could be gamed or improve without the experience improving, and propose a counter-metric where that risk is real.

You are a product designer defining success measures. Based on these pain points [paste] and this future state [paste], propose 4-6 success metrics. For each give the metric, why it matters to users, a baseline, a target, and how to instrument it. Then tell me which of these the business will care about most and which ones I'll have to argue for — and how to make that argument.

Define success metrics for this work based on these pain points [paste] and future state map [paste]. For each: metric, user outcome, baseline, target, instrumentation. Where relevant, note what comparable teams in [domain] typically measure for this kind of workflow, and flag metrics that are commonly tracked but rarely meaningful.

Create a success metrics document based on these pain points [paste] and this future state map [paste], formatted for a Word document shared with business stakeholders. For each metric include: what is measured, why it matters, current baseline, target, and how it will be tracked. Present as a table with a short executive summary above it. Use business language, not UX jargon.

<context>Feedback from [number] stakeholders: [paste all feedback]</context> Synthesize into a structured summary. Group into themes. For each theme: name, supporting evidence (direct quotes where possible), frequency, and whether there is stakeholder disagreement. Add a 'Decisions required' section at the end listing items that cannot be acted on until someone makes a call. Flag any feedback item that contradicts an earlier design decision.

You are a UX designer synthesizing stakeholder feedback. Here is feedback from [number] stakeholders [paste]. Identify recurring themes, surface any conflicting opinions between stakeholders, and flag items that require a design decision before the next iteration. Format as: Themes (with quotes), Conflicts (who disagrees with whom and why), and Action items (prioritized list). Suggest a recommended priority order for the next sprint.

Synthesize this stakeholder feedback [paste] into a structured report. Identify themes, conflicts between stakeholders, and items requiring a decision. For each theme, note whether the feedback reflects a genuine usability problem versus a personal preference — that distinction matters for prioritization. List actionable next steps at the end.

Synthesize this stakeholder feedback [paste] into a structured summary formatted for a client-facing document. Group by theme. For each theme include: a plain-language description, how many stakeholders raised it, whether there was disagreement, and a recommended action. Add a one-paragraph executive summary at the top and a prioritized action table at the bottom. Format for Word.

Apply [client name]'s design system to this prototype. Here are the design tokens and component specs [paste or attach]. Replace all generic styles with the client's color tokens, typography scale, and spacing units. For any component the design system doesn't cover, create a new component that is visually consistent with the existing patterns. List every component updated and flag any that required custom styling decisions.

Write a spec to apply [client name]'s design system to this prototype. Tokens and component specs: [paste]. The spec should define which components need updating, what token values to apply, and how to handle gaps in the design system. Generate the updated components and a summary of changes after applying.

Update this prototype to use [client name]'s design system. Apply these tokens [paste]. For each component: replace hardcoded styles with the correct token values, match interaction patterns to the design system spec, and flag any component that doesn't have a clear design system equivalent so I can make a decision.

Add a local SQLite database to this prototype using better-sqlite3. Define tables for these entities: [list entities and key fields]. Seed with realistic sample data — at least 10 rows per table with varied, non-placeholder content. Wire all existing list views, forms, and detail screens to read from and write to the database. Every create, update, and delete interaction should persist across page reloads. After setup, confirm each table and its seed data.

Write a spec to add a local SQLite database to this prototype. Entities: [list]. The spec should define the schema for each table, seed data requirements, and which UI components need to be wired to each table. Generate the database layer and updated components, running in Supervised mode so I can review the schema before data is seeded.

Add SQLite to this prototype using better-sqlite3 (or Drizzle if the project already uses it). Tables needed: [list entities and fields]. Create a db.ts file with the schema definitions. Seed each table with at least 10 realistic rows. Update the relevant components to fetch data from the database instead of using hardcoded arrays. Confirm each wired component after the update.

Use this process map [paste] to scaffold a full multi-page React app for [tool name]. Create one route per major workflow. Use a sidebar or top navigation to move between sections. Apply [style notes]. Prioritize working navigation over visual polish — stakeholders need to click through the full flow. List all routes created at the end.

Write a spec for a [tool name] web app based on this process map [paste]. Define all pages, navigation structure, and key UI elements per page. Use the spec to generate a full multi-page app in Bolt.new or as a React scaffold. Workflows to cover: [list].

Using this process map [paste], build a navigable multi-page prototype for [tool name]. Create one page per major workflow. Wire navigation between pages. Use [color/style notes] for visual consistency. Keep component logic simple — the goal is a clickable prototype, not production-ready code.

For every interactive component in this prototype, generate all UI states: default, hover, focus, active, disabled, loading, error, and empty. Implement each as a visible, triggerable state in the component — not just a comment. Create a /states dev page that renders every component side-by-side in all states so I can review them without navigating the prototype. Flag any state that requires a design decision before it can be implemented.

Write a spec to add full interaction state coverage to this prototype. For each interactive component define all states it needs to support: default, hover, focus, active, disabled, loading, error, empty. Generate the updated components and create a review page that displays all states in one view. Run in Supervised mode.

Audit this prototype for interaction state coverage. For every interactive component, identify which states are currently implemented and which are missing. Add the missing states — at minimum: disabled, loading, error, and empty for any data-dependent component. Create a dedicated /dev/states route that renders every component in every state for review.

Add responsive layouts to this prototype at three breakpoints: mobile (375px), tablet (768px), and desktop (1280px). For mobile: collapse navigation to a bottom nav or hamburger menu, stack all grid layouts vertically, increase tap target sizes to at least 44px, and ensure no horizontal overflow. For tablet: use a two-column layout where appropriate. Test every workflow at each breakpoint and list any component that required a significant structural change.

Write a spec to make this prototype fully responsive at mobile (375px), tablet (768px), and desktop (1280px). Define layout changes needed per breakpoint and navigation patterns appropriate to each screen size. Generate updated CSS and component changes. Prioritize mobile — assume that is the primary review device for stakeholders.

Update this prototype to be fully responsive across mobile (375px), tablet (768px), and desktop (1280px). Use CSS media queries or Tailwind responsive prefixes. Key requirements: no horizontal scroll at any breakpoint, navigation collapses appropriately on small screens, all interactive elements are thumb-reachable on mobile. After updating, list all components changed and the breakpoint-specific behavior added.

Audit this prototype against WCAG 2.2 AA. Cover: contrast ratios for text and UI components, form labels and accessible names, keyboard reachability and focus order, visible focus indicators, heading hierarchy, and any interactive element that isn't a real button or link. Produce a table — Component, Issue, WCAG criterion, Severity, Fix — sorted by severity. Separate issues you can fix in code from issues that need a design decision, and don't change brand colours without asking. Once I've reviewed the table, apply the code fixes only.

Write an accessibility audit spec for this prototype targeting WCAG 2.2 AA, then work through it with me. Check contrast, labels and accessible names, keyboard operability, focus order and visibility, and heading structure. Output findings as a checklist grouped by component, with each item marked as a code fix or a design decision. Don't apply fixes until I've reviewed the list.

Review this prototype for accessibility problems against WCAG 2.2 AA. Look for insufficient colour contrast, inputs without labels, images without alt text, interactive elements that can't be reached or operated by keyboard, missing focus styles, and skipped heading levels. For each, name the file and component, describe the failure, and suggest the fix. List anything that would require changing the visual design separately so I can decide on those myself.

Add toggleable annotation overlays to this prototype for these workflows: [list]. For each interactive element add a numbered callout that explains: what triggers it, what happens on interaction, any conditional behavior, and the resulting state. Add a global 'Show annotations' toggle button in the top-right corner. Annotations should not obscure the UI when hidden. After adding, confirm every workflow in the list has at least one annotation.

Write a spec to add annotation overlays to this prototype. Workflows to annotate: [list]. Each annotation callout should explain the trigger, behavior, and resulting state for the annotated element. The annotation layer should be toggleable without affecting the prototype layout. Generate the implementation and a list of all annotated elements.

Add a numbered annotation system to this prototype. For the following workflows [list], annotate every interactive element with a callout explaining: trigger, behavior, conditions, and resulting state. Implement as an overlay that can be toggled on/off via a button in the UI. Use a small numbered badge on each element and a sidebar panel that shows the full annotation when a badge is clicked.

<context>User type: [type] | Workflows to test: [list] | Prototype description: [paste]</context> Generate a usability test script. Include: (1) Facilitator intro script (2 min), (2) One task scenario per workflow — written from the user's perspective without revealing the solution path, (3) Observation prompts for each task (what to look for), (4) Post-task questions (1–2 per task), (5) Debrief questions. Flag any task where the prototype doesn't fully support end-to-end completion.

You are a UX researcher writing a usability test script. Based on these workflows [paste] for [user type], generate a test script with: a facilitator introduction, one task scenario per workflow (written from the user's perspective without revealing the answer), observation cues, and post-task questions. Then add a section for the facilitator on what to watch for and what follow-up questions to ask when a participant gets stuck.

Generate a usability test script for [user type] based on these workflows [paste]. Ground each task in how users in [domain] typically frame their goals — avoid UX or product language in the task wording. Include facilitator intro, task scenarios, observation prompts, post-task questions, and debrief. Flag any task scenario that might prime the participant toward the expected solution.

Create a usability test script for [user type] based on these workflows [paste]. Format as a Word document the facilitator can print and use in a moderated session. Include: script sections with clear labels, task scenarios in speech-bubble format (as if being read aloud), space for notes after each task, and a post-session debrief section. Keep language natural and conversational — this will be read aloud.

<context>Session notes: [paste] | Tasks tested: [list] | Participants: [number]</context> Synthesise these usability sessions. Produce: (1) a findings table with columns for Issue, Task, Participants affected, Severity, and Recovered unaided; (2) supporting quotes for each finding; (3) a separate list distinguishing usability failures from stated preferences; (4) anything raised by only one participant, flagged as unconfirmed. Do not inflate a single observation into a pattern — say when the evidence is thin.

You are a UX researcher synthesising usability test results. Here are notes from [number] sessions [paste] testing these tasks [list]. Identify what went wrong, group by task, and rate severity. Include quotes. Then give me the three findings I should take to the team first and explain why those three. Call out anywhere the evidence is too thin to justify a design change.

Synthesise these usability session notes [paste] from [number] participants testing [tasks]. Group findings by task and severity, note how many participants hit each issue, and include supporting quotes. Where a finding matches a known usability pattern or heuristic, name it. Flag observations that came from a single participant separately from confirmed patterns.

Synthesise these usability test notes [paste] into a findings report formatted for a Word document a client will read. Include an executive summary, a findings table (Issue, Task, Participants affected, Severity, Recommendation), supporting quotes, and prioritised next steps. Use plain language and avoid UX jargon — this will be read by non-designers.

Analyze this codebase and generate a complete feature inventory. For each feature document: feature name, what it does in plain language, which user type it serves, which workflow it belongs to, and the primary file(s) it lives in. Organize by section or module. At the end, flag any features that appear partially implemented or that lack a clear user-facing purpose.

Read this codebase and generate a feature inventory. For each feature: name, plain-language description, user type served, workflow it belongs to, and file location. Organize by module. Flag incomplete or stub features. Format the output as a markdown table I can copy into Confluence.

Audit this codebase and produce a feature inventory. List every user-facing feature with: what it does, which role uses it, and where it lives in the code. Organize by section. Flag any feature that appears to be placeholder or not yet wired to real functionality.

Remove the following features from this prototype: [list]. Ensure all remaining workflows still function end-to-end after removal — no broken navigation, missing components, or dead-end screens. Before removing, list any dependencies these features have on components or routes shared with features that are staying. After removal, do a full workflow walkthrough and confirm nothing is broken.

Write a spec to create an MVP-scoped version of this prototype. Features to remove for Phase 1: [list]. Features to keep: [list]. The spec should identify any dependencies between removed and retained features before making changes. Generate the updated prototype and confirm end-to-end workflows still function.

Scope this prototype down to the MVP feature set by removing: [list features]. Before removing, flag any shared components or routes that other features depend on. After removal, verify that remaining workflows are navigable end-to-end. Create a summary of what was removed and confirm what Phase 1 now covers.

Run a git diff between [branch/tag v1] and [branch/tag v2]. Summarize the changes in plain language organized by workflow or feature area. Format as: Added, Removed, Modified. Exclude dependency updates, config changes, and any diff under 5 lines that represents a style tweak. Focus on changes a stakeholder or PO would care about.

Generate a changelog by comparing this git diff [paste diff]. Summarize in plain language what was added, removed, and modified. Group by workflow or feature area. Write it for a non-technical stakeholder — avoid file names and technical jargon. Output as a formatted markdown changelog ready to paste into a Confluence page.

Analyze this git diff [paste diff] and generate a stakeholder-facing changelog. Group changes by workflow. Use plain language — no file names, no code references. Format as: ✅ Added, 🔄 Modified, ❌ Removed. Include a one-sentence summary at the top describing the overall focus of this iteration.

<context>User type: [type] | Prototype description or codebase summary: [paste]</context> Generate a user flow diagram as Mermaid syntax for [user type]. Show every screen reachable, every decision point encountered, and every exit or dead end. After the diagram, list any path where the user gets stuck with no clear next step — those are design gaps.

You are a UX designer documenting user flows. Based on this prototype description [paste], generate a user flow diagram for [user type]. Show the complete path from entry to exit, including all decision forks and alternative routes. Write the diagram in Mermaid syntax. Then identify the 3 most critical decision points and explain what the UX implication is if the user makes the wrong choice at each.

Generate a user flow diagram in Mermaid syntax for [user type] based on this prototype [paste description]. Map every screen reachable by this user type, every decision they face, and every exit point. After the diagram, evaluate whether the flow reflects best practices for [domain] type applications — note any steps where the flow could be simplified based on industry standards.

Based on this prototype description [paste], generate a user flow diagram for [user type]. Format as a numbered step list with decision branches clearly indented. Label each decision with Yes/No or the specific option chosen. Include a summary table below the flow listing: Total steps, Number of decision points, Number of dead ends. Format for a PowerPoint presentation.

<context>Component or screen: [name] | Prototype logic description: [paste relevant code or description]</context> Generate a state transition diagram in Mermaid stateDiagram-v2 syntax. Show every possible state, every transition trigger, and every condition that must be true for the transition to occur. After the diagram, flag any transition where the trigger is ambiguous — those are the conditions most likely to be implemented incorrectly by a developer reading the spec.

You are a UX designer documenting component behavior for a developer handoff. Based on this component description [paste], generate a state transition diagram for [component or screen name]. List every state it can be in, what triggers each state change, and any conditions required. Write in Mermaid stateDiagram-v2 syntax. Then list the 3 transitions most likely to be misunderstood and clarify each.

Generate a state transition diagram for [component or screen name] based on this description [paste]. Use Mermaid stateDiagram-v2 syntax. Map every reachable state, every transition trigger, and every conditional guard. After the diagram, evaluate whether the state model reflects how [this type of component] typically behaves in production — flag any state that appears to be missing based on standard UX patterns.

Create a state transition table for [component or screen name] based on this description [paste]. Format as a Word table with columns: Current State, Trigger/Event, Condition (if any), Resulting State. Include every possible state and transition. Add a brief summary above the table describing the component in one sentence for context. Format for sharing with a QA team.

<context>Prototype screens and UI copy: [paste or describe]</context> Generate an information architecture map. Show how content is grouped, how sections and categories are labeled, and how data entities relate to each other. Present as an indented hierarchy. Flag any inconsistencies in naming across screens — same concept labeled differently in different places. Note any grouping that contradicts typical user mental models for [domain].

You are an information architect auditing a product prototype. Based on this prototype description [paste], generate an IA map showing how all content is grouped, labeled, and structured. Use an indented hierarchy format. Then identify: (1) any label inconsistencies across screens, (2) any grouping that seems counterintuitive for the target user, and (3) any content that appears orphaned or hard to discover.

Analyze this prototype [paste description] and generate an information architecture map. Show the content hierarchy, section labels, and how data entities relate. Ground your evaluation in how [domain] products typically organize information — flag any structural decision that deviates from established patterns and explain the risk it creates for discoverability.

Based on this prototype description [paste], create an information architecture document formatted for a client review. Use an indented list showing all sections, categories, and content types. Add a second table flagging label inconsistencies found across screens. Keep language free of technical jargon. Format for Word with clear headings for each section.

Connect this repository to Vercel and configure it for automatic deployment on every push to main. Set the build command to [npm run build or equivalent] and the output directory to [dist or build]. Once deployed, output the production URL. If there is a base path configured in vite.config.ts or equivalent, confirm it is set to '/' for Vercel compatibility.

Write a deployment spec for pushing this prototype to Vercel. Steps: connect the GitHub repo, configure build settings (build command, output directory), enable automatic deploys on push to main, and confirm the public URL. Run in Supervised mode and confirm the live URL at the end.

Set up Vercel deployment for this prototype. Configure the project with the correct build command and output directory. Add a vercel.json if needed for routing (for SPAs, include a rewrite rule that catches all routes). Confirm auto-deploy is enabled on main. Output the live URL when done.

Build an in-app feedback tool for this prototype. (1) A floating feedback button on every page opening a compose panel with a comment field, a category selector, and the reviewer's name. (2) An 'attach a section' select mode: hovering outlines the section under the cursor and shows its name; clicking attaches it. Resolve the click to the nearest meaningful section — walk up from the clicked element until you find one with an explicit label or its own heading, and stop before you reach something the size of the whole page. (3) On selection, capture that section's rendered markup, its width, and the current build identifier. (4) Store submissions somewhere I own rather than a third-party service — propose two options before building. (5) Add a log view, kept out of the main navigation, that replays each snapshot at its captured width. Tell me which sections in this app already name themselves and which ones need an explicit label before you start.

Write a spec for an in-app feedback tool for this prototype, then build it once I approve. The spec should cover: a floating feedback button; a section select mode with hover outlining and a visible section name; resolving a click to the nearest named section rather than the raw element; capturing the section's rendered state, viewport width, and build ID at selection time; a storage approach that doesn't depend on a third-party service; and a log view that replays snapshots at the width they were captured. Call out the parts most likely to go wrong and how you plan to handle them before writing any code.

Add a feedback widget to this prototype. It needs a floating button on every page, a mode where clicking a section attaches it to the comment, and storage for each submission including the comment, the section name, the viewport width, and what the section looked like when it was selected. When resolving the click, use the nearest containing section that has a heading or an explicit label — not the exact element the user clicked. Add a separate page that lists the submissions and replays each captured section.

Audit this codebase for handoff readiness. Check for: (1) screens or states in the UI with no corresponding documentation, (2) components with missing interaction states (loading, error, empty), (3) data fields with no validation rules, (4) placeholder or inconsistent UI copy, (5) user flows with no defined error path. Output as a prioritized gap list. Mark each gap as High / Medium / Low based on how likely it is to block a developer.

Audit this prototype for dev handoff readiness. Review the codebase for: undocumented screens, missing component states, undefined validation rules, placeholder copy, and flows without error handling. Output a prioritized gap list with severity ratings. Run in Supervised mode so I can see each file reviewed.

Perform a handoff readiness audit on this prototype. Scan for: missing interaction states, undefined data validation, placeholder text, undocumented decision logic, and user flows with no error handling. Output a gap list organized by category. Flag the top 5 gaps most likely to result in developer questions on day one of the build.

<context>Workflows: [paste documentation] | User roles: [list]</context> Generate Jira-ready acceptance criteria for each workflow. Format each story as: Story title, User story (As a [role] I want to [action] so that [outcome]), and acceptance criteria in Given/When/Then format. After generating, flag any criterion that is not testable as written — those need to be rewritten before a developer can act on them.

You are a product owner writing Jira acceptance criteria. Based on this workflow documentation [paste] and these roles [list], generate a Jira story for each major workflow. Format: story title, user story statement (As a/I want/So that), and 3–5 Given/When/Then acceptance criteria. After each story, add a 'Definition of Done' checklist specific to that workflow.

Generate Jira stories with acceptance criteria for each workflow in this documentation [paste]. For each story: title, user story, and Given/When/Then criteria. Ensure each criterion is verifiable against a specific, observable outcome — not a general behavior. Flag any criterion that references a system capability not clearly demonstrated in the prototype.

Create Jira-ready user stories with acceptance criteria for each workflow [paste documentation]. Format as a Word table with columns: Story Title, User Story (As/Want/So That), Acceptance Criteria (Given/When/Then), Priority (High/Medium/Low). Use plain language suitable for a mixed technical and non-technical team. Format for copy-paste into Jira or Azure DevOps.

Generate a component inventory for this codebase. For each component: component name, all props with their TypeScript types, all possible states, and the screens or workflows where it appears. Format as a markdown table. Flag any component that is used in more than 3 places but has no documented shared prop interface — those are candidates for a design system extraction.

Read this codebase and generate a component inventory. For each component: name, props (with types), states, and screens where it appears. Format as a structured markdown table ready for Confluence. Flag any component that appears to be duplicated with slight variations — those should be consolidated before handoff.

Audit this codebase and produce a component inventory. List every React component with: its name, props and TypeScript types, all UI states it can render, and which screens it appears on. Output as a markdown table. Highlight any component that lacks prop types or uses 'any' — those need to be defined before dev handoff.

Generate accessibility annotations for this prototype for developer handoff, targeting WCAG 2.2 AA. Per screen: landmark regions, heading hierarchy, and intended reading order. Per interactive component: accessible name, role, keyboard interaction, focus behaviour including where focus moves on open and close, and live-region announcements for state changes. Output as markdown grouped by component, with a screen-level section above it. Flag every place the current markup would need to change to support the annotation.

Write an accessibility annotation spec for this prototype targeting WCAG 2.2 AA, for developer handoff. Cover landmarks, heading structure and reading order per screen, and accessible name, role, keyboard behaviour, focus management, and state announcements per component. Output as a structured document a developer can work from directly, and list any markup changes required to support it.

Produce accessibility annotations for this prototype for handoff. For each screen give landmark structure, heading order, and reading order. For each interactive component give the accessible name, role, keyboard behaviour, focus handling, and what should be announced on state change. Format as markdown grouped by component and note where the existing markup doesn't yet support the annotation.

Extract all design tokens from this codebase. Include: color palette (hex values + usage context), typography scale (font families, sizes, weights, line heights), spacing scale, border radii, and shadow styles. Format as CSS custom properties in a tokens.css file. Flag any value that appears more than once but is not yet tokenized — those are inconsistencies to resolve before handoff.

Extract design tokens from this codebase. Output: color palette with hex values, typography scale, spacing scale, border radii, and shadows. Format as CSS custom properties in a separate tokens.css file. Flag any hardcoded values that should be tokenized but aren't. Run in Supervised mode so I can approve the token naming convention before the file is written.

Generate a design token file from this codebase. Scan all CSS, Tailwind config, and inline styles. Extract all color values, font sizes, spacing values, border radii, and shadows. Output as CSS custom properties in /src/tokens.css. Use a consistent naming convention (--color-{name}, --font-size-{size}, --space-{n}). List any value that appears hardcoded in more than one place but isn't yet extracted.

Generate a complete sitemap for this prototype by reading the router configuration and page components. For each page: route path, page title, primary user type, and how it connects to other pages. Format as a hierarchical markdown list. Flag any route that is defined in the router but has no corresponding page component — those are skeleton routes that need to be filled before handoff.

Read this codebase and generate a sitemap. For each page: route path, page name, user type, and parent/child relationships. Format as an indented hierarchy in markdown. Flag incomplete or stub routes. Output ready to paste into a Confluence or Notion page.

Analyze the router configuration in this prototype and generate a sitemap. List every route with: path, page name, primary user type, and navigation connections. Format as an indented hierarchy. Flag any routes without a corresponding component or with placeholder content. Also list any navigation links in the UI that don't have a corresponding route definition.

Set up a Playwright script that identifies all user workflows in this prototype, navigates through each step, and captures a full-page screenshot at each state. Save screenshots to /screenshots/{workflow-name}/{step-number}-{step-label}.png. List all identified workflows before running the script so I can confirm coverage.

Write a spec to extract step-by-step screenshots from this prototype using Playwright. The script should: identify all major workflows, navigate each step in sequence, capture a screenshot at each state, and save to a folder organized by workflow name. Generate the Playwright script and run it. Output the file list when complete.

Create a Playwright screenshot script for this prototype. The script should walk through every major workflow step by step, take a full-page screenshot at each state, and save to /screenshots/{workflow}/{step-number}-{description}.png. First list all workflows it will cover, then run the script. Confirm the output file count after completion.

Generate a standalone SVG export for each unique screen in this prototype. Each SVG should be 1440x900. Structure layers as named groups: header, navigation, content, actions. Save to /exports/svgs/{screen-name}.svg. After generating, list all exported files and flag any screen where layer grouping was ambiguous.

Write a spec to export each screen of this prototype as a standalone SVG file for import into Figma. Requirements: 1440x900 dimensions, named layer groups (header, navigation, content, actions), organized by workflow. Generate the export script and run it. Confirm the output file list.

Create an SVG export script for this prototype. For each unique screen state, render a 1440x900 SVG with named layer groups for header, navigation, content, and actions. Save to /exports/svgs/. Name each file to match the screen it represents. List all generated files after the export completes.

Analyze the routing and navigation logic in this prototype and generate a workflow map as a Mermaid diagram. Show every screen as a node, every navigation link as a directed edge, and every decision point as a labeled branch. After the diagram, list any screens that are reachable but not connected from the main navigation — those are dead ends that need design decisions.

Read this prototype codebase and generate a Mermaid flow diagram showing how all screens connect. Include: all screens as nodes, navigation links as directed edges, and decision points as labeled branches. Export as both Mermaid syntax (for version control) and as a rendered SVG (for Figma import).

Generate a workflow map for this prototype by analyzing the router and navigation components. Output as a Mermaid flowchart showing all screens, connections, and decision branches. Then render it as an SVG file at /exports/workflow-map.svg for import into Figma. Flag any disconnected screens or dead-end flows.

<context>Roles: [list] | Prototype screens and actions: [paste description]</context> Generate a permission matrix as a table. Rows: screens and key actions. Columns: one per role. Cells: View / Interact / Restricted / Conditional (with condition noted). After the table, flag every cell marked Conditional — those are the permissions most likely to cause dev misunderstanding if not explicitly defined.

You are a UX designer documenting permissions for a multi-role application. Based on this prototype [paste description], generate a permission matrix for these roles: [list]. Format as a table with screens/actions as rows and roles as columns. Mark each cell as: Full Access, Read Only, Restricted, or Conditional. After the table, list every ambiguous permission and propose a resolution for each.

Generate a permission matrix for this prototype [paste description] covering these roles: [list]. Format as a table. For any permission marked Conditional, explain the condition in plain language. After the table, evaluate whether the permission model reflects standard security patterns for [domain] type applications — flag any permissions that appear unusually broad or restrictive compared to industry norms.

Create a permissions matrix for this prototype [paste description] covering these user roles: [list]. Format as a Word table suitable for a client presentation. Rows: each screen and key action. Columns: each role. Use simple symbols: ✓ (full access), 👁 (view only), ✗ (no access), ⚠ (conditional). Add a brief legend and a one-sentence description of each role above the table.

<context>Prototype description or notification logic: [paste]</context> Catalog all notifications and alerts. For each produce: notification name, trigger event, recipient(s), delivery channel (in-app / email / SMS), message content or template, and any conditions that suppress or modify it. Format as a table. Flag any notification where the trigger, timing, or recipient is not explicitly defined — those are gaps that will become developer assumptions.

You are a UX designer creating a notification inventory for developer handoff. Based on this prototype description [paste], catalog every notification, alert, status update, and email trigger. For each document: trigger, recipient, channel, content, and suppression conditions. After the inventory, group notifications by workflow and identify any workflow that has no user-facing communication — those may be missing a confirmation or status update.

Generate a notification inventory for this prototype [paste description]. For each notification: trigger, recipient, channel, content, and conditions. After the inventory, evaluate whether the notification strategy reflects best practices for [domain] — flag any pattern that is inconsistent with how this type of application typically communicates status or progress to users.

Create a notification and alert inventory for this prototype [paste description]. Format as a Word table with columns: Notification Name, Trigger Event, Recipient, Channel (In-App/Email/SMS), Message Template, Conditions. After the table, add a brief summary paragraph describing the overall communication strategy for a stakeholder review. Use plain business language throughout.

Review this codebase and extract every business rule as a plain-language statement. For each rule document: what triggers it, what it controls, and any exceptions or edge cases. Organize by workflow or feature area. Number each rule. Flag any rule where the logic is implemented in the prototype but no business rationale is evident — those need stakeholder sign-off before dev builds on top of them.

Read this codebase and generate a business rules log. For each conditional or logic branch: describe the rule in plain language, what triggers it, what it controls, and any exceptions. Group by workflow. Flag rules that appear to be placeholder logic rather than a deliberate business decision. Output as a numbered markdown list.

Analyze the conditional logic in this prototype and extract every business rule. Format as a numbered log organized by workflow. For each rule: plain-language description, trigger, outcome, exceptions. Flag any rule that conflicts with another rule in the same workflow — those are bugs or unresolved design decisions.

Generate a data dictionary for this prototype. For every field and data element: UI label (what the user sees), field name in code, data type, required/optional, validation rules, and default value. Format as a markdown table. Flag any field where the UI label differs significantly from the code variable name — those mismatches will confuse developers aligning with a back-end API.

Read this codebase and generate a data dictionary. For each field: UI label, code variable name, type, required/optional, validation rules, default value. Format as a markdown table. Flag fields that lack validation rules — those need to be defined before the back-end team writes the API spec.

Produce a data dictionary for this prototype by scanning all form components, data models, and state definitions. For each field: UI label, variable name, type, required/optional, validation, default value. Output as a markdown table. Flag any field that appears in the UI but is not stored or transmitted anywhere — those are display-only fields that need to be clearly labeled as such in the handoff.

Catalog all edge cases and error states in this prototype. For each: screen/component, trigger condition, message shown to user, UI treatment, and recommended next action. Include empty states, validation errors, system errors, and timeout states. Format as a table. After the table, list any interaction in the prototype that has no corresponding error handling — those are gaps that will surface as bugs in QA.

Read this codebase and produce an edge case and error state catalog. For each: location, trigger, user-facing message, UI treatment, next action. Include empty states, validation, system errors, and timeouts. Flag any component that handles user input but has no error state defined. Output as a markdown table.

Audit this prototype for error states and edge cases. For every component that can fail, produce a catalog entry: screen, trigger condition, error message, UI treatment, next action. Also identify components that should have error states but don't — those are QA blockers. Output as a markdown table sorted by severity.

Extract all UI copy from this prototype organized by screen. For each piece of copy: screen name, element type (heading / label / button / error message / placeholder / tooltip / empty state), and exact text. Format as a markdown table. After the table, flag: (1) any inconsistency in terminology for the same concept across screens, (2) any placeholder text still in the UI, (3) any copy that uses different casing or punctuation conventions inconsistently.

Read this prototype and extract all UI copy. For each text string: screen, element type, and exact copy. Format as a table. After extraction, flag terminology inconsistencies, placeholder text, and any copy that contradicts the tone or vocabulary used elsewhere. Output as a markdown table ready for a content review session.

Generate a copy audit for this prototype by extracting every text string in the UI. Organize by screen. For each: element type and exact text. Then produce a separate consistency report flagging: different labels for the same concept, mixed casing, placeholder text, and copy that may need localization consideration. Output both as markdown tables.

Document the business logic for [feature or workflow] in this prototype. Include: all validation rules and conditions, when elements show or hide based on state, how data flows between steps, any calculations or transformations applied, and integration points with external systems. Flag any logic that is implemented as a UI hack in the prototype but would require a different technical approach in production.

Read the [feature or workflow] implementation in this codebase and generate business logic documentation. Cover: validation rules, conditional display logic, data flow, calculations, and external dependencies. Format for Confluence. Flag any prototype-specific shortcuts that won't work in production — those need a technical design decision before the build starts.

Document the business logic for [feature or workflow] in this prototype. For each logical component: describe what it does, what data it depends on, what it outputs, and any conditions that modify its behavior. Flag any logic that depends on hardcoded values, mock data, or prototype-only assumptions. Output as structured markdown ready for Confluence or Notion.

<context>Workflows: [paste documentation] | Business goals: [paste] | Analytics platform: [Mixpanel / Amplitude / GA4]</context> Generate an analytics instrumentation plan. For each key interaction: event name (snake_case), trigger (what the user does), properties to capture, and the business question it answers. Organize by workflow. Flag any event that could surface privacy concerns — PII captured as an event property needs a legal review before instrumentation.

You are a product analyst designing an analytics tracking plan. Based on these workflows [paste] and business goals [paste], generate an instrumentation plan for [analytics platform]. For each event: name, trigger, properties to capture, and the metric or question it helps answer. Organize by workflow. After the plan, suggest a North Star metric for this product based on the workflows and goals, and list the 3 events most critical to tracking it.

Generate an analytics instrumentation plan based on these workflows [paste] and business goals [paste]. For each key user interaction: event name, trigger, properties, and business question it answers. Ground event selection in analytics best practices — focus on behavioral signals that indicate value delivery, not just activity counts. Flag any workflow that has no trackable completion event.

Create an analytics instrumentation plan based on these workflows [paste] and business goals [paste]. Format as a Word table with columns: Workflow, Event Name, User Trigger, Properties to Capture, Business Question Answered. Use snake_case for event names. Add a brief summary paragraph at the top explaining the tracking strategy and the primary KPIs this plan supports. Format for sharing with a development and product team.