Nikita Dhulekar, a Business Analyst/Technical Writer at Fluent Commerce, joined us in this episode of Knowledgebase Ninja Podcast to talk about technical documentation’s creative process and how it has evolved over the years, and some tips for delivering top quality documentation.
Check out all the other episodes here
Key Facts
- Nikita Dhulekar’s LinkedIn
- Fluent Commerce website
- Nikita has been working as a technical writer for more than ten years
- Nikita’s journey into technical writing started when she was in her final year of engineering for the University degree program in Bangalore
- Since she didn’t want to pursue the typical routes related to the field, she interned with a company called Yantra as a technical writer and found her calling. Luckily she was also hired by the company
- After moving to Australia, she has worked mainly with project managers and stakeholders
- Availability, conciseness, understandability and ease of accessibility are the major goals of her technical documents
Key Takeaways
- Nikita explains that the entire process of documentation and technical writing has evolved. When she began technical writing, the “waterfall model” was very much prevalent in tech writing and software development. So there were a lot of top contributors (such as product and project managers) who would create high-level documentation, and the writers would observe them creating end-user guides or online help
- Over time, and with the development of Agile practices, the whole documentation process has drastically changed – from PDF’s and online help, writers have moved on to webpages. As a result, Nikita now works directly with project managers and developers to create and finalize content
- With Agile practices, writers can focus on creating stronger information architecture and providing feedback instead of previous working models where only leads and superiors could do so. Product managers now also have a greater say about what features they are working on, and how their solutions will help solve business problems
- Nikita primarily uses Confluence and Markdown tools, and even support teams create documentation which is then passed on to writers who make sure the content aligns with the company’s tone, brand, and voice
- In terms of the documentation workflow, Nikita relies heavily on Jira. Using Agile practices, she tracks all her work via Jira tickets by creating Epics and Stories. This puts her right at the beginning of the creation of features or solutions, fishing out personas and creating user stories, and understanding the solution a company is providing
- Ultimately, the content Nikita generates has to be end-user friendly or partner/consultant friendly, while ensuring that everyone follows the style-guide and best user practices. The product manager does the final technical review, and, in some cases, even the support team leads to ensure all information captured at the beginning is filtered down and made into concise documents for the end-user
- According to Nikita, creativity in technical writing doesn’t come from the writing itself, since it is generally structured and organized. Creativity comes from project manager’s and customer support teams when they share ideas about problem-solving and when they have to make spontaneous decisions
- When creating documentation, Nikita explains that the base needs to be clear for everyone to understand what is expected from them. Second, when working on a frequently evolving product, the writer needs to create a system/methodology to update the document quickly when needed. Third, the team needs to see how the clients are accessing the documentation (PDF’s, online help, webpages). Fourth, ask for customer feedback and problems they have faced in the past. All this involves many brainstorming sessions that allow Nikita to grasp what is expected from her as a writer fully
- Nikita feels that quality documentation has reduced workload and helped develop easy-to-understand and concise documents for users and technical and non-technical team members. However, she emphasizes that the core documentation needs to be very strong so that the support teams don’t have to generate massive customised documentation for clients
- Nikita shares that in her ten years of technical writing, she has reported mainly to documentation managers. Her work has been reviewed by editors who are major players in finalizing documentation. With the Agile system in place, she sometimes also reports to product developers and CEO’s
- Nikita’s documentation is protected by a username and password and is only accessible to clients and stakeholders and anyone the company allows access. Internally, the company uses Google Analytics to see how users perceive shared information
- To conclude, Nikita says technical writers should talk and connect and learn from one another
Nikita’s biggest influence
- In terms of whom she learned the most from in her career, Nikita credits her leads and fellow technical writers in her first company – Sterling Commerce and AT&T Company
Key resource
- Nikita says she learns a lot from Slack channels run by technical writers who share different information types. For instance, for creating a concise writer portfolio, writers can visit GitHub and learn more.
- Confluence
- Jira
- Google Analytics
What documentation related advice would Nikita give to her 20-year old self?
Nikita says she would tell herself to keep up with the technology and be ready for sudden changes and to see herself as a writer before everything else.
Subscribe to Knowledgebase Ninjas
Quote:
–