In this article, I would like to discuss style guides, their role in the documentation development process, and the pros and cons of existing style guides and custom ones.

Similar to the software development process, where a team follows sequential steps to develop and deliver a product, documentation requires a similar approach. However, in addition to the need for a well-defined documentation development process, documents also require consistency, which is ensured by a style guide.

A style guide is a comprehensive set of established conventions and guidelines that govern the creation and presentation of documentation. These guidelines encompass various aspects of writing, formatting, and structuring content to ensure uniformity and readability. Some well-known examples of style guides include these:

• Google developer documentation style guide
• Microsoft Style Guide
• The Chicago Manual of Style

Problems addressed by style guides and their benefits​

Let's explore the specific issues that style guides aim to resolve and why they are valuable.

Consistency: One of the primary issues that style guides address is consistency. Consistency in documentation is crucial for creating a seamless reading experience. When you adhere to consistent rules regarding spelling, grammar, punctuation, naming, formatting, and structure, it minimizes confusion and enhances comprehension.

Reduction of ambiguity: Ambiguity in technical documentation can lead to misunderstandings, errors, and user frustration. A style guide helps reduce ambiguity by providing clear guidelines on how to express ideas, instructions, technical concepts, word choice, and more.

Enhanced user experience: A well-crafted style guide contributes to an improved user experience. When users encounter a documentation portal that adheres to a consistent style, they know what to expect from published documents. If users have used a user guide on this portal before, they can be confident that the next instruction they read will have a similar structure, wording, phrases, and format. This familiarity with the structure and wording enhances their ability to navigate and comprehend the content effectively.

Choosing between new and existing style guides​

When you realize the need for a style guide, you will likely consider two options: creating your own style guide or using an existing one. Let's delve into the advantages and disadvantages of each option.

Creating your own style guide​

Your project's documentation style, format, and other requirements might be highly specific, necessitating a tailored approach. For example, if you work for a healthcare IT company that develops software for medical practitioners, your documentation style guide would need to address strict regulatory requirements for handling patient data. Generic style guides like those from Google or Microsoft may not cover these aspects adequately. Your custom style guide would specify how to document data encryption procedures, user access controls, and compliance with healthcare regulations, ensuring that your documentation aligns with the industry's unique demands. However, designing a custom style guide has its advantages and pitfalls.

Advantages of a custom style guide​

Tailored to your technology stack: Existing style guides like Google's or Microsoft's are generic and may not address the intricacies of your specific technology stack. Your style guide can provide guidance on how to document code snippets, configuration files, and workflows unique to your projects.

Custom rerminology: Your projects may use domain-specific terminology or product names not covered by general style guides. A custom style guide allows you to define and standardize the usage of these terms. For instance, if your product uses a unique acronym, your style guide can specify whether to spell it out or use the acronym consistently. In some cases, you may want to supplement an existing style guide with additional rules for specific terms and acronyms.

Consistent branding and messaging: Your company or product may have a distinct brand voice and messaging strategy. A custom style guide ensures that your documentation aligns with your brand identity. For example, if your company emphasizes a friendly and approachable tone, your style guide can include guidelines on using conversational language in documentation.

Workflows and tools integration: Your projects may involve specific workflows or tools (e.g., code review processes in GitHub or issue tracking in Jira) that require documentation. A custom style guide can detail how to document these processes effectively, ensuring that your documentation integrates seamlessly with your development and project management tools.

Compliance and regulations: Depending on your industry, your documentation may need to adhere to specific compliance standards or regulations, such as GDPR or HIPAA. A custom style guide can provide guidelines for documenting sensitive information, ensuring that your documentation complies with legal requirements.

Pitfalls of a custom style guide​

Incomplete coverage: It's nearly impossible to cover all edge cases and scenarios at once. Building a style guide is an iterative process that may require continuous updates. Consequently, you can never be sure that your style guide includes everything you need, and when you write a new document, there might be breaches, unaddressed rules, formatting issues, or wording not covered in your style guide. As a result, you may need to simultaneously update your style guide and work on your task.

