Growth

How to Make Product Screenshots That Get Clicks

October 15, 2026
14 min read

AI-friendly Markdown · structured for AI citations

How to Make Product Screenshots That Get Clicks

Make product screenshots that get clicks: pick 3-5 outcome moments, use a realistic demo account, capture clean 2x shots, caption them, order the gallery.Product screenshots get clicks when each one shows a result a stranger wants, not a screen you happen to be proud of. Pick the three to five moments where your product delivers its outcome, fill a demo account with realistic fake data, capture clean high-resolution shots with no browser clutter, crop each image to the one thing that matters, and give it a short caption that names the result. Then order your launch gallery like a story: the result first, how it works next, proof last. That's most of it. The rest of this post is how to do each step without it eating your launch week. Below: choosing the moments, a believable demo account, capture setup, crops and captions, gallery order, sizes worth knowing, the share image, alt text, dark mode and mobile, keeping images current, tools, a made-up before/after example, a checklist, traps, and a 7-day plan. Why do screenshots matter so much to cold visitors? Because they get looked at before anything gets read. Think about how you browse a launch board yourself. You scroll, an image catches you, and only then do you read the tagline. A cold visitor doesn't know your name and doesn't trust your adjectives yet. A screenshot is the one thing on the page that can't exaggerate much: it either shows something useful or it doesn't. On hunt sites and Product Hunt-style listings, the gallery is basically your product tour, and plenty of people never click through to your site. On your landing page, the hero shot confirms (or kills) the headline. If your SaaS screenshots are a login screen, a settings panel, and a feature grid, you're asking strangers to imagine the value. Most won't bother. Which 3-5 moments should your screenshots show? Show the moments where the user gets something, not the places where they configure something. Write a shot list before you open the app

Product screenshots get clicks when each one shows a result a stranger wants, not a screen you happen to be proud of. Pick the three to five moments where your product delivers its outcome, fill a demo account with realistic fake data, capture clean high-resolution shots with no browser clutter, crop each image to the one thing that matters, and give it a short caption that names the result. Then order your launch gallery like a story: the result first, how it works next, proof last. That's most of it. The rest of this post is how to do each step without it eating your launch week.

Below: choosing the moments, a believable demo account, capture setup, crops and captions, gallery order, sizes worth knowing, the share image, alt text, dark mode and mobile, keeping images current, tools, a made-up before/after example, a checklist, traps, and a 7-day plan.

Why do screenshots matter so much to cold visitors?

Because they get looked at before anything gets read.

Think about how you browse a launch board yourself. You scroll, an image catches you, and only then do you read the tagline. A cold visitor doesn't know your name and doesn't trust your adjectives yet. A screenshot is the one thing on the page that can't exaggerate much: it either shows something useful or it doesn't.

On hunt sites and Product Hunt-style listings, the gallery is basically your product tour, and plenty of people never click through to your site. On your landing page, the hero shot confirms (or kills) the headline. If your SaaS screenshots are a login screen, a settings panel, and a feature grid, you're asking strangers to imagine the value. Most won't bother.

Which 3-5 moments should your screenshots show?

Show the moments where the user gets something, not the places where they configure something.

Write a shot list before you open the app. For each candidate screen, ask: "Would a buyer pay for what's on this screen?" If the answer is "no, but they need it to get there," it's not a gallery image.

  1. The result. The finished report, the sent proposal, the cleaned-up list, the published page. Whatever your product produces, show it done.

  2. The core action. The one step where the work happens: dragging the item, pasting the text, clicking generate, approving the change.

  3. The "oh, that's nice" detail. One small thing that saves time or prevents a mistake, shown in context.

  4. The handoff. What the user's client, teammate, or customer sees. For many products, this is the screen that sells it.

  5. Optional proof. A real quote with permission, or a defended number, laid out cleanly. Only if you have it.

The words for your captions should come from how buyers describe the job, not from your feature names. If you haven't pinned that down yet, a one-page positioning brief gives you the "who it's for" and "what they get" lines you'll reuse here.

Skip: login and signup screens, empty dashboards, settings pages, admin tables, and anything that needs a paragraph to explain.

