Multimodal Website UX Evidence Audit

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.