Technical Writer — стейкхолдер, с которым большинству из вас не придется сталкиваться, но если вы работаете в крупной конторе с техническим продуктом, то у вас, скорее всего, есть TW или даже целая команда писателей.

Их обязанности:

1. Написание документации для технических пользователей (представляем себе публичную документацию для AWS Lambda или Google Kubernetes Engine).
2. Написание текста, который видит пользователь системы. Названия кнопок, заголовки страниц, сообщения об ошибках/успешном выполнении задач/предупреждения. TW также участвуют в наименовании методов в API, полей в ответах (в JSON), ошибок и т.д.

Почему для этого отдельная роль?

В больших экосистемах, таких как AWS, к написанию текста нужно подходить системно, чтобы сотня продуктов ощущалась как один продукт, а не 100 продуктов, созданных сотней команд и тысячами разработчиков.

Как у дизайнеров есть дизайн системы, у технических писателей есть свои правила тона, глоссарий терминов, требования к оформлению и т.п.

Люди, с которыми я работал, были весьма интересными экземплярами. Я бы сказал, что они были как книжные черви, которым нравились компьютеры. Это люди, которые будут сидеть выверять мельчайшие детали и получать от этого удовлетворение.

К сожалению, часто команды разработки недооценивают важность текста в интерфейсах и API и пишут текст как попало. Эффект такой же как от дизайна, созданного разработчиками. Идет оптимизация под локальный максимум, в то время как отдельный тех писатель, являющийся частью команды писателей, оптимизирует под глобальный максимум.