The first impression frame

Expert: with sources and numbers. Plain: the same, without them, for beginners.

What is actually visible before a user decides, and why most product page work is spent below that line.

Verified 2026-09-19 · 37 days ago both creative conversion

Most conversion work is spent on things most users never see. This page is about the part they do.

What is visible before the decision

In an App Store search result: A the app name, up to three screenshots, app previews, ratings, app tags, developer cards, in-app events and promoted in-app purchases. (App Store search, verified 2026-09-18)

That is a substantial amount of information, and a user can decide without ever opening the product page. The search result is the first impression, not the product page.

On a product page before scrolling: icon, name, subtitle or short description, rating, and the first screenshots or the app preview’s poster frame (40-04). The description sits below that line, and on Play only the portion before “Read more” shows.

Everything else is below the fold: the rest of the screenshot set, the description body, What’s New, the full ratings breakdown.

What follows

The first three screenshots carry the argument. They appear in search results next to competitors, so they must work as a standalone unit. Assume no scrolling.

Portrait versus landscape is a real decision. Portrait yields roughly three narrow frames in a search result; landscape roughly one wide frame. Three chances at a short message, or one chance at a longer one. Worth testing rather than inheriting.

Caption text does the work. A Apple permits text and image overlays that demonstrate functionality on screenshots (Guideline 2.3.3, verified 2026-09-18). A raw screen capture of a UI communicates almost nothing at search-result size; a caption plus a cropped, enlarged UI region communicates one thing clearly.

Practical constraints on captions: short enough to read at a glance, large enough to survive scaling to smaller devices (40-02), and in the user’s language (40-07).

The short description is above the fold on Play. A Google’s guidance is to summarise the app’s biggest benefits and explain its core purpose in 80 characters (Best practices, verified 2026-09-18). It is read; the full description largely is not.

Matching the query

Everything above treats the search result as one frame. It is not. It is a frame shown against a specific query, and the user is scanning for evidence that your app does the thing they just typed.

The constraint that makes this hard: the default product page is the same for every query. A Custom product pages and product page optimization tests are the only ways to vary what a searcher sees (60-01, 50-01), and CPPs route traffic from keywords you already hold rather than adding new ones (CONFLICT-018). So for the default page you are choosing one visible wording to serve all your terms, and that choice has winners and losers among them.

What follows for the work:

Put the term itself in the visible metadata, not only the keyword field. Ranking for a term and looking like the answer to it are different problems. A user searching a feature name scans the name, subtitle and first caption for that word; if it appears only in the hidden field, you rank and lose the tap.

Decide which terms the visible copy is allowed to serve. Take the handful of terms that actually carry your search installs, and for each, look at the live result page on a real device and ask whether your entry reads as an answer to that query beside the competitors. Most apps discover the visible copy serves the brand term and one generic, and nothing else.

Weigh a visible-copy change across all terms, not the one that prompted it. Rewriting a subtitle to capture a rising term costs relevance on whatever it displaced. This is the reason a subtitle change is a conversion decision as much as a keyword decision, and why it belongs in the same review as the keyword field (runbooks/quarterly-keyword-refresh).

Where the term cannot fit, answer the intent instead. The caption does not have to contain the word to look like the answer to it. This is the part that is creative work rather than keyword work (40-10).

C The strongest version of this argument (that visible term matching lifts conversion for that term specifically, and that the lift then feeds the term’s ranking) is a practitioner model supported by individual cases rather than by controlled tests. The underlying mechanism is sound on both platforms’ own accounts, since conversion is a documented ranking input (00-04); the size of the effect is not evidenced. Use it to decide what to test, not to predict what a test will return.

Ordering the argument

A workable default, to be tested rather than believed:

  1. What it is and why it is better, the single claim that distinguishes you
  2. The primary use case, the thing most users came for
  3. Proof or breadth: social proof, scale, or a second major use case

Then, below the fold, the rest of the set for people already interested.

Do not lead with a feature nobody asked for. The most common first-screenshot error is opening with something novel rather than something wanted.

The rabbit hole

Screenshot design (colour psychology, device frames versus full-bleed, caption placement, the “hero” pattern) is a large practitioner literature with genuine craft in it and very little transferable evidence. Conversion effects are app-specific and category-specific, which is why claimed uplifts rarely reproduce.

The practical layer: decide what the first three frames must say, make them legible at the size they are actually seen, and test them (50-03). The rabbit hole exists; it is a place to take inspiration, not evidence.

How to hand that decision to a designer, with every constraint in one table, is 40-10.

What goes wrong

Designing a ten-screenshot story. Three are seen, in a list, beside competitors.

Captions sized for a design tool. Reviewed at full size, seen at a fraction of it.

Raw UI captures. Unreadable in a search result.

Leading with the newest feature. Interesting internally, irrelevant to someone deciding.

Optimising the description while the first screenshot is untouched. The description is below the fold; on iOS it is not even a search input (10-05).

In short

Every fact on this page in one line, with its evidence tier, source and verification date, 4 A. Generated from the claim register, so it cannot drift from the page above.

A Between 1 and 10 screenshots may be uploaded per localization; files must be .jpeg, .jpg or .png and must not contain alpha channels or transparency.
IOS-CRE-001 · verified 2026-09-18
A Guideline 2.3.3: screenshots must show the app in use, not only title art, login pages or splash screens. Text and image overlays demonstrating functionality are permitted. Guideline 2.3.9 requires rights to all material shown and fictional rather than real account information.
IOS-POL-006 · verified 2026-09-18
A An App Store search result can display the app name, up to three screenshots, app previews, ratings, app tags, developer cards, in-app events and promoted in-app purchases.
IOS-SURF-003 · verified 2026-09-18
A Google advises the 80-character short description should summarise the app's biggest benefits and explain its core purpose.
PLAY-MD-003 · verified 2026-09-18

Think your app deserves better?

Send the App Store link.
The audit comes back within two working days, whether you hire us or not.

Free, and we mean it. No card, no call required.