Документация к ПО для бизнеса: как написать инструкцию интуитивного интерфейса

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

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

А теперь вообразите на минуту дверную ручку, которая поставляется с руководством пользователя: брошюра на десять страниц, где подробно описано, что угол поворота не должен превышать тридцати двух градусов, направление усилия – строго по часовой стрелке, предварительно убедитесь, что дверь не заблокирована с обратной стороны, в случае затруднений обратитесь к разделу 14.2.

Скорее всего, вы испытаете не благодарность за заботу, а раздражение пополам с недоверием. Если предмет настолько сложен, что требует десяти страниц пояснений, значит, с ним что-то фундаментально не так. Значит, его создатели не справились с главной задачей – сделать вещь понятной без слов.

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

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

Всё начинается с маленького, почти незаметного компромисса: на этапе тестирования выясняется, что два человека по-разному поняли одну и ту же кнопку. Один решил, что она сохраняет черновик, другой – что отправляет документ на согласование. Это нормальная рабочая ситуация, и правильная реакция на нее известна: сделать название кнопки точнее, сменить цвет, перенести в другое место, добавить иконку, которая снимает неоднозначность.

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

В этот момент интерфейс делает первый шаг к своему упадку, потому что одно пояснение имеет свойство плодить другие. Через месяц рядом с первой строчкой появляется вторая, еще через месяц – иконка с вопросительным знаком, ведущая на страницу документации.

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

Парадокс в том, что документация, задуманная как помощь, становится оправданием для отказа от настоящей работы над удобством. Заказчик, который платит за разработку, часто не замечает подмены: ему кажется, что раз система сопровождается подробными руководствами, значит, о пользователе позаботились.

На деле произошло обратное: о пользователе перестали думать на этапе проектирования, переложив эту заботу на авторов инструкций. А пользователь, столкнувшись с экраном, на котором больше текста, чем смысла, чувствует то же самое, что почувствовал бы человек перед дверной ручкой с десятистраничной брошюрой.

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

Почему подробная документация убивает ваш продукт?

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

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

Шаг первый: проектировщик сталкивается с неоднозначностью

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

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

Это нормальная, более того – неизбежная часть проектирования. Интерфейс никогда не получается идеальным с первой попытки, и задача тестирования как раз в том, чтобы найти такие точки непонимания и устранить их. Типичных сигналов того, что интерфейс требует доработки, много:

• Один и тот же элемент интерпретируется разными пользователями по-разному.
• Пользователь пропускает важный шаг, потому что не заметил нужный элемент.
• Пользователь совершает действие и удивляется результату — он ожидал другого.
• На вопрос «Что вы сейчас сделали?» пользователь отвечает не то, что задумывал проектировщик.

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

Шаг второй: возникает соблазн быстрого решения

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

В этот напряженный момент кто-то – аналитик, разработчик, менеджер – произносит слова, которые звучат как спасение: «Давайте просто добавим пояснение».

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

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

Шаг третий: быстрые решения накапливаются

У пояснений есть коварное свойство: они размножаются. Если один текст решил проблему на одном экране, почему бы не применить тот же подход на другом? Через месяц рядом с первым пояснением появляется второе, через два месяца – третье.

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

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

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

Интерфейс перестает быть интерфейсом в изначальном смысле этого слова. Он превращается в текст, упакованный в визуальную оболочку. Пользователь смотрит не на кнопки и поля – он читает, как на веб-странице, только эта страница притворяется рабочим инструментом.

Шаг четвертый: документация становится частью продукта

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

Возникает новая норма, которую никто не формулирует вслух, но которая отныне управляет всеми решениями: «Если что-то непонятно – допишем инструкцию».

Последствия этой нормы хорошо видны по тому, как меняется рабочий процесс команды:

• На обсуждениях интерфейсных решений всё реже звучит вопрос «Как сделать это понятным?» и всё чаще – «Где мы это объясним?».
• Дизайнер тратит время не на поиск визуального решения, а на верстку текстовых блоков.
• Тестирование проверяет не «понятно ли без слов», а «есть ли пояснение на каждое возможное недопонимание».
• В бюджет закладываются часы на написание документации, но не на улучшение интерфейса.
• База знаний растет, а удобство падает – и эти две линии идут в противоположных направлениях.

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

