Export to
Saturday, May 2, 2015 at 11:44am.
Counterpoint: Don't Write The Docs
Access Notes
Check in at the security desk to get access to the 27th floor. This usually isn't required for official events and meetups.
Website
Description
The WTD NA conference is coming in May, so it's a good time to start planning for post-conference Meetups. We'll meet again on Tuesday June 9, when Diana Potter, the Senior Director of Customer Success at Customer.io tells us when to say: "Don't Write The Docs".
When I started working as a Technical Writer, our local VP told me that to do my job well, I'd spend significant time testing and pushing for changes to our software. To me, that sounds like the essence of Diana's talk.
Diana manages Customer.io's support/docs team. As such, I expect that her talk will interest Documentarians, Support Engineers, and Knowledge Base Creators. Here is the abstract of her talk:
Writing user facing documentation gives you a unique perspective on software. How does something work? Will the software explode when I push this button? Okay, now how do you explain that explosion to a user, in a way that makes sense and captures their attention?
What do you do, though, when that unique perspective illustrates areas of confusion? Why document something that's confusing? Fix the confusion!
Write the docs that make sense for the user and advocate for product changes on behalf of the "user" too.
How do you decide when it makes sense to document, and when it makes sense to dig in your heels and push for an internal change to the product? How can you use documentation to push for change? Come learn what I've learned, the processes I've put in place, and learn the following chant: "does this doc make sense?"