AI prompts for startups, UI and UX.

Explore free templates and member resources. Member prompt bodies require authorized access.

Act as a Principal Full-Stack Engineer, Cloud Security Architect, and Conversion Rate Optimization (CRO) Expert specializing in [industry / product category] SaaS platforms.

Perform a rigorous, end-to-end audit of [startup / product name] across its public marketing site, customer onboarding portal, mobile workforce or user application (if applicable), backend management hub, APIs, databases and integrations.

PROJECT CONTEXT
- Product and target customers: [name, industry, audience and core value]
- Surfaces and URLs: [marketing, onboarding, mobile app, management hub, API]
- Stack and hosting: [frameworks, database, authentication, cloud and third-party services]
- Roles and tenancy: [roles, organizations, ownership and access boundaries]
- Critical workflows: [signup, service or product selection, delivery, payment and administration]
- Available evidence: [sanitized source code, architecture, logs, metrics and test results]
- Pricing and usage limits: [free and paid tiers, credits, customer or seat caps and add-ons]
- Margin target: [target gross margin percentage and definition of included costs]
- Competitors: [relevant products and pricing URLs]
- Lead-generation model, if applicable: [targeting, geographic limits, consent and delivery rules]
- Constraints: [budget, timeline, jurisdictions and launch requirements]

Baseline against applicable industry best practices. Inspect supplied evidence and accessible systems within the authorized scope. Ask focused questions for missing critical inputs. Separate confirmed findings, assumptions and unverified risks; cite files, routes, queries or observed behavior. Do not invent vulnerabilities, performance measurements, competitor prices or passed tests. Mark inapplicable workflows as such. Propose reviewable patches without assuming permission for production changes.

## 1. User experience and workflow audit (UX/CRO)
- Customer flow: audit acquisition or referral entry, account creation, required inputs, selection or configuration, scheduling where relevant, checkout, payment enrollment, confirmation and recovery.
- Mobile or workforce flow: evaluate task visibility, team boundaries, instructions, next action or route clarity where relevant, low-connectivity behavior and durable asynchronous uploads or completion attachments.
- Management hub: review activity logs, customer portfolios, operations feeds, reporting, configuration and permissions.
- Identify friction, weak microcopy, accessibility issues, responsive layout problems and missing empty, loading, error and success states. Compare relevant competitor workflows using observable evidence.
- Provide revised copy and actionable workflow acceptance criteria.

## 2. Security and compliance infrastructure audit
- Threat-model all surfaces, trust boundaries, sensitive data and integrations.
- Multi-tenant isolation: inspect database policies and API ownership checks for cross-tenant leaks and insecure direct object references (IDOR). Include private files and signed-link access.
- Authentication and permissions: evaluate RBAC, least privilege, session handling, OAuth redirects, account recovery and privileged access controls.
- Harden critical endpoints such as geocoding (if used), payment webhooks and customer data APIs. Propose appropriate rate limits, CORS policies, input validation, webhook signature verification and secret handling.
- Map applicable privacy, retention, consent and regulatory requirements to evidence. Identify items requiring jurisdiction-specific legal review; do not claim compliance without verification.

## 3. Technical debt, duplicate code and refactoring
- Inspect repeated component and utility logic across surfaces, including validators, calculations, mapping utilities where applicable, dates, authorization and API clients.
- Identify inconsistent implementations, coupling and obsolete code with concrete file references.
- Propose a maintainable shared workspace architecture when warranted, such as packages/shared-ui and packages/core-utils, with clear ownership, dependency boundaries and environment separation.
- Provide an incremental migration plan and behavior-preserving patches. Do not recommend a monorepo solely for its own sake.

## 4. Code optimization and performance tuning
- Assess bundle size, dynamic loading, media optimization and asset lifecycle. Distinguish immutable public assets from personalized or private content in caching policies.
- Investigate measured runtime and database bottlenecks, including N+1 queries, heavy dashboards, route calculations where applicable and billing aggregation.
- Propose indexes based on query plans and appropriate cache strategies, including tenant-safe keys, invalidation and consistency requirements. Use Redis only where justified.
- Review responsive layouts, light/dark mode, CSS variables or design tokens, readable contrast and usability in bright or low-light environments.
- Include measurement methods, budgets and regression checks for each recommendation.

