How to keep help center screenshots up to date: a system for support teams

Every release breaks a few screenshots in your help center. A button gets renamed, the sidebar gains an item, and articles that were right last month show a product your customers can’t find. This post covers how to keep help center screenshots up to date without retaking all of them: a system that works with any help center and screenshot tool, when scripted screenshots are the better answer, and where AtriumKit fits. We make AtriumKit, so read that part with that in mind.

Customers do notice. In a Hacker News thread on self-updating screenshots that reached 489 points, one commenter put it bluntly: users “WILL DEFINITELY notice if the screenshots don’t match”. The usual fix is manual. A Zendesk user described theirs on the community forum in 2023: “I go into each Help Center article and update each screenshot.”

How to keep help center screenshots up to date, in short

1. Take an inventory: one row per image, with the screen it shows and when it was captured.
2. Triage by how often each article is read and how likely its screen is to change.
3. Use fewer, tighter screenshots, cropped to the action.
4. Put what changes in text, so a search finds it.
5. Review on every release, starting from the screens that changed.
6. Script the screenshots if your docs live in a code repository, or edit the captured screen when only the words changed.

Why screenshots go stale faster than text

• A screenshot shows more than the step. A picture of one button also shows the navigation, the sample data, the theme and that week’s banner. A change to any of them dates the picture.
• Pictures can’t be searched. A search for a renamed label finds every article that names it in text, and none of the screenshots that show it.
• Retaking is a chain of chores. Sign in, set up the data, capture, crop, blur, upload, replace. Then again for every article that shows the same screen.
• Nobody owns them. Release notes list what changed, not which articles it breaks. Support finds out from a ticket.

Not every change costs the same to fix. There are three kinds:

• Copy changes. A label, menu item or heading reads differently.
• Layout changes. Something moved, appeared or went away; the task is the same.
• Flow changes. The task takes different steps now.

Most teams treat all three the same way: retake. The steps below give each one its cheapest fix.

Step 1: Take an inventory

You can’t keep up with screenshots you haven’t counted. Make a spreadsheet with one row per image:

The Screen column does the work. Release notes and tickets talk about screens, not articles, so one filter on “Team settings” lists every picture a settings change might break.

To fill it quickly, export your articles and list the images in each. No upload dates for images? Use the article’s last edit: the picture is at least that old.

Step 2: Triage by how likely each screen is to change

Ask your product team which screens they expect to change next quarter, and mark each likely to change or stable. Onboarding, settings pages that keep growing, anything under active development and the navigation itself (it’s in every full-page capture) usually change. Sign-in, billing forms and older admin screens are usually stable.

Then put views next to it:

A rarely read article about a screen that changes every month shouldn’t carry six screenshots.

Step 3: Use fewer, tighter screenshots

Every picture is a promise to update it later. Make fewer promises.

• Show only the steps where people need to find something. A control that’s hard to spot, the first step on an unfamiliar screen, or a result they need to recognize. “Click Save” doesn’t need a picture.
• Crop to the action. A crop of one panel survives a sidebar redesign; a full-page capture doesn’t. Leave the navigation out unless finding your way is the point of the step.
• Capture from one demo account. Same sample data, window size, theme and language every time. A retake then matches the pictures around it, and no real customer’s name ends up in your docs.
• Keep out what changes for other reasons. Trial banners, chat widgets, dates and notification counts date a picture and tell the reader nothing.

Step 4: Put the parts that change in text

Text is cheaper to keep current: you can search it and change it in place.

• Write every label in bold, exactly as the product spells it. When Members becomes People, one search finds every article that needs the new word.
• Write paths as text: Settings → Team → Invite. Readers follow the words and the picture confirms them.
• Keep numbers, limits and prices out of pictures. They change most often and cost the most to get wrong.
• Name the screen and its labels in the alt text. “The Team settings page with the Invite button” makes the image findable in an article export, so next year’s inventory is a search. It helps screen reader users too.

Step 5: Review on every release, not on a calendar

With a quarterly screenshot day, a picture can be wrong for three months. Tie the review to the thing that breaks them.

1. Add one line to your release checklist: which screens changed, and which labels were renamed? Whoever ships the change answers it, in your inventory’s screen names.
2. Filter the inventory by those screens. That’s your update list.
3. Fix each item by the kind of change. A renamed label is a text fix plus a picture fix. A moved control is a new crop or a retake. A changed flow means rewriting the article.
4. Batch by screen, not by article. Get each screen into the right state once and take every picture you need from it.
5. Update the Captured column.