Time-consuming: Developing a comprehensive style guide is a time-intensive process that demands careful planning and execution. Your team must be prepared for the extended duration of style guide development, which could span weeks, months, or even longer. If you already have published documentation, each time you update your style guide, you may need to review the published documents to maintain consistency.

Responsibility: As your project evolves, so do documentation requirements and style guide updates. When you have your style guide, it becomes your responsibility to keep it up-to-date, ensuring it remains relevant and effective. This necessitates regular reviews and updates to incorporate new terminologies, best practices, and evolving user expectations.

Using an existing style guide​

The easiest and often suitable approach for most projects is to select an existing style guide that aligns with your needs. However, even this option has its advantages and disadvantages, which you should weigh when making a decision.

Advantages of using an existing style guide​

Established best practices: Existing style guides are often based on established best practices in the field. By adopting one, you benefit from the collective wisdom and expertise of the industry.

Community support: You don't need to maintain popular style guides. They have active user communities and resources for addressing questions and challenges, making it easier to find solutions and stay updated.

Time and cost efficiency: Using an existing style guide saves you the time and resources required to create and maintain a custom guide, allowing you to focus on your documentation tasks more efficiently.

Interoperability: Aligning with a widely recognized style guide enhances the likelihood that your documentation will be interoperable with other projects and industry standards, improving usability and acceptance.

Automated checks: For well-known style guides like Google and Microsoft, there are ways to adopt them through automation, using tools such as the Vale linter.

Weaknesses of using an existing style guide​

Lack of specificity: Existing style guides are designed to be general and may not cover all the specific needs of your project. You may encounter situations where the guide doesn't provide clear guidance on how to handle certain types of content or industry-specific terminology.

Limited customization: While existing style guides offer a framework for consistency, they may not allow for extensive customization to perfectly align with your project's unique requirements. You may find yourself needing to make exceptions or add supplementary guidelines.

Evolution lag: Established style guides may not adapt quickly to emerging trends or technologies. Your project may need to incorporate modern practices or address new issues that the existing guide hasn't accounted for.

Overcomplexity: Some well-known style guides can be quite extensive and complex, which may not be suitable for all projects. Navigating and applying every rule effectively can be challenging, especially for smaller teams or projects with limited resources.

Conflict with brand identity: Using an existing style guide may not align perfectly with your company's specific brand voice and messaging strategy. Conflicts between the prescribed style and your desired brand image may arise.

Conclusion​

The decision to create your own style guide or adopt an existing one depends on your project's specific needs, resources, and objectives. While creating a custom style guide offers greater flexibility and control, it comes with the costs of time and effort. Alternatively, automated or manual adoption of existing style guides provides efficiency but may require ongoing learning and vigilance. Ultimately, your choice should align with your documentation goals and your team's capabilities.

Regardless of your choice, choosing and following a style guide is a vital part of documentation development and maintenance. It ensures that your documentation consistently delivers clarity and professionalism, enhances the user experience, and contributes to the success of your projects.

In my previous article, Docs-as-Code Methodology and Advantages, I provided an overview of the Docs-as-Code methodology and its general advantages. In this article, I will delve into the specific benefits of integrating Docs-as-Code, discuss the tools used, present an example of the Docs-as-Code workflow in your team's development process, and explain the significance of Docs-as-Code tools.

Integrating Docs-as-Code​

When contemplating the documentation process and whether integration is worthwhile, it's essential to consider who will be responsible for authoring the documentation. If this responsibility primarily falls on the shoulders of technical writers, the choice of tools may not be as critical. However, if developers are actively involved in the writing process, embracing Docs-as-Code and integrating suitable writing and publishing tools into the development workflow can yield significant advantages. By "suitable tools," I refer to developer-focused programs, tools, version control systems, and collaboration platforms. These tools are well-known to developers, enabling them to seamlessly participate in documentation production.

