Shipshot guide

What to review before you change an app-store screenshot set

Changing a live screenshot set is easy to do and hard to learn from. If you replace six frames, adjust the captions, and ship a new build in the same week, you will not know what caused whatever happens next. A little discipline before the change is what turns an edit into information.

Record the baseline you are leaving behind

Keep the exact files, captions, and order you are replacing, plus the date the change went live and what else changed around it. Six months later, when someone asks whether the old set performed better, a folder of the previous exports and a one-paragraph note is the difference between an answer and a guess.

  1. Archive the current exports for every target and locale before replacing them.
  2. Write down the change date and anything else shipping in the same window.
  3. Note the metric you expect to move and roughly by how much.

Change one thing you can name

A change you cannot describe in one sentence is a change you cannot evaluate. Replacing the first-frame caption is a test. Redesigning the palette, reordering the frames, and rewriting every caption at once is a relaunch. Both are legitimate, but only the first teaches you anything transferable to the next release.

  1. Write the single sentence describing what is different before you start editing.
  2. Keep every other frame, caption, and target identical to the archived version.
  3. If you cannot keep the rest identical, accept that you are relaunching, not testing.

Avoid the changes that contaminate the window

A price change, a rename, a new icon, a category move, a press mention, or a seasonal spike will all move installs more than a caption edit. If any of those are scheduled, either wait or accept that the result is uninterpretable. Screenshot changes deserve a quiet window.

  1. Check the release calendar for pricing, naming, icon, and marketing activity.
  2. Postpone the screenshot change or the other change so they do not overlap.
  3. Record any external event that lands in the window anyway.

Decide in advance what would make you revert

Write the reversion condition before you ship, while you are still neutral. Afterwards you will be attached to the new work and will find reasons to keep it. Keeping the previous exports editable makes reverting a short task rather than a rebuild, which is the main practical reason to keep a screenshot project rather than only its flattened output.

  1. State the outcome that would cause you to restore the archived set.
  2. Set the date you will look at the result rather than checking daily.
  3. Keep the previous project editable so reverting is minutes of work.

Review checklist

✓ The previous exports and captions are archived with a date.✓ The change is describable in one sentence.✓ No pricing, naming, or icon change shares the window.✓ The metric and the review date are written down in advance.✓ A reversion condition exists and the old set can be restored quickly.

Questions to ask before handoff

Is it worth changing screenshots if I cannot run a formal test?

Yes, but change deliberately and keep records. Most small teams learn from a disciplined sequence of single changes rather than from formal experiments.

How long should I wait before judging a change?

Long enough to cover your normal weekly cycle and any promotion that inflates a few days. Pick the date in advance so you are not reacting to a quiet Tuesday.

Should I change screenshots for every release?

No. Change them when the product changed, the message is wrong, or you have a specific hypothesis. Churn for its own sake removes your ability to attribute anything.

Share this guide