27 min read ·
How to Turn Product Screens Into a Clear Five-Slide Launch Story
Use a matched-state protocol: the same input, task, scope, plan, billing period, date, version, environment, and outcome definition.
A Product Hunt screenshot gallery should do more than prove that an interface exists. In a few quick frames, it should explain what the product promises, how it works, why the outcome matters, and what the viewer can do next.
That requires editing. A raw dashboard capture may be accurate, but accuracy alone does not create clarity. A useful launch slide preserves the real product while adding hierarchy: a concise benefit, an intentional crop, one focal point, and enough context to make the evidence credible.
The goal is not exhaustive documentation. It is a coherent visual argument built around the smallest product moment that demonstrates your main benefit.
What a Product Hunt screenshot gallery needs to accomplish
Think of the gallery as a short visual explanation, not a folder of unrelated interface captures. Screenhance, a commercial launch-asset vendor, proposes a coordinated promise-to-action sequence rather than disconnected screenshots. That is practitioner guidance, not an official Product Hunt rule or independent performance study (Screenhance’s gallery guidance).
A useful gallery performs three jobs:
- Establish the promise. Tell the viewer which problem the product addresses or which outcome it helps produce.
- Make the product credible. Show recognizable, readable interface evidence instead of relying exclusively on slogans, logos, or illustrations.
- Demonstrate the path to an outcome. Connect a product action to a visible result so the viewer understands what using the product involves.
These jobs can be distributed across several slides. One image does not need to explain the entire company.
A raw screenshot records the interface as it appeared on screen. A designed launch slide uses that screenshot as evidence and adds communication structure:
- a concise benefit headline;
- an intentional crop;
- an enlarged action or output;
- restrained highlighting or annotation;
- enough navigation, labeling, or surrounding UI to establish context;
- consistent treatment across the gallery.
The designed version should clarify the interface, not reconstruct it into something the product cannot do. Avoid composite states that imply users can see features, results, or data together when they cannot. If you combine screens to explain a workflow, make the sequence explicit.
Feature completeness is usually the wrong objective. Giving equal space to permissions, integrations, themes, account settings, filters, exports, and administrative controls can make the primary use case harder to find. One understandable workflow is generally more useful than ten isolated capabilities.
Use progressive disclosure to manage complexity:
- Start with the promise.
- Add visible product evidence.
- Show how the core workflow progresses.
- Introduce detailed proof or differentiation after the product is understood.
- End with an appropriate action or resolved outcome.
It remains flexible: a technical product may need to establish product credibility immediately, while a visually transformative product may lead with a before-and-after result.
They are recurring communication practices to adapt and test, not rules for manipulating launch performance.
A five-slide Product Hunt gallery storyboard
A five-slide structure gives every image a distinct role while remaining compact enough to edit rigorously. It is a useful planning default, not a universal optimum.
Slide 1 — Promise
Pair one concise user benefit with a recognizable product view and one obvious focal point.
The viewer should be able to answer:
- What does this product help me accomplish?
- Which part of the interface appears to deliver that result?
Avoid a decorative logo-only image unless the brand provides essential context. Also avoid shrinking a complete dashboard until every label becomes unreadable. If the main value happens in one editor, terminal panel, mobile screen, comparison table, or generated output, make that element dominant.
Possible formulas include:
- “Resolve production errors without leaving your trace”
- “Turn customer calls into assigned follow-ups”
- “Compare every proposal in one workspace”
- “Ship localized listings from one editor”
Slide 2 — Product proof
Enlarge the interface action or output that makes the first-slide promise believable.
If the promise is “Find the source of an API failure,” show a readable trace and the highlighted failure point. If the promise is “Summarize research interviews,” show the source material, the product action, and enough of the generated structure to make their relationship clear.
Use a short annotation only when the viewer might otherwise miss the evidence. “Suggested owner” may help beside an assigned task. Three arrows, five callout bubbles, and several paragraphs of explanation usually indicate that the crop or headline needs more work.
Slide 3 — Workflow
Connect one or two screens to show the primary task from input to action to result. Number the sequence when the relationship is not obvious.
A workflow slide might show:
- Import the source.
- Review the proposed change.
- Publish or export the result.
Omit secondary settings and edge cases. The slide should explain the main route through the product, not replace documentation.
Slide 4 — Difference or outcome
Explain why the workflow matters. Suitable evidence might include:
- a fair before-and-after comparison;
- a visible output;
- a documented workflow reduction;
- a supported metric;
- an attributable testimonial;
- a dated pricing or capability comparison;
- a product capability demonstrated in the UI.
This slide carries the greatest claim risk. A comparison can look persuasive even when its inputs, plans, environments, or definitions are mismatched. Use neutral labels and retain the records behind every claim.
Slide 5 — Action
Summarize the achieved outcome and give the viewer one appropriate next step:
- Try the product.
- Watch the full demonstration.
- Explore a specific use case.
- Run the workflow on your own data.
- Read the technical documentation.
- Join the beta.
The final slide should resolve the story already told, not introduce a large new feature category.
Here is an original hypothetical SaaS storyboard:
| Slide | Headline | Visual evidence |
|---|---|---|
| 1 | Finish reports in minutes | Recognizable report editor with the finalization panel enlarged |
| 2 | Turn source notes into a structured draft | Highlighted “Build draft” action and a readable generated section |
| 3 | Import, review, publish | Three numbered states showing the primary workflow |
| 4 | The same report, without the manual handoffs | Matched old-process and new-process paths with identical start and end points |
| 5 | Try it with your next report | Completed report, product name, and one next step |
A simple slide-level wireframe makes the hierarchy concrete:
┌──────────────────────────────────────────────────────────┐
│ FINISH REPORTS IN MINUTES │
│ Turn source notes into a reviewable draft. │
│ │
│ ┌────────────────────────────────────────────────────┐ │
│ │ Report editor │ │
│ │ │ │
│ │ Source notes Draft section │ │
│ │ • Interview A [Readable generated content] │ │
│ │ • Interview B │ │
│ │ ┌──────────────────────┐ │ │
│ │ │ BUILD DRAFT │ ← focus │ │
│ │ └──────────────────────┘ │ │
│ └────────────────────────────────────────────────────┘ │
└──────────────────────────────────────────────────────────┘
At minimized size, the headline, editor, and highlighted action should remain identifiable even if supporting copy becomes secondary.
Do not replace “minutes” or “without the manual handoffs” with a precise savings claim unless you have documented the method and result. Without a measurement, use bounded language such as “Move from notes to a reviewable draft in one workspace.”
Alternative sequences are valid. Product proof can precede a broad promise when technical credibility is the primary barrier. Proof can come before differentiation, and a final call to action can be omitted when the listing already makes the next step obvious. One firsthand founder account recommends approximately four or five “benefit and hint” slides, but that reflects Stackfix’s reported practice rather than evidence that a particular count or order is universally optimal (Tom Dekan’s Stackfix launch account).
Five comparative screenshot layouts and when to use each one
Comparative screenshots work when they remove ambiguity. They fail when they compare unlike states, conceal important context, or use the visual authority of a table to imply unsupported superiority.
Before designing any comparison, define a matched-state protocol:
- same input;
- same user task and scope;
- same plan or tier;
- same billing period where pricing is involved;
- same comparison date or documented product version;
- same device, browser, model, or operating environment where relevant;
- same definition of a successful outcome.
If a variable differs, disclose it or reconsider the comparison.
1. Before versus after
Use this layout when the product creates a visible transformation: an edited image, cleaned dataset, reformatted document, repaired layout, organized schedule, or summarized record.
Keep the two sides equivalent:
- Use the same source material.
- Display it at the same scale.
- Preserve comparable context.
- Label both states clearly.
- Do not make the “before” intentionally ugly with weaker zoom, color, or typography.
Copy formula:
From [documented old state] to [documented new state]
Example:
From an unstructured interview transcript to a reviewable research brief
If quality is subjective, name the evaluation criterion rather than declaring the output “better.”
┌──────────────────────┬──────────────────────┐
│ BEFORE │ AFTER │
│ Same source and zoom │ Same source and zoom │
│ │ │
│ Unstructured record │ Reviewable brief │
│ [visible evidence] │ [visible evidence] │
└──────────────────────┴──────────────────────┘
2. Old workflow versus new workflow
Use this layout when the primary value is reduced effort, fewer handoffs, or a consolidated process.
Show the same start and end points on both sides. Number each route so the viewer can compare paths instead of inferring them from a decorative diagram.
Copy formulas:
[Same task], fewer steps
From [documented old process] to [documented new process]
Only display exact step counts or elapsed time when they come from a documented method. Define what constitutes a step, whether waiting time is included, who performed the task, and what completion means.
OLD WORKFLOW NEW WORKFLOW
Same input Same input
↓ ↓
1. Export data 1. Import source
2. Send file ↓
3. Review in another tool 2. Review result
4. Return comments ↓
5. Re-enter changes Same completed output
↓
Same completed output
The visual structure can communicate consolidation without asserting an unsupported percentage or time saving.
3. Input versus output
This format suits AI products and other transformation tools. Show enough of the source to establish what the product received, then place the generated or transformed result beside it.
Copy formula:
[Input] in, [specific output] out
Example:
Meeting transcript in, assigned action list out
The SyncUp pattern—a messy transcript beside a generated summary—is useful as a hypothetical layout. It is not evidence of a real launch result or objectively superior output; the underlying lesson presents it as an educational example (Grasp’s launch-asset lesson).
Preserve source-output traceability where possible. For example, highlight the sentence that produced an assigned task or show the citation connected to a generated answer.
4. Product versus alternative
Use a direct alternative comparison only when you can match and source the relevant conditions.
Record:
- the alternative’s product version;
- the date checked;
- the plan tested;
- the input and task;
- the operating environment;
- the evaluation criteria;
- the result;
- any material limitation in the test.
Prefer labels such as “Workflow in Product A” and “Workflow in Product B” to “the only serious option” or “dramatically faster.” If you cannot reproduce a claim, leave it out.
Copy formula:
[Capability] without [verifiable constraint]
For example, “Repository-level search without a local index” is defensible only if both the capability and constraint accurately describe the tested products under the stated conditions.
5. Pricing or feature comparison
Tables create an impression of precision, so their definitions must be precise.
Normalize:
- monthly versus annual billing;
- taxes and regional differences;
- included usage;
- overage charges;
- trial terms;
- plan tiers;
- feature definitions;
- seat minimums;
- comparison date.
Do not mark an alternative as lacking a feature when it exists under another name, in another tier, or through an included integration. Add a compact “Checked on [date]” note and retain the source record behind each cell.
A third-party Waitlister checklist names before-and-after workflows and pricing comparisons as possible gallery assets, but it does not establish that either format improves launch performance (Waitlister’s comparative asset suggestions).
Stackfix provides a more concrete firsthand example. Its launch author describes a slide headed “compare live prices” supported by a cropped fragment of the product’s pricing-comparison table. That is a useful benefit-and-evidence pairing: the headline states the value while the crop shows where it occurs. The account does not establish that this slide caused the reported launch result.
Apply the same discipline when comparing your product with an earlier internal process. “Manual” is not automatically a fair baseline. Document who completed the old process, which tools they used, and whether the new workflow produces the same finished outcome.
From raw dashboard capture to readable launch slide
The transformation from screenshot to launch slide begins with one question:
What is the smallest visible action or output that proves this headline?
Suppose a raw analytics dashboard contains global navigation, filters, a chart, a table, alerts, billing status, profile controls, and several cards. If the slide promises “Find the accounts at risk,” the evidence may be one risk table and its explanation panel—not the entire dashboard.
1. Capture a trustworthy product state
Prepare the product before capturing it:
- use realistic but privacy-safe content;
- close irrelevant menus;
- remove debugging overlays;
- select the state that demonstrates the intended action;
- make sure dates, totals, and labels agree;
- capture at sufficient resolution for later cropping.
Do not fabricate performance data merely to make the screen look populated.
2. Identify the aha moment
Mark the control, state change, result, or output that gives the viewer a reason to believe the benefit. It might be a generated answer with citations, a resolved trace, a synchronized mobile state, or a price cell updated from a documented source.
3. Crop around the evidence
Remove unused browser chrome, empty margins, irrelevant navigation, and unrelated panels. Preserve recognizable labels or surrounding structure when they establish where the viewer is and what happened.
Cropping involves a real tradeoff:
- Too little crop: the interface becomes illegible at gallery size.
- Too much crop: the image can resemble a generic mockup, conceal qualifications, or make a comparison misleading.
The right crop lets the viewer identify the product state while reading the decisive evidence.
4. Enlarge the interface
Make the product larger than the device frame, gradient, shadow, or decorative background. Presentation should support the evidence rather than compete with it.
A phone or browser frame is useful when platform context matters. It can clarify that a task happens in a browser extension, mobile app, desktop application, or responsive web product. Remove the frame when it consumes space without changing the viewer’s understanding.
5. Add one benefit headline
Do not narrate every visible control. Write the result the crop supports:
- Weak: “Analytics dashboard”
- Better: “See which accounts need attention”
- Weak: “AI assistant feature”
- Better: “Trace every answer to its source”
- Weak: “Settings and integrations”
- Better: “Connect the tools already in your workflow”
6. Add one restrained highlight
A box, arrow, mask, underline, or numbered marker can direct attention. Use the smallest intervention that works. Do not cover the evidence, and do not assign different colors to several concepts unless the labels remain understandable without color.
7. Inspect at thumbnail size
Zoom out until the slide approximates a minimized display, then check it on a phone.
Ask:
- Is the benefit readable?
- Is the focal point obvious?
- Can I identify the product category or state?
- Are critical labels still legible?
- Does the slide work without tiny body copy?
An original raw-to-designed walkthrough might look like this:
RAW CAPTURE
┌────────────────────────────────────────────────────────────┐
│ Browser tabs, address bar, global navigation │
├──────────┬──────────────────────┬───────────────────────────┤
│ Billing │ Charts and filters │ Alerts and profile │
│ Settings │ │ │
│ Export │ Risk table │ Explanation panel │
└──────────┴──────────────────────┴───────────────────────────┘
SELECTED EVIDENCE
┌──────────────────────────┬───────────────────────────┐
│ Risk table │ Explanation panel │
│ Account Risk │ Why this account is at │
│ Northstar High │ risk and suggested action │
└──────────────────────────┴───────────────────────────┘
DESIGNED SLIDE
┌────────────────────────────────────────────────────────────┐
│ SEE WHICH ACCOUNTS NEED ATTENTION │
│ │
│ ┌────────────────────────────────────────────────────┐ │
│ │ Account Risk Suggested action │ │
│ │ Northstar HIGH Contact owner │◀──│
│ └────────────────────────────────────────────────────┘ │
│ one restrained highlight │
└────────────────────────────────────────────────────────────┘
Maintain one visual system across the gallery: consistent typography, colors, backgrounds, corner treatment, product naming, annotation style, and terminology. BrandBird’s catalog illustrates formats such as annotated interfaces, highlighted elements, phone screens, desktop-and-mobile compositions, and two-screen layouts, but those template categories do not establish that one treatment performs better (BrandBird’s Product Hunt graphics formats).
Include accessibility in the production review:
- use sufficient contrast for text and essential controls;
- caption narrated media;
- do not communicate status through color alone;
- keep type readable at small sizes;
- avoid rapid, repetitive, or unnecessary motion;
- leave enough time to read each state.
These are practical production checks, not claims about official Product Hunt accessibility thresholds.
Category-specific screenshot and comparison examples
The five-slide logic can work across categories, but the required evidence changes. Generated output, command-line results, mobile sequences, synchronized states, and marketplace completions each need different framing.
AI workflow
Show the source problem, the product action, the generated output, and the relationship between input and result. Do not present subjective quality as objective fact without evaluation criteria.
| Slide | Sample headline | UI evidence | Comparison |
|---|---|---|---|
| 1 | Turn support calls into a searchable knowledge base | Call-import screen with one source selected | Promise |
| 2 | Extract answers with source context | Generated answer and linked transcript passage | Product proof |
| 3 | Import, review, publish | Three connected states | Workflow |
| 4 | Transcript in, approved article out | Same call beside the reviewed article | Input versus output |
| 5 | Build your first article from a real call | Finished article and next action | Outcome/action |
If output quality matters, define criteria such as factual consistency, required-field completion, reviewer acceptance, or successful execution. “Best summary” is not meaningful without an evaluation method.
Developer tool
Begin with the developer problem. Show a readable command, code fragment, trace, configuration change, or query, followed by the resulting output. Do not shrink an entire IDE or observability dashboard into a small slide.
| Slide | Sample headline | UI evidence | Comparison |
|---|---|---|---|
| 1 | Find the request that broke production | Readable trace with one failed span | Promise |
| 2 | Jump from exception to source | Selected stack frame and repository link | Product proof |
| 3 | Trace, inspect, resolve | Three numbered panels | Workflow |
| 4 | The same incident with fewer tool switches | Matched old and new investigation paths | Old workflow versus new |
| 5 | Inspect your next failed request | Resolved trace and documentation link | Action |
Use monospaced text at a size that survives minimized display. Retain the filename, command prompt, service name, or panel title needed for credibility.
Mobile app
Two or three connected phone screens can explain setup, core action, and result. Add arrows or numbering only when the sequence is not self-evident.
| Slide | Sample headline | UI evidence | Comparison |
|---|---|---|---|
| 1 | Plan dinner from what you already have | Pantry scan result | Promise |
| 2 | Add ingredients in one scan | Camera state and recognized items | Product proof |
| 3 | Scan, choose, cook | Three phone screens | Workflow |
| 4 | Your pantry in, matched recipes out | Ingredient list beside recipe results | Input versus output |
| 5 | Plan tonight’s meal | Selected recipe and next action | Action |
Phone frames clarify platform context, but oversized hardware mockups can leave too little room for the interface. Let the screen content dominate.
Browser or SaaS product
Enlarge one meaningful panel or table while preserving enough browser or navigation context to identify the product state.
| Slide | Sample headline | UI evidence | Comparison |
|---|---|---|---|
| 1 | Review every renewal from one queue | Enlarged renewal table | Promise |
| 2 | See owner, risk, and next action together | Selected row and detail panel | Product proof |
| 3 | Prioritize, assign, follow up | Connected queue states | Workflow |
| 4 | The same renewal process without spreadsheet handoffs | Matched process paths | Old versus new |
| 5 | Review your next renewal cycle | Completed queue and CTA | Action |
Cross-device service
Pair desktop and mobile screens only when synchronization, handoff, or responsive use is an actual benefit. A laptop and phone placed together for decoration do not explain anything.
| Slide | Sample headline | UI evidence | Comparison |
|---|---|---|---|
| 1 | Start at your desk, approve on the move | Desktop draft and mobile approval | Promise |
| 2 | Changes stay synchronized | Same item and status on both devices | Product proof |
| 3 | Draft, notify, approve | Numbered cross-device sequence | Workflow |
| 4 | One task, continuous context | Matched desktop-to-mobile handoff | Handoff comparison |
| 5 | Continue from any approved device | Completed state | Action |
Marketplace
Show one user task through discovery, comparison, and completion. When contrasting listings, use matched categories, dates, locations, availability, and selection criteria.
| Slide | Sample headline | UI evidence | Comparison |
|---|---|---|---|
| 1 | Find the right specialist for this project | Search results with relevant filters | Promise |
| 2 | Compare experience on the same criteria | Matched listing cards | Product proof |
| 3 | Discover, compare, book | Three connected marketplace states | Workflow |
| 4 | Shortlist options without rebuilding the brief | Same brief applied across listings | Old versus new workflow |
| 5 | Create your first project brief | Completion screen | Action |
Template sources name browser, phone, multi-device, annotation, split-gallery, and multi-screen compositions. Those labels are useful for exploring layouts, but the available evidence does not establish that any specific template produces better launch results.
Static screenshots, GIFs, clips, or a hosted demo?
Choose the simplest medium that fully explains the claim.
Use a static slide for:
- a benefit understandable in one frame;
- a readable interface detail;
- a feature or capability;
- a before-and-after comparison;
- a documented metric or testimonial;
- an outcome that does not depend on timing.
Use motion or video when comprehension depends on:
- timing;
- a state change;
- drag-and-drop behavior;
- generation or processing;
- live collaboration;
- a multi-step interaction;
- a handoff between tools or devices.
Use this decision tree:
- Can one frame prove the claim? Use a static slide.
- Are two states sufficient? Use a comparison.
- Is sequence essential? Consider a short clip.
- Are narration and context essential? Consider a hosted demo.
- Does user-led exploration matter? Offer an interactive walkthrough outside or alongside the listing where currently supported.
Motion is not inherently better. Poindeo, a commercial demo-tool vendor, recommends animated thumbnails and captioned feature GIFs, while the Stackfix founder account recommends skipping GIFs because the author considered the production effort unjustified. Neither source supplies comparative evidence that its preferred format universally performs better (Poindeo’s motion-oriented recommendations).
Use the same focused structure for a demo:
- Problem: establish the user’s situation.
- Action: perform one representative task.
- Result: reveal the product outcome.
- Next step: tell the viewer what to do.
For example:
- “A customer reports a failed payment, but the relevant event is spread across three systems.”
- Open the product and search for the customer.
- Select the failed event and reveal the linked cause.
- Close with “Inspect your own event history.”
An authentic founder walkthrough and a polished animated demonstration are production styles, not proven performance tiers. A founder recording can communicate immediacy and technical context. Animation can remove distracting pauses and explain otherwise invisible processes. Choose according to the product, audience, editing capacity, and need for explanation.
Duration recommendations vary substantially. Product Hunt-oriented third-party sources recommend demos as short as approximately 20 seconds or as long as one or two minutes, while broader B2B demo guidance allows two to five minutes for engaged evaluators (Motion’s demo-format guidance). These are practitioner ranges, not official Product Hunt requirements.
Do not force a complex developer workflow into an arbitrary short duration. Conversely, do not make viewers watch several minutes to discover a benefit that one screenshot could communicate.
One clean screen recording can become:
- still crops for the gallery;
- a short product demonstration;
- captioned social clips;
- a founder walkthrough;
- onboarding material;
- help-center documentation.
Capture slowly, keep the pointer controlled, use a stable product state, and leave clean pauses around important actions. Add captions to narrated material, review every motion asset without sound, and ensure each state remains visible long enough to understand.
What real and illustrative examples can—and cannot—teach you
Examples are useful for studying choices. They are weak evidence of causation.
Stackfix
The strongest firsthand example in the available material is Stackfix. Its author reports using approximately four or five benefit-and-hint slides, with each slide naming a user benefit and pairing it with a relevant interface fragment or mockup. The “compare live prices” slide uses part of a pricing-comparison table as its visual hint.
The same author reports that Stackfix’s December 2024 launch received more than 1,200 upvotes and several Product Hunt distinctions. These are self-reported results, not controlled evidence that the gallery produced them (Tom Dekan’s Stackfix account). Product quality, audience, promotion, timing, launch execution, and community engagement prevent causal attribution.
The author also points to Fathom, Amie, Remento, and Wordware as references. The extracted evidence does not support a dependable slide-by-slide evaluation of those galleries, so they should be inspected directly rather than summarized from incomplete descriptions.
SyncUp
The transcript-versus-summary SyncUp layout is an educational hypothetical. Its value is structural: the source appears on one side, the generated output on the other, and visual emphasis is placed on the result. It should not be treated as a documented launch case study or proof that the illustrated product achieved a particular outcome.
Screenhance and Launch Shots
The Product Hunt listings for Screenhance and Launch Shots contain gallery-image links. However, their extracted descriptions are generic, so the evidence does not support rigorous analysis of slide order, copy, cropping, or comparison treatments.
Screenhance’s listing describes static visual and short clip capabilities, but these are listing or maker claims rather than comparative launch findings (Screenhance’s Product Hunt listing). Launch Shots likewise displays gallery assets, but the available text does not describe their composition in enough detail to establish a reusable visual pattern (Launch Shots’ Product Hunt listing).
When inspecting examples directly, use a consistent rubric:
| Criterion | What to examine |
|---|---|
| Hook | Can you identify the intended user benefit quickly? |
| Message hierarchy | Is there one dominant idea or several competing messages? |
| UI legibility | Can critical labels and outputs be read at minimized size? |
| Claim support | Does the visible evidence substantiate the headline? |
| Comparison fairness | Are inputs, plans, dates, environments, and outcomes matched? |
| Narrative continuity | Does each slide logically follow the previous one? |
| Proof | Is the result visible, documented, attributable, or reproducible? |
| Final action | Is the next step clear and appropriate? |
Do not use upvotes, awards, rankings, comments, follower counts, or supportive reactions as proof that a screenshot treatment increased conversion. Those outcomes combine too many uncontrolled variables.
Prelaunch production, claim, and readability checklist
Run one final review in which every asset is examined as part of the same launch story.
Narrative
- [ ] Every asset has one distinct role.
- [ ] The sequence can be summarized as promise, evidence, workflow, outcome or difference, and action.
- [ ] The primary use case appears before secondary features.
- [ ] No slide repeats another without adding useful context.
- [ ] The gallery, demo, maker comment, and landing page describe the same core benefit.
Claims
- [ ] Every metric has a traceable source, method, and date.
- [ ] Every price includes the relevant plan, billing period, usage assumptions, region, and comparison date.
- [ ] Every capability claim reflects the current product.
- [ ] Every testimonial is attributable and approved for use.
- [ ] Every competitor statement is reproducible.
- [ ] Subjective output quality is labeled as such or tied to explicit evaluation criteria.
Comparisons
- [ ] Inputs are matched.
- [ ] Task scope is identical.
- [ ] Plans and billing periods are normalized.
- [ ] Versions and dates are recorded.
- [ ] Devices, browsers, models, and environments are comparable.
- [ ] Both sides use the same presentation scale.
- [ ] “Completion” or “success” means the same thing on both sides.
- [ ] Material differences are disclosed.
Readability and accessibility
- [ ] Every slide has been inspected at minimized gallery size.
- [ ] Every slide has been checked on a mobile screen.
- [ ] The benefit remains readable.
- [ ] The focal point remains obvious.
- [ ] Critical UI labels remain legible.
- [ ] Annotations do not cover the evidence.
- [ ] Meaning does not depend on color alone.
- [ ] Narrated or dialogue-dependent media includes captions.
Design consistency
- [ ] Colors, typography, backgrounds, shadows, and framing are consistent.
- [ ] Product terminology and capitalization do not change.
- [ ] Arrows, boxes, and step markers follow one annotation system.
- [ ] Thumbnail, gallery, demo, maker comment, and landing page reinforce the same positioning.
Privacy
- [ ] Customer names and personal information have been removed or approved.
- [ ] Credentials, API keys, internal URLs, and account identifiers are absent.
- [ ] Proprietary customer data has been replaced safely.
- [ ] Redactions do not conceal information needed to assess a comparison.
- [ ] Sample data is not presented as real performance evidence.
Demo
- [ ] The opening establishes the user problem.
- [ ] One representative action is completed.
- [ ] The result remains on screen long enough to understand.
- [ ] Narrated material has captions.
- [ ] Audio is intelligible but optional for comprehension.
- [ ] Pointer movement and pacing are controlled.
- [ ] The recorded product state matches the current release.
- [ ] The final action is clear.
- [ ] Every external link works.
Export and platform requirements
- [ ] Current image dimensions have been verified.
- [ ] Accepted formats and file-size limits have been verified.
- [ ] Current gallery limits have been checked.
- [ ] Thumbnail behavior has been previewed.
- [ ] Current video-hosting rules have been confirmed.
- [ ] Uploaded assets have been inspected in the actual listing preview.
Several third-party sources recommend 1270×760-pixel gallery images, but the supplied evidence does not reproduce current official Product Hunt requirements. BrandBird, for example, recommends that size on its commercial Product Hunt graphics page. Verify current specifications directly with Product Hunt before producing final exports.
Asset-count recommendations also conflict. One third-party guide specifies three to five gallery images in one section and five to ten elsewhere, illustrating why these quantities should not be treated as platform rules (Smol Launch’s conflicting gallery-count guidance). Use only the assets needed to tell the story, then confirm the current platform limits.
As a lightweight comprehension review, show the minimized gallery to several people unfamiliar with the product. Ask them to state:
- who the product is for;
- what outcome it promises;
- which interface moment supports that promise;
- what happens in the primary workflow;
- what they would do next.
Do not coach them while they answer. Their confusion can reveal weak hierarchy, unexplained terminology, or missing context. This is a practical prelaunch heuristic, not a Product Hunt requirement or validated conversion test.
What size should Product Hunt launch screenshots be?
Several third-party template and launch guides recommend 1270×760 pixels, including Screenhance and BrandBird, but the available evidence does not establish that as Product Hunt’s current official requirement. Verify the current dimensions, aspect ratio, accepted formats, and file-size limits directly with Product Hunt before exporting.
Design at sufficient source resolution to support cropping, then test the uploaded result at minimized and mobile sizes. A technically valid image can still fail if its headline, interface labels, or focal point become unreadable.
How many screenshots should a Product Hunt gallery include?
Use the fewest assets needed to communicate a complete story. For many products, five roles provide a useful planning structure: promise, product evidence, workflow, outcome or difference, and action.
Third-party recommendations in the supplied material range from approximately three to ten assets, and no evidence establishes one count as optimal. Remove slides that repeat the same benefit, and add a slide only when it answers an important question the existing sequence does not.
Are static screenshots, GIFs, or demo videos better for a Product Hunt launch?
Static screenshots are usually the simplest choice for benefits, interface details, comparisons, proof, and outcomes that can be understood in one frame. Use a two-state comparison when that is sufficient to communicate the change.
Consider a GIF or short clip when timing, state change, generation, collaboration, or interaction is essential. Use a hosted demo when narration or broader context is necessary. Practitioners disagree about whether GIFs justify the work, and the supplied evidence does not establish that motion universally outperforms static media.
How can I make a Product Hunt competitor comparison fair and credible?
Use a matched-state protocol: the same input, task, scope, plan, billing period, date, version, environment, and outcome definition.
Document the sources behind prices and capabilities. Use neutral labels, disclose meaningful differences, and avoid superiority claims that cannot be reproduced. If the products solve materially different problems or reach different outcomes, use separate workflow demonstrations instead of forcing them into one comparison table.
What should appear in the first Product Hunt gallery image?
Lead with one concise user benefit, a recognizable product view, and one clear focal point. The image should help the viewer understand both what the product offers and where that value appears in the interface.
Avoid an unreadable full dashboard, a collage of unrelated features, or a decorative logo-only treatment. Crop and enlarge the strongest product evidence while preserving enough navigation, labels, or surrounding structure to keep the state credible.
The operating principle is compact: identify the smallest visible product moment that proves the main benefit, then build a coherent sequence around it. Use comparison only when states can be matched. Use motion only when sequence improves understanding. Verify current Product Hunt specifications directly, substantiate every comparative claim, and inspect every asset at small-screen size.
Publisher note for technical founders: A concise product link or visual explanation can also help an early-stage investor understand what is being built. Lunera says it partners early with technical founders working in areas including developer tools, data infrastructure, applied AI, and foundational business systems, and accepts a short note, deck, or product link without requiring a warm introduction (Lunera’s founder guidance).