Перевод статьи Стива Колда «Technical Writing and Interaction Design«, опубликованной в 2004 году в «журнале» компании Cooper.

Сначала пара слов от переводчика

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

Об авторе

Стив Колд (Steve Calde) — управляющий директор в Cooper, где с 1998 года он работает над тем, чтобы сделать цифровой мир более безопасным для пользователей. Стив участвовал во множестве проектов в различных областях, таких как ирригация площадок для гольфа, онлайн-радио, управление ресурсами предприятия (ERM-системы), внутривенная подача лекарственных средств, телекоммуникации и т.д., и т.п. Стив также ведет в Cooper практикум по проектированию взаимодействия и курсы коммуникации. В прошлой жизни, перед тем, как попасть в Cooper, Стив работал техническим писателем в Rational systems и GW Associates (автоматизация производства полупроводников).

Разработка технической документации и проектирование взаимодействия

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

Технические писатели и проектирование взаимодействия

Когда я начинал свою карьеру технического писателя в 1992 году, проектирование взаимодействия еще не было самостоятельной дисциплиной в разработке программных продуктов. Моя роль в процессе разработки сводилась примерно к следующему: в самом начале разработки я, основываясь на неких довольно общих и весьма неопределенных требованиях, исходящих от менеджера продукта, должен был оценить время, необходимое для документирования. Несколько месяцев спустя разработка наконец выпускала первый внутренний релиз, который очень слабо напоминал исходные требования. После этого группа технической документации пересматривала наши оценки требуемого времени, и начиналась работа над документацией. Раз в неделю группа разработки выпускала очередной внутренний релиз, который мог напоминать предыдущий, а мог и нет, и цикл повторялся.
Будучи техническим писателем я чувствовал, что этот процесс предоставляет уникальную возможность — я был первым из людей, не вовлеченных непосредственно в разработку, который видел и мог поработать с продуктом до его выпуска. Поскольку моя работа заключается в посредничестве, в установлении контакта между продуктом и пользователем, мне приходилось думать о продуктах критически, с точки зрения пользователя. Мне всегда нравились сложности, неизбежные при документировании сложных взаимодействий. Это было довольно интересно — превращать невразумительные сами по себе взаимодействия в ясное и гармоничное повествования из текста, диаграмм, скриншотов и разнообразных пояснений. Однако скоро я сообразил, что поступаю отнюдь не самым эффективным образом:  не было бы лучше улучшить взаимодействие вместо того, чтобы тратить время на создание документации, которая должна покрывать его недостатки?

История повторяется

Мои первые попытки поучаствовать в разработке продукта не были особенно удачными. Однажды на довольно поздней стадии цикла разработки одного продукта я заметил на панели инструментов бросающийся в глаза желтый треугольник. На этом месте никогда не было желтого треугольника, и он точно не упоминался ни в одном из виденных мной документов с исходными требованиями. Клики по нему ни к чему не приводили, так что прояснения здесь ждать не приходилось. Я спросил о нем у других технических писателей, у менеджера продукта, некоторых разработчиков, но никто не знал, для чего же нужен этот желтый треугольник. В конце концов я нашел программиста, который его создал.
– Итак, для чего же нужен этот желтый треугольник? — спросил я, держа ручку наготове над своим блокнотом.
– А, это кнопка просмотра истории.
“Конечно же, это кнопка просмотра истории”, — подразумевалось в ответе.
– Но когда я кликаю по ней, ничего не происходит.
– Это потому, что ты еще не сделал ничего, что было бы записано в буфер.
Я решил, что вопрос: “Так почему же я могу нажать кнопку, если за ней ничего нет?” не поможет, и попробовал зайти с другой стороны: “Окей, так почему же именно желтый треугольник?”
Разработчик не только не ответил на вопрос, но был просто расстроен тем, что я спрашиваю об уже решенных вопросах. Из-за постоянных изменений требований у него оставалось еще столько несделанной работы, что внесение изменений в уже выполненную работу было последней вещью, которую он стал бы делать.
По мере накопления опыта, я освоил несколько стратегий для того, чтобы избавляться от желтых треугольников, которые неизменно появлялись в каждом новом продукте. Я не был проектировщиком взаимодействия, но выполнял некоторые из их обязанностей, хотя и скрытно. Кто заподозрил бы, что технический писатель, этот парень с приятными манерами, вовлечен в определение требований и проектирование продукта? Я поделюсь несколькими стратегиями, которые позволят вам, как техническим писателям, сделать ваши продукты лучше, не задевая при этом чувств разработчиков.

Будьте на стороне пользователя

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

Участвуйте в проектировании

