Programme

GOST 34 is a proven tool for structuring information about automated systems at all stages of their lifecycle. Its strength lies in a systematic view of a system, enabling analysis of all related information.

This raises the question: is the standard applicable to modern AI systems? GOST 34 assumes deterministic behavior, whereas AI systems are fundamentally non-deterministic. Applying its requirements directly to intelligent systems yields results that are formally correct but practically useless. Does this mean a new standard is needed? The authors believe the general approach (distinguishing between system behavior and the means of implementing it) remains relevant, though description methods require revision to reflect AI technologies.

The talk presents existing approaches to describing AI systems, the authors’ practical experience, and the documentation templates they developed.

This talk explores the experience of replacing the traditional technical writer's review stage with a Large Language Model (LLM). We will examine how this shift impacts the accuracy, clarity, and consistency of documentation, highlighting the areas where AI outperforms humans and where human expertise remains irreplaceable. The talk will also cover quality metrics, experiment results, and practical recommendations on integrating AI into the documentation review workflow.

In 2024, Cloud.ru abandoned its matrix structure. Technical writers, developers, testers, and analysts came under the direct management of product managers. We had to come up with a way to prevent these roles from living by the “raisin-in-the-bun” principle — where each product team has its own standards, with no shared culture or common rules.

Over the next two years, we built professional communities (committees) for all roles — including technical writers. In my talk, I’ll share how we made it happen, how we maintain documentation quality without centralized management, and why our community is more vibrant than any formal department.

Our experience in building an effective professional community will be valuable for companies of any size — whether they’re going through similar organizational changes or have long operated in a fragmented structure — for everyone looking for ways and mechanisms to unite a profession within their company.

A good user experience starts with clear, high-quality texts. But what happens when a product has to speak more than one language? How do a technical writer and a localisation specialist work together to ensure that the text remains accurate, user-friendly, and natural in every locale?

In this talk, we will explore:

• why seamless collaboration between a technical writer and a localisation specialist is critical for the product;

• how they interact at different stages — from writing to adaptation;

• our practical experience: which tools and approaches help avoid mistakes and accelerate the process.

This talk will be valuable for anyone working with texts in IT products, as well as for those who want to understand how to make documentation and interfaces truly comfortable for an international audience.

As the number of products in our department grew, it became clear that without a unified design system, our interfaces would quickly lose consistency. Our frontend team initiated the creation of a shared UI Kit as a “single source of truth” — covering everything from Figma designs to production-ready code.

In this talk, I’ll describe how we built an end-to-end workflow from design to production, organised work on texts and localisation, and involved designers, technical writers, analysts, and product managers. I’ll also share our processes for developing and documenting reusable components, as well as our experience running an internal frontend blog that helps scale knowledge across the company.

Documentation is no longer a set of supplementary materials; it has become an independent product. A product-oriented approach creates measurable value for both users and the business: it improves onboarding, reduces support workload, and enhances the overall user experience.

The shift from a service-oriented to a product-oriented approach changes the role of the team: at the operational level, the author creates text artifacts; at the tactical level, they integrate with the product team and form hypotheses to improve the user experience; at the strategic level, they act as a visionary, influencing product decisions and the systematic development of documentation. This approach ensures consistency, transparency, scalability, and long-term value.

In this talk, participants will learn how to integrate product best practices into documentation work, manage its development as a full-fledged product, and generate measurable value for all stakeholders.

• Auto-generating word forms (cases, moods, etc.) to ensure consistency. 
• Automatic document formatting when generating DOC files (goodbye, copy-paste). 
• Using LLMs in Copilot mode within an MD editor. 
• Utilizing JSON/YAML structures for prompts to generate high-quality LLM responses. 
• Technical and economic limitations of applying LLMs (“token economy”). 

What are the benefits of having software listed in the Ministry of Digital Development’s register? Tax incentives, grants, and regulatory preferences.

We will discuss why software and software–hardware complexes (SHCs) should be registered with the Ministry, as well as the specific requirements for SHCs designed for information security purposes, including FSTEC-related considerations.

