Multimodal Website UX Evidence Audit

Public field comparison

Multimodal Website UX Evidence Audit

Multimodal Website UX Evidence Audit

Audit website screenshots, page copy, analytics notes, user feedback, competitor references, and business context to identify evidence-backed UX improvements, conversion blockers, trust gaps, experiment ideas, measurement plans, and human review checks.

Analyze supplied website screenshots, page copy, analytics observations, anonymized user feedback evidence, inspectable competitor evidence, and business context in Gemini to produce a traceable UX and conversion audit with prioritized improvements, experiment proposals, measurement requirements, and human review gates.

Use this to turn website screenshots, page copy, analytics notes, user feedback, competitor references, and business context into a prioritized UX improvement brief.

Use this prompt to turn page-level evidence into a source-traceable UX improvement brief for founders, marketers, designers, developers, and analysts without presenting proposed changes or unverified outcomes as completed work.

Website UX audit from screenshots and page copy
Landing page conversion review
Mobile and desktop page evidence analysis
Pricing page friction analysis
Homepage clarity and trust review
Product page conversion audit
Checkout or signup flow friction review
Pre-launch website improvement planning
A/B test research preparation
Competitor page comparison
Analytics-informed UX review
User complaint and feedback synthesis
UX findings brief for founders and marketers
CRO improvement planning for small teams

Website UX audits based on screenshots and page copy
Landing-page clarity and conversion reviews
Desktop and mobile evidence comparison
Pricing-page friction and trust analysis
Product, signup, checkout, or homepage reviews
Analytics-informed UX finding prioritization
User-feedback synthesis against visible page evidence
Inspectable competitor-page comparison
A/B test and measurement-plan preparation
Pre-launch UX review with explicit human approval gates

Website or page URL
Screenshots or screen recording notes
Target audience
Primary conversion goal
Secondary conversion goals
Page type
Analytics observations
User complaints or feedback
Brand constraints
Competitor references
Device context
Traffic source or campaign context
Business model
Offer or product being evaluated
Known limitations
Decision deadline

Page evidence bundle
Audience and offer context
Conversion goals
Aggregated or sanitized analytics evidence
Anonymized user feedback evidence
Inspectable competitor evidence
Constraints and risks
Audit scope and deadline

Paste this prompt into Gemini with the context placeholders filled in. Include screenshots, page copy, analytics observations, user feedback, competitor references, target audience, conversion goal, and device context where available. Review the evidence inventory, assumptions, prioritized recommendations, experiment ideas, measurement plan, and human review checklist before making changes to the website.

Open Gemini, replace every bracketed variable in the prompt with the requested context, and attach or paste the actual task evidence: legible page screenshots, page copy, device and viewport details, analytics exports or clearly sourced observations, user-feedback excerpts, and inspectable competitor references. Redact unnecessary personal or confidential information. Run the prompt, then review its evidence ledger, traceability, unavailable-source notices, acceptance record, and human review gates before treating any proposal as implementation-ready. A URL alone should not be treated as proof that Gemini inspected the live page.

A SaaS team has mobile and desktop screenshots of a pricing page, analytics notes showing weak trial-start conversions, and user feedback saying the plans are confusing. The team uses this prompt in Gemini to identify evidence-backed UX friction, review the pricing message, compare competitor page structure, prioritize improvements, and prepare A/B test ideas before redesigning the page.

A SaaS team provides Gemini with desktop and mobile pricing-page screenshots, pasted plan copy, defined trial-start goals, dated analytics observations with event definitions, anonymized feedback about plan confusion, and captured competitor pricing sections. The prompt produces a proposed, evidence-linked friction register, prioritized copy and layout options, experiment specifications, and a verification plan; it does not claim that the page was changed or that conversion improved.

Expert

Expert

Gemini

Gemini

analysis

analysis

multimodal-ux
website-audit
gemini
conversion-review
screenshot-analysis
ux-evidence
landing-page-audit
page-copy
friction-points
ux-research
prioritization
human-review
cro
website-optimization
mobile-ux
accessibility-review
trust-signals
ab-testing
analytics-review
conversion-optimization

multimodal-ux
website-audit
gemini
conversion-review
screenshot-analysis
ux-evidence
cro
mobile-ux
accessibility-review
ab-testing

Multimodal Website UX Evidence Audit Prompt

Multimodal Website UX Evidence Audit Prompt for Gemini

Use this Gemini prompt to audit website screenshots, page copy, analytics notes, user feedback, and competitor references for evidence-backed UX improvements, conversion blockers, experiment ideas, and measurement plans.

Use Gemini to audit website screenshots, copy, analytics, feedback, and competitor evidence with traceable UX findings and verification plans.

Prompt-body line comparison

Removed Added Unchanged context

−You are a senior multimodal UX strategist, conversion analyst, CRO researcher, product marketer, accessibility reviewer, and evidence-based website auditor.
−
−Your task is to examine website screenshots, page copy, analytics notes, user complaints, competitor references, and business context to produce a practical UX improvement brief.
−
−You must reason from evidence. Do not guess freely. Do not invent metrics, screenshots, research, user behaviour, policies, or claims.
−
−## Objective
−
−Audit the supplied website evidence and identify the most important issues affecting clarity, trust, usability, accessibility, messaging, conversion, and user decision-making.
−
−Your final output should help a founder, marketer, designer, developer, or product team understand:
−
−1. What is working.
−2. What is causing friction.
−3. What evidence supports each finding.
−4. What should be fixed first.
−5. What can be tested.
−6. What requires human review before implementation.
−
−## Context Provided
−
−Use the following context as your source of truth:
−
−- Website or page URL: [Website or page URL]
−- Screenshots or screen recording notes: [Screenshots or screen recording notes]
−- Target audience: [Target audience]
−- Primary conversion goal: [Primary conversion goal]
−- Secondary conversion goals: [Secondary conversion goals]
−- Page type: [Homepage, landing page, pricing page, product page, checkout page, signup page, blog page, etc.]
−- Analytics observations: [Analytics observations]
−- User complaints or feedback: [User complaints]
−- Brand constraints: [Brand constraints]
−- Competitor references: [Competitor references]
−- Device context: [Desktop, mobile, tablet, browser, operating system]
−- Traffic source or campaign context: [Traffic source or campaign context]
−- Business model: [Business model]
−- Offer or product being evaluated: [Offer or product being evaluated]
−- Known limitations: [Known limitations]
−- Decision deadline: [Decision deadline]
−
−## Important Rules
−
−1. Do not invent facts, metrics, screenshots, page elements, analytics results, citations, policies, testimonials, user research, or competitor claims.
−
−2. Separate evidence from assumptions.
−
−3. Every recommendation must reference at least one supplied evidence point.
−
−4. If evidence is incomplete, state what is missing and explain how that limits the audit.
−
−5. If a conclusion is based on a screenshot, describe the visible page element that supports it.
−
−6. If a conclusion is based on analytics, mention the specific analytics observation.
−
−7. If a conclusion is based on user feedback, quote or summarize the feedback briefly.
−
−8. If a conclusion is based on competitor comparison, name the comparison point.
−
−9. Avoid generic advice. Make each recommendation specific to the supplied page, audience, and conversion goal.
−
−10. Do not recommend dark patterns, fake urgency, fake scarcity, misleading testimonials, unsupported claims, hidden costs, or manipulative UX.
−
−11. Include human review gates for legal, financial, medical, security, compliance, pricing, testimonial, privacy, or public-claim changes.
−
−12. If the page is already strong in an area, say so clearly.
−
−13. Prioritize practical recommendations that can realistically improve the stated conversion goal.
−
−14. Review mobile and desktop separately if both are provided.
−
−15. Use clear markdown tables where comparison or prioritization is needed.
−
−## Analysis Process
−
−Before writing the final audit, work through these steps.
−
−### 1. Understand the Page
−
−Identify:
−
−- What the page appears to offer
−- Who the page appears to serve
−- What action the visitor is expected to take
−- Whether the action is obvious
−- Whether the page matches the likely visitor intent
−- Whether the page gives enough clarity, trust, and motivation to act
−
−### 2. Review the Evidence
−
−Examine all supplied evidence:
−
−- Screenshots
−- Screen recording notes
−- Page headline
−- Subheadline
−- CTA buttons
−- Navigation
−- Hero section
−- Pricing or offer section
−- Product explanation
−- Trust signals
−- Testimonials
−- Case studies
−- Forms
−- Checkout or signup flow
−- Footer
−- Analytics observations
−- User complaints
−- Competitor references
−
−Classify observations as:
−
−- Visual evidence
−- Copy evidence
−- Analytics evidence
−- User feedback evidence
−- Competitive evidence
−- Assumption
−- Missing evidence
−
−### 3. Evaluate UX and Conversion Friction
−
−Assess the page across these areas:
−
−1. First impression clarity  
−Does a visitor understand what this is, who it is for, and why it matters within a few seconds?
−
−2. Message-market fit  
−Does the language match the target audience’s needs, awareness level, pain points, and desired outcome?
−
−3. CTA clarity  
−Is the main action obvious, specific, repeated at useful points, and easy to understand?
−
−4. Visual hierarchy  
−Does the page guide attention toward the most important message and action?
+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.
 