What "Docs-as-Code tooling" exactly stands for​

Docs-as-Code, in essence, involves applying the same principles and practices to your documentation as developers do to their code. Therefore, when referring to "Docs-as-Code tooling," I'm talking about embracing tools and approaches that are familiar to developers:

Working with plain text files: In Docs-as-Code, documentation is authored in plain text files, steering clear of proprietary binary formats like Adobe FrameMaker or Microsoft Word. Plain text files are more conducive to version control and collaboration.

Leveraging static site generators: An essential aspect of Docs-as-Code is employing open-source static site generators like Sphinx, Jekyll, or Hugo. These tools empower you to build documentation locally via the command line, a departure from commercial software like FrameMaker or Word.

Utilizing Text Editors: To align with Docs-as-Code principles, authors prefer text editors such as Atom or Sublime Text. These editors foster a transparent, code-like approach, in contrast to closed, proprietary tools that operate as enigmatic black boxes.

Storing documentation in a version control repository. Docs are stored within version control repositories, commonly Git repositories, much like how software code is managed. This approach replaces conventional storage solutions like SharePoint, Google Docs, or shared drives. In some cases, documentation may even reside in the same repository as the codebase it documents.

Using collaborative version control platforms: Collaboration in Docs-as-Code hinges on version control systems like Git. Writers employ the same approach as developers: branching, merging, pushing, and pulling to facilitate seamless collaboration. Technical Writers can use GitHub for Desktop to alleviate the adaptation. In this case, they don't need to work with a CLI and memorize a bunch of commands to manage documentation within a repository because GitHub for Desktop offers an intuitive user interface, which allows getting started with minimum knowledge.

Automated site building: Automation is a cornerstone of Docs-as-Code. Continuous delivery pipelines automate the generation of web-ready documentation whenever changes are pushed to a specific branch. This eliminates the need for manual publishing and file transfers.

Validation through custom workflows and scripts: Custom workflows and scripts play a vital role in Docs-as-Code by automating validation checks. These scripts can identify broken links, sidebar discrepancies, code owners, pull request (PR) labels, incorrect terminology, formatting discrepancies, and other errors, reducing the reliance on manual content inspection.

Agile documentation management: Docs-as-Code aligns documentation processes with agile development methodologies, such as Scrum. Documentation work is structured into manageable chunks, tracked in an issue management system like Jira, assigned to bi-weekly sprints, and progress is regularly reported to stakeholders, often involving live demonstrations.

In summary, adopting Docs-as-Code entails applying the same systems, workflows, and best practices to documentation that are commonly employed in software development. This approach enhances collaboration, version control, and overall efficiency in managing documentation projects.

Example: Docs-as-Code documentation development workflow​

Let's dive into a practical example of how the Docs-as-Code documentation development process can work in a real project. Let's consider a scenario where a software development team is using Docusaurus for documentation, Jira for issue tracking, GitHub (or GitHub desktop as an option for technical writers) for version control, and S3 for storing images.

Step 1: Issue creation (Jira)​

1. An epic or user story is created in Jira as part of the development process.
2. A documentation ticket is automatically generated in Jira and linked to the epic or user story.
3. During the planning phase, the product owner (PO) or product manager (PM) identifies the need for documentation based on the epic's requirements and specifies the type of documentation required (for example, user guide, API, or integration guide), and assigns tickets to respective team members (a technical writer or developer).
4. The PO or PO closes all redundant documentation tickets.
5. The assignee reviews the documentation ticket and begins working on it.

Step 2: Documentation authoring (GitHub)​

1. The assignee creates a branch in the GitHub repository associated with the project.
2. Using a text editor like Visual Studio Code, the assignee writes the documentation in markdown format, uploads images to an S3 bucket, and adds links to the documentation.

Step 3: Collaboration (GitHub)​

