SaaS launch graphics, from the Product Hunt gallery to the help center.

The launch graphics list

Not every launch needs every item, but most need more than one size of the same idea. Plan them together so the message and screenshots are the same everywhere.

Product Hunt gallery specs

Product Hunt's help center and launch guide give the media requirements. The thumbnail and gallery are required; video is optional. Product Hunt notes that about 53% of products that reached Product of the Day since 2021 included a video, and that videos help depending on the product but are not always necessary.

In MockupX, set a custom 1270 × 760 canvas for the gallery, or 2540 × 1520 for a sharper file, checking that each export stays under 3 MB (JPEG helps). MockupX canvases start at 320 pixels per side, so build the thumbnail as a 320 × 320 or larger square and let Product Hunt scale it down. Product Hunt discourages strobing effects, quick cuts and unreadable text in GIF thumbnails; MockupX exports still images, which avoids that.

Storyboard the Product Hunt gallery

Product Hunt's own advice is that successful launches tell a story of the product, including what the interface looks and feels like. Treat the gallery as answers to the questions a visitor has, in order. Write the questions first, then assign one real screen to each.

Keep votes, rankings, badges and quotes out of the artwork unless they are real, current and yours to use. A gallery built on screens and claims the team can support ages well; one built on borrowed logos does not.

• Image 1: what it is and who it is for, with the main screen visible (category plus outcome)
• Image 2: the core workflow, one step that shows how it works
• Image 3: the output: the report, the published page, the result
• Image 4: setup or integrations, if they are a reason to choose it
• Image 5: what makes it different, shown, not claimed

Launch and feature announcement posts

A launch post should show what is launching. A decorative “We're live!” card says nothing about the product; a real screen under a specific headline says what changed. For a feature release, show the new capability in a useful state: the new filter next to the filtered results, the new export menu open with the file it produces.

Worked example: a scheduling tool launching team availability. The 1600 × 900 X image shows a Chrome frame with the team calendar, cropped to five rows so names and free slots are readable, under “See when everyone's free.” The 1080 × 1350 version uses the same crop, larger, in a phone frame. The Story version keeps the phone and moves the headline into the top safe area.

• Choose the screen that answers “what can I do now?”
• Use before-and-after only when the difference is visible at a glance, and show both at the same scale with the same data
• Make the product the largest element in the image
• Keep explanation in the post text; the image needs a few words at most

Landing-page product screenshots

Each image on a landing page should answer the question its section raises. The hero establishes the product's category and quality without making people read; feature sections show the specific screen the copy describes; a workflow section can use a short sequence. An image that does not support the text beside it is decoration.

• Hero: the main workspace or result, in a browser or MacBook frame on a 16:9 or 3:2 canvas
• Feature sections: frameless crops of the relevant panel, larger than they would appear in the full app
• Mobile: prepare a tighter crop or a phone-frame version instead of shrinking the desktop image

Release notes and help-center screenshots

Documentation images have a different job: help someone find and use something. Keep enough of the interface to show where the control lives (the panel title, the navigation item) and crop away the rest. Use restrained styling: MockupX's frameless screenshot style with modest padding, a small corner radius and a white or paper background suits docs better than a tilted device on a gradient.

• Capture at a consistent window size so images across articles match
• Use sample data, never a real customer's workspace
• MockupX has no arrow or annotation tool; add highlights in your docs tool, or capture with the relevant menu already open
• Keep an inventory of article, product area, capture date and owner so stale screenshots can be found when the UI changes

Sales deck product slides

A sales slide supports a person talking, so it needs less interface than a demo. Crop each screenshot to the region that supports the talking point and show one strong visual per slide on the 1920 × 1080 HD canvas. Different buyers ask different questions: an executive wants the outcome, an operator the workflow, a technical evaluator the integration. Make crops for each instead of one dashboard slide for everyone.

Label demo data clearly. A placeholder metric or invented company name on a slide can be mistaken for a customer result once the deck is forwarded.

App launches: store assets first

If the launch includes a mobile app, build the store assets first, because Apple and Google set strict sizes and the rest of the launch can reuse their screenshots. MockupX has presets for current App Store iPhone and iPad sizes, Google Play phone and tablet screenshots, and the 1024 × 500 Google Play feature graphic. Use the real UI for each platform; do not show an iPhone screenshot in a Google Play listing or imply a feature exists on both when it does not.

Hand off the launch kit

MockupX exports flattened images, not layered files, so record what is needed to rebuild or update each graphic: the source screenshot, frame, background, layout, canvas size and export format. Name files by launch, content, destination and version, such as team-availability-x-1600x900-v2.png, and keep drafts separate from approved files.

• One folder of approved source screenshots, with capture dates
• A sheet listing each graphic's destination, size, owner and status
• A final check of every export against the shipped product before it is posted