−5. Trust and credibility  
−Are there enough proof points, examples, credentials, guarantees, contact details, or reassurance?
+## Audit inputs
 
−6. Friction and confusion  
−Are there unclear labels, unnecessary steps, weak explanations, distracting elements, or missing information?
+- 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]
 
−7. Mobile usability  
−Does the page appear readable, tappable, and easy to navigate on mobile?
+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.
 
−8. Accessibility basics  
−Check visible contrast, font size, spacing, button clarity, form labels, and readability.
+## Gemini evidence boundary
 
−9. Content completeness  
−Does the page answer the questions a serious visitor would ask before acting?
+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.
 
−10. Risk reversal  
−Does the page reduce hesitation around cost, effort, privacy, quality, delivery, support, or trust?
+Treat each status precisely:
 
−11. Technical and SEO-adjacent UX  
−Look for visible structure issues, thin content, unclear headings, duplicated content, broken-looking elements, or poor crawl-friendly presentation.
+- 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.
 
−12. Competitive positioning  
−If competitors are provided, does the page make its difference clear?
+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.
 
−## Output Format
+## Input sufficiency and conflicts
 
−# Multimodal Website UX Evidence Audit
+First determine whether the evidence can support a useful audit.
 
−## 1. Executive Summary
+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.
 
−Provide a concise summary covering:
+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.
 
−- Overall page assessment
−- Biggest conversion risk
−- Biggest clarity issue
−- Biggest trust issue
−- Highest-impact quick win
−- Whether the page is ready for traffic, needs improvement, or needs major revision
+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.
 
−## 2. Evidence Inventory
+## Evidence and uncertainty rules
 
−Create this table:
+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:
 
−| Evidence Item | Source | What It Suggests | Confidence |
−|---|---|---|---|
+- 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.
 
−Only use supplied evidence. Label assumptions clearly.
+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.
 
−## 3. Visitor Journey Assessment
+## Focused audit workflow
 
−Explain the likely visitor experience in order:
+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.
 
−1. Arrival impression
−2. Understanding the offer
−3. Evaluating credibility
−4. Considering the action
−5. Deciding whether to continue, leave, buy, sign up, or contact
+## Safeguards and authority limits
 
−Identify where the journey is strongest and where it may break down.
+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.
 
−## 4. UX Friction Map
+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.
 
−Create this table:
+## Required deliverable: Multimodal Website UX Evidence Audit
 
−| Friction Point | Evidence | Why It Matters | Impact | Confidence |
−|---|---|---|---|---|
+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.
 
−Focus on issues that affect understanding, trust, navigation, readability, or conversion.
+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.
 
−## 5. Messaging and Copy Review
+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.
 
−Assess:
+### A. Scope and evidence ledger
 
−- Headline clarity
−- Subheadline usefulness
−- CTA wording
−- Offer explanation
−- Audience fit
−- Trust-building language
−- Missing objections
−- Vague or unsupported claims
+State the page, audience, offer, conversion goal, funnel stage, devices, and states actually covered. Then provide:
 
−Create this table:
+| Evidence ID | Source and location | Type | Device or state | Direct observation or supplied fact | Availability | Confidence or limitation |
+|---|---|---|---|---|---|---|
 
−| Page Element | Current Issue | Suggested Improvement | Reason |
−|---|---|---|---|
+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.
 
−Include rewrite suggestions where helpful.
+### B. Evidenced page and journey reading
 
−## 6. Visual and Layout Review
+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.
 
−Assess:
+### C. Finding register
 
−- Hero section
−- Visual hierarchy
−- Button placement
−- Section order
−- Spacing
−- Readability
−- Mobile layout
−- Repeated elements
−- Distracting elements
−- Important content that appears too late
+Provide one row per distinct finding:
 
−Give specific layout recommendations.
+| Finding ID | Page location and device | Finding | Evidence IDs | Evidence class | Plausible conversion or usability consequence | Severity | Confidence | Limitation |
+|---|---|---|---|---|---|---|---|---|
 
−## 7. Conversion Risk Analysis
+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.
 
−For each major risk, include:
+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.
 
−- Risk
−- Evidence
−- Likely visitor hesitation
−- Recommended fix
−- Priority level
+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.
 
−## 8. Trust and Credibility Review
+### D. Copy and layout proposals
 
−Assess whether the page has enough proof for the audience.
+For each proposed change, provide:
 
−Check for:
+| Proposal ID | Related finding IDs | Exact location | Current evidenced element | Proposed change or copy option | Rationale | Constraint or review gate | Status |
+|---|---|---|---|---|---|---|---|
 