How do you set up a demo account that looks real?

Fake data that looks fake makes the product look fake. Real customer data in a public image is worse. The fix is a dedicated demo account filled with realistic, invented, non-personal data.

  • Create one fictional workspace with a plausible name in your buyer's world, and keep it consistent across every image.

  • No lorem ipsum, no "Test User 1," no "asdf." These scream unfinished. Write short, believable entries: "Kitchen remodel, 3 rooms," "Q3 newsletter draft," "Order #1042."

  • Use invented names and contact details that can't belong to anyone real you know. No celebrities, no friends "as a joke."

  • Make numbers plausible. Not round, not huge. 37 items looks lived in; 10,000 looks staged for a tiny product.

  • Keep dates recent and relative. A calendar stuck in a year-old month tells people the product might be abandoned.

Never screenshot a real customer's account, even "just blurred." Blur misses the name in a sidebar or the email in a tooltip. Build the demo account once and reuse it for every screenshot, video, and docs image.

How do you capture clean, sharp screenshots?

Most screenshot ugliness comes from the stuff around the product, not the product itself. Clean that up first.

  1. Use a fresh browser profile for captures: no bookmarks bar, no extension icons, no logged-in avatar from your personal account, no other tabs.

  2. Turn on Do Not Disturb and close toasts, cookie notices, and "new version" banners.

  3. Fix the window size and use the same one every time, so every image in a set has the same proportions and text size. Write the size down in your inventory sheet (more on that below).

  4. Capture at 2x on a high-density screen, or with browser zoom set so the UI renders crisply. Text that looks fine on your laptop can turn to mush when a platform scales the image down.

  5. Hide the cursor unless it's pointing at the one thing you want people to notice.

On a Mac, Apple's guide to taking a screenshot on Mac covers the shortcuts: Shift-Command-4 then Space captures a single window, and holding Option while you click leaves out the window shadow. Shift-Command-5 opens the Screenshot app with a timer and an option to show or hide the pointer. On Windows, Windows logo key + Shift + S opens Snipping Tool's capture overlay.

For web apps, Chrome DevTools device mode is underrated for this job. You can type an exact viewport width and height, set a device pixel ratio, and use "Capture screenshot" from the device toolbar menu to grab exactly the viewport with no browser chrome at all.

How should you crop and caption each image?

Crop until the image has one point, then say that point in a few words.

A full-window screenshot shrunk into a gallery slot becomes a grey rectangle with tiny text. Crop to the panel that matters and let it fill the frame. If you need the sidebar for context, keep a sliver.

Captions work best as outcomes, not feature names:

  • Weak: "Smart Templates"

  • Better: "Start every client proposal from last month's best one"

A few rules of thumb (opinions, not platform rules):

  • One caption per image, ideally under ten words.

  • One annotation at most: a single arrow, circle, or highlight. Three arrows means the image is trying to do three jobs.

  • Put the caption on a plain band, not floating over busy UI.

  • Check the caption and key UI text at thumbnail size on a phone. If you squint at your own image, strangers won't try.

How do you order a launch gallery so it tells a story?

Treat the gallery like a very short pitch: what you get, how you get it, why to believe it.

  1. Image 1: the result. This is often the only image people see, and on many boards it doubles as the preview. Show the finished outcome with a caption that names who it's for.

  2. Images 2-3: how it works. The core action and the handoff. Each one should make the next step obvious.

  3. Image 4: the nice detail. The small thing that makes switching feel worth it.

  4. Image 5: proof or a clear next step. A short real quote, a defended number, or a simple "who it's for / where to start" card. If you have very little proof, keep it honest; there's a whole playbook on social proof when you have almost no users.

Product Hunt's help page on how to post a product says the gallery needs two or more images before it's viewable, that you can drag and drop to reorder after upload, and that the recommended gallery image size is 1270x760. Even on boards with no stated minimum, three to five strong images beat eight weak ones.

If you also have a short demo video, it complements the gallery rather than replacing it. The 90-second product demo guide covers that side.

What sizes and formats should you actually use?