## 5. Strategic pricing and competitive audit
- Review the supplied free-tier caps, paid growth tiers, usage credits, team or capacity limits and add-ons against customer value and cost to serve.
- Model the supplied margin target using revenue, infrastructure, AI usage, support, payment processing and other relevant costs. Show assumptions, sensitivity and break-even; distinguish gross margin from net profit.
- Verify current competitor pricing through official sources, with retrieval date, currency, billing cadence, limits and add-ons. If browsing is unavailable, mark prices unverified and request sources.
- Recommend pricing experiments that balance positioning, conversion, retention and margin; do not assume undercutting is always best.
- If lead generation is relevant, map demand capture, targeting rules, consent, qualification, deduplication, ownership, operator matching and delivery. Use [geographic radius or segmentation options] rather than fixed industry-specific limits.
- Draft clear disclaimers for estimated demand and no guaranteed conversions, with applicable privacy and legal review requirements.

## 6. Billing, subscription and idempotency tests
- Design an integration and end-to-end testing matrix for [payment provider, such as Stripe].
- Prevent duplicate charges and credit grants on retries, webhook redelivery, concurrent events and dropped updates using idempotency keys, unique event constraints and transactional state transitions.
- Verify recoverable order or deliverable state before charging, and handle asynchronous payment outcomes, refunds and reconciliation.
- Cover interrupted plan changes, partial failures, out-of-order events, entitlement changes, cancellation, grace periods and credit distribution edge cases.
- Provide Playwright or equivalent blueprints for customer signup, test-mode checkout, payment completion, server-side entitlement or credit verification and management billing history.
- Include tenant-isolation and unauthorized-access negative tests. Use synthetic accounts and test-mode payments; never report tests as passed without execution evidence.

## Output requirements
Deliver the report under clear Markdown headers with itemized findings. Use concise tables for copy revisions, configuration recommendations, competitor comparisons and the billing test matrix.
For each finding include severity, evidence, user or business impact, affected surface, proposed fix, acceptance criteria and validation steps. Prioritize launch blockers before improvements.
Provide stack-appropriate patches or clearly labeled implementation blueprints, including prerequisites, rollout and rollback considerations. Separate completed verification from tests still to run. Keep instructions direct, technical and implementation-focused.

Act as a LinkedIn Strategist, Personal Branding Expert, and B2B Lead Generation Specialist.

GOAL
Transform my LinkedIn profile into an asset that attracts the right people, builds credibility, and generates qualified leads.

MY INFORMATION
• Current LinkedIn headline: [INSERT HEADLINE]
• About section: [INSERT ABOUT]
• Current role/business: [INSERT ROLE]
• Skills/expertise: [INSERT SKILLS]
• Target audience/ideal clients: [INSERT AUDIENCE]
• Problems I solve: [INSERT PROBLEMS]
• Services/offers: [INSERT SERVICES]
• Proof/results: [INSERT RESULTS, IF ANY]
• Main goal: [INSERT GOAL]

TASK
Analyze the information provided and identify what is weakening my positioning, credibility, clarity, and ability to convert profile visitors.

Then rewrite or improve:
1. Headline
2. About section
3. Experience section
4. Featured section strategy
5. Call-to-action
6. Profile positioning

STRUCTURE
Make each section clearly address:
• Who do I help?
• What problem do I solve?
• Why should they trust me?

DELIVERABLES
• A concise profile audit with the highest-priority improvements
• Revised profile sections ready to use
• 3 positioning options
• 5 profile CTAs
• 5 content topics that attract my ideal prospects
• A simple profile-to-lead journey

CONSTRAINTS
Keep the positioning specific, credible, outcome-focused, and natural.
Do not use exaggerated claims, generic buzzwords, or empty corporate language.
Do not invent results, credentials, client names, testimonials, or metrics.
If important information is missing, ask focused questions or use clearly marked placeholders.

Act as a UX startup strategist. For [idea], serving [audience], solving [observed problem], outline the riskiest assumptions, five neutral interview questions, a small demand test and success criteria. Separate evidence from assumptions. Do not invent market figures or claim the idea is validated.

Design a responsive UI for [product] helping [user] complete [task] in [context]. Define content hierarchy, primary action, components, keyboard behavior, and empty, loading, error and success states. Use [brand constraints]. Explain each major decision in terms of the user need.

Review [screen or markup] for keyboard access, focus order, semantic controls, accessible names, contrast and error recovery. Return likely issues, suggested fixes and manual test steps. Do not claim WCAG conformance without testing.

Create a discovery brief for [product]. Users: [audience]. Evidence: [observations]. Outcome: [desired result]. Constraints: [platform, timeline, security]. Return problem, scope, assumptions, research questions and a validation plan. Label missing evidence.

For a UX team building [product], draft AI working standards covering privacy, evidence, accessibility, human review, design approval and development handoff. Define owner, required evidence and review checkpoints for each. Keep weekly reporting concise.

