Amo.ng curated workflow
Website UX Audit to Experiment Plan
Turn multimodal website evidence into prioritized conversion hypotheses and a measurable UX experiment plan with clear instrumentation, guardrails, and decision criteria.
# Website UX Audit to Experiment Plan Workflow ID: AMO-W-000003 ## Outcome Produce an evidence-backed UX improvement plan that moves from observed usability and conversion issues to a prioritized hypothesis and a measurement-ready experiment brief. ## Before you begin - Website or landing-page screenshots, URLs, copy, and journey captures - Relevant behavioral or analytics evidence - User feedback, research findings, or support observations where available - Target audience and priority user journey - Business or conversion objective - Current baseline metrics where available - Known UX, technical, legal, privacy, brand, or operational constraints - Available analytics and experimentation capabilities ## Step 1 — Build the multimodal UX evidence audit **Prompt** Multimodal Website UX Evidence Audit **Instructions** Review the supplied screenshots, interface copy, behavioral signals, user feedback, journey evidence, and business context to identify traceable usability and conversion findings. Separate observed evidence from interpretation, assumptions, and information that remains unknown. **Input for this step** Provide the actual website or journey assets and observations, affected pages and devices, target audience, business or conversion goal, relevant behavioral evidence, known constraints, and limitations in the available evidence. **Carry forward** Carry the evidence register, prioritized UX findings, supporting evidence, material unknowns, and candidate improvement areas into the focused conversion critique. **Human checkpoint** Confirm that private or sensitive user data is sanitized, findings are traceable to the supplied evidence, and observations are clearly distinguished from assumptions or inferred user intent. **Prompt content** Analyze the supplied multimodal website evidence in Gemini and produce a page-specific UX and conversion audit. Base all findings on material available in the current Gemini conversation; do not imply that inaccessible URLs, dashboards, recordings, files, or external sources were opened or inspected. ## Audit inputs - Page evidence bundle: [Page evidence bundle] - Audience and offer context: [Audience and offer context] - Conversion goals: [Conversion goals] - Aggregated or sanitized analytics evidence: [Aggregated or sanitized analytics evidence] - Anonymized user feedback evidence: [Anonymized user feedback evidence] - Inspectable competitor evidence: [Inspectable competitor evidence] - Constraints and risks: [Constraints and risks] - Audit scope and deadline: [Audit scope and deadline] The page evidence bundle should identify the page type and include the relevant URL for reference, pasted page copy, screenshots or accessible media, device and viewport context, and screen-recording notes where available. The other inputs should identify the intended audience, offer, business model, primary and secondary conversions, traffic context, analytics observations, feedback provenance, comparison pages, brand restrictions, known limitations, regulated claims, and decision timing when relevant. ## Gemini evidence boundary Use Gemini only to inspect text, images, files, or other material that is actually accessible in the current conversation. A URL is a reference, not proof that its live contents were reviewed. If Gemini cannot access an attachment, read an image clearly, inspect a recording, or retrieve a linked page, label that source unavailable and request an accessible screenshot, export, transcript, or pasted excerpt. Do not claim browsing, analytics access, live-page testing, interaction testing, accessibility scanning, implementation, deployment, publication, or experiment execution unless direct evidence of that action is supplied and the action genuinely occurred. Treat each status precisely: - Requested: an analysis or action the user asked for. - Proposed: a recommendation, rewrite, measurement specification, or experiment that has not been implemented. - Executed: work shown by supplied implementation or execution evidence. - Unavailable: source material Gemini cannot inspect in the current conversation. - Unverified: a claim or outcome for which adequate evidence was not supplied. This audit normally produces proposed work only. Never describe a recommendation as fixed, tested, deployed, approved, published, validated, or completed. If supplied notes claim an action occurred, report it as a supplied claim and mark it unverified unless corroborating evidence such as dated screenshots, implementation records, event data, test configuration, or approval records is present. ## Input sufficiency and conflicts First determine whether the evidence can support a useful audit. A page screenshot, pasted page copy, or equivalent inspectable page evidence plus an identifiable audience or conversion goal is the minimum basis for substantive findings. If no inspectable page evidence is available, stop after a concise intake response listing the exact blocking materials needed. If the audience or conversion goal is missing, ask for it; if the user cannot provide it, continue only with clearly bounded usability observations and do not infer conversion intent. For non-blocking omissions, continue with reduced scope and identify the limitation beside every affected conclusion. Review mobile and desktop separately only when evidence for each is supplied. Do not infer responsive behavior from one viewport. Do not infer interaction behavior, DOM semantics, keyboard support, screen-reader behavior, page speed, tracking accuracy, statistical significance, or live technical condition from static screenshots. When inputs conflict, preserve both versions, identify their sources, explain the consequence, and request resolution. Do not silently choose one. Prefer direct page evidence for visible content, event definitions and dated reports for analytics claims, verbatim or faithfully summarized records for user feedback, and inspectable competitor material for comparisons. Recency alone does not override stronger evidence without explanation. ## Evidence and uncertainty rules 1. Assign evidence IDs in the form E1, E2, and so on to every source item actually used. 2. Record each source's type, page or section, device or viewport if known, date if supplied, accessibility status, and relevant observation. 3. Separate direct observations, supplied factual context, reported claims, interpretations, hypotheses, unknowns, and conflicts. 4. Describe visible evidence precisely, such as the displayed headline, CTA label, field, price, disclosure, hierarchy, or obstruction. Do not invent content outside the captured area. 5. Quote only short excerpts that were supplied. Otherwise provide a faithful summary. 6. Reproduce metrics only as supplied, including period, denominator, segment, event definition, and comparison basis when available. Never manufacture a baseline or attribute causation from correlation. 7. Competitor patterns are comparison evidence, not proof that copying them will improve performance. 8. Use qualitative confidence only: - High — direct, relevant, sufficiently complete, and internally consistent evidence supports the finding across the applicable page state or viewport. - Medium — the evidence is relevant but partial, covers only part of the journey or state, or requires limited interpretation. - Low — the evidence is indirect, incomplete, stale, conflicting, difficult to inspect, or covers only a narrow part of the relevant experience. Explain every confidence rating briefly by referring to evidence quality, coverage, consistency, and direct observability. Do not use numerical confidence percentages or present confidence as proof of causal impact. 9. Every finding must cite at least one evidence ID. Recommendations may also address an explicitly identified evidence gap, but must not be presented as a confirmed remedy. 10. State what appears strong when evidence supports it; do not create problems to fill the report. ## Focused audit workflow 1. Inventory accessible and unavailable inputs, reconcile them against the materials the user says were supplied, and note missing device, state, funnel, or provenance coverage. 2. Establish the page's evidenced offer, intended audience, primary action, traffic context, and visitor questions. Mark inferred elements as hypotheses. 3. Trace the visible journey from arrival through offer comprehension, credibility evaluation, action consideration, form or checkout progression, and exit risk. Analyze only stages represented by evidence. 4. Evaluate first-impression clarity, message and audience fit, CTA specificity, information hierarchy, offer and pricing comprehension, objection handling, trust signals, risk reversal, navigation, forms, and conversion friction. 5. Review desktop and mobile evidence independently for readability, crowding, CTA visibility, overlays, form presentation, and apparent tap-target or contrast concerns. Label screenshot-based accessibility findings as preliminary visual checks rather than conformance results. 6. Compare competitor or reference evidence only on matched elements and states, including offer clarity, differentiation, CTA treatment, proof, pricing explanation, and section order. 7. Prioritize findings using evidenced impact on the stated conversion goal, breadth of affected traffic or journey stages when supplied, confidence, effort estimate, dependencies, reversibility, and risk. Do not invent revenue impact or uplift percentages. 8. Convert supported findings into specific proposed changes, copy options, layout directions, evidence-gathering steps, or experiments. Keep observations separate from proposed solutions. 9. Define measurement and verification requirements before recommending implementation or testing. 10. Run the acceptance checks below and disclose any failed check in the final section. ## Safeguards and authority limits Do not recommend deceptive urgency, fabricated scarcity, hidden fees, obstructive cancellation, preselected consent, misleading comparison, unsupported superiority claims, false testimonials, or other manipulative patterns. Minimize reproduction of personal or confidential data found in feedback or screenshots and advise redaction when it is unnecessary to the finding. Flag legal, regulatory, privacy, security, financial, medical, pricing, guarantee, testimonial, certification, accessibility-conformance, and public performance claims for review by the accountable human specialist. Do not provide approval or certify compliance. Product owners must confirm factual claims and pricing; analysts must confirm event definitions and data interpretation; designers and developers must confirm feasibility and rendering; legal or compliance reviewers must approve regulated public claims. No change should be implemented solely because it appears in this audit. ## Required deliverable: Multimodal Website UX Evidence Audit Keep the deliverable concise and proportional to the supplied evidence, page scope, funnel stage, and decision need. Do not repeat the same observation or evidence across multiple sections unnecessarily. If a section is genuinely not applicable or lacks sufficient inspectable evidence, retain the heading, state Not applicable or Insufficient evidence, explain briefly why, and identify the evidence needed to complete it. Never omit the Scope and evidence ledger, Finding register, Verification plan and acceptance evidence, or Audit acceptance record. Do not fill unsupported sections with generic UX advice merely to complete the format. ### A. Scope and evidence ledger State the page, audience, offer, conversion goal, funnel stage, devices, and states actually covered. Then provide: | Evidence ID | Source and location | Type | Device or state | Direct observation or supplied fact | Availability | Confidence or limitation | |---|---|---|---|---|---|---| Follow with separate lists for unavailable sources, missing inputs, conflicting evidence, and assumptions or hypotheses. For each missing input, explain the affected audit area and the best collection method. ### B. Evidenced page and journey reading Summarize what the page demonstrably communicates, the action it requests, what appears to work, and where the evidenced journey may break. Separate direct observations from interpretations. Do not assign a readiness verdict beyond the captured scope. ### C. Finding register Provide one row per distinct finding: | Finding ID | Page location and device | Finding | Evidence IDs | Evidence class | Plausible conversion or usability consequence | Severity | Confidence | Limitation | |---|---|---|---|---|---|---|---|---| Describe the consequence as a plausible mechanism, visitor risk, or supported observation unless supplied experimental or causal evidence justifies stronger language. Do not state that a visible page issue caused a conversion change merely because the issue and the metric appeared during the same period. Use Critical only for an evidenced blocker or material deception, High for substantial friction tied to the primary goal, Medium for meaningful but non-blocking friction, and Low for a minor issue or weakly supported concern. Do not inflate severity. Cover only evidenced areas among clarity, messaging, CTA, hierarchy, navigation, pricing or offer comprehension, trust, objections, forms, checkout or signup, mobile presentation, and preliminary visual accessibility. For accessibility observations, distinguish visible concerns from checks requiring code, interaction, assistive technology, or specialist testing. ### D. Copy and layout proposals For each proposed change, provide: | Proposal ID | Related finding IDs | Exact location | Current evidenced element | Proposed change or copy option | Rationale | Constraint or review gate | Status | |---|---|---|---|---|---|---|---| Set Status to Proposed unless execution evidence proves otherwise. Preserve factual meaning and brand constraints. Mark any new factual, comparative, pricing, guarantee, or testimonial language as requiring owner verification before use. ### E. Competitor comparison If inspectable competitor evidence exists, provide: | Matched area | Current-page evidence IDs | Competitor evidence IDs | Observed difference | Context limitation | Testable opportunity | |---|---|---|---|---|---| If it does not exist, state that no comparison was performed and specify the screenshots, page states, audience match, and date context needed. Do not rely on competitor names or URLs alone. ### F. Prioritized improvement backlog | Rank | Proposed improvement | Finding IDs | Expected mechanism | Impact | Effort | Confidence | Dependency | Suggested owner | Human review gate | |---|---|---|---|---|---|---|---|---|---| Use qualitative impact and effort unless supplied data supports another scale. Explain ties and identify quick, reversible improvements separately from structural work. Expected mechanism must describe why the change might affect comprehension, trust, usability, or the stated conversion action; it is not a guaranteed outcome. ### G. Experiment and measurement specifications Suggest experiments only where there is a supported uncertainty and enough prospective traffic or measurement context to justify testing. Otherwise recommend research, instrumentation, or a usability check instead. | Experiment ID | Finding IDs | Hypothesis | Control and proposed variant | Primary metric | Guardrail metric | Required event definition | Segment and device | Run prerequisites | Decision rule owner | Risk | |---|---|---|---|---|---|---|---|---|---|---| Do not invent sample sizes, test duration, minimum detectable effect, baselines, or expected uplift. List those as analyst inputs when absent. Distinguish leading indicators from the primary conversion. Include a before-and-after comparison only when experiment randomization is unsuitable, and disclose confounding risks. ### H. Verification plan and acceptance evidence For each high-priority proposal, define: | Proposal ID | Check to perform | Method or artifact | Expected observable condition | Accountable reviewer | Evidence required to mark complete | Current status | |---|---|---|---|---|---|---| Use concrete checks appropriate to the proposal, such as matched desktop and mobile screenshots showing the intended hierarchy, approved final copy linked to claim substantiation, form completion across named states, analytics event payload confirmation by an analyst, keyboard and assistive-technology test records, or experiment configuration and results. Do not claim any check was performed. Set Current status to Proposed, Unavailable, or Unverified unless supplied evidence supports Executed. ### I. Action sequence and decisions needed Group the backlog into immediate evidence collection, low-risk proposals ready for owner review, design or development exploration, measurement setup, and later experiments. Identify the decision owner and unresolved dependency for each group. Respect the supplied deadline without implying approval or delivery. ### J. Audit acceptance record Report Pass, Fail, or Not applicable for every check and explain failures: 1. Every cited evidence ID exists in the evidence ledger. 2. The ledger reconciles all files, screenshots, text excerpts, datasets, and references the user says were supplied; inaccessible items are marked unavailable. 3. Every finding cites direct evidence or is explicitly labeled as a hypothesis or evidence gap. 4. Every recommendation cites finding IDs and has a Proposed, Executed, Unavailable, or Unverified status. 5. Desktop and mobile conclusions are separated and limited to supplied viewports and states. 6. Analytics statements preserve supplied values, periods, segments, denominators, and event definitions; absent details are marked missing. 7. Competitor comparisons cite inspectable matched evidence rather than unsupported reputation or memory. 8. Accessibility conclusions are limited to the inspection method and do not claim conformance without appropriate test evidence. 9. Experiment proposals specify metrics, guardrails, prerequisites, and ownership without fabricated uplift, duration, or sample size. 10. High-risk claims and changes have the appropriate human review gate. 11. No recommendation is described as implemented, tested, approved, deployed, published, or successful without corresponding evidence. 12. The final priorities directly trace to the stated conversion goal or an explicitly identified usability or trust risk. End with a concise evidence coverage statement naming what Gemini inspected, what it could not inspect, what remains uncertain, and whether the audit is suitable for prioritization, requires more evidence, or is limited to preliminary observations. ## Step 2 — Challenge the priority conversion journey **Prompt** Landing Page Conversion Critique Prompt **Instructions** Use the evidence and prioritized findings from Step 1 to critically evaluate the priority conversion page or journey for clarity, relevance, friction, trust, proof, calls to action, information hierarchy, and likely conversion blockers. **Input for this step** Provide the relevant Step 1 findings, current page content and structure, desired user action, target audience, known objections or friction points, available proof assets, business constraints, and unresolved evidence gaps. **Carry forward** Carry the strongest evidence-backed improvement hypotheses, their supporting rationale, expected user or business effect, implementation dependencies, risks, and unresolved questions into experiment design. **Human checkpoint** Select the hypothesis to test based on evidence, expected impact, strategic relevance, feasibility, and risk rather than visual preference or stakeholder opinion alone. **Prompt content** Act as a senior Marketing specialist using ChatGPT. Your task is: [Goal or task]. Context: - Current situation: [Current context] - Constraints: [Constraints] - Available materials: [Files, data, examples, URLs, logs, notes] - Success criteria: [Definition of done] Workflow: 1. Restate the objective in operational terms and identify any missing information that would block a reliable answer. 2. Make reasonable assumptions only when they are low risk, and label them clearly. 3. Produce the main deliverable for "Landing Page Conversion Critique Prompt" with enough detail that a skilled operator can execute it immediately. 4. Include edge cases, failure modes, dependencies, and tradeoffs that a junior prompt would usually miss. 5. Add a verification checklist with concrete tests, review questions, metrics, or acceptance criteria. 6. End with the smallest safe next action. Output format: - Executive summary - Detailed plan or implementation - Risks and mitigations - Verification checklist - Next action Do not give generic advice. Optimize for a production-quality cro outcome. ## Step 3 — Design the measurable UX experiment **Prompt** GTM Experiment Design and Measurement Brief **Instructions** Translate the selected evidence-backed hypothesis from Step 2 into a bounded experiment with a defined audience, control and treatment, success metrics, instrumentation requirements, guardrails, implementation dependencies, and explicit decision rules. **Input for this step** Provide the selected hypothesis and supporting evidence, current baseline behavior where available, eligible audience, proposed change, implementation constraints, available traffic or sample considerations, analytics and tracking capabilities, and acceptable risk limits. **Carry forward** Produce and retain the approved experiment brief, implementation requirements, instrumentation checklist, launch guardrails, measurement plan, decision thresholds, and post-experiment readout requirements for execution. **Human checkpoint** Require appropriate design, product, engineering, analytics, privacy, legal, and release approval where applicable before exposing users to the experiment. Confirm that the measurement setup can answer the experiment question before launch. **Prompt content** You are an expert go-to-market experimentation strategist specializing in growth test design, measurement planning, campaign operations, sales motion testing, and decision-ready experiment readouts. Turn the supplied GTM idea into a measurable experiment brief with a clear hypothesis, audience, channel plan, offer or message, baseline metrics, tracking setup, guardrails, decision rules, launch checklist, and readout plan. The goal is to help marketing, sales, growth, RevOps, product marketing, founders, and leadership teams test GTM ideas without confusing activity, noise, or vanity metrics for real market signal. ## Context Placeholders Use the context below. If the experiment idea, target audience, hypothesis, or success criteria are missing, ask for them before producing the brief. If other inputs are missing, continue only with clearly labeled assumptions. * [Experiment idea and target audience] * [Hypothesis, offer, and channel] * [Baseline metrics and success criteria] * [Budget, constraints, and decision deadline] * [Tracking setup, owners, and review cadence] ## Important Constraints * Do not invent facts, metrics, benchmarks, conversion rates, customer evidence, market research, channel performance, budgets, legal approvals, tracking data, attribution results, or revenue impact. * Separate confirmed evidence from assumptions, hypotheses, risks, and recommendations. * Label confidence level and uncertainty for every major recommendation. * Do not present this output as legal, financial, tax, regulatory, security, medical, or compliance advice. * Customer-facing claims, pricing, discounts, guarantees, incentives, tracking plans, data usage, consent, privacy, and regulated-industry messaging must be reviewed by the appropriate human owner before launch. * Do not recommend launching an experiment if success criteria, tracking ownership, customer-facing message, or guardrails are too unclear to measure safely. * Do not treat impressions, clicks, opens, or leads as proof of business impact unless they are tied to the experiment objective and downstream evidence. * Do not overstate statistical certainty when sample size, time window, attribution quality, or baseline data is weak. * Treat weak baselines, unclear audience, poor segmentation, missing tracking, overlapping campaigns, sales follow-up gaps, attribution noise, and vague decision rules as experiment risks. * Make recommendations specific to the supplied experiment idea, audience, channel, offer, baseline metrics, budget, constraints, owners, and deadline. ## Step-by-Step Instructions 1. Summarize the GTM experiment context: * experiment idea * target audience * customer segment * channel * offer or message * hypothesis * baseline metrics * budget * constraints * owners * decision deadline 2. Clarify the hypothesis: * target audience * behavior expected * reason the behavior should happen * channel or message being tested * expected measurable change * business decision the test should inform * what would change if the test succeeds * what would change if the test fails 3. Identify assumptions: * audience assumption * pain-point assumption * offer assumption * channel assumption * timing assumption * sales follow-up assumption * tracking assumption * conversion assumption * budget assumption * operational-capacity assumption 4. Design the experiment setup: * test group * comparison group or baseline * segmentation * channel setup * message or offer variant * landing page or conversion path * sales handoff if relevant * tracking events * attribution approach * time window * sample constraints * budget limit * owner responsibilities 5. Define measurement: * primary metric * secondary metrics * leading indicators * lagging indicators * quality signals * disqualification signals * customer experience signals * sales acceptance signals * revenue or pipeline signal if relevant * baseline comparison * minimum evidence needed before deciding 6. Define guardrails: * budget cap * brand-risk limit * customer-experience limit * unsubscribe or complaint threshold * low-quality lead threshold * sales-capacity limit * legal or compliance review gate * privacy and tracking review gate * stop condition * escalation trigger 7. Define decision rules: * continue * stop * iterate * scale * retest * hand off to sales * exclude a segment * change message * change channel * run deeper discovery 8. Identify measurement risks: * attribution noise * small sample size * seasonality * overlapping campaigns * weak baseline * poor tracking * audience mismatch * novelty effect * sales follow-up inconsistency * lead quality distortion * vanity metrics * false positive * false negative 9. Create a launch checklist and readout plan: * pre-launch checks * owner approvals * tracking verification * launch monitoring * readout structure * decision meeting agenda * follow-up actions ## Output Format ### 1. Missing Context List missing inputs needed before a reliable GTM experiment brief can be completed. If enough context is available, say so. ### 2. Experiment Snapshot Use this table: | Area | Current View | Evidence | Risk or Uncertainty | | ---- | ------------ | -------- | ------------------- | Cover idea, audience, channel, offer, hypothesis, baseline metrics, success criteria, budget, constraints, owners, and deadline. ### 3. Hypothesis and Assumptions Use this table: | Hypothesis Element | Current Statement | Evidence | Assumption or Risk | | ------------------ | ----------------- | -------- | ------------------ | Include audience, behavior, pain point, offer, channel, expected change, and business decision. ### 4. Experiment Design Use this table: | Design Area | Recommendation | Owner Role | Check Needed | | ----------- | -------------- | ---------- | ------------ | Cover audience, segment, channel, offer, creative/message, landing path, tracking, sales handoff, time window, and budget. ### 5. Measurement Plan Use this table: | Metric | Type | Why It Matters | Baseline | Decision Use | | ------ | ---- | -------------- | -------- | ------------ | Separate primary metric, secondary metrics, leading indicators, lagging indicators, quality signals, and guardrail metrics. ### 6. Tracking and Attribution Review Use this table: | Tracking Area | Current Setup | Risk | Required Check | Owner Role | | ------------- | ------------- | ---- | -------------- | ---------- | Cover UTMs, CRM fields, landing page events, conversion events, sales follow-up, attribution window, and reporting source. ### 7. Risk and Guardrail Review Use this table: | Risk or Guardrail | Evidence | Threshold or Limit | Owner Role | Action if Triggered | | ----------------- | -------- | ------------------ | ---------- | ------------------- | ### 8. Decision Rules Use this table: | Outcome | Evidence Needed | Decision | Follow-Up Action | | ------- | --------------- | -------- | ---------------- | Include stop, iterate, continue, scale, retest, or escalate. ### 9. Launch Checklist Provide a practical checklist covering message approval, tracking verification, audience QA, budget cap, sales handoff, owner readiness, legal/compliance/privacy review where relevant, and reporting setup. ### 10. Readout Plan Provide a concise readout structure covering what was tested, what happened, what evidence was strong or weak, what assumptions changed, what decision is recommended, and what action happens next. ### 11. Missing Inputs and Human Checks List assumptions made, unresolved risks, blocked decisions, confidence level, and human checks required before launch or scaling. ## Verification Checklist Before finalizing, confirm that: * the hypothesis is specific and testable * target audience is clearly defined * success criteria are measurable before launch * baseline metrics are identified or flagged as missing * tracking and attribution risks are addressed * vanity metrics are separated from business outcomes * guardrails and stop conditions are included * customer-facing claims receive appropriate review * privacy, consent, compliance, finance, and legal review gates are included where relevant * decision rules are defined before launch * missing inputs and unresolved risks are clearly listed ## Final Instruction to Begin Begin now. First review the supplied experiment idea, target audience, hypothesis, channels, offer or message, baseline metrics, success criteria, constraints, budget, tracking setup, owners, review cadence, and decision deadline. If required context is missing, ask for it. Otherwise, produce the full GTM experiment design and measurement brief in the requested markdown format. ## Completion criteria The workflow is complete when: - UX findings are traceable to supplied evidence rather than unsupported assumptions. - The most important usability and conversion issues are prioritized. - A specific evidence-backed improvement hypothesis has been selected. - The hypothesis is translated into a bounded experiment. - The experiment defines audience, treatment, metrics, guardrails, and decision rules. - Required analytics and instrumentation checks are documented. - Material uncertainties, dependencies, and limitations remain explicit. - Required product, design, analytics, privacy, technical, and release approvals are identified before execution. # Website UX Audit to Experiment Plan Use this Amo.ng workflow with your preferred AI tool. Complete the steps in order and carry the specified output forward. Outcome: Produce an evidence-backed UX improvement plan that moves from observed usability and conversion issues to a prioritized hypothesis and a measurement-ready experiment brief. Required inputs: - Website or landing-page screenshots, URLs, copy, and journey captures - Relevant behavioral or analytics evidence - User feedback, research findings, or support observations where available - Target audience and priority user journey - Business or conversion objective - Current baseline metrics where available - Known UX, technical, legal, privacy, brand, or operational constraints - Available analytics and experimentation capabilities ## Step 1 — Build the multimodal UX evidence audit **Instructions** Review the supplied screenshots, interface copy, behavioral signals, user feedback, journey evidence, and business context to identify traceable usability and conversion findings. Separate observed evidence from interpretation, assumptions, and information that remains unknown. **Input for this step** Provide the actual website or journey assets and observations, affected pages and devices, target audience, business or conversion goal, relevant behavioral evidence, known constraints, and limitations in the available evidence. **Carry forward** Carry the evidence register, prioritized UX findings, supporting evidence, material unknowns, and candidate improvement areas into the focused conversion critique. **Human checkpoint** Confirm that private or sensitive user data is sanitized, findings are traceable to the supplied evidence, and observations are clearly distinguished from assumptions or inferred user intent. **Prompt** Multimodal Website UX Evidence Audit **Prompt URL** https://amo.ng/prompts/multimodal-website-ux-evidence-audit ## Step 2 — Challenge the priority conversion journey **Instructions** Use the evidence and prioritized findings from Step 1 to critically evaluate the priority conversion page or journey for clarity, relevance, friction, trust, proof, calls to action, information hierarchy, and likely conversion blockers. **Input for this step** Provide the relevant Step 1 findings, current page content and structure, desired user action, target audience, known objections or friction points, available proof assets, business constraints, and unresolved evidence gaps. **Carry forward** Carry the strongest evidence-backed improvement hypotheses, their supporting rationale, expected user or business effect, implementation dependencies, risks, and unresolved questions into experiment design. **Human checkpoint** Select the hypothesis to test based on evidence, expected impact, strategic relevance, feasibility, and risk rather than visual preference or stakeholder opinion alone. **Prompt** Landing Page Conversion Critique Prompt **Prompt URL** https://amo.ng/prompts/landing-page-conversion-critique-prompt ## Step 3 — Design the measurable UX experiment **Instructions** Translate the selected evidence-backed hypothesis from Step 2 into a bounded experiment with a defined audience, control and treatment, success metrics, instrumentation requirements, guardrails, implementation dependencies, and explicit decision rules. **Input for this step** Provide the selected hypothesis and supporting evidence, current baseline behavior where available, eligible audience, proposed change, implementation constraints, available traffic or sample considerations, analytics and tracking capabilities, and acceptable risk limits. **Carry forward** Produce and retain the approved experiment brief, implementation requirements, instrumentation checklist, launch guardrails, measurement plan, decision thresholds, and post-experiment readout requirements for execution. **Human checkpoint** Require appropriate design, product, engineering, analytics, privacy, legal, and release approval where applicable before exposing users to the experiment. Confirm that the measurement setup can answer the experiment question before launch. **Prompt** GTM Experiment Design and Measurement Brief **Prompt URL** https://amo.ng/prompts/gtm-experiment-design-measurement-brief Completion criteria: The workflow is complete when: - UX findings are traceable to supplied evidence rather than unsupported assumptions. - The most important usability and conversion issues are prioritized. - A specific evidence-backed improvement hypothesis has been selected. - The hypothesis is translated into a bounded experiment. - The experiment defines audience, treatment, metrics, guardrails, and decision rules. - Required analytics and instrumentation checks are documented. - Material uncertainties, dependencies, and limitations remain explicit. - Required product, design, analytics, privacy, technical, and release approvals are identified before execution.Outcome
Produce an evidence-backed UX improvement plan that moves from observed usability and conversion issues to a prioritized hypothesis and a measurement-ready experiment brief.
Before you begin
- Website or landing-page screenshots, URLs, copy, and journey captures
- Relevant behavioral or analytics evidence
- User feedback, research findings, or support observations where available
- Target audience and priority user journey
- Business or conversion objective
- Current baseline metrics where available
- Known UX, technical, legal, privacy, brand, or operational constraints
- Available analytics and experimentation capabilities
Ordered sequence
Workflow steps
-
Step 1 Build the multimodal UX evidence audit
Review the supplied screenshots, interface copy, behavioral signals, user feedback, journey evidence, and business context to identify traceable usability and conversion findings. Separate observed evidence from interpretation, assumptions, and information that remains unknown.
Prompt: Multimodal Website UX Evidence AuditAnalyze the supplied multimodal website evidence in Gemini and produce a page-specific UX and conversion audit. Base all findings on material available in the current Gemini conversation; do not imply that inaccessible URLs, dashboards, recordings, files, or external sources were opened or inspected. ## Audit inputs - Page evidence bundle: [Page evidence bundle] - Audience and offer context: [Audience and offer context] - Conversion goals: [Conversion goals] - Aggregated or sanitized analytics evidence: [Aggregated or sanitized analytics evidence] - Anonymized user feedback evidence: [Anonymized user feedback evidence] - Inspectable competitor evidence: [Inspectable competitor evidence] - Constraints and risks: [Constraints and risks] - Audit scope and deadline: [Audit scope and deadline] The page evidence bundle should identify the page type and include the relevant URL for reference, pasted page copy, screenshots or accessible media, device and viewport context, and screen-recording notes where available. The other inputs should identify the intended audience, offer, business model, primary and secondary conversions, traffic context, analytics observations, feedback provenance, comparison pages, brand restrictions, known limitations, regulated claims, and decision timing when relevant. ## Gemini evidence boundary Use Gemini only to inspect text, images, files, or other material that is actually accessible in the current conversation. A URL is a reference, not proof that its live contents were reviewed. If Gemini cannot access an attachment, read an image clearly, inspect a recording, or retrieve a linked page, label that source unavailable and request an accessible screenshot, export, transcript, or pasted excerpt. Do not claim browsing, analytics access, live-page testing, interaction testing, accessibility scanning, implementation, deployment, publication, or experiment execution unless direct evidence of that action is supplied and the action genuinely occurred. Treat each status precisely: - Requested: an analysis or action the user asked for. - Proposed: a recommendation, rewrite, measurement specification, or experiment that has not been implemented. - Executed: work shown by supplied implementation or execution evidence. - Unavailable: source material Gemini cannot inspect in the current conversation. - Unverified: a claim or outcome for which adequate evidence was not supplied. This audit normally produces proposed work only. Never describe a recommendation as fixed, tested, deployed, approved, published, validated, or completed. If supplied notes claim an action occurred, report it as a supplied claim and mark it unverified unless corroborating evidence such as dated screenshots, implementation records, event data, test configuration, or approval records is present. ## Input sufficiency and conflicts First determine whether the evidence can support a useful audit. A page screenshot, pasted page copy, or equivalent inspectable page evidence plus an identifiable audience or conversion goal is the minimum basis for substantive findings. If no inspectable page evidence is available, stop after a concise intake response listing the exact blocking materials needed. If the audience or conversion goal is missing, ask for it; if the user cannot provide it, continue only with clearly bounded usability observations and do not infer conversion intent. For non-blocking omissions, continue with reduced scope and identify the limitation beside every affected conclusion. Review mobile and desktop separately only when evidence for each is supplied. Do not infer responsive behavior from one viewport. Do not infer interaction behavior, DOM semantics, keyboard support, screen-reader behavior, page speed, tracking accuracy, statistical significance, or live technical condition from static screenshots. When inputs conflict, preserve both versions, identify their sources, explain the consequence, and request resolution. Do not silently choose one. Prefer direct page evidence for visible content, event definitions and dated reports for analytics claims, verbatim or faithfully summarized records for user feedback, and inspectable competitor material for comparisons. Recency alone does not override stronger evidence without explanation. ## Evidence and uncertainty rules 1. Assign evidence IDs in the form E1, E2, and so on to every source item actually used. 2. Record each source's type, page or section, device or viewport if known, date if supplied, accessibility status, and relevant observation. 3. Separate direct observations, supplied factual context, reported claims, interpretations, hypotheses, unknowns, and conflicts. 4. Describe visible evidence precisely, such as the displayed headline, CTA label, field, price, disclosure, hierarchy, or obstruction. Do not invent content outside the captured area. 5. Quote only short excerpts that were supplied. Otherwise provide a faithful summary. 6. Reproduce metrics only as supplied, including period, denominator, segment, event definition, and comparison basis when available. Never manufacture a baseline or attribute causation from correlation. 7. Competitor patterns are comparison evidence, not proof that copying them will improve performance. 8. Use qualitative confidence only: - High — direct, relevant, sufficiently complete, and internally consistent evidence supports the finding across the applicable page state or viewport. - Medium — the evidence is relevant but partial, covers only part of the journey or state, or requires limited interpretation. - Low — the evidence is indirect, incomplete, stale, conflicting, difficult to inspect, or covers only a narrow part of the relevant experience. Explain every confidence rating briefly by referring to evidence quality, coverage, consistency, and direct observability. Do not use numerical confidence percentages or present confidence as proof of causal impact. 9. Every finding must cite at least one evidence ID. Recommendations may also address an explicitly identified evidence gap, but must not be presented as a confirmed remedy. 10. State what appears strong when evidence supports it; do not create problems to fill the report. ## Focused audit workflow 1. Inventory accessible and unavailable inputs, reconcile them against the materials the user says were supplied, and note missing device, state, funnel, or provenance coverage. 2. Establish the page's evidenced offer, intended audience, primary action, traffic context, and visitor questions. Mark inferred elements as hypotheses. 3. Trace the visible journey from arrival through offer comprehension, credibility evaluation, action consideration, form or checkout progression, and exit risk. Analyze only stages represented by evidence. 4. Evaluate first-impression clarity, message and audience fit, CTA specificity, information hierarchy, offer and pricing comprehension, objection handling, trust signals, risk reversal, navigation, forms, and conversion friction. 5. Review desktop and mobile evidence independently for readability, crowding, CTA visibility, overlays, form presentation, and apparent tap-target or contrast concerns. Label screenshot-based accessibility findings as preliminary visual checks rather than conformance results. 6. Compare competitor or reference evidence only on matched elements and states, including offer clarity, differentiation, CTA treatment, proof, pricing explanation, and section order. 7. Prioritize findings using evidenced impact on the stated conversion goal, breadth of affected traffic or journey stages when supplied, confidence, effort estimate, dependencies, reversibility, and risk. Do not invent revenue impact or uplift percentages. 8. Convert supported findings into specific proposed changes, copy options, layout directions, evidence-gathering steps, or experiments. Keep observations separate from proposed solutions. 9. Define measurement and verification requirements before recommending implementation or testing. 10. Run the acceptance checks below and disclose any failed check in the final section. ## Safeguards and authority limits Do not recommend deceptive urgency, fabricated scarcity, hidden fees, obstructive cancellation, preselected consent, misleading comparison, unsupported superiority claims, false testimonials, or other manipulative patterns. Minimize reproduction of personal or confidential data found in feedback or screenshots and advise redaction when it is unnecessary to the finding. Flag legal, regulatory, privacy, security, financial, medical, pricing, guarantee, testimonial, certification, accessibility-conformance, and public performance claims for review by the accountable human specialist. Do not provide approval or certify compliance. Product owners must confirm factual claims and pricing; analysts must confirm event definitions and data interpretation; designers and developers must confirm feasibility and rendering; legal or compliance reviewers must approve regulated public claims. No change should be implemented solely because it appears in this audit. ## Required deliverable: Multimodal Website UX Evidence Audit Keep the deliverable concise and proportional to the supplied evidence, page scope, funnel stage, and decision need. Do not repeat the same observation or evidence across multiple sections unnecessarily. If a section is genuinely not applicable or lacks sufficient inspectable evidence, retain the heading, state Not applicable or Insufficient evidence, explain briefly why, and identify the evidence needed to complete it. Never omit the Scope and evidence ledger, Finding register, Verification plan and acceptance evidence, or Audit acceptance record. Do not fill unsupported sections with generic UX advice merely to complete the format. ### A. Scope and evidence ledger State the page, audience, offer, conversion goal, funnel stage, devices, and states actually covered. Then provide: | Evidence ID | Source and location | Type | Device or state | Direct observation or supplied fact | Availability | Confidence or limitation | |---|---|---|---|---|---|---| Follow with separate lists for unavailable sources, missing inputs, conflicting evidence, and assumptions or hypotheses. For each missing input, explain the affected audit area and the best collection method. ### B. Evidenced page and journey reading Summarize what the page demonstrably communicates, the action it requests, what appears to work, and where the evidenced journey may break. Separate direct observations from interpretations. Do not assign a readiness verdict beyond the captured scope. ### C. Finding register Provide one row per distinct finding: | Finding ID | Page location and device | Finding | Evidence IDs | Evidence class | Plausible conversion or usability consequence | Severity | Confidence | Limitation | |---|---|---|---|---|---|---|---|---| Describe the consequence as a plausible mechanism, visitor risk, or supported observation unless supplied experimental or causal evidence justifies stronger language. Do not state that a visible page issue caused a conversion change merely because the issue and the metric appeared during the same period. Use Critical only for an evidenced blocker or material deception, High for substantial friction tied to the primary goal, Medium for meaningful but non-blocking friction, and Low for a minor issue or weakly supported concern. Do not inflate severity. Cover only evidenced areas among clarity, messaging, CTA, hierarchy, navigation, pricing or offer comprehension, trust, objections, forms, checkout or signup, mobile presentation, and preliminary visual accessibility. For accessibility observations, distinguish visible concerns from checks requiring code, interaction, assistive technology, or specialist testing. ### D. Copy and layout proposals For each proposed change, provide: | Proposal ID | Related finding IDs | Exact location | Current evidenced element | Proposed change or copy option | Rationale | Constraint or review gate | Status | |---|---|---|---|---|---|---|---| Set Status to Proposed unless execution evidence proves otherwise. Preserve factual meaning and brand constraints. Mark any new factual, comparative, pricing, guarantee, or testimonial language as requiring owner verification before use. ### E. Competitor comparison If inspectable competitor evidence exists, provide: | Matched area | Current-page evidence IDs | Competitor evidence IDs | Observed difference | Context limitation | Testable opportunity | |---|---|---|---|---|---| If it does not exist, state that no comparison was performed and specify the screenshots, page states, audience match, and date context needed. Do not rely on competitor names or URLs alone. ### F. Prioritized improvement backlog | Rank | Proposed improvement | Finding IDs | Expected mechanism | Impact | Effort | Confidence | Dependency | Suggested owner | Human review gate | |---|---|---|---|---|---|---|---|---|---| Use qualitative impact and effort unless supplied data supports another scale. Explain ties and identify quick, reversible improvements separately from structural work. Expected mechanism must describe why the change might affect comprehension, trust, usability, or the stated conversion action; it is not a guaranteed outcome. ### G. Experiment and measurement specifications Suggest experiments only where there is a supported uncertainty and enough prospective traffic or measurement context to justify testing. Otherwise recommend research, instrumentation, or a usability check instead. | Experiment ID | Finding IDs | Hypothesis | Control and proposed variant | Primary metric | Guardrail metric | Required event definition | Segment and device | Run prerequisites | Decision rule owner | Risk | |---|---|---|---|---|---|---|---|---|---|---| Do not invent sample sizes, test duration, minimum detectable effect, baselines, or expected uplift. List those as analyst inputs when absent. Distinguish leading indicators from the primary conversion. Include a before-and-after comparison only when experiment randomization is unsuitable, and disclose confounding risks. ### H. Verification plan and acceptance evidence For each high-priority proposal, define: | Proposal ID | Check to perform | Method or artifact | Expected observable condition | Accountable reviewer | Evidence required to mark complete | Current status | |---|---|---|---|---|---|---| Use concrete checks appropriate to the proposal, such as matched desktop and mobile screenshots showing the intended hierarchy, approved final copy linked to claim substantiation, form completion across named states, analytics event payload confirmation by an analyst, keyboard and assistive-technology test records, or experiment configuration and results. Do not claim any check was performed. Set Current status to Proposed, Unavailable, or Unverified unless supplied evidence supports Executed. ### I. Action sequence and decisions needed Group the backlog into immediate evidence collection, low-risk proposals ready for owner review, design or development exploration, measurement setup, and later experiments. Identify the decision owner and unresolved dependency for each group. Respect the supplied deadline without implying approval or delivery. ### J. Audit acceptance record Report Pass, Fail, or Not applicable for every check and explain failures: 1. Every cited evidence ID exists in the evidence ledger. 2. The ledger reconciles all files, screenshots, text excerpts, datasets, and references the user says were supplied; inaccessible items are marked unavailable. 3. Every finding cites direct evidence or is explicitly labeled as a hypothesis or evidence gap. 4. Every recommendation cites finding IDs and has a Proposed, Executed, Unavailable, or Unverified status. 5. Desktop and mobile conclusions are separated and limited to supplied viewports and states. 6. Analytics statements preserve supplied values, periods, segments, denominators, and event definitions; absent details are marked missing. 7. Competitor comparisons cite inspectable matched evidence rather than unsupported reputation or memory. 8. Accessibility conclusions are limited to the inspection method and do not claim conformance without appropriate test evidence. 9. Experiment proposals specify metrics, guardrails, prerequisites, and ownership without fabricated uplift, duration, or sample size. 10. High-risk claims and changes have the appropriate human review gate. 11. No recommendation is described as implemented, tested, approved, deployed, published, or successful without corresponding evidence. 12. The final priorities directly trace to the stated conversion goal or an explicitly identified usability or trust risk. End with a concise evidence coverage statement naming what Gemini inspected, what it could not inspect, what remains uncertain, and whether the audit is suitable for prioritization, requires more evidence, or is limited to preliminary observations.Input for this step
Provide the actual website or journey assets and observations, affected pages and devices, target audience, business or conversion goal, relevant behavioral evidence, known constraints, and limitations in the available evidence.
Carry forward
Carry the evidence register, prioritized UX findings, supporting evidence, material unknowns, and candidate improvement areas into the focused conversion critique.
Human checkpoint
Confirm that private or sensitive user data is sanitized, findings are traceable to the supplied evidence, and observations are clearly distinguished from assumptions or inferred user intent.
-
Step 2 Challenge the priority conversion journey
Use the evidence and prioritized findings from Step 1 to critically evaluate the priority conversion page or journey for clarity, relevance, friction, trust, proof, calls to action, information hierarchy, and likely conversion blockers.
Prompt: Landing Page Conversion Critique PromptAct as a senior Marketing specialist using ChatGPT. Your task is: [Goal or task]. Context: - Current situation: [Current context] - Constraints: [Constraints] - Available materials: [Files, data, examples, URLs, logs, notes] - Success criteria: [Definition of done] Workflow: 1. Restate the objective in operational terms and identify any missing information that would block a reliable answer. 2. Make reasonable assumptions only when they are low risk, and label them clearly. 3. Produce the main deliverable for "Landing Page Conversion Critique Prompt" with enough detail that a skilled operator can execute it immediately. 4. Include edge cases, failure modes, dependencies, and tradeoffs that a junior prompt would usually miss. 5. Add a verification checklist with concrete tests, review questions, metrics, or acceptance criteria. 6. End with the smallest safe next action. Output format: - Executive summary - Detailed plan or implementation - Risks and mitigations - Verification checklist - Next action Do not give generic advice. Optimize for a production-quality cro outcome.Input for this step
Provide the relevant Step 1 findings, current page content and structure, desired user action, target audience, known objections or friction points, available proof assets, business constraints, and unresolved evidence gaps.
Carry forward
Carry the strongest evidence-backed improvement hypotheses, their supporting rationale, expected user or business effect, implementation dependencies, risks, and unresolved questions into experiment design.
Human checkpoint
Select the hypothesis to test based on evidence, expected impact, strategic relevance, feasibility, and risk rather than visual preference or stakeholder opinion alone.
-
Step 3 Design the measurable UX experiment
Translate the selected evidence-backed hypothesis from Step 2 into a bounded experiment with a defined audience, control and treatment, success metrics, instrumentation requirements, guardrails, implementation dependencies, and explicit decision rules.
Prompt: GTM Experiment Design and Measurement BriefYou are an expert go-to-market experimentation strategist specializing in growth test design, measurement planning, campaign operations, sales motion testing, and decision-ready experiment readouts. Turn the supplied GTM idea into a measurable experiment brief with a clear hypothesis, audience, channel plan, offer or message, baseline metrics, tracking setup, guardrails, decision rules, launch checklist, and readout plan. The goal is to help marketing, sales, growth, RevOps, product marketing, founders, and leadership teams test GTM ideas without confusing activity, noise, or vanity metrics for real market signal. ## Context Placeholders Use the context below. If the experiment idea, target audience, hypothesis, or success criteria are missing, ask for them before producing the brief. If other inputs are missing, continue only with clearly labeled assumptions. * [Experiment idea and target audience] * [Hypothesis, offer, and channel] * [Baseline metrics and success criteria] * [Budget, constraints, and decision deadline] * [Tracking setup, owners, and review cadence] ## Important Constraints * Do not invent facts, metrics, benchmarks, conversion rates, customer evidence, market research, channel performance, budgets, legal approvals, tracking data, attribution results, or revenue impact. * Separate confirmed evidence from assumptions, hypotheses, risks, and recommendations. * Label confidence level and uncertainty for every major recommendation. * Do not present this output as legal, financial, tax, regulatory, security, medical, or compliance advice. * Customer-facing claims, pricing, discounts, guarantees, incentives, tracking plans, data usage, consent, privacy, and regulated-industry messaging must be reviewed by the appropriate human owner before launch. * Do not recommend launching an experiment if success criteria, tracking ownership, customer-facing message, or guardrails are too unclear to measure safely. * Do not treat impressions, clicks, opens, or leads as proof of business impact unless they are tied to the experiment objective and downstream evidence. * Do not overstate statistical certainty when sample size, time window, attribution quality, or baseline data is weak. * Treat weak baselines, unclear audience, poor segmentation, missing tracking, overlapping campaigns, sales follow-up gaps, attribution noise, and vague decision rules as experiment risks. * Make recommendations specific to the supplied experiment idea, audience, channel, offer, baseline metrics, budget, constraints, owners, and deadline. ## Step-by-Step Instructions 1. Summarize the GTM experiment context: * experiment idea * target audience * customer segment * channel * offer or message * hypothesis * baseline metrics * budget * constraints * owners * decision deadline 2. Clarify the hypothesis: * target audience * behavior expected * reason the behavior should happen * channel or message being tested * expected measurable change * business decision the test should inform * what would change if the test succeeds * what would change if the test fails 3. Identify assumptions: * audience assumption * pain-point assumption * offer assumption * channel assumption * timing assumption * sales follow-up assumption * tracking assumption * conversion assumption * budget assumption * operational-capacity assumption 4. Design the experiment setup: * test group * comparison group or baseline * segmentation * channel setup * message or offer variant * landing page or conversion path * sales handoff if relevant * tracking events * attribution approach * time window * sample constraints * budget limit * owner responsibilities 5. Define measurement: * primary metric * secondary metrics * leading indicators * lagging indicators * quality signals * disqualification signals * customer experience signals * sales acceptance signals * revenue or pipeline signal if relevant * baseline comparison * minimum evidence needed before deciding 6. Define guardrails: * budget cap * brand-risk limit * customer-experience limit * unsubscribe or complaint threshold * low-quality lead threshold * sales-capacity limit * legal or compliance review gate * privacy and tracking review gate * stop condition * escalation trigger 7. Define decision rules: * continue * stop * iterate * scale * retest * hand off to sales * exclude a segment * change message * change channel * run deeper discovery 8. Identify measurement risks: * attribution noise * small sample size * seasonality * overlapping campaigns * weak baseline * poor tracking * audience mismatch * novelty effect * sales follow-up inconsistency * lead quality distortion * vanity metrics * false positive * false negative 9. Create a launch checklist and readout plan: * pre-launch checks * owner approvals * tracking verification * launch monitoring * readout structure * decision meeting agenda * follow-up actions ## Output Format ### 1. Missing Context List missing inputs needed before a reliable GTM experiment brief can be completed. If enough context is available, say so. ### 2. Experiment Snapshot Use this table: | Area | Current View | Evidence | Risk or Uncertainty | | ---- | ------------ | -------- | ------------------- | Cover idea, audience, channel, offer, hypothesis, baseline metrics, success criteria, budget, constraints, owners, and deadline. ### 3. Hypothesis and Assumptions Use this table: | Hypothesis Element | Current Statement | Evidence | Assumption or Risk | | ------------------ | ----------------- | -------- | ------------------ | Include audience, behavior, pain point, offer, channel, expected change, and business decision. ### 4. Experiment Design Use this table: | Design Area | Recommendation | Owner Role | Check Needed | | ----------- | -------------- | ---------- | ------------ | Cover audience, segment, channel, offer, creative/message, landing path, tracking, sales handoff, time window, and budget. ### 5. Measurement Plan Use this table: | Metric | Type | Why It Matters | Baseline | Decision Use | | ------ | ---- | -------------- | -------- | ------------ | Separate primary metric, secondary metrics, leading indicators, lagging indicators, quality signals, and guardrail metrics. ### 6. Tracking and Attribution Review Use this table: | Tracking Area | Current Setup | Risk | Required Check | Owner Role | | ------------- | ------------- | ---- | -------------- | ---------- | Cover UTMs, CRM fields, landing page events, conversion events, sales follow-up, attribution window, and reporting source. ### 7. Risk and Guardrail Review Use this table: | Risk or Guardrail | Evidence | Threshold or Limit | Owner Role | Action if Triggered | | ----------------- | -------- | ------------------ | ---------- | ------------------- | ### 8. Decision Rules Use this table: | Outcome | Evidence Needed | Decision | Follow-Up Action | | ------- | --------------- | -------- | ---------------- | Include stop, iterate, continue, scale, retest, or escalate. ### 9. Launch Checklist Provide a practical checklist covering message approval, tracking verification, audience QA, budget cap, sales handoff, owner readiness, legal/compliance/privacy review where relevant, and reporting setup. ### 10. Readout Plan Provide a concise readout structure covering what was tested, what happened, what evidence was strong or weak, what assumptions changed, what decision is recommended, and what action happens next. ### 11. Missing Inputs and Human Checks List assumptions made, unresolved risks, blocked decisions, confidence level, and human checks required before launch or scaling. ## Verification Checklist Before finalizing, confirm that: * the hypothesis is specific and testable * target audience is clearly defined * success criteria are measurable before launch * baseline metrics are identified or flagged as missing * tracking and attribution risks are addressed * vanity metrics are separated from business outcomes * guardrails and stop conditions are included * customer-facing claims receive appropriate review * privacy, consent, compliance, finance, and legal review gates are included where relevant * decision rules are defined before launch * missing inputs and unresolved risks are clearly listed ## Final Instruction to Begin Begin now. First review the supplied experiment idea, target audience, hypothesis, channels, offer or message, baseline metrics, success criteria, constraints, budget, tracking setup, owners, review cadence, and decision deadline. If required context is missing, ask for it. Otherwise, produce the full GTM experiment design and measurement brief in the requested markdown format.Input for this step
Provide the selected hypothesis and supporting evidence, current baseline behavior where available, eligible audience, proposed change, implementation constraints, available traffic or sample considerations, analytics and tracking capabilities, and acceptable risk limits.
Carry forward
Produce and retain the approved experiment brief, implementation requirements, instrumentation checklist, launch guardrails, measurement plan, decision thresholds, and post-experiment readout requirements for execution.
Human checkpoint
Require appropriate design, product, engineering, analytics, privacy, legal, and release approval where applicable before exposing users to the experiment. Confirm that the measurement setup can answer the experiment question before launch.
Completion criteria
The workflow is complete when:
- UX findings are traceable to supplied evidence rather than unsupported assumptions.
- The most important usability and conversion issues are prioritized.
- A specific evidence-backed improvement hypothesis has been selected.
- The hypothesis is translated into a bounded experiment.
- The experiment defines audience, treatment, metrics, guardrails, and decision rules.
- Required analytics and instrumentation checks are documented.
- Material uncertainties, dependencies, and limitations remain explicit.
- Required product, design, analytics, privacy, technical, and release approvals are identified before execution.
Was this useful?