Разорвать этот круг со временем становится всё труднее, потому что документация сама становится активом, в который вложено много сил, и выбросить ее жалко, и переделать интерфейс означает переписать сотни страниц инструкций, а на это уже нет ресурсов.

Что происходит с пользователем? Пока команда пишет пояснения, он живет своей жизнью: открывает систему не для того, чтобы читать, а чтобы сделать задачу. У него есть цель, и он хочет достичь ее как можно быстрее. Документация для него – не помощь, а препятствие, которое нужно преодолеть или обойти:

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

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

Конечный результат – продукт, который не умеет разговаривать с пользователем на визуальном языке. Бизнес платит за разработку этого текста, за его поддержку, за обучение сотрудников, за службу поддержки, которая пересказывает текст своими словами.

Цена многотомной инструкции

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

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

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

Если умножить эти потери на количество новых сотрудников в год, получается сумма, сопоставимая с фондом оплаты труда нескольких человек.

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

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

Третья статья – затраты на службу поддержки, которая превращается в живой интерфейс. Операторы целыми днями отвечают на вопросы, ответы на которые уже есть в базе знаний, но пользователи туда не идут – им проще позвонить.

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

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

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

Наконец, у проблемы есть свойство к самовоспроизводству. В документацию вложены сотни часов работы, по ней обучены десятки сотрудников, и любое изменение интерфейса означает, что инструкции придется переписывать, а людей – переучивать.

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

Принципы написания документации в связке с интуитивным проектированием

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

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

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

Тестирование молчанием

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

Если человек справляется – интерфейс работает, если застревает – нужно смотреть, в каком именно месте, и переделывать не инструкцию, а само место застревания.

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

Признаки того, что интерфейс прошел тестирование молчанием:

• Пользователь ни разу не замер в нерешительности, глядя на экран.
• Он не произнес фраз вроде «а что здесь надо сделать?» или «куда тут нажимать?».
• Он выполнил задачу быстрее, чем вы ожидали.
• На вопрос «Почему вы нажали именно сюда?» он отвечает что-то вроде «ну это же очевидно».

Признаки того, что интерфейс провалил тестирование:

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

Текст как последнее средство

Текстовая подсказка в интерфейсе – это не преступление и не запрещенный прием, но она должна применяться только после того, как все остальные способы сделать экран понятным исчерпаны. Последовательность, которую стоит держать в голове при проектировании, выглядит так:

• Сначала – правильное название. Слова на кнопке или рядом с полем должны быть подобраны так, чтобы два разных человека поняли их одинаково. Если в компании принято говорить «контрагент», а на экране написано «субъект учета», пользователь споткнется гарантированно.
• Затем – правильное расположение. Человек сканирует экран по определенным шаблонам, которые изучаются десятилетиями: если важная кнопка задвинута в угол, а второстепенная информация вынесена в центр, пользователь будет нажимать не туда не потому, что он невнимателен, а потому что ему дали неверный визуальный сигнал.
• Затем – правильный визуальный акцент. Кнопка главного действия должна выглядеть как главная: цвет, размер, положение – всё должно кричать «нажми сюда». Кнопка второстепенного действия должна выглядеть скромнее.
• Затем – короткая подсказка. Только теперь, когда название точное, расположение логичное, акценты расставлены, но тестирование всё еще показывает неоднозначность, можно добавить текст. И это должна быть не простыня, а короткая фраза, которая снимает конкретное сомнение.
• И только затем – ссылка на документацию. Да, у продукта может быть полноценная справочная система, но она нужна для углубленного использования, а не для выживания. Если пользователь вынужден открывать ее, чтобы выполнить базовую операцию, – интерфейс провалился на одном из предыдущих шагов.

Документация для углубленного использования, а не для выживания

У хорошего продукта тоже есть документация. Но она устроена иначе, чем у продукта, который пытается текстом закрыть дыры в интерфейсе. Разница примерно как между кулинарной книгой для опытного повара и инструкцией к микроволновке, которая объясняет, что в нее нельзя класть кота.