Act as a senior UX strategist. Help me frame a discovery brief for [product].
Audience: [users and context]
Need: [problem and observed evidence]
Outcome: [desired user and business outcomes]
Constraints: [platform, security, accessibility, timeline]
Return: problem statement, research questions, scope, success criteria, assumptions, risks, and validation plan. Clearly label assumptions. Do not invent research findings.

Create a moderated interview guide for [audience] about [task].
Decision to inform: [decision]
Unknowns: [questions]
Session length: [minutes]
Include an introduction, consent reminder, open questions about recent behavior, neutral follow-ups, and a closing. Avoid leading questions and speculative feature preferences.

Using only the sanitized research notes below, outline a persona with goals, context, behaviors, obstacles, accessibility needs, and evidence references. Label unsupported fields as unknown. Do not fabricate demographics or participant quotes.
Notes: [sanitized observations]

Create a prototype for [product].
User and situation: [context]
Primary task: [task]
Success: [outcome]
Platform: [responsive web / iOS / other]
Flow: [steps]
Include empty, loading, error, success, and recovery states. Specify responsive behavior, keyboard interaction, semantic controls, and accessible labels. Identify assumptions and ask about critical missing information before generating.

Draft a usability study plan for [product].
Study questions: [questions]
Participants: [audience and inclusion needs]
Tasks: [realistic tasks]
Include recruitment criteria, neutral task scenarios, consent and privacy considerations, success measures, moderator guidance, and a findings format. Do not present hypothetical results as observed evidence.

Create a UX handoff checklist for [feature] on [platform].
Include approved flow, component references, content, data rules, required and optional fields, responsive behavior, accessibility expectations, error handling, acceptance criteria, open questions, and implementation review steps.

Create three offers for [startup] serving [customer]. Use [problem evidence] and [desired outcome]. Give promise, scope, reason to believe, pricing hypothesis and a validation experiment. Do not invent demand.

For [offer], build a worksheet using [price], [variable costs], [delivery hours] and [acquisition cost]. Show assumptions, gross margin, break-even and sensitivity. Ask for missing inputs; never present estimates as verified results.

Draft a pilot for [offer] with [audience], [problem], [budget] and [timeline]. Define recruitment, neutral tasks, success criteria, consent, support and go / revise decisions. Do not fabricate results.

For [business], [audience] and [offer], create positioning, voice and visual brief using [evidence]. Include accessibility considerations and identify claims needing validation.

Design a course about [topic] for [audience] at [level]. Define outcomes, modules, objectives, practice, video outline, PDF slides and review criteria. Do not invent certifications or recordings.

Review [course outline]. Create checks for accurate captions, transcripts, meaningful visuals, readable PDFs, keyboard playback and alternative instructions. Separate recommendations from verified findings.

For [startup], define the minimum workflow delivering [outcome]. Include screens, ownership, authorization, responsive states, errors, recovery and acceptance criteria. Label assumptions.

Audit [product] using [architecture and test evidence]. Cover onboarding, recovery, isolation, payments, mobile, accessibility, privacy, support and rollback. Give confirmed findings, unverified risks and remediation. Never claim tests passed without evidence.

Act as a front-end developer who specializes in the U.S. Web Design System (USWDS 3).

MY SITE
• Agency / program: [NAME]
• Audience: [WHO USES THE SITE]
• Brand colors (hex): [PRIMARY, SECONDARY, ACCENT]
• Preferred fonts: [FONTS, or "use USWDS defaults"]
• Build setup: [e.g. @uswds/compile with gulp, or Sass in my own build]

TASK
1. Map each brand color to the closest USWDS system color token (e.g. "blue-60v") and say which theme token it should set (primary, primary-dark, secondary, accent-cool, accent-warm, base).
2. Write the _uswds-theme.scss settings block using @use "uswds-core" with (...).
3. Pick type settings ($theme-font-type-sans, -serif, -mono) from fonts USWDS supports, and say what to do if my brand font isn't one of them.
4. Check every text/background pair I'm likely to use against the USWDS "magic number" (grade difference 50+ for normal text, 40+ for large text) and flag failures.

FORMAT
• A token mapping table: Brand color | Hex | Closest system token | Theme token | Grade
• The Sass block in a code block
• A short list of pairs that fail contrast, with a passing alternative

RULES
• Use only real USWDS tokens. If you're unsure a token exists, say so.
• Don't hard-code hex values in components; everything goes through tokens.
• Tell me which settings to verify against designsystem.digital.gov.

Act as a senior UX designer on a federal digital service team using USWDS.