Only a few numbers for launch gallery images are worth memorizing, and they come from the platforms themselves:

  • Product Hunt gallery: 1270x760 recommended. Thumbnail: square, 240x240 recommended (from the same Product Hunt help page above).

  • LinkedIn link share image: LinkedIn's help article on making your website shareable on LinkedIn lists a minimum of 1200x627 pixels, a recommended 1.91:1 ratio, and a 5 MB maximum file size.

  • Other boards and directories: check the form you're filling in; many state a size next to the upload button. If one doesn't, a wide image around 16:10 to 16:9 is a safe rule of thumb.

The workflow that saves the most time: capture one high-resolution master per moment, then export each platform's crop from that master. Don't re-shoot for every site.

Export UI screenshots as PNG so text stays sharp, then run them through a compressor before upload. That's all I'll say about file size here; heavy page-speed work is its own project.

When someone pastes your URL into a chat or a social post, the image that shows up comes from your page's Open Graph tags. The Open Graph protocol lists og:image as one of the four required properties for every page, and says that if a page specifies an og:image it should also specify og:image:alt, a description of what's in the image.

Make it a cropped version of your best result screenshot, with a four to six word outcome line and your product name. A plain logo on a gradient says nothing. Size it for the strictest platform you care about (the LinkedIn guidance above is a good default) and keep the important part away from the edges, since apps crop previews differently.

How do you write alt text for screenshots?

Describe what the screenshot shows and why it's there, in one or two plain sentences. "Screenshot of dashboard" helps nobody. "Weekly plan view showing five prepped lunches and one merged grocery list for a client" tells a screen reader user, and a search engine, what the image proves. Skip "image of" at the start, keep UI labels that matter, and leave out decorative details like colors unless they carry meaning.

Dark mode or light mode, and do you need mobile screenshots?

Pick one mode for the whole set. Mixing dark and light in one gallery looks like two different products. Rule of thumb: match the mode your buyers actually use, and keep the landing page and gallery consistent with each other.

Mobile screenshots earn a slot when the phone is part of the job: a client receives something, a field worker checks in, a customer pays from a link. If your product is desktop-only, a phone mockup is decoration. When you do use one, capture a real phone screen or a correctly sized viewport.

How do you keep screenshots current when the UI changes?

Stale screenshots are a quiet trust leak. A visitor signs up, the app looks nothing like the gallery, and the first feeling is "wait, is this the same product?"

Keep a tiny screenshot inventory sheet. It takes ten minutes to set up and saves you from hunting for "that old hero image" on six different sites:

File

Where it's used

UI version

Capture setup

Last updated

result-weekly-plan.png

Landing hero, MakerHunt gallery #1, share image

v2.3

1440x900 viewport, 2x, light

Oct 2026

core-build-week.png

Gallery #2, docs page

v2.3

1440x900 viewport, 2x, light

Oct 2026

handoff-client-phone.png

Gallery #3, onboarding email

v2.1

390x844 viewport, 3x

Aug 2026

The rows are illustrative. The habit: when you ship a visible UI change, filter the sheet for affected screens and re-shoot only those, from the same demo account and capture setup. A monthly glance at "last updated" catches the rest.

Which tools do you actually need?

Fewer than you think. Your OS already covers capture: the Mac shortcuts and Screenshot app, or Snipping Tool on Windows (which also has a text action that can quickly redact email addresses and phone numbers in a snip, handy as a last check, though not a substitute for a clean demo account). Chrome DevTools handles exact viewport sizes and pixel ratio for free. For captions and crops, any design tool you already use is fine; a template with a fixed caption band at your gallery size makes each new image a few minutes' work. Dedicated screenshot apps are a convenience, not a requirement.

Everything in this example is made up. Prepcairn is a fictional tool that lets personal trainers build a weekly meal-prep plan and send each client a phone-friendly version with one merged grocery list. Ines, the solo maker, is getting ready for a weekly launch on a hunt site.

Slot

Before

After

1

Full-window dashboard with an empty "Welcome!" panel

Client's phone view of a finished week, caption "Your client's whole week on one screen"

2

Settings page with units and timezone toggles

Trainer dragging a saved recipe into Wednesday, caption "Build a week from recipes you already trust"

3

Feature grid with six icons and no product UI