The session will cover a concise step-by-step overview of the software and SHC registration process and provide an overview of prohibited foreign components.

Participants will also receive a checklist for reviewing software and SHC technical documentation to ensure compliance with the Ministry’s requirements for submission to the Russian Software Register.

How can we understand whether your documentation works and brings value to the product and the business?

In this talk, I will cover:

• where to start and which metrics are worth introducing,

• how our team built the reporting from scratch,

• how we use data to measure the impact of documentation on business outcomes and customer support.

We’ll have a close look at our “success stories” as well as the challenges we faced along the way.

Styles are an important tool when working with MS Word.

The purpose of this workshop is to share three cases that were born in practice and will help you work with documents faster, more comfortably and more productively — all at zero cost to implement.

In real time, I will show you how each of the cases is applied and answer your questions.

Who will find this useful?

Those who can’t escape MS Word — and those who are trying to create an alternative to it.

This talk focuses on the introduction of AI agents into the processes of creating and maintaining technical documentation within a large team working with complex infrastructure. It demonstrates the evolution of the approach: from using agents as an auxiliary tool for checking and editing texts to semi-autonomous work based on predefined templates and rules.

The talk also addresses the choice of tools and models, examining the selection criteria: compliance with security requirements, quality of output, and usability.

The talk includes an effectiveness analysis. It demonstrates how agents handle different classes of tasks — from bringing texts into the required format to generating instructions. The economic impact is also assessed: reduced labour costs, lower operational expenses, and faster documentation delivery.

This material will be useful for technical writers, team leads, and other specialists considering the use of AI agents to automate documentation processes.

This talk presents a practical approach to developing UX editing and improving the quality of interface texts using a method that combines Nielsen’s classic heuristics with additional proprietary evaluation criteria. Based on these principles, the team created a checklist for quick and standardised assessment of interfaces, UX texts, error messages and hints.

A special focus is placed on the “PYATKA” formula, which brings together five essential properties of high-quality UX text: usefulness, clarity, structured composition, conciseness, and activity. This multi-tool enables technical writers, designers, and researchers to consistently improve content and interfaces without the need for continuous user involvement.

The talk will be valuable to anyone looking to systematically enhance the quality of interface solutions and introduce clear, reproducible UX editing practices within their team.

A knowledge base is meant to be the main source of information for employees, yet it often remains an undervalued tool.

In this talk, I will explore practical methods for promoting the knowledge base internally and motivating teams to search for answers independently. I will also share specific examples of successful introduction, and examine how to change the knowledge base from a formal reference guide into an indispensable assistant for every employee — and why this is not as difficult as it may seem.

At the beginning of 2025 our team started working on a product that supports versioning. To ensure our users are promptly informed about updates, changes, and fixes, we quickly realised the importance of publishing changelogs in a timely manner.

Initially, we tried to compile changelogs using our task management system, but we discovered that the sheer number of tasks made it difficult to keep track of every change. Looking for a more effective solution, we switched to automatically generating changelogs based on the commit history in GitLab.

In my talk, I will share how we used GitLab tools to set up a changelog generation process that brought together both the development team and the technical writer. I will discuss our implementation experience, outline the results we achieved, and highlight the unexpected positive effects this approach had on our change-management process.

Developing custom solutions at the intersection of microelectronics, embedded platforms and AI, our company has long realised one sad truth: standard documentation is not enough any more. If we deliver a tailored product, then user assistance must be equally precise and customised. Clients have repeatedly asked video guides for the most non-trivial features, and we did that in several cases. Previously, this was not cost-effective: a unique product equalled a unique and expensive-to-maintain video. However, the world has changed: tools have become more accessible, and the short video format has evolved from entertainment into a familiar way for users to consume information. 

This talk is the story of reviving a once “shelved” idea. We will explain how, using modern technologies, we integrate targeted video instructions into technical documentation to flexibly and effectively address the most pressing requests of different clients.