PAGE
• Page purpose: [e.g. Apply for a benefit / Find a clinic / Program overview]
• Primary user task: [ONE TASK]
• Content I have: [PASTE OUTLINE OR KEY CONTENT]
• Site type: [informational / transactional / internal tool]

TASK
Plan this page using standard USWDS components:
1. Required site elements: official government banner (usa-banner), header and navigation, identifier and footer. Say which variant fits.
2. Body layout using the USWDS layout grid (grid-container, grid-row, grid-col) for mobile, tablet and desktop.
3. For each section, name the component (e.g. usa-alert, usa-summary-box, usa-card, usa-step-indicator, usa-process-list, usa-accordion, usa-button) and why.
4. Headings in order (one h1), and the primary call to action.
5. Accessibility notes: landmarks, skip link, focus order, link text.

FORMAT
A section-by-section table: Section | USWDS component | Content | Why. Then starter HTML using usa- class names.

RULES
• Prefer an existing USWDS component over a custom one. Flag any custom pattern and justify it.
• Don't invent component names or modifiers. Mark anything uncertain [CHECK DOCS].

Act as a USWDS front-end reviewer who keeps sites on-system.

HERE IS MY CURRENT MARKUP AND CSS
[PASTE HTML + CSS]

TASK
1. Replace custom CSS with USWDS utility classes wherever possible (spacing units like padding-2 / margin-y-4, text, color, flex, display, border, radius, shadow).
2. Where a utility doesn't exist, write Sass that uses USWDS functions and tokens (units(), color(), font-size(), etc.) instead of raw values.
3. Flag any raw hex, px or font sizes that bypass tokens.
4. Point out responsive prefixes I should use (e.g. tablet:, desktop:).

FORMAT
• Before / After code blocks
• A table: Old CSS | USWDS replacement | Note

RULES
• Remember 1 USWDS spacing unit = 8px. Show the math when you convert.
• Don't change the visual design unless the original fails contrast or touch-target size; if so, say why.
• Mark any utility you're unsure exists as [CHECK DOCS].

Act as a content designer and accessibility specialist using USWDS form components.

FORM
• What the form collects: [FIELDS]
• Who fills it in: [AUDIENCE, devices, assistive tech needs]
• What happens after submit: [OUTCOME]

TASK
1. Cut any field that isn't needed. Explain each cut.
2. Group the remaining fields with fieldset/legend and order them the way people think.
3. For each field: usa-label text, usa-hint text (if needed), input type, autocomplete value, required/optional marking, and validation rule.
4. Write the usa-error-message text for each error: what went wrong and how to fix it.
5. Decide if this should be one page or a multi-step form with usa-step-indicator.
6. Draft the confirmation message.

FORMAT
A field table: Field | Label | Hint | Type | autocomplete | Required | Error message. Then starter HTML.

RULES
• Plain language, 8th-grade reading level or lower.
• Mark optional fields, not required ones, unless my agency's style says otherwise. Ask if unsure.
• Never rely on placeholder text as a label.

Act as a Section 508 / WCAG 2.2 AA reviewer for a federal website built with USWDS.

PAGE
[PASTE HTML, a written description of the page, or a list of its components]

TASK
Review the page and report issues in these areas:
1. Structure: landmarks, heading order, skip link, page title, lang attribute
2. Keyboard: focus order, visible focus, traps, controls reachable without a mouse
3. Color & contrast: text, icons, focus rings, states (use USWDS grade differences where tokens are known)
4. Forms: labels, hints, error messages, grouping
5. Media & images: alt text, captions, transcripts
6. Components: any USWDS component used differently from its documented markup
7. Content: link text, plain language, tables with headers

FORMAT
A table: Issue | WCAG criterion | Element | Severity (blocker / major / minor) | Fix.
Then a list: "Needs a human / assistive tech check" for things you can't verify from code.

RULES
• Don't claim the page is "508 compliant." You're preparing it for formal testing.
• Cite WCAG success criteria by number only when you're confident.

Act as a federal content designer who follows the Federal Plain Language Guidelines.

CONTENT
[PASTE THE ORIGINAL TEXT]
Audience: [WHO READS IT, their situation, reading level]
Goal: [WHAT THEY NEED TO DO OR KNOW]

TASK
1. Rewrite the content for the web: short sentences, active voice, "you" for the reader, common words.
2. Put the most important information first.
3. Break it into sections with descriptive headings, short paragraphs, and lists where it helps.
4. Suggest which USWDS components could help (usa-summary-box for key points, usa-process-list for steps, usa-alert for deadlines).
5. List any legal or policy phrases that must stay as written, and flag them for review.

FORMAT
• Rewritten content
• A table: Original phrase | Plain version | Why

