Store Listing Basics: Screenshots, Short Description and Feature Graphic

If you only have a few hours to spend on your Google Play listing, spend them on three things: the first two or three screenshots, the short description, and the feature graphic. Those are what most people see before they decide to install, or before they decide to keep testing your app. The rest of the listing matters, but it matters less.

This post covers what each asset is for, the practical limits, and the mistakes that cost indie developers the most time. Google changes asset specs and policies from time to time, so check the current numbers in Play Console Help before you export anything.

Why the listing matters even during a closed test

It is easy to treat the store listing as a last-minute chore before production. That is a mistake for two reasons.

You need it eventually. Play Console asks you to complete the main store listing as part of getting an app ready to publish, so you will write it anyway.
It is a free consistency check. If your screenshots show features the build does not have, or your description promises things the app does not do, you will notice while writing the listing. Your closed testers will notice too.

Writing the listing while your closed test is still running means you can fix mismatches between what you say and what the app does before reviewers or real users see them.

Screenshots

What they are for

Screenshots answer one question: what will I be able to do with this app? Most people will look at the first two or three, so put your strongest screens there.

Practical guidelines

Lead with the core action. If your app is a habit tracker, show a habit being checked off, not a splash screen or a login form.
Use real screens. Screenshots from the actual build keep you honest and avoid misleading-content problems.
Add a short caption if it helps. A few words above the device frame, such as "Track habits in two taps", is usually enough. Long captions get unreadable at thumbnail size.
Keep the order logical. Think of the sequence as a mini walkthrough: open, do the main thing, see the result, then secondary features.
Use clean demo data. Realistic sample content looks better than "test test test" or lorem ipsum.
Hide personal data. Check notifications, account names and email addresses in the status bar and content.

Technical limits to verify

Play Console has requirements for file format (JPEG or 24-bit PNG without transparency, at the time of writing), minimum and maximum dimensions, and the number of screenshots per device type. It also asks for a minimum number of screenshots. Exact values can change, and tablet and other form factor requirements differ from phone ones, so check Play Console Help rather than relying on a blog post, including this one.

The short description

The short description is a single line shown near the top of your listing, and it has a hard limit of 80 characters. It is often the first text a person reads, so every word has to work.

A simple formula

Say what the app does, for whom, and the main benefit, in plain words. For example:

Weak: The best habit app ever, download now!
Better: Track daily habits and see your streaks at a glance.

The second one tells you what you can do and what you get. It does not need superlatives.

What to avoid

Keyword stuffing. Repeating search terms makes the line unreadable, and Google's metadata policy discourages it.
Hype claims. "Best", "#1" and similar claims without clear support can run into policy problems and make you sound like everyone else.
Emoji and ALL CAPS. A little styling is fine in some places, but excessive emoji, symbols or capital letters can be flagged. Read the current metadata policy in Play Console Help.
Promises the app cannot keep. If a feature is "coming soon", leave it out.

Write the short description first, then use it as the spine of your longer description. If you cannot say it in 80 characters, you may not have decided yet what the app is for.

The feature graphic

The feature graphic is a wide banner image that Google Play can show at the top of your listing and in some promotional spots. At the time of writing it is 1024 x 500 pixels, in JPEG or 24-bit PNG without transparency, but confirm that in Play Console Help.

Design tips that work for small teams

Keep the text minimal. The app name and a very short tagline at most. The image may be scaled down, and some surfaces overlay a play button on a promo video if you add one.
Leave the edges clear. Keep key elements toward the center so cropping or overlays do not cut them off.
Match your icon and screenshots. Same colors, same typeface, same tone. A listing that looks consistent feels more trustworthy.
Do not copy store UI. Fake rating stars, download buttons or badges that imitate Google Play can be treated as misleading.
Show the product, not a stock photo. A device frame with one clear screen is usually better than a generic abstract background.

You do not need a designer. A simple background in your brand color, the app name, one device mockup and a short tagline will do the job.

A quick order of work

Write the 80-character short description.
Pick the three screens that best show the core value and capture them from the current build.
Add captions and finish the remaining screenshots.
Build the feature graphic from the same colors and one of those screens.
Write the full description, using the short description as the opening.
Compare everything against the actual app, line by line.

Use your closed testers as listing reviewers

Closed testers see your app with fresh eyes, which is exactly what you need for a listing check. Ask them two extra questions in your feedback request:

Does the app match what the screenshots and short description led you to expect?
Was there anything in the listing you could not find in the app?

If you use TesterMob, the testers are people using the app on their own Android phones for about 20 minutes a day and sending written feedback, so you can include those questions in what you ask them. Details on how that works are on the developer page, and the FAQ covers common questions. Either way, the point is the same: someone who is not you should read your listing and then use your app.

Common listing mistakes

Screenshots from an old version. The UI has changed, the screenshots have not. Update them before each release that changes the interface.
A default or placeholder icon and graphic. These make the app look unfinished.
Description that does not match reality. This is the one most likely to cause negative reviews later and policy trouble sooner.
Ignoring localization. If your app supports several languages, consider translating at least the short description. Machine translation is fine as a starting point, but have a native speaker check it if you can.
Forgetting to proofread. Typos in an 80-character line are very visible.

A note on approval

A clean, accurate listing will not guarantee that Google approves your app for production. Review depends on many things, including your policy compliance, your app's behavior and your closed test. A listing that is honest and consistent simply removes one avoidable source of problems. TesterMob is not affiliated with Google and cannot guarantee production approval.

Wrap-up

Treat the three assets as a set. The short description says what the app does, the screenshots prove it, and the feature graphic makes the listing look like one coherent product. Check the current specs and metadata policy in Play Console Help, then ask a few real people whether the listing matches the app. If you are still working on the testing side of things, our blog has more step-by-step posts for indie Android developers.