1. The assignee commits their changes to the branch, opens a pull request (PR) on GitHub, and, depending on the documentation type and workflow, requests a developer or technical writer review.
2. The PR goes through a review process and the reviewers provide feedback and suggestions.
3. The assignee makes necessary adjustments based on feedback and updates the PR.
4. Once all reviewers approve the PR, it is merged into the master branch.

Step 4: Automated publishing​

1. Automated CI/CD pipelines detect changes to the main branch and trigger a build.
2. The build process generates the static documentation site using Docusaurus.
3. The updated documentation is automatically published on the project's website.

Step 5: Documentation lifecycle management (Jira)​

1. The documentation ticket status is updated in Jira to reflect its progress.
2. Documentation tasks are linked to the corresponding development epic or user story.
3. Any documentation-related issues or updates are tracked in Jira.

Step 6: Iteration and continuous improvement​

1. The team follows an agile approach, iterating on documentation during bi-weekly sprints.
2. Documentation improvements, updates, or new documents are added as needed.
3. End-user and stakeholder feedback is collected during these iterations to ensure that the documentation meets their needs.

By following this workflow, the team seamlessly integrates documentation into the development process, ensuring that documentation is up-to-date, high-quality, and closely aligned with the product's development. This approach enhances collaboration, version control, and overall efficiency in managing documentation projects.

Advantages of the Docs-as-Code adoption​

While Docs-as-Code may not be the best fit for every documentation scenario, it offers several compelling advantages that make it a valuable approach for many teams. Here are some of the key benefits of adopting Docs-as-Code:

Collaboration with developers​

One of the standout advantages of Docs-as-Code is the enhanced collaboration it fosters between technical writers and developers. In complex technical documentation, developers often possess specialized knowledge that can be challenging for non-developers to document accurately. By treating documentation as code and leveraging familiar tools like Git and Markdown, developers can play a more active role in crafting and reviewing documentation. This collaboration ensures that the documentation remains technically accurate and aligned with the codebase.

Continuous delivery​

Docs-as-Code simplifies the process of publishing and updating documentation. With continuous delivery pipelines integrated into a Git repository, authors can commit and push content changes effortlessly. The automated build and publishing process eliminates the need for manual file transfers or complex deployment procedures. This streamlines the publishing workflow, allowing for quick and efficient updates to documentation.

Increased collaboration with contributors​

When documentation teams collaborate within a shared Git repository, they gain better visibility into each other's work. Using Git, authors can easily track changes made by teammates, synchronize their work, and even contribute to each other's content. This collaborative environment promotes knowledge sharing, consistency, and efficient teamwork.

Flexibility and control​

Docs-as-Code tools provide unparalleled flexibility and control over documentation outputs. Authors can customize documentation to match specific requirements, such as URL patterns, layouts, or metadata incorporation. This flexibility is particularly valuable when integrating documentation into websites or other systems with unique needs. Skilled users can harness web technologies like HTML, CSS, JavaScript, and templating languages to achieve complex documentation goals.

Processes as well as tools​

Beyond the tools themselves, Docs-as-Code encourages the adoption of engineering processes for managing documentation. Agile methodologies like Scrum can be applied to documentation projects, enhancing organization and efficiency. By aligning documentation processes with software development practices, teams can improve their workflows and deliver higher-quality documentation.

Handling challenging factors​

Docs-as-Code tools and practices offer solutions for addressing challenging documentation requirements. Localization, content reuse, versioning, authentication, and PDF generation are all areas where Docs-as-Code tools can excel with some creativity and technical expertise. Advanced templating and scripting logic in tools like Liquid, Docusaurus, or Jekyll empower authors to tackle complex tasks effectively.

Conclusion​