Безусловно, обнаружение проблем на этапе внутреннего релиза довольно-таки поздновато, и внесение изменений на этом этапе требует значительного изменения планов и сроков. Лучше было бы с самого начала проектировать продукт с большей ясностью. Но как это делать без специально выделенных ресурсов?
В отсутствие специальной группы проектирования, иногда даже простое увеличение осведомленности, выделении времени для проектирования и для предварительного определения ясных и стабильных  требований, может иметь большое значение.
Знакома ли вам следующая ситуация? Отдел маркетинга предоставляет список неопределенных высокоуровневых требований, но суть этих требований остается незадокументированной. Затем отдел разработки пытается создать продукт на основе этого списка, но им не хватает информации о контексте и других деталей для правильных решений. Когда люди из маркетинга видят готовый продукт, он совершенно не соответствует их представлениям, и приходится перекраивать и переделывать готовый продукт, чтобы он пришел в соответствие с первоначальными представлениями.
Так что же в этой ситуации может сделать угнетенный и притесняемый технический писатель, чем он может помочь? Конечно же, тем, что вам и так хорошо удается — ясностью изложения идей, организованностью и вниманием к деталям.

Заставьте приглашать вас на встречи по обсуждению требований

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

Заведите хорошие отношения с разработчиками и заинтересованным лицами со сторны маркетинга

Разработчики привыкли обжигаться на требованиях, изменяющихся в конце процесса разработки, и могут с подозрением и настороженностью отнестись к какому-то техническому писателю, обсуждающему с ними проектирование взаимодействия. Поэтому встретьтесь с разработчиками на ранних стадиях разработки. Обсудите с ними неудачный опыт, вспомните случай, когда вы тоже пострадали из-за изменяющихся требований, и помогите им понять, что вы хотите помочь избежать подобной вещи в вашем общем проекте. В ответ вы получите информацию от первоисточника о том, что на самом деле разрабатывается, и может быть заметите тревожные сигналы о том, что каким-то важным аспектам продукта не хватает внимания из-за того, что разработчики работают в спешке, пытаясь соблюсти сроки. Как человек, ответственный за описание продукта для пользователей, вы сможете лучше оценить приоритеты в том, что действительно важно для пользователей. Поделитесь этой информацией с командой по разработке продукта, и оцените, в чем продукт не удовлетворяет ключевым потребностям пользователей.
Я заметил, что лучший способ заслужить доверие разработчиков — это задавать много вопросов. Не пытайтесь произвести впечатление рассуждениями о том, как должен разрабатываться продукт. Задавая умные вопросы, вы создадите атмосферу диалога между коллегами, вместо того, чтобы просто выставить себя еще одним «экспертом», советующим разработчику, что делать.
Подобным же образом уделите время и заинтересованными лицам от маркетинга, вовлеченными в создание продукта. В структуре компании технические писатели часто являются частью производственных подразделений, и контакт с отделом маркетинга может быть возможен только при посредничестве менеджера продукта.
Однако понимание маркетинговых перспектив тоже очень важно. Лучший способ прояснить все вопросы — это организация личных встреч с нужными представителями разработки и маркетинга, участвующими в вашем проекте. Установление хороших отношений вызовет доверие к вам и упростит общение. Это позволит вам высказывать свое мнение о требованиях к продукту на ранних стадиях процесса. Кроме того, вы сможете получать необходимую информацию о том, что должно быть отражено в пользовательской документации, причем в таких деталях, которые вы не смогли бы найти даже в функциональных спецификациях и других проектных документах.

Документируйте плохие взаимодействия

Потратьте время на документирование исключительно неудобных взаимодействий и поделитесь записями с людьми из разработки и маркетинга. Если для описания того, что должно быть простым или стандартным интерфейсом, требуется несколько страниц текста, диаграмм и схем, это может послужить хорошей иллюстрацией серьезных проблем со взаимодействием, ожидающих пользователей. Покажите этот документ и другим членам команды, дайте им понять сложность работы с продуктом. Я уверен, что вы способны описывать и “плохие” взаимодействия, но такие описания не очень помогут пользователям, и вряд ли хорошая документация к неудобному в использованию продукту сделает их счастливее. Это особенно важно для типичных пользовательских задач, которые требуют выполнения множества отдельных взаимодействий — технических, или элементарных, операций. В спецификациях продукта описания этих взаимодействий обычно изолированы, и ни одно из них в отдельности не выглядит ни сложным, ни утомительным. Документирование же задачи в целом производится с обычной точки зрения пользователя и повторяет то, что пользователь действительно должен выполнить.

Создавайте персонажей

Персонажи — это модели пользователей, основанные на исследованиях, состоящих в первую очередь из интервьюирования пользователей и наблюдения за ними. Персонажи — это мощный и эффективный инструмент для определения требований к продукту и избегания поклонения излишним функциональным возможностям. Это также полезный инструмент и для технических писателей при планировании, определении приоритетов и написании пользовательской документации.
Создание персонажей — отнюдь не тривиальная задача, и она заслуживает отдельного обсуждения. Если вам интересна эта тема, на http://www.cooper.com/insights/journal_of_design/articles/personas/ можно найти подборку статей о персонажах.^*

И в заключение

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

Вместо послесловия

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