A competency matrix is useful for developing an individual employee, but how can you ensure systematic development for an entire group or department? One approach is to develop a maturity matrix.

In this presentation, we will showcase the maturity matrix we developed for three key text-related processes in IT: technical writing, UX editing, and localisation. Unlike other examples, our template is practical and can be adapted to different processes and companies.

The presentation will be valuable for managers, team leads, and writers who want to assess the current state of their text-related processes, identify growth opportunities, plan strategically, and simplify business justifications. Additionally, the template allows you to immediately organise and classify key takeaways and best practices from the conference or other sources for future implementation.

We often talk about how to write documentation — but how is it actually read? Are our assumptions correct? What does a product user really do when searching for information or trying to solve a problem? Surprisingly, there is very little research on this.

I took part in organising three such studies: we invited customers to a UX lab, observed them working with our products, interviewed them about the documentation, and gave them tasks to complete.

Using the example of our user documentation portal Sharx Base, we will share how we organised the documentation development process in our company with the help of MkDocs. What triggered the transition? What were the first steps? What does the work of a technical writer look like now? What challenges have we faced, and what are our plans for the future?  A real case from real life.

Not long ago, the documentation for VK WorkSpace products decided to migrate from one static site generator — MkDocs, to another — Hugo. I’d like to share my impressions and the hidden pitfalls we encountered. We’ll discuss which of these tools is better suited for Enterprise products, and which one works best for startups. We’ll also have a look at where a technical writer has more opportunities to develop both the portal and their personal skills.

And of course, we’ll play a round of bingo to compare the two generators and their technical capabilities.

In my talk, I'll share my personal burnout story: what led me to that state and how I recovered from it. I'll also present the results of my research on the causes of burnout among technical writers, along with advice on how to organize the documentation process in a way that's comfortable and prevents technical writers from burning out.

My talk is the story of the evolution of simple functionality into a powerful tool. I'll tell you how we developed a service for exporting web documentation to PDF, which replaced Pandoc.

You will learn not only about the technical implementation, but also about the path that we have followed: from a simple Python and Puppeteer solution to a high-performance Go service that uses the power of goroutine and ChromeDP to render dozens of pages in parallel.

We will discuss:

• Why HTML → PDF is the best way to get a document that perfectly matches a live website.
• Architectural solutions that allowed us to create a fault-tolerant and easily deployable service.
• Key reasons why our own service turned out to be better and more convenient than Pandoc.

Is it possible to align GOST-compliant documentation with the docs-as-code approach?

How can you keep an entire set of documents up-to-date at once?

Is it possible to stop worrying about document formatting?

We found answers to these and other questions while implementing documentation automation. 

In this talk, I will share how we:

• Solved the problem of document versioning.

• Automated the assembly and formatting of documents.

• Stopped duplicating the same information.

• Reduced the time required to prepare documentation while improving its quality.

For the past few years, we (documentat.io) have been actively studying the technical writing labor market: we conduct sociological research among technical writers and communicate extensively with companies that have a demand for documentation specialists.

Now I want to share my thoughts on how the structure of the labor market allows us to classify and rank employers offering technical writing jobs.

- Employers in the "below median" and "above median" zones: who are they and why do they pay differently?
- How the maturity of documentation processes determines a company's salary policy.
- What categories can all companies hiring technical writers be divided into, and why the career path of a competent technical writer almost certainly goes from a lower category to a higher one.

In a small team, it may seem that verbal agreements are enough and everyone knows what is happening. However, over time, even a small team faces increasing chaos: knowledge gets lost, mistakes are duplicated, and newcomers keep asking the same questions.

In the talk, I will show how simple instructions helped my team save time, mental health and resources. 

We’ll discuss:

• what documents are really necessary,

• how to motivate your teammates to write and use the documentation,

• what principles help introduce process documentation.

I'll share a real-life case study of onboarding, not only of a new employee joining an existing team, but also of a new team adapting to a new product. We'll explore practical cases with onboarding options and the specific challenges of each.

Standard cases: onboarding a new employee into a team, and onboarding a group of employees into a team.