In summary, the adoption of Docs-as-Code brings forth numerous advantages, including improved collaboration, streamlined publishing, increased contributor awareness, flexibility, enhanced processes, and the ability to tackle challenging documentation needs. While it may require a learning curve and adaptation, Docs-as-Code offers substantial benefits for teams engaged in technical documentation. By embracing this approach, you empower your team to create, maintain, and deliver documentation that aligns seamlessly with your development efforts, ultimately resulting in better, more accurate, and up-to-date documentation.

In this article, I want to delve deeper into setting up a documentation development process and provide a real example of how to integrate it into your project's development process.

Determining document types​

First, you need to identify all potential document types that your team delivers within your project. You can achieve this by conducting a series of interviews with your team members, including product owners, tech leads, architects, developers, and quality assurance engineers.

Example​

Let's consider an example where the team delivers the following documents: feature overviews, user guides, API documents, migration guides, integration guides, and installation guides. In this case, the documentation can be categorized into two groups:

• User documentation: Feature overviews and user guides.
• Technical documentation: Migration guides, integration guides, installation guides, and API documents.

Determining responsible teams​

Once you have a comprehensive list of required documents, you need to discuss and align which team members will be responsible for writing each type of documentation.

In this scenario, developers are accountable for creating installation and integration guides, while technical writers handle API and migration documents, as well as feature overviews and user guides. Therefore, you have two groups of responsible individuals:

• Technical writers: API documents, migration guides, feature overviews, and user guides.
• Developers: Installation and integration guides.

Setting up a documentation development process​

After identifying the document types and assigning specific teams, you can establish a documentation development process. Your goal here is to analyze each document type and determine the most efficient approach for delivery.

Example​

If an epic introduces a feature that enables Back Office users to create discount vouchers for customers, the best approach might be to test the feature and then write a corresponding user guide. In this case, a technical writer can handle it independently. Conversely, if the epic involves technical documents, such as integration or installation guides that require running multiple commands and incorporating updated code examples, modules, and dependencies, developers should be responsible for these documents.

Consequently, for each document type requiring a distinct documentation process, you need to establish a separate workflow.

Returning to the example from the previous Determining Document Types section, the project encompasses two document groups: technical and user. Each group necessitates its documentation process. In this scenario, a general workflow for each group may look like this:

• Technical documentation: New → In Progress → Dev Review → PO Review → TW Peer Review → Published
• User documentation: New → In Progress → PO Review → TW Peer Review → Published

Exploring and integrating in the development process​

Now that you've established your documentation development process, you need to integrate it into the development process workflow. To do this, you should examine your team's development process workflow in detail and identify the most suitable point for integration. Analyze each step, understand the significance of each workflow status, the responsible parties, and the tasks involved.

Once you have a thorough understanding of the development process, you can determine when documentation tickets should be created. Subsequently, provide the list of requirements to your Jira administrator to automate the generation of documentation tickets for each document type.

Development process example​

Let's consider a scenario where the development process follows this workflow:

New Epic → In Progress → Code Review → Testing → Architectural Review → Demo → Ready for Release → Done

Documentation should be initiated as early as possible to avoid delaying the release. Therefore, the most appropriate time to begin documentation might be when an epic enters the In Progress phase, as this is when all team members start working on their respective tasks. Depending on the document type, the stage at which documentation tickets are picked up and processed may vary, but they should always be ready for the right moment.

When the documentation step is integrated into the development process, it will follow this workflow:

1. When an epic transitions from New to In Progress, documentation tickets are automatically created.
2. The PO or PM decides which documents need to be created or updated based on the epic. They update ticket descriptions to specify the required documentation and close redundant tickets.
3. The technical writer and development teams assign the relevant documentation tickets and follow the documentation development workflows.
4. Once all documentation and development tickets are resolved, the epic can be closed.

Conclusion​

In this article, we've explored the essential steps to establish a documentation development process and seamlessly integrate it into your project's development workflow. By following these guidelines, you can ensure that your technical documentation meets the needs of your project and its stakeholders.

Key takeaways from this discussion include the folliwing points:

