# Four screenshot prompts that keep your product readable Canonical: https://www.lazyscreenshots.com/blog/screenshot-prompts-social-media-preserve-ui/ Author: Ali Abouelatta (https://www.lazyscreenshots.com/authors/ali-abouelatta/) Published: 2026-09-19 Updated: 2026-09-19 Research type: Practical templates + calculated examples Method: Original prompt templates and proportional-scaling calculations for a specified screenshot fixture. These are authored workflows, not a product benchmark, readability study or social-engagement experiment. Technical and accessibility references checked September 18, 2026. Pretty screenshots still need to be readable. A full desktop, a gradient, and a generous border can look good at export size. At a smaller viewing width, the label you wanted someone to notice can shrink below a useful size. The example below takes a 14px label down to about 5.1px. I would start with the crop. Then write the prompt. Below are four prompts for a design or coding assistant. They ask it to compose around an existing screenshot, not generate a replacement interface. The distinction is practical: the screenshot is evidence of what the product does. An invented button, price, customer name, or success message makes that evidence unreliable. ## The calculation I would do before picking a background Take a 1,440-CSS-pixel-wide app window captured at 2× resolution. The image is 2,880 pixels wide. A 14 CSS-pixel interface font has a nominal size of about 28 image pixels at 2×; the visible glyph height depends on the font. Place it on a 1,200-pixel canvas with 80 pixels of padding on each side. The screenshot gets 1,040 pixels. Now view that card at 600 CSS pixels wide. The nominal text size is about **5.1 CSS pixels**. That follows from `28 × (1040 ÷ 2880) × (600 ÷ 1200)`. No amount of shadow adjustment changes it. Here is the same source label, canvas, padding, and viewing width with three different crops: | Width of source crop, in image pixels | Screenshot width on the exported card | Approximate nominal label size at a 600px viewing width | | --- | --- | --- | | 2,880: the whole window | 1,040px | 5.1px | | 1,440: half the window | 1,040px | 10.1px | | 960: one-third of the window | 1,040px | 15.2px | These are calculated layout scenarios, not a readability study or measurements of a particular social network. The model assumes proportional scaling, no extra crop by the destination, and the same original text size. Its job is to reveal a composition problem before you spend time decorating it. Doubling the export dimensions while keeping the crop, relative padding, and final viewing width unchanged does not double the visible text size. You have more image pixels describing the same small thing. Higher resolution can improve sharpness; it cannot give the label more room in the reader's feed. [MDN's canvas guide](https://developer.mozilla.org/en-US/docs/Web/API/Canvas_API/Tutorial/Optimizing_canvas) explains why canvas backing resolution and its CSS display dimensions are separate. That is the technical distinction behind this calculation, not a claim about engagement or conversion. ## Prompt 1: One feature, one screenshot Use this for a feature announcement. Choose the crop yourself, or make the assistant propose one before it exports. ```text Create a social image around the attached product screenshot. The screenshot is a fixed image asset. Use an HTML or an equivalent image layer. Do not redraw, regenerate, retouch, or replace the interface. Preserve its text, numbers, icons and state. The one thing this image should communicate is: [SPECIFIC FEATURE]. The exact headline is: [YOUR FINAL HEADLINE]. Do not add claims. Start with a crop that makes that feature legible. Keep enough surrounding interface to explain where it lives. If the crop would remove necessary context, show me that tradeoff before proceeding. Compose on a 1200 × 900 canvas. Use one quiet background, a modest border, and a restrained shadow. Avoid device mockups and extra UI. Show the result at 600px and 360px CSS widths as well as export size. If the feature is unreadable at those sizes, tighten the crop or split the story into two images. Do not pretend sharpening fixes it. Deliver the editable composition and a PNG. Keep the original asset. ``` The two viewing widths are review fixtures. They are not universal feed sizes. Open the result in the actual destination's preview before posting. ## Prompt 2: A before-and-after that is a fair comparison Before-and-after images are easy to oversell. The new design gets a tighter crop, larger scale, cleaner sample data, and a flattering background. Then we attribute the difference to the redesign. Lock the comparison first. ```text Build a before-and-after image using the two attached screenshots. Keep both screenshots as unchanged image assets. Use the same crop boundaries, displayed scale, background, padding, and annotation style for both. Label them Before and After. Preserve the dates/version labels I provide: [BEFORE], [AFTER]. Highlight only this change: [OBSERVED CHANGE]. Use one short annotation per side. Do not invent performance results or label the new version a winner. If dimensions differ, align the shared content and disclose any unmatched crop. Do not stretch either image to force alignment. Preview the pair at 600px wide. If either side becomes unreadable, make a two-image sequence with matching framing instead. ``` This is especially useful for growth work. A screenshot can show that a team changed its paywall. It cannot tell you whether the change improved conversion. Keep that sentence out unless you have the experiment results. ## Prompt 3: A three-frame product story Use a sequence when the feature only makes sense after an action. Three readable screenshots can do more work than one full-page capture shrunk into a square. ```text Create a three-image sequence from the attached screenshots. Use the originals as fixed assets; do not regenerate the product UI. Frame 1 explains the user's starting problem: [PROBLEM]. Frame 2 shows the action: [ACTION]. Frame 3 shows the observed result: [RESULT]. Use matching canvas dimensions, typography and margins. Keep the relevant UI at a comparable visible scale across the sequence. Use only the headline/caption text I supplied. Number the frames. For each frame, identify the exact UI region that supports its caption. Flag any caption the screenshot does not support. Preview every image at 360px wide. Increase the focus of the crop before increasing decoration. Provide editable source and PNGs. ``` Do not use a success state from a different workflow to finish the story. If the product requires an approval, review, or extra step, the sequence should show or explain it. ## Prompt 4: An annotated technical screenshot For a bug report, documentation, or a developer audience, I would spend the visual budget on the explanation. ```text Create a documentation image from the attached screenshot. Preserve the original pixels. Add no decorative device frame. Add numbered callouts for these exact observations: [LIST]. Keep annotations outside important UI. Use a consistent label style and connecting lines that clearly identify their targets. The screenshot must remain understandable in grayscale. Do not rely on red/green alone or use color as the only status signal. Write a short text equivalent that explains the action or issue without requiring someone to read text embedded in the image. Separate what is visible from what I infer caused it. Deliver the annotated image plus an unannotated original. ``` For accessibility, the useful text equivalent describes the information the image adds. It should not be a decorative caption that says “screenshot of the app.” W3C's [informative-images guidance](https://www.w3.org/WAI/tutorials/images/informative/) makes the alternative depend on the image's purpose and surrounding context. ## The review pass before sharing First, compare the composition with the original. Check prices, counts, selected states, product names, and labels. If the composition tool has changed them, go back to an unchanged image layer. Second, look at the image at the width at which someone will actually encounter it. Can you read the one thing the post is about without opening the full-size image? If not, crop, split, or rewrite the post around something visible. Third, check the original for private information before you send it to an external tool: names, account details, browser tabs, messages, tokens, and notifications. Cropping after upload does not undo that upload. Finally, post the text explanation alongside the image. The screenshot should make your point easier to understand, not become the only place the point exists. ## Disclosure Ali owns LazyScreenshots. That creates a conflict when he writes about LazyScreenshots or reviews competitors, so relevant pieces say so plainly. These articles are research and opinion, not independent third-party ratings.