Всё для технического документирования
+7 (495) 001-00-42
Разработка технической документации
Курсы для технических писателей
Программное обеспечение

Адвокат пользователя: пользователи глупые… или нет

08.12.2016

Если кто-то не понял вашу инструкцию, значит он глуп? Или же причина в вас? Разберёмся вместе с Филом Девисом, техническим писателем с 20-летним стажем из Integral Development Corp., США.


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

— Дуглас Адамс, Последняя возможность увидеть

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

«Глупый», с другой стороны, это преднамеренное незнание. Глупость исключает обучение.

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

Глупость приходит во множестве обличий. Некоторые можно распознать:

  • Слепота к рискам
  • «Мы с приятелем были на прогулке. На знаке было написано: «Не входите. Скользкие скалы», и мой приятель обошёл знак, поскользнулся, упал и умер».
  • Честная слепота
  • «Я нашёл в документации комбинации клавиш, но не вижу комбинацию для этой конкретной операции. Лично я не вижу большой красной надписи «ВАЖНО» вверху этой страницы с комбинацией клавиш, которую ищу».
  • Гордость
  • «Я эксперт в этой области и использую такие продукты годами. Документация не скажет мне ничего, что я ещё не знаю».
  • Отвлечение внимания
  • «Я слишком занят, чтобы учиться использованию этого продукта, который является ключом к моему заработку или успеху моей организации».
  • Лень
  • «Мне не хочется тратить усилия на обучение этому критическому для выполнения миссии продукту каким-то другим способом, отличным от того, чтобы запустить и нажимать на кнопки».

Как мы можем остаться эффективными адвокатами пользователей перед лицом такой глупости?

Просто. Не будьте глупы в ответ.

Когда я только начинал работать писателем, почти все вопросы пользователей и жалобы, поступающие к нам, были глупыми. Мы закатывали глаза, скрежетали зубами и презрительно ворчали «RTFM» (читай чёртову документацию), потому что работали как демоны, мы документировали всё полностью, и мы знали, что проблему легко решить с помощью иллюстрации 14-9 на странице 452 руководства программиста. Тупые, ленивые пользователи! Такие моменты только подстёгивали меня работать больше и документировать всё более основательно.

Я обрабатывал мегабайты Javadoc. Я вручную делал HTML-системы помощи. Я вносил вклад во впечатляющие бумажные руководства, которые солидно хлопали, если их бросить на стол. Мы заставляли работать наши мозги под прессом дедлайнов и продуктовых планов, чтобы накрыть банкет гурманам контента. Мы были горды проделанной работой, и когда пользователи задавали вопросы, которые делали её банальной, когда даже не открывали книги, моя уязвлённая гордость скисала до обиды.

Теперь я лучше.

Как я мог делать всё так неправильно?

RTFM имеет корни в ранней, педагогической модели взаимоотношений пользователь/писатель/технология, разрабатываемой во время Второй мировой войны и Холодной войны под прессом военного времени, чтобы подготовить буквально армии пользователей к орудованию новым сложным вооружением и ответным мерам, изменённым совершенствующимися технологиями.

В этой модели пользователь (как солдат) ожидает обучение технологии и использование её. Писатель действует как посредник и переводчик, готовящий контент для потребления пользователем. Если писатель делает свою работу тщательно, пользователю нет пощады: RTFM.

Я не знал, что старая модель больше не применима.

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

Пользователи со слепотой к рискам

Проблемы с безопасностью лучше всего решаются при разработке, до того, как пользователи потерпят неудачу с продуктом, но писатели часто вынуждены работать с тем, что получают. Иногда риска нельзя избежать из-за природы продукта (например, походный маршрут к водопаду или приложения, дающие возможность пользователям иметь дело с десятками миллионов долларов при одной продаже). Пользователи могут очень плохо разбираться в том, что опасно. Это не делает из них тупиц. Это делает их людьми. Неважно, в чём причина: или их обычная активность — приземлённая (прогулки) и они не снаряжены, чтобы распознать риск в контексте (скользкие горы, падение с высоты и смерть), или же они регулярно производят опасные работы (торги на многие миллионы долларов) и у них растёт невосприимчивость к риску (финансовые потери).

Так что делают адвокаты пользователей? Страшные последствия должны быть понятными и недвусмысленно вводить пользователей в шоковое состояние из состояния самоуспокоенности. Например, придорожные знаки вдоль рек и водопадов Йосемити точно описывают эту дорогу, обычно безопасные действия здесь небезопасны: «Не входите в воду! Мощные невидимые потоки вынесут вас на водопад. Не подходите к скользким камням на границе воды. Если вы вылетите через порог водопада, то погибните». В некоторых расположениях знаки содержат имена, фотографии и даты жертв для каждого серьёзного случая.

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

Невидящие пользователи

Недавно один из моих пользователей, очевидно, ослеп. Я знаю этого пользователя. Она не глупая. Напротив, она умная и опытная. Она сверилась с документацией и нашла подходящий топик. Каким образом она пропустила эту большую, красную ВАЖНУЮ надпись?

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

Гордые и всё знающие пользователи

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

Отвлекающиеся и ленивые пользователи

Внимание ваших пользователей фрагментировано. Их время ограничено. Я, надеюсь, дал ясно понять: вы не сильно хороший адвокат для этих пользователей, если ваше решение — толстая инструкция. Я бы мог многое сказать о копании в этой инструкции и легко воспринимаемых грациозных вставках, ненавязчивых инструкциях, предупреждениях, а также советы по пользовательскому интерфейсу и использованию, но другие люди сказали больше по этой теме, чем у меня есть места здесь (Аврора Хэйли (Aurora Harley, @aurorararara) проводит хорошую работу здесь: https://www.nngroup.com/articles/mobile-instructional-overlay/).

Так что теперь неудачи пользователей больше не признак их глупости, но подтверждение того, что они люди и что продукт (включая документацию, конечно) потерпел неудачу. Вместо того, чтобы говорить «RTFM» в качестве лёгкого и бессильного отпущения наших грехов технических писателей, мы, наконец, начинаем допускать, что никто не читает чёртову инструкцию, потому что в чёртовой инструкции часто даже нет смысла.

Сделаю небольшое признание. Несмотря на моё хвастовство о направленных на пользователей инновациях и альтернативах в документации, я создаю множество традиционных инструкций в PDF. Когда я громко радовался о недавнем кросс-функциональном триумфе, совместно работая с моей командой поддержки, чтобы произвести рефакторинг 50 страниц плотного контента в 13 ориентированных на пользователей страниц, то хороший друг мило резюмировал основное отношение: «13 страниц, вероятно, всё ещё слишком много». Конечно, я поддерживаю репозитории единого источника. Я создаю билды всех видов справок и поддержки пользователей во множестве форматов для интеграции с различными технологиями, я также создаю билды тысяч страниц PDF-инструкций в парадигме книг. Почему я делаю это? Мои пользователи требуют их. Клиенты запрашивают их. Они стоят в условиях контрактов. Продажи, поддержка, служба технической поддержки просят их. Почему я должен перестать делать PDF? Почему я должен приводить в замешательство всех этих пользователей и их ожидания? Это было бы глупо.

Источник: Users’ Advocate: Users Are Stupid…Or Not

Тэги: , , , ,

< Вернуться к списку публикаций

Облако тегов