CONVERSION

Mobile specific conversion issues

Use when mobile converts far worse than desktop and you need to separate real mobile problems from general ones.

mobile-specific-conversion-issues.md

Download .md

You are diagnosing why a page converts worse on mobile than desktop. Only report issues that are genuinely mobile specific.

PAGE OR FLOW: {{PAGE}}
MOBILE CONVERSION RATE: {{MOBILE_RATE}}
DESKTOP CONVERSION RATE: {{DESKTOP_RATE}}
MOBILE TRAFFIC SOURCES: {{MOBILE_SOURCES}}
KNOWN MOBILE BEHAVIOR OR NOTES: {{MOBILE_NOTES}}
PAGE DESCRIPTION OR COPY: {{PAGE_CONTENT}}

Work through these categories and report only where you find something:
1. Above the fold on a small viewport - what is actually visible before scrolling, and is the value proposition among it
2. Tap targets, thumb reach, and anything requiring precision
3. Input burden - keyboard types, date pickers, dropdowns with many options, anything requiring typing
4. Interruptions - interstitials, cookie banners, sticky bars, app install prompts
5. Load and layout shift, given the sources listed
6. Content that assumes a wide layout, such as comparison tables or side by side columns
7. Context of use - the mobile visitor may be interrupted, on data, or mid task

OUTPUT a table: Category | Issue | Why it is mobile specific | Fix | Confidence.

Then state clearly which part of the mobile to desktop gap is likely explained by intent and traffic source rather than by usability, and what you would measure to tell the two apart. Do not present a general usability issue as a mobile issue. No em dashes.

Fill in before running

Replace each placeholder with your own detail. The more specific you are, the less the model invents.

{{PAGE}}
{{MOBILE_RATE}}
{{DESKTOP_RATE}}
{{MOBILE_SOURCES}}
{{MOBILE_NOTES}}
{{PAGE_CONTENT}}

Getting a better result

Split your mobile rate by source before running this - paid social intent alone explains many gaps.
Describe the cookie banner and any sticky elements, since they cover more of a small screen than people expect.
The intent versus usability split at the end is the part to argue about internally.

Questions about this prompt

When do I use this rather than a general friction teardown?

When mobile converts far worse than desktop and somebody has already proposed a redesign. The teardown finds friction of any kind; this reports only what is genuinely mobile specific and refuses to present a universal usability problem as a mobile one. That distinction is what keeps the resulting fix list defensible.

What do I need in front of me before running it?

Both conversion rates, the mobile traffic sources, any behavioural notes and the page content. Split your mobile rate by source before running it, because paid social intent alone explains a large part of many gaps. Describe the cookie banner and any sticky bars, since they cover far more of a small screen than people expect.

What comes back, and which part is worth acting on?

A table of category, issue, why it is mobile specific, fix and confidence, covering only the categories where something was found. The closing paragraph is the important part: how much of the gap is likely explained by intent and traffic source rather than usability, and what you would measure to tell the two apart.

What is the mistake that costs me here?

Treating the whole mobile to desktop gap as something to be closed. Part of it is intent and never closes, so a team that promises parity is promising what it cannot deliver. Argue the intent versus usability split internally before committing to a target, and treat the measurement suggestion as work rather than as a footnote.