Add two backstops for what slips through: a ticket tag such as “article doesn’t match the product”, and a quarterly look at the oldest captures in your most-read articles. Some tools also flag help center screenshots that no longer match the product.

When scripted screenshots are the better answer

If your docs live in a code repository, the screenshots can take themselves. A script drives a browser through your app with a seeded account and saves each picture on every build.

• Camunda described this in 2020. Its Optimize user guide had 94 screenshots, updating it by hand took “a day or two”, and the team reused its end-to-end tests to take the pictures.
• James Adam’s Self-updating screenshots, the post behind that Hacker News thread, puts each picture’s instructions in a comment in the Markdown article and has a headless Chrome take them.
• In Playwright, locator.screenshot() captures one element by selector. The mask and style options of page.screenshot() keep things out of the picture, and toHaveScreenshot() compares a capture with the stored one, so a test run tells you which pictures changed.

Scripts win when your docs are Markdown in a repository, engineers review them, you have hundreds of pictures and you already run browser tests. They also cost something:

• Someone who writes code owns them. Scripts break when selectors change, and the seeded account has to produce the same data on every run.
• Some states stay manual. Camunda still updated its dashboard pictures by hand, because its test tool handled drag and drop poorly.
• Rendering varies. Playwright’s docs warn that browser rendering differs by operating system, settings and hardware, so take screenshots in one fixed environment.
• The words don’t update. The script retakes the renamed button; the paragraph still says the old name. Another commenter in the Hacker News thread pointed out that an old picture at least signals an out-of-date article; a new picture beside old words just confuses readers.

For a hosted help center run by people who don’t write code, scripts are usually more machinery than the problem needs.

How AtriumKit changes the math

A screenshot’s cost is the work to make it, times the number of times you remake it. For articles that walk through a task in a web app, AtriumKit lowers both.

Make it once. Install the Chrome extension, press Start recording and do the task. Every click becomes a step with a screenshot. Publish, and you get an interactive walkthrough to embed in the article and a step-by-step guide with a numbered instruction and a picture per step, the clicked spot highlighted. Crop a screen and the guide’s pictures show only that part. Link to the hosted guide, which follows every publish, or paste it into your help center with Copy → Rich text. A pasted guide is a copy, so paste it again after changes. The interactive help center playbook walks through the setup.

When a label changes, edit it on the captured screen. By default, AtriumKit saves every page you record twice: as a screenshot and as a copy of the page’s HTML without its scripts (HTML capture, on every plan). That’s close to what one Hacker News commenter suggested: “consider not doing screenshots at all and just embedding the html”. So when Members becomes People:

1. In the editor, choose Edit text, click the old label on the captured page and type the new one. It keeps the page’s own fonts.
2. Or click Find & replace… to change it on every HTML screen at once. It lists the matches on each screen first.
3. Find & replace… changes the captured pages, not your step text, so update any tooltip or guide wording that names the button.
4. Click Publish changes. The embed and the hosted guide both update.

The guide’s pictures come from the screenshot kept with each page, and AtriumKit paints your text edits onto it too. Where it has no record of the old text’s font, or where you replaced an image, it blurs that spot in the pictures instead. On screens recorded as images (with Screenshots only on, or pages too large to save as HTML), Edit text paints the new words over the old ones in the captured font, one screen at a time. See edit text on captured screens.

When the layout or the flow changes, record again. A captured page keeps the layout it was recorded with. Small fixes work: on HTML screens, Hide removes an element that’s gone from the product and keeps its space, and Crop trims any screen. When a control moved or the steps changed, record the task again: a clickable demo takes new pages with + Capture more screens. A guided demo can’t re-capture a single step, so it needs a new recording and a new embed code in the article.

Go back when you need to. Every publish is a version in History that you can preview and restore, kept for 7 days on Free and longer on paid plans (version history).

One limit: translating a demo translates your copy, not the text inside captured screens.

Which fix for which change

Start with the article behind the most tickets

Build the inventory and triage this week with a spreadsheet and your help center’s export. Then pick the article your team links to most in replies, record its task once and see how the next release goes. The Free plan keeps three demos live, enough for your top three articles. Create a free account to try it.