How to Take Product Screenshots That Explain the Product in Four Frames
Take product screenshots that show the result, not the sign-in screen: choose the four moments a new user cares about, fill the app with realistic invented data, capture at the size you will display, and crop to the part that matters. Put the frame showing the finished outcome first, and give every image a short caption and a descriptive file name.
Which four frames should you capture?
A set of screenshots is a short story, and the order is part of the message. Lead with the frame a visitor would most like to end up with, then show how they get there. The table maps four frames to what each one proves.
| Frame | Shows | Common mistake |
|---|---|---|
| 1. The result | The finished state: the invoice, the report, the cleaned folder | Starting with a sign-in or a blank dashboard |
| 2. The input | What the user gives the product: a file, a list, a pasted note | Showing an empty form, which says nothing |
| 3. The one step that is different | The moment your product does what others do not | Capturing a settings page because it looks busy |
| 4. Where it fits | The product beside the tools around it, or on a phone | A grid of menus that the reader has to decode |
The frames adapt to the product. A command-line tool has no dashboard, so show the command and its output in a terminal with the font enlarged and the prompt trimmed. A mobile app is better shown full height, on one screen at a time. A browser extension needs the page it changes, with the extension’s effect visible. In every case ask which single frame, shown alone, would make a visitor understand what the product gives them.
How do you fill the app with believable data?
An empty app screenshots badly, and so does one full of “test test test”. Invent data that looks like real use: names of the right length, plausible dates, numbers that are not all round. Make up a small business, a project with a few real-sounding tasks, a week of entries. Then walk through the product once as that fictional user and capture along the way.
- Never use real customer data. A real name, an email address or an invoice in a public image is a privacy problem you cannot take back.
- Check the edges of the frame. Browser tabs, bookmarks, notification banners, a second monitor’s window and a clock in the corner all leak things. Use a clean browser profile.
- Remove secrets. API keys, tokens and signed URLs in a terminal or settings page must be blurred or replaced, even if you intend to rotate them.
- Use one theme. Mixing light and dark in one set looks careless unless the switch itself is the point.
What size, format and tool should you use?
Capture at the size you will show, or larger, and never stretch a small image up. Wide frames suit desktop products, tall ones suit phones. PNG keeps the edges of interface text crisp; JPEG or WebP suit photographic content and keep files small. On a Mac, Shift-Command-5 opens the screenshot toolbar, and on Windows, Windows key plus Shift-S opens the Snipping Tool. In Chrome’s developer tools, the device toolbar lets you capture a phone-sized view of a web page.
Check the limits of each place before you export. The launch form on this board accepted, as of 13 November 2026, a square logo of up to 1 MiB and up to four gallery images of up to 3 MiB each, in PNG, JPEG or WebP, so compress anything larger and do not plan on an SVG or an animated GIF. Other platforms ask for other sizes; the launch platform screenshot sizes page lists what each one states, and the logo and icon specs cover the square mark.
How should you annotate, caption and name the files?
Use at most one arrow or highlight per frame, in one colour, and only where the eye would otherwise miss the point. A caption should say what the visitor is looking at in terms of their job, for example “Notes pasted in on the left, action list on the right”, and not describe the screen’s layout.
Name files for what they show. Google’s image guidance, read on 13 November 2026, says short, descriptive filenames give light clues about the subject, and that my-new-black-kitten.jpg is better than IMG00023.JPG. It calls alt text the most important attribute for describing an image, advises writing it to be useful and in context, and warns against stuffing it with keywords. For a launch screenshot that means a file such as meetingmint-action-list.png and alt text such as “Action list generated from pasted meeting notes”. Where a platform does not let you set either, the habit still keeps your own files tidy for your site.
What should you keep out of the frame?
- Mockups of features you have not built. Visitors try to use what they see, and a screenshot of something that does not exist is a broken promise on the first visit.
- Text too small to read. Shrink each image to about thumbnail width before you commit. If you cannot read the key words, crop closer or enlarge the interface.
- Stock device frames that hide the interface. A shiny laptop around a tiny screen shrinks the part that matters.
- Error states you did not mean to show. Scan for red banners, loading spinners and dev-mode warnings.
Browse the design tool ideas on the board for a sense of how makers describe visual products, and keep your screenshots consistent with the wording in your product description.
How do you test the set before you publish?
- Shrink each image to thumbnail size and check that the main idea survives.
- Show the first frame alone to someone for five seconds, hide it, and ask what the product does.
- Put the frames in a different order and read them as a story. If the story needs a caption to make sense, the frames are not carrying it.
- After publishing, see whether commenters ask about things the images already show. If they do, the images are not being seen or not being understood.
A moving demo covers what stills cannot; how to record a demo video covers that, and you can launch your product free with up to four of your first frames. Choose them before you press Publish, since the gallery is final once the launch is live; the moving demo itself can live on your own page.
Frequently asked questions
How many screenshots should a product launch have?
Three or four that tell a short story: the result first, then the input, the step that makes your product different, and where it fits. More frames dilute the message. The launch form on this board takes up to four gallery images as of 13 November 2026, which suits that shape. Check each platform’s limit before you upload.
What should the first screenshot show?
The finished outcome a visitor would most like to reach, such as the generated invoice, the clean report or the organised folder. Do not start with a sign-in page or an empty dashboard. The first frame often decides whether someone looks at the others, so it should show value without a caption.
Is it okay to use mockups instead of real screenshots?
Use mockups only for things that exist. A mockup of a feature you have not built sets up visitors to try something that fails, which costs trust. Polished layouts are fine if they match the real product. If the real product is rough, a clear, honest screenshot of it beats a pretty fake.
Do screenshot file names and alt text matter?
On your own site they do a little. Google’s image guidance recommends short, descriptive file names and useful alt text written in context, and warns against stuffing keywords into it. Descriptive names also keep your own files organised. On a launch board, check whether the form lets you add them at all.
Written by Post your build ideas with AI assistance and edited for this site. Where a page names another product, the facts came from that product’s own pages on the date shown above; terms change, so check them before you rely on them. About the publisher.