Datadog is a monitoring company, and we excel at collecting discrete data about systems to make them better. However, collecting meaningful feedback from our technical documentation was a challenge. Getting feedback on whether your docs are helpful to users is difficult. Standard metrics like conversion (when there’s no checkout process) or time spent (longer sessions may indicate difficulty) don’t apply well to documentation.

In an effort to get better feedback, we implemented a documentation survey six years ago which allowed users to rank the content and include a screenshot of their issues, but it didn’t empower them to provide actionable feedback. Our documentation survey required deliberate intervention to refine its structure, incorporate additional logic, and benefit from a user researcher’s perspective to enhance the flow and ensure a seamless user experience.

Technical documentation should not be a barrier to understanding. No one (or at least we hope no one) has ever said “the documentation was thorough, but I wish it had been more bland and boring”. Instead, we wanted to open the floodgates, encourage users to provide meaningful feedback, and even feel empowered to contribute to our open source documentation repository.

In this session, I’ll share the journey of implementing a documentation survey and fixing it by dissecting the survey mechanism, enhancing feedback paths, updating our survey design, and integrating survey results with our data analytics platform.

Ever received vague review suggestions like “make this better” and thought “how?” Or received a prickly response to your review comments from an engineer/author and wondered “why?” Off-target or unintentionally insensitive comments can derail collaboration, especially between technical writers, developers, and non-writers.

When reviewing a colleague’s work, you want to improve the content while recognizing the author’s effort. On the flip side, as the author, you often need feedback from stakeholders who may not communicate effectively or even understand the writing process.

In this session, you’ll learn how to give precise, respectful feedback and how to ask for—and handle—constructive criticism. We’ll share practical tips for navigating feedback challenges from a diverse range of stakeholders like developers, product owners, authors, and anyone else who wants to stick their oar in.

This presentation is essential for anyone involved in document reviews. Drawing on thousands of reviews from The Good Docs Project’s technical writers, we provide actionable strategies for using tools like Google Docs, Word, LibreOffice, Pages, GitHub, and GitLab. We’ll cover one-person reviews and managing conflicting comments from multiple stakeholders.

Developers, writers, and docs-as-code practitioners alike will benefit from techniques that foster smoother collaboration and improve documentation quality. You’ll leave with practical, ready-to-use tips for feedback and communication that you can start using straight away.

It may not seem like journalism and writing adverts have much to do with each other, let alone with technical writing, but I’ve got a different perspective. I LOVE my job, which is writing documents for SaaS customers, including release notes, how-tos, and online learning materials, but it wasn’t a straightforward path to this point.

This presentation will cover how the lack of technical background can become your technical writing superpower, as long as you’re driven by both curiosity AND altruism.

I want to explain why translating developers’ explanations of software into “what’s that mean for me” for end users has a lot in common with writing a well-structured news story.

Some further enticing bullet points (because if you can’t get meta in this context, when can you?!):

• Specific writing techniques taught in journalism school that can become part of your technical writing skillset.
• Things journalism and advertisement copywriting definitely DON’T have in common with technical writing – and yet, what tips from these disciplines you might find useful. BONUS: How the above can help you identify and ‘correct’ a particular feature of many AI-written documents.
• What the research says about the link between emotions and understanding instructions.
• Uncovering the best motivation to be a better technical writer.

All the answers? Definitely not. But it's always a good thing to throw around some questions!

ChatGPT is everywhere now, and all us documentarians are presumably going to be first up against the wall when the AI revolution comes. So what if we just took the opportunity to get a large language model to write all our documentation for us, and we can sit back and enjoy all that spare time before we have to learn potato farming?

Lana and a small group of colleagues at Shippit decided to put generative AI to the test. We needed a bunch of developer documentation written last week, we had some basic docs that we thought would be a great starting point, and we had two days to work on whatever we liked. Generative AI was just the thing we needed to deliver results.

And results were delivered. Of sorts. This talk covers which LLMs we considered, what content we gave the tool, and what we didn't, the prompts we used to get results, and the results themselves. Lana will also discuss the benefits and drawbacks of this approach to documentation, and - if the demo gods are with us - throw in a live demo or two.

Organisations can be very heterogeneous in their naming conventions and in their naming needs. How do we go about developing naming guidelines in these cases? Different business units may be siloed and have strong standards and long-established conventions, and these standards often contradict.

A recent project at CSIRO developing IT naming guidelines has provided me with a template for any future such projects.

To succeed in getting buy-in for the adoption of naming guidelines from management and stakeholders, both the discovery process and the final deliverables must carefully balance factors such as:

