Fo proofreading, we would usually take a few steps:
Defining docs KPIs/Goals to measure success, some examples:
What are we trying to make the reader achieve?
How much time should it take to complete the goal?
How many steps are required for success? can we reduce any?
How many iterations did the user need?
Were we right with our assumptions about preliminary knowledge necessary to achieve the document goal?
Trying to follow the docs ourself, this will be by the author itself (not that trivial as it may seem :))
Sharing the doc with teammates and even better, developers from our community.
Having a feedback loop as long as possible, honestly, this might be affected by time constraints a lot of the time, but we try and do our best to make the process as useful as possible.
Most of the time, we'll use a beta stage that might take weeks to help us gain more feedback from a wider audience.
We will monitor the usage of our docs, just like a media company will monitor its content consumption (read time, user funnel, bounce rate, etc..).
At the end of the day, we want to treat the docs on our site as an equal part of our product, just the same way our API or developer dashboards are.
Hey Max, thanks for sharing these resources!
Fo proofreading, we would usually take a few steps:
At the end of the day, we want to treat the docs on our site as an equal part of our product, just the same way our API or developer dashboards are.
That's gold. I reckon an extra hour you put into making better docs saves hundreds of hours across the user base. Thanks for the detailed reply!
Sure Max! Would love to see join our Discord channel so we could chat more: discord.gg/GSeTUeA