The problem
Your help center is behind your last release.
You ship every week. The screenshots, videos and step-by-step articles were made by hand, releases ago. Nothing connects the two, so the first person to notice a guide is wrong is usually a customer.
How it happens
A help article is a capture of the product on the day someone wrote it. The product keeps moving; the article doesn’t. There’s no signal between them, so a change reaches customers before it reaches the docs.
People who keep these docs describe it the same way:
“That’s all fine and dandy until the interface layout changes and you have to go through and replace a massive amount of screenshots. That’s not fun at all.”
A technical writer, r/technicalwriting, January 2026
“Pendo/WalkMe workflows need to be QAed as they randomly break unexpectedly. As they’re relying on nestled UX element’s IDs/attributes, and should something change in UX/code… Well it’s gonna break workflows”
A docs team member, r/technicalwriting, April 2026
“It took ~5 months for anyone to notice and fix something that is obviously wrong at a glance.”
An engineer, on a vendor’s docs page, Hacker News, February 2026
Even the companies that make the product say they can’t tell. Replying to a customer request to remove outdated training videos, one vendor wrote: “The challenge is it’s hard for us to know what’s out of date unless someone points it out.” (GoHighLevel ideas board, 2024)
It’s rarely just the screenshot
A new screenshot doesn’t fix a guide whose steps changed:
“If the settings button had moved to another dialog box and that’s why this person couldn’t find it, the issue isn’t the settings button - the entire procedure needs to be updated. A new screen cap isn’t solving that problem.”
A technical writer, r/technicalwriting, November 2025
“if the documentation says press “Options > Customize” but the application is updated so this becomes “Preferences > Advanced” then the screenshot will show the new text but the documentation will still show the old labels.”
An engineer, Hacker News, April 2026
The labels, the order of the steps, the screenshots and the video all describe the same flow. They go stale together, so they need to be checked together.
What teams do today
Use fewer visuals. “I’ve learned to drastically minimize the number of screenshots I use, precisely because of Product’s blithe UI changes.” (r/technicalwriting, September 2026). It works, at the cost of guides that are harder to follow.
Make docs part of the release. “Ideally “Docs updated” should also be a release approval condition but we take what we can get.” (r/technicalwriting, September 2026). And from an engineer: “PRs: for any behaviour change, feature addition etc: patch must include corresponding documentation updates. If not: reject.” (Hacker News, July 2026)
The second answer points at the right moment: the pull request, while the person who changed the flow is still looking at it. What’s been missing is a way to know, on that pull request, which guides the change affects.
Why it matters
Self-service already struggles. In Gartner’s survey of 5,728 customers, published in August 2024, only 14% of customer service issues were fully resolved in self-service, and 43% of self-service failures happened because the customer couldn’t find relevant content (Gartner). Gartner didn’t measure stale content. But an article that shows last quarter’s screens isn’t relevant content, and as one engineer put it: “Out-of-date documentation can be worse than no documentation at all when it is actively wrong.” (Hacker News)
If your help desk’s AI answers from those articles, it repeats the stale steps too: Stale articles are why your AI support agent answers wrong.
Catching it on the pull request
What it takes:
- Notice on the pull request that changes a flow, not after the release.
- Check the whole flow, steps and labels included, by running it, not only by comparing pictures.
- Decide what happened. If the change was intended, the guide should update. If it wasn’t, the product broke, and that’s a bug.
- Update everything that shows the flow at once: the steps, the screenshots and the video.
That’s what Stagewright does. Each walkthrough is a file in your repository that runs against the pull request’s preview. When a change affects it, the PR shows before and after frames. An intended change is approved and the linked help article, its screenshots and the video update together, as a draft in Intercom, Zendesk or Productlane by default. A broken flow is filed as an issue with the video before it merges. How it decides is on the Method page.
What it doesn’t do: it checks the flows you have walkthroughs for, and lists the other articles as not checked. It records web apps. It’s in private beta.
Where to go next: for support teams, for engineering, or start from your Playwright tests.
Try it on your own product
Record a first walkthrough on your machine with no account. PR checks, approvals and publishing are in private beta: join the waitlist and we'll set you up by hand.