Типичный пользователь технической связи торопится и находится в плохом настроении. Они работали вместе, пытаясь сделать работу, чтобы они могли пойти домой и поужинать с детьми, потом что-то сломалось или отказалось работать так, как они думали, или часть не работала должным образом, или ошибка вышла из нигде, либо вся система перестала работать и повалил сизый дым.

Они не в настроении для шуток.

Мы должны думать о техническом общении как о пит-стопе. Настало время дать пользователю то, что ему нужно, чтобы продолжать работу максимально эффективно и с минимальными драмами. В пит-стопе нет времени рассказывать тому про дантиста и дочь фермера.

Именно поэтому юмора в большинстве технических коммуникаций нет и быть не должно.

Юмор в учебных материалах — это другое дело. Некоторым это нравится. Некоторые презирают это. Если вы продаете книгу для чайников, вы можете обратиться только к тем, кому она нравится, и позволить людям, которые не покупают книгу О'Рейли. Но если это ваше корпоративное обучение, вы, наверное, не хотите отключать половину своей аудитории.

В Руководстве Microsoft по стилю это хорошо сказано:

Не пытайтесь быть забавным. Шутки, сленг и сарказм зависят от контекста, и их трудно перевести и локализовать. То, что кажется вам забавным, может оскорбить или оттолкнуть часть вашей аудитории, поэтому лучше избегать таких риторических подходов.

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

Юмор подразумевает интимность и небрежность, которые обычно не подходят для технических коммуникаций. Будь то напряженная ситуация с исправлением ошибки или что-то сломалось у меня, как описывает Марк Бейкер , учебный документ, используемый в деловой или профессиональной среде, или что-то еще, в большинстве случаев просто неуместно предполагать определенный уровень знакомства. с читателем.

Кроме того: что, если они сочтут шутку ужасной? (Или, что еще хуже, оскорбительно?) У вас гораздо больше шансов потерять благосклонность читателя, которому не нравится юмор, чем завоевать расположение читателя, которому он нравится.

В большинстве случаев юмор просто мешает.

Общее правило в техническом общении — избегать юмора, и я думаю, что основными моментами для рассмотрения являются: аудитория, контекст и локализация — если вы вообще это рассматриваете.

Говоря конкретно о проблеме локализации, перевод идиоматического языка является важным фактором, но еще одна важная проблема — это культурная интерпретация вашего юмора.

Я увидел интересную презентацию на LavaCon в прошлом году, где Джон Энн Линдси, контент-стратег из Google, рассказал о своих собственных попытках и исследованиях в этой области.

В синопсисе: Google поощряет своих сотрудников «гуглить», и они провели большое тематическое исследование, в котором у них были фокус-группы примерно из 40 разных стран, чтобы просмотреть их документацию, и на самом деле кто-то лично сел с этими группами, чтобы получить обратную связь. Они обнаружили, что даже самые незначительные юмористические отсылки (например, изображение симпатичного пингвина из их библиотеки изображений, которое использовалось в их документации о том же самом) плохо восприняли во многих регионах. Отчасти это было незнакомо, потому что люди из некоторых стран, возможно, никогда не видели пингвина. Другие сочли это просто бесящим и неуместным, когда кто-то пытается вставить «юмор» или «милое» там, где они пытаются получить техническую информацию.

Мой главный вывод из этого был: знай свою аудиторию. Если вы локализуете контент, это еще более сложно и обязательно. К сожалению, у многих из нас нет тех же ресурсов, что и у Google, для проведения такого рода исследований в глобальном масштабе, поэтому, вероятно, лучше оставаться в сфере резки и сухости.

Это зависит от аудитории

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

Вот пример, когда я переборщил с легкомыслием, и это было хорошо воспринято. Для отчета по физике мы с напарником решили использовать тезаурус для каждого слова, которое только могли, не меняя значения, заменяя общеупотребительные слова их наиболее неясными и запутанными синонимами. Отчет представляет собой самую нелепую и чрезмерную болтовню, которую я когда-либо писал, но технически она верна. Мы получили полные оценки и пощечину за «щечку».

В другой раз, когда я писал свой отчет о проекте за последний год, я работал над разделом «почему этот проект». Проект был о системе посадки с визуальным управлением для автономных дронов, и мы подумали, что было бы уместно указать главную причину, поскольку «дроны — это круто». Это не понравилось, мы потеряли оценки за «непрофессионализм».

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

Недавно мне пришлось наблюдать за внедрением заказной ИТ-системы в промышленной среде. Несколько шуток в руководстве были хорошо восприняты во время обучения. Они были похожи на использование имени известного компьютерно-неграмотного человека для иллюстрации входа в систему или перечисления примеров приказов, которые невозможно выполнить по неочевидным причинам.

Однако в этом примере: 1) юмор был совершенно не связан с техническим сообщением, на него не тратились слова, 2) он был тонким до невозможности отрицать, 3) он был специфичен для аудитории - давал им почувствовать себя умными для получение справок.

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