Repair or recapture product screenshots?

Repair a screenshot when the interface is still accurate and one short piece of text is stale. Recapture it when the product state, layout, or user path has changed.

Documentation screenshots age quickly. A button gets renamed, a plan label changes, or one line of helper text is corrected. Recreating the exact account, permissions, data, and product state can take longer than the copy change itself. A focused repair is reasonable when it keeps a truthful screenshot current. It is the wrong choice when it hides a real interface change.

A 30-second decision rule

Ask these questions before editing:

1. Would a reader still find every visible control in the same place?
2. Is the change limited to text, not product behavior or account state?
3. Can a reviewer compare the repaired image with the current product and call it accurate?
4. Do you own the screenshot or have permission to update it?

If any answer is no, recapture.

Example 1: one label changed, so repair it

A help-center article shows a project screen that is still current. The product team renamed the button from Create draft to Create project, but the surrounding screen and action are unchanged. Repairing the button label keeps the article accurate without rebuilding a seeded demo account.

This is a good repair because the edit changes no product meaning. Keep the selection tight, match the original label length where possible, and inspect the baseline, spacing, and nearby icon after generation.

Example 2: navigation moved, so recapture it

A release reorganized the product from a left sidebar to a top navigation bar. Changing Reports to Insights inside the old screenshot would leave the reader with a false map of the interface. The correct maintenance choice is a fresh capture of the current product state.

Recapture when the relationship between elements changed. Text repair cannot make an old layout truthful, even when it can make individual words look current.

What usually makes a safe repair

• A short button or menu label changed but still performs the same action.
• A help-center screenshot contains a typo in owned product copy.
• A date, price, plan name, or demo label is stale while the surrounding state remains accurate.
• The exact product state is expensive to reproduce, and the repair does not conceal that state.

For these cases, use a focused screenshot text editor. Edit one region at a time and keep the original capture beside the result during review.

What should trigger a fresh capture

• The navigation, information hierarchy, or visual structure changed.
• A control moved, disappeared, or now behaves differently.
• The screenshot shows an obsolete permission, warning, modal, or account state.
• The correction would require rebuilding several regions across the image.
• The screenshot is blurred, compressed, or too small to verify confidently.

A maintenance workflow that stays honest

1. Keep the source. Preserve the original screenshot and note the product version or capture date.
2. Name the reason. Record whether the update is a copy repair or a full product recapture.
3. Change the smallest region. Avoid touching icons, avatars, controls, and surrounding interface details.
4. Review against the live product. Confirm that every visible element still represents the current interface.
5. Check the article context. Alt text, captions, step numbers, and written instructions may need the same update.

Do not use repair to change evidence

Screenshot repair is for owned documentation, product demos, help centers, and marketing assets. Do not alter private messages, transactions, account records, grades, legal material, or screenshots presented as evidence. When a screenshot records what happened rather than explains how a product works, preserve the original.