Документация к интуитивному продукту описывает то, что пользователь, скорее всего, не будет делать каждый день: настройку интеграций, сложные отчеты, нестандартные сценарии, пограничные случаи. Она не нужна для того, чтобы создать заявку, найти клиента или отправить письмо. Эти вещи должны быть понятны без чтения.

Признаки того, что документация выполняет правильную роль:

• Базовые операции выполняются новичком без открытия инструкции.
• Документация открывается только тогда, когда пользователь хочет сделать что-то нетипичное.
• Служба поддержки отвечает на вопросы, которых действительно нет в интерфейсе, а не пересказывает то, что написано на экране.
• При обновлении системы документация правится в части сложных сценариев, а не базовых операций.

Признаки того, что документация подменяет собой интерфейс:

• Каждый новый сотрудник проходит обязательное обучение, на котором ему показывают, как пользоваться системой.
• Служба поддержки половину времени отвечает на вопросы, ответы на которые есть на экране.
• Если из системы убрать все подсказки и справочные материалы, пользователь не сможет выполнить базовую операцию.
• Документация растет быстрее, чем функциональность, – добавляется одна новая кнопка, а инструкций к ней пишется на три страницы.

Единый язык по всей системе

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

В одном месте системы используется слово «проект», в другом – «сделка», и оба обозначают одно и то же. Пользователь, привыкший к одному названию, не узнает его в другом разделе и думает, что речь идет о чем-то новом.

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

Если где-то в интерфейсе появляется новый термин, которого нет в глоссарии, это должно быть поводом для вопроса, а не для автоматического принятия. Что должно быть в глоссарии:

• Все ключевые объекты системы: клиент, заявка, сделка, счет, договор и так далее.
• Все ключевые действия: создать, согласовать, отправить, подтвердить, отклонить.
• Все статусы и их точные значения: чем «в работе» отличается от «на согласовании» и может ли объект находиться в обоих статусах одновременно.
• Запрещенные синонимы: если договорились говорить «клиент», то слово «заказчик» не используется нигде, даже если кому-то из разработчиков оно кажется более привычным.

Вопросы на старте, которые всё меняют

Даже самые правильные принципы останутся абстракцией, если не встроить их в процесс обсуждения на самом раннем этапе. Чтобы заложить здоровый подход к интерфейсу, заказчику достаточно задать команде несколько вопросов – не про технологии, не про архитектуру, а про пользователя и его опыт:

• Если убрать с экрана все всплывающие подсказки, пользователь всё еще сможет выполнить основную задачу?
• Сколько времени потребуется новому сотруднику, чтобы начать работать без обучения, и устраивает ли эта цифра бизнес?
• Какие ошибки пользователи совершают чаще всего при тестировании, и можно ли предотвратить их изменением интерфейса, а не предупреждающим текстом?
• Есть ли в системе места, где одно и то же понятие называется разными словами?
• Если через год документация устареет и ее никто не обновит, пользователи смогут работать дальше или всё встанет?

Культура переделки вместо культуры пояснений

Речь идет о том, как команда реагирует на проблемы, обнаруженные при тестировании. В культуре пояснений реакция такая: «Пользователь не понял кнопку – надо дописать пояснение». В культуре переделки реакция другая: «Пользователь не понял кнопку — надо переделать кнопку».

Смена этой установки не происходит по приказу. Она выращивается через несколько повторяющихся действий:

• Каждый раз, когда кто-то предлагает добавить пояснение, задается вопрос: «А что нужно изменить в самом интерфейсе, чтобы пояснение не понадобилось?»
• Тестирование планируется так, чтобы на него было выделено достаточно времени, и результаты тестирования воспринимаются не как придирки, а как руководство к действию.
• Сроки изначально закладываются с учетом итераций на доработку интерфейса, а не с расчетом на то, что всё получится идеально с первого раза.
• Заказчик понимает, что неделя, потраченная на переделку экрана до запуска, сэкономит месяцы мучений пользователей и годы оплаты лишней поддержки после запуска.

Разработка ПО от 66 Бит

Всего за 10 минут вы овладели секретами написания комфортной документации, самое время разработать тот самый интуитивно понятный продукт. А поможет вам в этом команда 66 Бит!

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