RULES
• Keep the meaning exactly the same. Don't add or drop requirements, dates or eligibility rules.
• Flag anything ambiguous instead of guessing.

Act as a design systems auditor for a team that uses USWDS.

INPUT
[PASTE a list of colors, font sizes, spacing values and radii used in the design, or the CSS/Figma variables]

TASK
1. Map every value to the nearest USWDS token: color (system or theme token), spacing unit, font size token, radius, shadow.
2. Flag values that don't match any token, and say whether to round to a token or request a new one.
3. Flag near-duplicates (e.g. three slightly different blues).
4. Check text color pairs for USWDS magic-number contrast.

FORMAT
A table: Found value | Where used | Nearest USWDS token | Difference | Action (use token / keep / request).
End with a count: on-system vs off-system values.

RULES
• Don't invent tokens. If no token fits, say "no match."
• Note which values need a designer's judgment, not just rounding.

Act as a design system lead on a federal team that extends USWDS.

NEED
• What users need to do: [TASK]
• Why existing USWDS components don't work: [REASON]
• Where it will appear: [PAGES / PRODUCTS]

TASK
1. First, list the closest existing USWDS components and patterns, and explain whether a variant or combination could solve the need.
2. If a new component is still needed, write a component proposal:
   • Name (by job, not looks) and use-when / don't-use-when guidance
   • Anatomy and variants
   • States: default, hover, focus, active, disabled, error
   • Accessibility: keyboard behavior, ARIA, screen reader output
   • Tokens it uses (color, spacing, type) — existing tokens only
   • Research or evidence that supports it
3. A short plan to test it with real users.

RULES
• Reuse before you invent. Push back if a new component isn't justified.
• Don't claim USWDS endorses the component.

Act as a Salesforce UX architect and certified admin.

CONTEXT
• Object: [e.g. Case, Opportunity, custom object]
• Who uses this page: [ROLES / PROFILES]
• Their top 3 tasks on this record: [TASKS]
• Current pain points: [e.g. too many fields, users scroll to find status]
• Fields available: [PASTE FIELD LIST]

TASK
1. Propose a Lightning record page layout using Lightning App Builder: template, regions, tabs, components.
2. Use Dynamic Forms to group fields into sections and set visibility rules by role or record state.
3. Recommend a Path with key fields and guidance for success per stage, if the object has a status process.
4. Choose the compact layout fields (what shows in the highlights panel).
5. Recommend Dynamic Actions: which buttons show, when.
6. List related lists to keep, cut or move to a tab.

FORMAT
• A wireframe described region by region
• A table: Field / component | Section | Visible when | Why

RULES
• Fewer fields above the fold. Justify every field you keep there.
• Mark any feature that depends on edition or licensing as [CHECK ORG].
• Don't invent field API names. Use the ones I gave you.

Act as a Salesforce front-end developer who follows the Salesforce Lightning Design System (SLDS).

COMPONENT
• What it does: [DESCRIPTION]
• Where it lives: [record page / app page / Experience Cloud site]
• Current markup and CSS: [PASTE, or "starting fresh"]
• Brand needs: [e.g. org theme colors]

TASK
1. Use base Lightning components (lightning-card, lightning-button, lightning-datatable, etc.) wherever they fit before writing custom markup.
2. For custom markup, use SLDS blueprint classes and utility classes (slds-grid, slds-col, slds-p-around_medium, slds-text-heading_small, etc.).
3. Replace hard-coded colors and spacing with SLDS styling hooks / design tokens. Note which SLDS version my org uses changes the hook names, and tell me what to check.
4. Cover states: loading (spinner), empty, error, and success toast.
5. Accessibility: labels, keyboard behavior, focus, aria attributes.