• Prescriptive rules vs. loose guidance
• Overall consistency vs. necessary differences in approach between business units
• Grandfathering existing practice vs. starting fresh
• Meaningfulness and searchability vs. uniqueness (e.g. including IDs in names)
• Detailed guidance vs. quick reference value
• Addressing current project scope vs. later scalability to organisation-wide guidelines

The insights from this project are interesting because (at project kick-off) the organisation was an outlier in how disparate the approaches of different business units towards naming and categorising assets were (even within IT), and also how different their needs were.

We wanted to make our knowledge centres' content more digestible. While our current articles are available to be read, what about people who have difficulty reading or learning. We recognized the need for alternative methods of learning for those who struggle with reading, comprehension, or prefer visual learning.

It was time to make a change, so we invested in making short videos instead of the previous hour-long videos or re-purposed webinars. Now, people can snack video instead of eating a meal.

In this talk, I will cover the following:

• Reasons behind our approach with looking at how different generations learn and the importance of learning accessibility.
• Explore the video foundations, such as scripts, as it is still important to have written words.
• Look at the learner’s mental models and how bite-sized learning can be easily digested.
• Give an overview of the production process that you can implement.

And finally, it is showtime and we will watch 2 short videos.

Open Source thrives on the diversity of its global contributors, which has driven the creation of some of the most inclusive documentation practices in the industry. Yet, nearly 80% of the global tech community remains underrepresented and faces numerous inclusivity barriers, extending beyond just language. In this talk, we'll see how open-source documentarians have harnessed their diverse voices to craft documentation inclusive of all identities, including gender representations and multilingual accessibility. By the end of this talk, attendees will gain practical insights to implement these inclusive standards in their work, ensuring their documentation is welcoming and accessible to all.

This talk highlights a critical issue in the tech industry - THE LACK OF INCLUSIVITY. While this problem spans multiple sectors, we will focus specifically on documentation. We'll explore how language barriers, gender biases, and accessibility gaps have historically excluded many from fully engaging with technical content. We'll also look at how some of the most successful open-source communities, such as Kubernetes and the Linux Foundation, have faced inclusivity challenges before, how they have tackled them head-on, and what we can learn from their experiences.

Do you work with engineers who find it challenging to write technical documentation that is concise, simple, and understandable by the intended audience? Is documentation something that makes your team shudder, because they feel out of their depth, and like writing is not a skill they can master?

Brick Docs is a 1 hour fun learning activity using LEGO® bricks that technical writers can run with engineers who are responsible for writing internal documentation. It is a judgment-free way to learn essential writing skills, all while having fun with LEGO®!

We will take you through the activity and give you a set of instructions as well as a list of the LEGO® bricks that you need to run this workshop yourself.

See if you can be the first to guess what it is you are building!

Skills developed:

• Identifying problems in documentation and how to improve the writing, with a focus on writing to meet the needs of the user
• Practising collaboration skills
• Facilitating this workshop

Check out the Brick Docs Workshop page for more detail.

In this talk I will discuss with you what Developer Experience (DX) is and how it draws directly from User Experience (UX) guidelines and principles. It is beautiful and intuitive and a joy to experience, very much like excellent documentation.

As technical documentarians, you are also developer advocates. You advocate TO developers and FOR developers. You have the privilege of contributing directly to developers’ experience (DX), not only with your documentation but also with their experience and perception of the wider product, system or tool the documentation supports.

While we say in UX “Don’t Make me Think”, we in fact always think. When Daniel Kahneman talks about “Thinking Fast and Slow”, it is your users’ Thinking Fast system that shapes the developer experience of your product and its documentation.

What then, do Thinking Fast and Don’t Make me Think, have in common? And how do these connect with UX, DX and documentation?

Everything is changing so fast that predictions are beginning to sound like history lessons.

Once upon a time, jobs became redundant little by little. Switchboard operators were replaced by automated exchanges. Typists and assembly line workers disappeared. Now entire business models are on the brink of or in the midst of revolutionary change. New assembly lines with AI overseers and automated quality assurance. Software systems that write and review legal documents. Virtual researchers that schedule and conduct interviews, analyse the results and make design recommendations. News corporations that abandon old-style journalism in favour of prompted outputs from compliant bots. Content created by machines predicting what the content would be if humans were producing it.

Purveyors of AI systems try to reassure us (or themselves perhaps) that AI and humans will continue to work hand-in-(what?) marching towards a brighter future.

And all the while AI's environmental cost grows rapidly, perhaps exponentially.

Where should we position ourselves on these shifting sands? Will tech comms people disappear like the switchboard operators of old? Will there be a "Write the Docs" conference next year, in 5 years, in 10?

Without "skin in the game" Gerry is perhaps in a good position to offer a view from the sidelines of the maelstrom.