Non-standard cases: onboarding a new team into a new product, and a new employee into a new team within new products. 

I'll share mistakes and offer my recommendations.

In this talk, I want to discuss the most difficult stage of the documentation process from my perspective: gathering information and preparing for writing documentation. 

Typically, when a documentation task is assigned, we receive a technical specification. I will explain how to quickly understand it and use the information from it for documentation: break it down into semantic blocks, understand the terms and transform the content so that it is suitable for the end user. 

Moreover, sometimes there are tasks with no technical specifications at all. I will describe where to look for the necessary information in such cases, and whom and how to ask the right questions.

The talk is intended for everyone involved in writing documentation, from beginners to experienced technical writers.

In this talk, we will explain how to create an IT glossary for a large project or a complex technology platform:

• We'll outline where to start and how to eliminate unnecessary debates over terminology.
• We'll show the glossary structure and discuss how to determine which words should become terms.
• We'll explain how to create an AI assistant that can simplify documentation development using the glossary.
  

Editors often face situations where a text needs to be reviewed under tight deadlines. Whether it’s documentation, a press release, a Telegram post or an internal digest — the type of content doesn’t matter if you have the right tool. For our team, the Iterative Editing Matrix has become exactly that tool, enabling us to work in a truly efficient way.

How to introduce KPIs for editors, which text metrics to track, and what reports to present to stakeholders? And how to ensure that spreadsheets don’t kill employees’ motivation?

The speaker observes an interesting paradox: service-oriented creative teams in large corporations are expected to deliver concrete business results using inherently non-measurable methods. And the high level of self-awareness and creative mindset typical of editors and designers makes centralised performance management particularly challenging.

This talk explores how to maintain a healthy balance between corporate and individual goals. It will feature specific approaches, personal experience, and practical advice for professionals in the creative industry — from team members to team leads and their managers.

In our team, documentation is closely tied to original solutions and non-standard processes: custom markup tags, proprietary HTML-components, examples written in an internal programming language. To simplify working with this stack, we developed a custom VS Code extension that has become an indispensable tool in our daily practice.

In this workshop, I will show the entire journey — from the initial idea to working code, share pitfalls of building an extension “from scratch”, and discuss key architectural decisions behind it. Together, we will go through the full cycle: from environment setup and the first launch to implementing features for rapid text editing, editor visual enhancements, working with templates and UI components. In the end, you will get a fully functional plugin that you can adapt to your needs, as well as the knowledge required to build your own plugin for your specific tasks.

In this talk, we will examine the key challenges involved in migrating documentation for large-scale projects to a new technical stack.

You will learn why this need arises and how to properly plan the transition process. We will discuss real-world case studies, both expected and unexpected challenges, as well as practical solutions and effective approaches.

By the end of the talk, you will receive actionable recommendations to help minimize risks and make documentation migration to a new technical stack more manageable and predictable.

How and why we switched from GitBook to Diplodoc for publishing documentation. How the transition went, how long it took, and how our infrastructure changed as a result. We'll share life hacks, failures, and outcomes: stability, content reuse, feedback, and Grafana to analyse documentation quality.

The documentation set for the same software product can vary significantly depending on business objectives: the composition of materials, the target audience, the depth of detail, the required level of relevance, and compliance with rules — such as GOST, industry regulations, regulatory requirements, and internal style guides. Also, different projects may apply their own criteria for assessing documentation quality: delivery time, formatting, completeness of content, relevance, and other parameters.

I'll show how defining the required quality level directly affects timelines and effort. We'll discuss which parameters should be prioritised, including:

• the need for strict compliance with GOST standards,

• requirements for illustrations and captions,

• the clickability of cross-references,
  and much more.

We'll also explore how the chosen level of quality influences not only the overall scope of work, but also the level of expertise required from the specialists involved in the project.

In this talk, we will explore:

• how a technical writer becomes a leader by shifting focus from writing to strategic vision and mentoring;

• why a leader takes responsibility for the team’s mistakes and uses them as opportunities to improve processes;