FORMAT
HTML template, JS (only what's needed), CSS, then a short checklist of what to verify in my org.

RULES
• Don't override SLDS classes with !important.
• Mark any class or hook you're unsure exists as [CHECK SLDS DOCS].

Act as a Salesforce Flow designer focused on usability.

PROCESS
• What users are trying to do: [e.g. log a site visit, request a refund]
• Who runs the flow: [ROLE]
• Data it reads and writes: [OBJECTS / FIELDS]
• Where it starts: [button, record page, utility bar, Experience Cloud]

TASK
1. Break the process into the fewest screens possible. Say what each screen asks and why.
2. For each screen: components (text, picklist, lookup, data table, etc.), labels, help text, required fields, and default values.
3. Add conditional visibility so people only see relevant fields.
4. Write validation and fault-path messages in plain language.
5. Define the finish: confirmation text, where the user lands, what records change.
6. List edge cases: duplicate record, missing permission, user closes mid-flow.

FORMAT
A screen-by-screen table, then a simple text diagram of the flow (screens, decisions, actions, fault paths).

RULES
• Ask only for information the system can't already look up.
• Every fault path needs a human-readable message.
• Mark anything that depends on org configuration as [CHECK ORG].

Act as a Salesforce admin who cares about data quality and user experience.

CONTEXT
• Object: [OBJECT]
• Data problems we see: [e.g. closed cases with no resolution, opportunities with past close dates]
• Fields involved (API names): [LIST]
• Who should be exempt: [e.g. integration user, system admins]

TASK
For each data problem:
1. Write the validation rule formula.
2. Explain in one plain sentence what it blocks.
3. Write the error message: what's wrong and how to fix it, shown at the field when possible.
4. Note the bypass approach for exempt users (e.g. a custom permission check).
5. List test cases: one record that should pass, one that should fail.

FORMAT
One block per rule: Name | Formula (code block) | Error message | Error location | Test cases.

RULES
• Use only the field API names I gave you. Ask if one is missing.
• Avoid rules that will break existing integrations; flag the risk.
• Remind me to test in a sandbox first.

Act as a Salesforce reporting analyst and dashboard designer.

AUDIENCE
• Who views it: [ROLE, e.g. regional manager]
• Decisions they make with it: [DECISIONS]
• Questions they ask every week: [LIST]
• Objects and key fields: [LIST]

TASK
1. For each question, define the report: report type, grouping, filters, summary fields and time frame.
2. Choose a dashboard component for each (metric, gauge, bar, line, table) and say why.
3. Lay out the dashboard: most important number top-left, max [8] components.
4. Recommend dashboard filters and the running user setting.
5. Flag questions the current data can't answer, and what field or process would fix that.

FORMAT
A table: Question | Report setup | Component | Position. Then a simple layout sketch in text.

RULES
• No vanity metrics. Every component must support a decision.
• Don't invent data or numbers. Use placeholders.
• Mark report types that may need a custom report type as [CHECK ORG].

Act as a Salesforce security and access architect.

CONTEXT
• User roles in the business: [LIST ROLES and what each does]
• Objects and sensitive fields: [LIST]
• Current state: [e.g. many cloned profiles, everyone is admin]

TASK
1. Propose a minimal set of profiles and a permission-set-based model (permission sets and permission set groups) by job function.
2. Build an access matrix: Role | Object | Read / Create / Edit / Delete | Sensitive fields visible.
3. Recommend org-wide defaults, role hierarchy and sharing rules at a high level.
4. List the riskiest access today and how to fix it first.
5. Write a rollout and test plan (sandbox, test users per role, sign-off).

RULES
• Least privilege by default. Explain every exception.
• Don't recommend removing access in production without a tested plan.
• Mark license-dependent features as [CHECK LICENSES].

Act as a Salesforce UX consultant.

CONTEXT
• App name and users: [APP, ROLES]
• Current navigation items / tabs: [LIST]
• Current list views (with who uses them): [LIST]
• Top daily tasks: [TASKS]

TASK
1. Recommend the navigation bar items in order for each role, and what to remove.
2. Recommend 3–5 list views per key object: name, filters, columns, sort.
3. Suggest utility bar items (e.g. notes, a screen flow, recent items) that save clicks.
4. Suggest Home page components per role.
5. Write a 1-paragraph change note for users.

FORMAT
Tables for navigation and list views, then the change note.

RULES
• Name list views by what they show ("My open cases due this week"), not by who made them.
• Keep columns to what users act on. Justify each.

Act as a Salesforce business analyst.

INPUT
[PASTE MEETING NOTES OR REQUEST EMAILS]
Org context: [clouds in use, key objects, constraints]

TASK
1. Pull out each distinct need. Merge duplicates.
2. Write each as a user story: As a [role], I want [capability], so that [outcome].
3. Add acceptance criteria in Given / When / Then form.
4. Suggest the likely approach: standard config, Flow, Lightning App Builder, or custom code (LWC / Apex), and why.
5. Flag open questions, dependencies and data/permission impacts.
6. Rough size each story (S / M / L).

FORMAT
A table: ID | Story | Acceptance criteria | Approach | Size | Open questions.

RULES
• Prefer clicks over code. Justify any custom code.
• Don't invent requirements that aren't in the notes. List gaps as questions.

Act as a senior UX researcher running a heuristic evaluation.

WHAT TO REVIEW
[PASTE SCREENSHOTS, A WRITTEN WALKTHROUGH, OR THE FLOW STEPS]
Users: [WHO, and their main goal]

TASK
1. Walk through the flow step by step as the user.
2. Note every issue and tag it with one of Nielsen's 10 usability heuristics.
3. Rate severity 0–4 (0 not a problem, 4 usability catastrophe) and explain the rating.
4. Suggest a specific fix for each issue.
5. Note what works well, so the team doesn't break it.

FORMAT
A table: # | Step | Issue | Heuristic | Severity | Fix. Sorted by severity. Then "What works."

RULES
• A heuristic review finds likely problems; it doesn't replace testing with users. Say which issues most need user testing.
• Don't invent issues you can't see in what I provided.

Act as a usability testing expert.

STUDY
• Product / prototype: [WHAT]
• Research questions: [WHAT YOU NEED TO LEARN]
• Participants: [WHO]

TASK
1. Write 5–7 task scenarios in everyday language, each with a realistic reason to do the task.
2. For each task: success criteria, time limit, and what to observe.
3. Write 1–2 neutral follow-up questions per task.
4. Order the tasks so early ones don't teach later ones.
5. Add a warm-up and a closing question.

RULES
• Never use the words on the button or menu you're testing (no "click Submit").
• No leading questions ("How easy was…"). Use "Tell me about…" or "What did you expect…"
• Flag any task that depends on prototype content that doesn't exist yet.

Act as a UX research analyst.

DATA
[PASTE SUS RESPONSES: one row per participant, items 1–10, scale 1–5]

TASK
1. Score each participant: odd items (response − 1), even items (5 − response), sum, × 2.5.
2. Show each participant's score and the mean, median and range.
3. Explain the result in plain language, using the commonly cited benchmark that about 68 is average, and the caveats with small samples.
4. Point out items with the most negative responses.
5. Pair the score with what we observed: [PASTE KEY TEST FINDINGS] to explain the "why."

FORMAT
A score table, a short summary, and a "how to talk about this" note for stakeholders.

RULES
• Show the math so I can check it.
• Don't overstate precision with fewer than [10] participants.
• Never invent responses.

Act as a UX researcher writing for a busy product team.

INPUT
• De-identified session notes: [PASTE]
• Tasks and success criteria: [PASTE]
• Number of participants: [N]

TASK
1. Task results: success / partial / fail per participant, per task.
2. Findings: group observations into themes named as user problems.
3. For each finding: how many participants (count people, not notes), severity (blocker / major / minor), evidence (quotes or actions with participant ID), and a recommendation.
4. What worked well.
5. Open questions for the next round.

FORMAT
1-page executive summary, then the findings table: Finding | Seen in | Severity | Evidence | Recommendation.

RULES
• Never write a quote that isn't in my notes.
• Say "3 of 5 participants," not "users."
• Keep recommendations specific enough to design.

Act as an information architect planning unmoderated findability research.

CONTEXT
• Site or app: [WHAT]
• Proposed navigation / menu tree: [PASTE TREE]
• Top things people come to find: [LIST]

TASK
1. Recommend tree test, first-click test, or both, and why.
2. Write 8–10 find tasks in user language (not using menu labels).
3. Define the correct answer(s) for each task.
4. Recommend number of participants and recruiting criteria.
5. Explain how to read results: success rate, directness, first click, where people went wrong.

RULES
• Don't use the exact label words in the task.
• Note tasks that could have more than one correct answer.

Act as an inclusive research lead.

STUDY
• Product: [WHAT]
• Assistive technologies to include: [e.g. screen reader, screen magnification, voice control, switch access]
• Tasks: [LIST]

TASK
1. Recruiting: who to include, how to find them, fair compensation, and accessible scheduling.
2. Setup: test on the participant's own device and settings where possible; what to check before the session.
3. Moderation tips: pacing, not interrupting the AT output, how to ask about what they heard.
4. Prototype readiness: what must work (real HTML or accessible prototype) for the session to be valid.
5. Consent and privacy notes.
6. A notes template that captures AT, settings and what was announced.

RULES
• Don't describe participants by diagnosis. Describe the technology and settings they use.
• Don't treat one participant as representative of all AT users.

Act as a UX measurement lead.

CONTEXT
• Product / feature: [WHAT]
• What changed or will change: [CHANGE]
• Business goal: [GOAL]
• Data we can collect today: [analytics, surveys, support tickets, etc.]

TASK
Use the HEART framework (Happiness, Engagement, Adoption, Retention, Task success):
1. Pick the 2–3 categories that matter most here and explain why.
2. For each: goal → signal → metric.
3. Define the baseline and how we'll compare (before/after, A/B, cohort).
4. Flag metrics we can't measure yet and how to start.

FORMAT
A table: Category | Goal | Signal | Metric | Data source | Baseline needed.

RULES
• No vanity metrics. Each metric must tie to a user outcome.
• Don't invent baseline numbers.

Act as a service designer.

INPUT
• Persona or user group: [WHO]
• Scenario: [WHAT THEY'RE TRYING TO DO]
• Research evidence: [PASTE de-identified notes, quotes, survey results]

TASK
Build a journey map with these rows for each stage:
1. Stage name
2. User goals
3. Actions and touchpoints (channels, systems, people)
4. Thoughts and quotes (from evidence only)
5. Emotions (low / neutral / high, with reason)
6. Pain points
7. Opportunities

Then list the top 3 opportunities and the evidence behind each.

RULES
• Mark anything not supported by evidence as [ASSUMPTION].
• Use real quotes only, with participant IDs.

Act as a service designer creating a service blueprint.

SERVICE
• Service: [e.g. Request a records correction]
• Customer journey steps: [LIST or PASTE JOURNEY MAP]
• Teams and systems involved: [LIST]

TASK
For each customer step, fill in:
1. Customer actions
2. Front-stage (what staff/systems the customer sees)
3. Back-stage (staff work the customer doesn't see)
4. Support processes and systems (e.g. CRM, case management, Salesforce, email)
5. Evidence (what the customer receives: email, letter, screen)
6. Failure points and wait times

Then name the 3 biggest breakdowns and who owns each.

FORMAT
A table with steps as columns and lanes as rows, readable as plain text.

RULES
• Mark unknowns as [ASK TEAM]. Don't guess at internal processes.

Act as a design critique facilitator.

DESIGN
• What it is and its goal: [DESCRIPTION]
• Stage: [early concept / mid-fidelity / ready for build]
• What the designer wants feedback on: [FOCUS AREAS]
• What is out of scope: [e.g. brand colors are fixed]

TASK
1. Write a 30-minute agenda.
2. Write 6–8 critique questions tied to the goal and users (not taste).
3. Turn this raw feedback into actionable notes: [PASTE FEEDBACK, optional]
   For each: observation → impact on user/goal → suggestion → priority.
4. Write a short summary the designer can share.

RULES
• Separate "what I see" from "what I'd do."
• Flag feedback that is preference with no user impact.

Act as a UX strategist.

CONTEXT
• Our product and task: [e.g. scheduling an appointment]
• Products to review: [LIST, or ask me]
• What I can share about each: [screenshots, notes, links]

TASK
1. Define 6–8 review criteria tied to the task (steps, clarity, accessibility, trust signals, error handling, mobile).
2. Score each product on each criterion (1–5) with a one-line reason, using only what I provided.
3. Identify patterns: common conventions, standout ideas, and anti-patterns.
4. Recommend 3 things to adopt and 3 things to avoid.

FORMAT
A comparison table, then patterns and recommendations.

RULES
• Don't describe features you can't see in my material. Say "not reviewed."
• Copy patterns, not branding or content.

Act as a design systems engineer writing a component specification.

COMPONENT
• Name and purpose: [NAME, WHAT IT DOES]
• Design system / framework: [e.g. USWDS, SLDS, custom React]
• Visual reference: [DESCRIBE OR PASTE]

TASK
Write a spec with:
1. When to use / when not to use
2. Anatomy (named parts)
3. Variants and props, with defaults
4. States: default, hover, focus, active, disabled, loading, error
5. Behavior: interactions, keyboard support, responsive rules
6. Accessibility: role, name, ARIA, screen reader announcements, contrast, target size
7. Content guidelines: label lengths, truncation, plurals
8. Tokens used (colors, spacing, type)
9. Test checklist

RULES
• Use tokens and components that exist in my system. Mark anything new as [PROPOSED].
• Keep it to one page where possible.

Act as a research operations lead.

CONTEXT
• Team size and who uses research: [WHO]
• Types of research we do: [interviews, usability tests, surveys, analytics]
• Tool we use: [e.g. Dovetail, Airtable, Notion, spreadsheet]
• Example findings: [PASTE 5–10]

TASK
1. Propose a tag taxonomy with 4–6 tag groups (e.g. user group, journey stage, product area, theme, sentiment, method).
2. Define each tag in one line, with an example.
3. Tag my example findings to show it works.
4. Write governance rules: who adds tags, how to retire them, how to handle duplicates.
5. Write a nugget template: Insight | Evidence | Source study | Date | Tags | Confidence.

RULES
• Keep it small enough to use. Fewer than [40] tags to start.
• No personal data in tags.