1. Determining document types: Begin by identifying all the different types of documents required for your project, ranging from user guides to technical specifications.
2. Determining responsible teams: Assign responsibilities to the appropriate team members based on their expertise. All team members play vital roles in documentation.
3. Setting up a documentation development process: Establish a clear and efficient workflow for creating, reviewing, and publishing documentation tailored to each document type.
4. Exploring and integrating the development process: Seamlessly integrate documentation into your project's development process to ensure documentation aligns with the development timeline.

By implementing these practices, you can streamline your documentation process and improve collaboration among team members, ultimately resulting in high-quality documentation that enhances your project's success.

Remember that documentation is not just an afterthought but an integral part of your project's lifecycle. Starting documentation early and integrating it into your development process will help ensure your project is complete, well-documented, and ready for success.

In this article, I want to explain what Docs-as-Code is and its importance and compare it to a typical documentation process.

Defining Docs-as-Code​

Docs-as-Code is a philosophy and methodology that integrates documentation seamlessly into the software development workflow. Instead of treating documentation as a standalone task, it treats documentation as code—a core component of the project that evolves alongside the codebase. In essence, Docs-as-Code promotes the idea that documentation should be versioned, reviewed, and updated in the same way as source code.

Traditional documentation process​

To get a better understanding of the docs-as-code approach and its advantages, let's consider the traditional documentation process. Documentation has often been a disjointed and isolated task that occurs at the tail end of a project. It usually involves the following:

Late inclusion: Documentation is typically considered a separate and often secondary task. It's often addressed toward the end of the project when time constraints may lead to rushed and incomplete content.

Static nature: Traditional documentation is often static, with limited interactivity and responsiveness to changes in the project. It may not adapt well to dynamic and agile project environments.

Silos: Collaboration between developers, technical writers, and other stakeholders can be fragmented. This can result in misunderstandings, miscommunication, and errors in the documentation.

Manual updates: Updating documentation is a manual and sometimes cumbersome process. It may not be well-integrated with code changes, leading to delays in keeping documentation current.

Versioning challenges: Traditional documentation may not be closely linked to the code's version control system, making it difficult to track changes and maintain a history of documentation updates.

Quality bariation: The quality of documentation can vary widely in a traditional approach. It often depends on individual effort and priority, leading to inconsistent documentation quality across projects.

Versioning challenges: Keeping documentation in sync with the evolving codebase can be challenging, leading to outdated and inaccurate information.

Why embrace Docs-as-Code?​

Now, that you know a bit more about the pitfalls of a traditional documentation process, let's look into Docs-as-Code advantages:

Improved collaboration: One of the primary benefits of Docs-as-Code is improved collaboration. By integrating documentation into the development workflow, it encourages real-time communication between developers, technical writers, product owners, and other stakeholders. This collaboration fosters a shared understanding of project requirements and functionalities, reducing misunderstandings and enhancing the overall quality of the documentation.

DDLC automation: Docs-as-Code aligns with modern software development methodologies like DevOps and Agile. It allows for the automation of documentation generation, ensuring that documentation always reflects the latest changes in the codebase. This not only saves time but also minimizes the risk of human errors in the documentation.

Version control: In the Docs-as-Code approach, documentation lives in the same version control system as the code. This means you can track changes, revert to previous versions, and maintain a comprehensive history of your documentation. It ensures that documentation remains consistent with the project's current state, making it an invaluable resource for troubleshooting and auditing.

Enhanced quality: When documentation becomes an integral part of the development process, it naturally receives more attention and scrutiny. Developers, product owners, and technical writers collaborate closely to ensure that documentation is accurate, concise, and up-to-date. This leads to documentation that is not just a necessary evil but a valuable asset that adds to the project's overall quality.

Streamlined updates: In traditional documentation processes, updating documents can be a cumbersome task. Docs-as-Code simplifies this by making documentation an integral part of code changes. This ensures that updates are prompt, and changes are well-documented, reducing the chances of information becoming obsolete.