• classic management principles, which require adaptation to match the specific motivation of technical writers;

• effective delegation — why it is a tool for team growth rather than micromanagement;

• why the motivation of technical writers is based on the impact of their work with the product and the user;

• what true leadership is, and how it is expressed through actions and authority rather than a formal job title;

• how a technical writer’s career can evolve both towards deeper expertise and towards senior management roles.

The presentation will showcase practical experience in developing and implementing a solution for automating CLI command descriptions. I will outline key implementation stages and technologies used (scripts, RST templates, CI/CD integration, repository API).

Previously, documenting each new or modified CLI command required technical writers to manually gather information, write content, format it in RST, create a Merge Request (MR) in the documentation repository, and undergo subsequent reviews.

This process was labour-intensive and created a bottleneck.

We developed and implemented a system that automatically extracts data, generates structured files, automates the delivery of changes, and creates tasks for technical writers.

This experience will benefit teams seeking to optimise documentation processes through automation.

As part of this round-table discussion, we will explore why companies engage technical writing interns, what benefits internships offer to both parties, and which drawbacks and risks should be considered.

We will also examine different internship models and discuss whether internships should be paid.

When documenting any project, we inevitably encounter the same thoughts: “I'm doing redundant work,” “I can't keep up with new features,” “It's too early to document this,” or “It doesn't work like that in practice.” Sooner or later, the idea emerges to try to synchronise the documentation with the code so that it is generated automatically or, at the very least, checked for consistency. For documentation auto-generation to be genuinely effective, three aspects must be considered:

1. Technological approaches.
2. Principles of cross-functional collaboration: what constraints arise, and how to overcome them.
3. Criteria for evaluating the effectiveness of the resulting solution.

According to the Pareto principle, 80% of result is achieved with only 20% effort.

We analysed what takes up most of the remaining 80% of an editor's working time and found ways to reduce the time spent on routine tasks. To achieve this, we categorised tasks by type, developed a general algorithm for working with content, and created variations of this algorithm for different types of texts. We introduced “text masks” — a collection of templates for various content formats: applications, instructions, notifications, mailings, and even landing pages. 

All of this has enabled us to significantly reduce the time required to complete standard editorial tasks.

This talk explores how modern AI technologies can be used to automate the generation of user guides directly from Figma interface designs.

We will demonstrate how to extract structural and visual data via the Figma API, transform it into a convenient format, and then use multimodal models such as GPT-4o to generate meaningful, user-friendly documentation.

For thirty years, technical writers have had to prove the value of documentation to the business. Today, the future has arrived: content is created instantly, quality is improving, and translations are automated — often without the involvement of writers. Resources are now invested not in hiring authors, but in tools and in managing AI.

In this talk, we'll discuss how to transform this technological shift into career growth. You will learn how MCP turns AI into a full-fledged collaborator, who a context manager is and why knowledge architecture is valued more than writing itself, how to prevent hallucinations through proper data structuring, and how documentation can become a product diagnostics tool and a real lever for influencing UX.

This talk is not about the death of the profession, but about its reset. You will leave with a clear understanding of which tools to pick up and where to start as early as Monday.

This talk explores how the requirements of government regulators and public-sector customers impact product development and internal company processes. Submitting applications for inclusion in various government registers or obtaining mandatory approvals leads to significant product modifications: from changes in architecture and technology stack to enhanced security measures and integration with government services.

This talk will be useful for companies planning to enter the B2G market.

I will share my experience in a unique subject area for a tech writer as a Game Development (GameDev). It has its own traits: independent teams of artists and designers, a whole "zoo" of different developers. Due to the difference in the technical background, the target audience of the documentation is very different and it's very important to define technical things clearly in simple language. 

In this report:

• I'll tell you about the history of my recruiting: what the employer expected, what he faced and what he got in the end.
• I'll show you examples of the tasks that I had to solve.
• I'll give you the arguments for and against GameDev working so you can decide for yourself whether to join it as a technical writer.