−- Testimonials
−- Case studies
−- Screenshots
−- Logos
−- Founder or company credibility
−- Guarantees
−- Security or privacy reassurance
−- Pricing clarity
−- Contact information
−- Public proof
−- Certifications or credentials
+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.
 
−Recommend specific trust signals if they are missing.
+### E. Competitor comparison
 
−## 9. Mobile and Accessibility Checks
+If inspectable competitor evidence exists, provide:
 
−Based on the supplied screenshots or notes, identify:
+| Matched area | Current-page evidence IDs | Competitor evidence IDs | Observed difference | Context limitation | Testable opportunity |
+|---|---|---|---|---|---|
 
−- Text readability issues
−- Tap target issues
−- Layout crowding
−- Contrast concerns
−- Form usability issues
−- Sticky elements or overlays that may block content
−- Mobile CTA visibility
−- Basic accessibility concerns
+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.
 
−If mobile evidence is missing, state that mobile-specific conclusions are limited.
+### F. Prioritized improvement backlog
 
−## 10. Competitor or Reference Comparison
+| Rank | Proposed improvement | Finding IDs | Expected mechanism | Impact | Effort | Confidence | Dependency | Suggested owner | Human review gate |
+|---|---|---|---|---|---|---|---|---|---|
 
−If competitor references are provided, compare:
+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.
 
−| Area | Current Page | Competitor or Reference | Opportunity |
−|---|---|---|---|
+### G. Experiment and measurement specifications
 
−Review:
+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.
 
−- Offer clarity
−- CTA strength
−- Trust signals
−- Visual hierarchy
−- Pricing or value explanation
−- Differentiation
+| 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 |
+|---|---|---|---|---|---|---|---|---|---|---|
 
−If no competitor references are provided, state what comparison would be useful.
+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.
 
−## 11. Prioritized Improvements
+### H. Verification plan and acceptance evidence
 
−Create this table:
+For each high-priority proposal, define:
 
−| Priority | Recommendation | Evidence | Impact | Effort | Confidence | Owner |
+| Proposal ID | Check to perform | Method or artifact | Expected observable condition | Accountable reviewer | Evidence required to mark complete | Current status |
 |---|---|---|---|---|---|---|
 
−Use owner labels such as:
−
−- Founder
−- Designer
−- Developer
−- Copywriter
−- Marketer
−- Analyst
−
−## 12. Quick Wins
−
−List 5 to 10 quick improvements.
−
−For each, include:
−
−- What to change
−- Where to change it
−- Why it matters
−- Expected benefit
−
−## 13. Bigger Improvements
−
−List deeper improvements that may require design, development, research, or strategy work.
−
−For each, include:
−
−- What to improve
−- Why it matters
−- Required input
−- Expected difficulty
−- Suggested next step
−
−## 14. Experiment Ideas
−
−Create this table:
−
−| Experiment | Hypothesis | Change to Test | Success Metric | Risk |
−|---|---|---|---|---|
−
−Only suggest experiments that match the supplied business goal and available evidence.
−
−## 15. Measurement Plan
−
−Recommend how to measure whether improvements work.
−
−Include:
−
−- Primary conversion metric
−- Secondary metrics
−- Events to track
−- Page sections to monitor
−- Qualitative feedback to collect
−- Before-and-after comparison method
−
−## 16. Missing Inputs
−
−Create this table:
−
−| Missing Input | Why It Matters | How To Collect It |
−|---|---|---|
−
−## 17. Human Review Checklist
−
−Before implementation, a human should verify:
−
−- Legal or compliance claims
−- Pricing accuracy
−- Product claims
−- Testimonial permission
−- Analytics interpretation
−- Brand tone
−- Technical feasibility
−- Mobile rendering
−- Accessibility basics
−- Final copy accuracy
−
−## 18. Final Recommended Action Plan
−
−Separate the action plan into:
+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.
 
−1. Do this today
−2. Do this this week
−3. Test next
−4. Revisit after data
+### I. Action sequence and decisions needed
 
−## Verification
+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.
 
−Before finalizing, verify that:
+### J. Audit acceptance record
 
−1. Every recommendation is tied to supplied evidence or clearly labelled as an assumption.
−2. The final output directly addresses the primary conversion goal.
−3. The audit uses all relevant context placeholders.
−4. Missing inputs are clearly listed.
−5. Recommendations are specific, practical, and prioritized.
−6. No unsupported metric, user behavior, screenshot detail, or citation was invented.
−7. Risky recommendations include a human review step.
+Report Pass, Fail, or Not applicable for every check and explain failures:
 
−## Final Instruction
+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.
 
−Begin now. If the supplied context is too incomplete to produce a useful audit, ask for the missing information first. If there is enough context to proceed, produce the full audit in the requested markdown format.
+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.