Test your website →

Blog

Show, Don't Tell: Screenshots That Explain in an Instant

A good product screenshot answers questions faster than any paragraph, but most homepages show decoration instead of evidence.

Writers are told to show, don’t tell. Websites should take the advice literally, because a website can actually show. A novelist showing courage has to construct a scene. You, showing your product, just have to take a picture of it. And yet the average software homepage is a wall of telling: paragraphs about power and simplicity and seamlessness, with either no image of the product at all or an image so stylized it might as well be abstract art.

The reason a screenshot works is that pictures and text are processed differently. Text is serial. The visitor reads word by word, holds the pieces in memory, and assembles a mental picture at the end. A screenshot delivers the picture directly. When someone sees an actual screen from your product, they learn a dozen things at once without effort: what kind of software it is, how dense it is, whether it looks like something they could operate, whether it resembles the tools they already know. A screenshot of a kanban board says “this is a kanban tool” faster than the sentence “organize your work visually” ever could, and it says it in a way that can’t be disbelieved. Adjectives can lie. Screenshots mostly can’t, which is precisely why they’re persuasive.

But there’s a craft to it, and most homepages get it wrong in one of two opposite ways.

The first failure is showing nothing real. The product image is an illustration: floating gradient shapes, a cartoon person watering a plant that grows into a chart. Illustrations are honest about being decoration, so nobody mistakes them for evidence, but nobody learns anything from them either. Slightly worse is the fake screenshot, a designer’s idealized mockup with three tidy rows of data that never came from the real app. Visitors have developed a nose for these. A too-clean mockup registers the way a food photo with obviously plastic fruit does: it makes you wonder what the real thing looks like, which is exactly the doubt you were trying to remove.

The second failure is showing everything. The founder screenshots the whole application, every panel and toolbar, and shrinks it to fit the hero. The result is technically real and totally illegible, a smear of gray rectangles. The visitor can see that you have software but not what it does. Density that would be fine on a monitor becomes noise when compressed into a card on a phone screen, and more than half your visitors are on phones.

The craft, then, is selective truth. Show a real screen, but choose the screen, and crop it around the moment that matters. Every product has one screen that embodies the reason people buy it. For an analytics tool it’s the chart that answered a question. For an invoicing app it’s the invoice, done, ready to send. For GazeSite it’s the graded report, so that’s what our homepage shows, because I learned this lesson on my own site: the version of the page that described the report converted strangers into curious visitors much less reliably than the version that just showed the report. Find your equivalent of that screen and crop away everything else. A screenshot at 100 percent scale showing one meaningful region beats a full-app screenshot at 30 percent scale showing all of them.

Two details do outsized work. First, the data in the screenshot should look plausibly real, because visitors read the data. If it’s a CRM screenshot, the visitor imagines their own customers in those rows; give them rows worth imagining into. Second, the screenshot should sit as close to the claim it proves as possible. The pattern to aim for is claim, then evidence, adjacent: the headline says “see every invoice’s status at a glance” and the image beside it shows a list of invoices with status badges. When image and claim are separated, or worse, when the image contradicts the claim, the visitor feels a small dissonance they couldn’t name but act on anyway.

There’s an accessibility footnote that is really a clarity test in disguise. Every image on the page needs alt text, the written description that screen readers speak aloud to blind visitors. Writing alt text for your hero screenshot forces you to say, in one plain sentence, what the image shows. If you find yourself writing “abstract illustration of connected shapes,” the alt text is telling you the image carries no information. If you can write “screenshot of a schedule showing three employees’ shifts for the week,” you’ve got evidence on the page. The sentence you’d write for a blind visitor is a good proxy for what a sighted visitor learns in the first glance.

Telling has its place. Some things a screenshot can’t convey: pricing, guarantees, who the product is for. But when founders write three paragraphs about how intuitive their interface is, they’re doing something faintly absurd, like a restaurant describing its food’s deliciousness on a billboard instead of photographing the dish. If the interface is intuitive, show it and let the visitor conclude it. Conclusions people reach themselves are the only ones they trust.

More articles

← All posts