Is outdated product documentation a known issue for you too?
4 comments
I’m working on a product to tackle the same problem - keeping user-facing docs up-to-date as products evolve. I’m still early, currently building a proof of concept.
Would love to connect and exchange ideas. Feel free to reach out on LinkedIn: https://www.linkedin.com/in/bpetryshyn/
Would love to connect and exchange ideas. Feel free to reach out on LinkedIn: https://www.linkedin.com/in/bpetryshyn/
One thing I’ve also noticed is that some big teams doing (Google included) is avoiding direct UI recordings/screenshots altogether. Instead, they use animated GIFs or illustrations that suggest the UI rather than replicate it exactly.
That way, when the product changes visually, the help content doesn’t immediately break. It communicates what to do rather than exactly where to click, and that seems to make it more resilient over time.
Kind of a “show the concept, not the pixels” approach.
It’s definitely a more scalable mindset, but also harder for smaller teams to pull off without design resources.
Curious if anyone else here has tried something similar or has lightweight ways to make help content more durable?
That way, when the product changes visually, the help content doesn’t immediately break. It communicates what to do rather than exactly where to click, and that seems to make it more resilient over time.
Kind of a “show the concept, not the pixels” approach.
It’s definitely a more scalable mindset, but also harder for smaller teams to pull off without design resources.
Curious if anyone else here has tried something similar or has lightweight ways to make help content more durable?
Who’s responsible for updating your docs?
When we made it the responsibility of the Support team and they developed an internal rotation, the problem went away.
We had a slack channel that spit out summaries and ticket links from our CI/CD system. Support would watch that and respond to it for doc updates. If they didn’t understand a specific ticket, they’d consult with Product, who were supposed to fully understand the changes but could pull in Engineering in a pinch.
Major releases would be coordinated in advance, and our KB had a system for preparing and promoting new drafts of already-published docs so those could be staged as well.
When we made it the responsibility of the Support team and they developed an internal rotation, the problem went away.
We had a slack channel that spit out summaries and ticket links from our CI/CD system. Support would watch that and respond to it for doc updates. If they didn’t understand a specific ticket, they’d consult with Product, who were supposed to fully understand the changes but could pull in Engineering in a pinch.
Major releases would be coordinated in advance, and our KB had a system for preparing and promoting new drafts of already-published docs so those could be staged as well.
Hi,
Interesting. Thanks.
From what I’ve seen, the responsibility for keeping documentation up to date really depends on how the company is structured. In some cases, it falls under the product team; in others, it’s handled by the support team.
In a previous role at a large company, I was on the product team, and initially, we were responsible for creating and maintaining the docs. Later, that responsibility shifted to the support team. At first, this freed us up a bit, but eventually, we started producing videos so the support team could use them as a base for writing the final documentation.
That handoff helped somewhat, but it didn’t solve the core issue: even small UI changes still required updating the docs. Screenshots had to be redone constantly, which quickly became a time sink.
From what I’ve seen, the responsibility for keeping documentation up to date really depends on how the company is structured. In some cases, it falls under the product team; in others, it’s handled by the support team.
In a previous role at a large company, I was on the product team, and initially, we were responsible for creating and maintaining the docs. Later, that responsibility shifted to the support team. At first, this freed us up a bit, but eventually, we started producing videos so the support team could use them as a base for writing the final documentation.
That handoff helped somewhat, but it didn’t solve the core issue: even small UI changes still required updating the docs. Screenshots had to be redone constantly, which quickly became a time sink.
Screenshots go stale, videos become misleading, step-by-step guides are obsolete after one or two UI changes. Even internal wikis end up half-wrong because no one updates them in time.
The result: - Users get confused or frustrated - Support gets bombarded with tickets that “should be answered in the docs” - The wiki becomes a graveyard—nobody trusts what’s in there
Everyone I’ve talked to agrees it’s frustrating, but most seem to just accept it as a cost of shipping fast.
I’m currently building something to help with this—making help content more resilient and easier to keep up-to-date, even when your product changes constantly.
Before I go deeper, I wanted to ask here: Is this a well-known issue for you or your team too? Or have you found workflows or tools that actually work long-term?
Appreciate any thoughts!