Jessica Valero Gil, Senior Technical Writer at Zapier joins us in this episode of Knowledgebase Ninjas Podcast and discusses the Document Development Life Cycle (DDLC) and how to ensure the effectiveness of the document process.
- Jessica’s LinkedIn
- She never realized it was a career option until she joined Zapier in 2017.
- She has a background in graphic design and has worked in domains such as HR, SEO, support and finally moving into documentation.
- At Zapier, initially, her role was focused on writing articles for the help center, then transitioned into hybrid, and then eventually became a full-time technical writer there.
- Speaking about the documentation process, Jessica explains that at Zapier, the technical writers are placed across different areas of the product. Earlier, the documentation team used to heavily rely on the relationships with different product teams. Teams must be frequently notified of any internal communications or any potential things coming down the pipeline.
- However, with this shift (of having technical writers within different areas of the product), the documentation team is much more aware of changes since they are a part of the product development cycle.
- “Another aspect of our documentation process is the internal knowledge of Zapier’s support knowledge base. Here, we lean on the methodology of KCS. KCS stands for Knowledge Center Service. It integrates the knowledge base into an organizational workflow.
- For the majority part of the Document Development Life Cycle (DDLC), I’ve taken inspiration from GitLab as their documentation is publicly accessible. Under DDLC, there are 3 different phases in general. The first one is discovery; the second one is shaping and the last one is delivery. At the discovery stage, we are kind of informed that something is coming down the line. Moving towards shaping and delivery, we try to understand what the documentation requests will form and look like.
- With this process model, it’s an opportunity for us to collaborate a little bit more versus knowing about it. It can help us to give timely feedback to the product teams. I think before we used to heavily rely on someone saying, hey this needs to be updated and we weren’t necessarily part of the process and then from there, we had to kind of figure out how best to kind of translate that in a way that would make sense to the customer. But now, kind of being a part of the process, we’re able to kind of share our insights and improve the product and experience of the user.”
- According to Jessica, good documentation enables the users to find the answers they are looking for at the right time. If the documentation can cover the fundamentals of say, what the product does, it can help reduce the redundancies of support and success teams a great deal.
- “To measure documentation effectiveness, we track a lot of different data. Apart from users and sessions, we track how readers are coming in and out. We also look at searches with no results. Say, if someone is searching for a piece of information, and if there’s nothing kind of pulled up, that is also an indication that the information is missing or maybe the article itself not written in the way that the customer expects.” She adds.
Rapid fire with Jessica
- Biggest influence
I started as a lone writer and whatever I have learned since then, I owe it to Write the Docs community. They have an amazing slack community and they organize good number of conferences to participate virtually and in-person.
- Highly recommended resource
- https://everypageispageone.com/the-book/ by Mark Baker
- A piece of advice you would give your 20-year-old self.
My advice would be to always focus on progress over perfection. Not every single piece of documentation will be perfect, and this is something I picked up from learning KCS.
Subscribe to Knowledgebase Ninjas: