A+ product pages / QUESTION GUIDE
Should an A+ page use generated screenshots for a connected product’s app?
Use actual captures of the supported app version when the page explains controls, menus or software behavior. A generated phone screen can invent features and status messages. Keep the software screenshot as a factual asset and use generated imagery only for the surrounding product context that you can review.
Capture the actual supported workflow
Choose a test account that contains no private customer information. Record the app version, device context and feature shown. Remove personal identifiers using an appropriate external editor, but do not change the meaning of the screen. Keep a record of what was redacted and why.
For an illustrative smart lamp, a brightness slider and schedule menu might belong to different screens. Do not merge them into a fictional single screen just to fit a compact design. A static image should not look like a guaranteed live status for every buyer.
Separate interface and scene layers
| Layer | Source | Approval owner |
|---|---|---|
| App screen | Actual supported version capture | Product/software team |
| Device frame | Authorized actual or approved artwork | Design reviewer |
| Product context | Reviewed merchandise scene | Product owner |
| Explanatory copy | Verified operation steps | Content reviewer |
The app screenshot should remain available in a readable flat view if a perspective mockup makes the controls too small. Do not rely on an oblique phone display as the only explanation of the interface.
Generate around the factual screen
In A+ product pages, create a scene that shows the actual product without asking it to invent the software interface. Place the approved screenshot in a precise external layout workflow. For this handoff, preserve the approved screen as a separate factual source and compare its final placement with the capture; do not treat a generated screen as live app-state evidence.
If a generated scene already contains a screen, compare every visible control with the supported app. Reject invented automation, notification or connection indicators. A persuasive image cannot establish a feature the software does not have.
Maintain a versioned screenshot record
When the app changes, review the affected screenshots and operation copy. Keep the screen version with the final module so a later background edit does not restore an obsolete interface. Check phone readability and provide accessible text explaining the relevant operation.
Use screen-content sources for display evidence and native copy planning for readable instructions. The deliverable is a factual software explanation, not a generated approximation of an app.
Fictional lamp-app record: app2.4 screen S1 shows brightness; S2 shows scheduling. A later app2.5 moves the schedule control. No app was opened or tested for this exercise.
| Candidate change | Evidence decision | Next step |
|---|---|---|
| Remove an account email from authorized S1 | Privacy redaction, if no product meaning changes | Keep clean source and redaction record private |
| Combine S1 slider and S2 menu into one invented screen | Unsupported interface arrangement | Use real separate captures or clear explanatory steps |
| Reuse2.4 capture for2.5 instructions | Version match unresolved | Verify current UI and update affected text/captures |
| Generate an online/connected status | Not evidence of supported behavior or current state | Use an actual approved capture or omit the claim |
Approve the capture’s version and meaning before changing the surrounding scene. Shopify’s Files guidance explains why a public media upload is not a place for a private original. It does not approve a specific screenshot or certify every redaction. Keep the flat factual source readable and recheck its final destination rendering.
Sources and further reading
Recorded source-review dates are listed individually below. An undated source does not inherit the article’s publication date. Software and platform rules can change; check the current original before acting.
- CartVisual: editorial scope and evidence policy · Review date not separately recorded
- Amazon: A+ Content design guide · Reviewed
- Shopify Help: product media · Reviewed
Frequently asked questions
Can I generate a prettier app screen?
Do not present invented controls or states as actual software.
Can a screenshot contain customer information?
Use a clean authorized test context and redact private details.
What if perspective makes the controls unreadable?
Provide a readable flat capture and accurate native explanation beside the scene.
PREPARE ASSETS FOR YOUR NEXT STEP
Create supporting product assets in CartVisual.
Create new product creative assets in the workspace, then continue in your chosen tools. Third-party software procedures described in this guide take place in those applications; this workspace link does not imply an integration. Check current capabilities, account access and credit quotes.
Explore asset creation tools Check pricing and credits