Merged grocery list, caption "One shopping list, duplicates already combined"

4

Client list showing "Test User 1" through "Test User 4"

Check-in view with invented clients, caption "See who actually prepped this week"

5

Angled laptop mockup with unreadable text

A short quote from a trainer who gave permission, plus "For trainers with 5 to 40 clients"

She built a demo workspace called "Northside Strength" with twelve invented clients, captured everything at 2x in one fixed viewport, and reused the slot 1 crop as her share image. Made-up result: across two similar launch weeks, listing clicks went from 31 to 52, and more comments asked about the grocery list than about price. Small numbers, direction only. The bigger change: commenters described the product correctly without reading the description.

Check

Pass when

Shot list

3-5 moments, each one shows a result, action, handoff, detail, or real proof

Demo account

One fictional workspace, no lorem ipsum, no test users, no real customer data

Clean capture

No bookmarks, extensions, notifications, stray tabs, or cursor (unless it points at something)

Consistency

Same window size, same mode, same pixel ratio across the set

Crop

Each image has one point and fills its frame

Caption

One outcome caption, under about ten words, readable at thumbnail size

Order

Result first, how it works next, proof or next step last

Sizes

Exported per platform from one master; stated sizes checked on each form

Share image

og:image set to a cropped result shot with an outcome line, og:image:alt filled in

Inventory

Every file listed with where it's used, UI version, and last updated

What traps make screenshots backfire?

  • The feature-tour gallery. Eight images, one per menu item. Nobody learns what they get.

  • Tiny unreadable text. A full 27-inch-monitor screenshot shrunk into a gallery slot. Crop harder.

  • Fake data that looks fake. "John Doe," "Lorem ipsum," and order totals of $1,000,000.00 make the whole thing feel like a template.

  • Stale UI. The gallery shows last spring's sidebar. New signups feel bait-and-switched even when nothing bad happened.

  • Device mockups that hide the product. An angled laptop on a marble desk with the actual UI taking up a fifth of the frame. If you use a frame, keep it flat and let the screen dominate.

  • Real customer data leaks. A name in a dropdown, an email in a notification, a client logo in a table. Use the demo account, every time.

A 7-day plan to ship your screenshots

Day

Focus

Done when

1

Shot list

3-5 moments written down with a draft outcome caption for each

2

Demo account

Fictional workspace filled with realistic data; every target screen looks lived in

3

Capture setup

Clean browser profile, Do Not Disturb, fixed viewport and pixel ratio noted

4

Capture masters

One high-resolution master per moment, all in the same mode

5

Crop and caption

Each image cropped to one point with one caption; checked at thumbnail size on a phone

6

Export and place

Gallery exports per platform, hero shot on the landing page, share image and og:image:alt set, alt text written

7

Inventory and review

Inventory sheet filled in; one person who hasn't seen the product explains it back from the gallery alone

Day lengths are planning guesses. If day 2 runs long, that's normal; the demo account is the part you'll reuse the most.

FAQ

Are animated GIFs better than still images?

They can help for one interaction that's hard to show in a still, like a drag-and-drop. Keep them short and calm. Product Hunt's help page notes that a GIF thumbnail needs to be under 3MB and warns against strobing effects, quick cuts, and unreadable text. Your first gallery image should still work as a still.

Is it OK to edit a screenshot to make it look better?

Cropping, captions, a highlight, and cleaning up demo data are fine. Adding features that don't exist, or numbers the product can't produce, isn't. If a new user can't reach what the image shows, change the image.

How often should I update product screenshots?

Whenever a visible change touches a screen in your inventory, plus a quick monthly check. Before any launch or relaunch, re-shoot anything older than your current UI version.

Make the first image do the work

Good product screenshots aren't about design skill. They're about choosing the moment that shows the result, making the data believable, and cutting everything else. Get image one right and the rest of the gallery just has to keep the promise.

When you list on MakerHunt, your listing gallery is exactly where these images go to work, so it's a good first place to use the set you just made.

product screenshotsSaaS screenshotslaunch gallery imagesProduct Hunt galleryOpen Graph imagelaunch assetsproduct marketingmakersindie hackersGrowth