Compared to the traditional documentation process, Docs-as-Code allows you to bridge the gap between different teams on a project, fostering collaboration and agility while enhancing the quality of documentation. For technical writers, business analysts, project managers, product owners, and developers alike, embracing Docs-as-Code is more than a trend—it's a strategic shift that promises improved project outcomes, streamlined workflows, and documentation that is not just a byproduct but an integral part of the development process.

On this page, you can get acquainted with my work experience.

Welltech: Dec. 2023–Present​

Position: Senior Technical Writer

Responsibilities:

• Developing and integrating a documentation ticket workflow into the development process (Asana+GitLab+Docusaurus+Confluence).
• Building a knowledge base from scratch.
• Writing and maintaining user guides, feature overviews, and concept documents.
• Gathering information and interviewing SMEs to write and update documentation.
• Using AI to create custom scripts and prompts that automate documentation review, updates, and translations (Script+Asana API+GPT/GPT API).
• Conducting end-user surveys to assess satisfaction with documentation.

Achievements:

• Created, presented, and integrated documentation delivery processes.
• Automated repetitive tasks, including documentation review, updates, and translation.
• Reduced time spent on release notes writing and delivery by 90% through automation.
• Built a comprehensive knowledge base from scratch.

Spryker Systems: Dec. 2020–Aug. 2023​

Position: Technical Writer

Responsibilities:

• Managed developer documentation, ensuring accuracy and clarity.
• Wrote user guides, API documents, and feature overviews.
• Reviewed documentation PRs created by developers, product owners, and other technical writers.
• Tested Postman collections to gather data for documenting APIs.
• Created GIFs to visually demonstrate feature functionality.
• Migrated documentation from Confluence/Document360 to Jekyll+GitHub to implement the docs-as-code approach.
• Handled documentation change requests from internal and external users.
• Shaped and refined the documentation development life cycle (DDLC).
• Used AI (ChatGPT) to improve DDLC and accelerate time-intensive tasks.

Achievements:

• Automated repetitive tasks using GitHub Actions workflows.
• Enhanced adherence to the developer documentation style guide by configuring and implementing the Vale.sh linter.
• Automated the "Internal Contributor of the Month" celebration initiative.
• Mentored new technical writers on internal documentation processes and standards.
• Improved the overall developer and business user documentation creation workflow.

EPAM Systems: Aug. 2019–Dec. 2020​

Position: Technical Writer

Responsibilities:

• Conducted editing and quality assurance for documentation produced by instructional designers and developers.
• Collaborated with technical SMEs to ensure technical accuracy of documentation.
• Created and maintained developer instructions, readme files, user guides, security and compliance documents, and high-level architecture diagrams.

Kuehne + Nagel: Jun. 2018–Jul. 2019​

Position: Technical Writer

Responsibilities:

• Maintained the Process Catalogue by documenting and updating Warehouse Management System (WMS) operational processes.
• Translated technical documentation into user-friendly formats for business users.
• Designed and supported documentation workflows based on SME inputs and feedback.

Bintime: Oct. 2017–Jun. 2018​

Position: Junior Technical Writer

Responsibilities:

• Created, updated, and maintained developer and end-user documentation in Confluence.
• Interviewed subject matter experts to gather technical details.
• Collaborated with clients to define and align documentation requirements.
• Used MySQL queries to examine databases and describe software functionality.

Skills​

• Technical Skills: Docs-as-code, GitHub, GitLab, JSON, Markdown.
• Tools: VS Code, Postman, Jira, Confluence, Snagit, draw.io, Document360, ScreenToGif.
• Guides and Standards: Google Developer Documentation Style Guide, Microsoft Manual of Style.

Education​

University: National Technical University of Ukraine 'Kyiv Polytechnic Institute’
Years: 2010–2016
Degree: Specialist Degree in Biomedical/Medical Engineering