С инструкциями зачастую приходится разбираться в самый неподходящий момент — когда задача срочная, а техника или система неожиданно начинает работать не так, как нужно. Недавно я открыла руководство к новой стиральной машине. Казалось бы, подробный документ с техническими характеристиками, схемами и предупреждениями перед использованием. Но ответ на простой вопрос «как стирать одеяло?» пришлось поискать.
В ИТ-проектах ситуация удивительно похожа.
На этапе внедрения любой информационной системы почти всегда приходится готовить пользовательские инструкции. Чаще всего мы идем по привычному пути — даем общее представление, описываем возможности и ограничения системы, перечисляем разделы меню, объекты, кнопки, поля. Пошагово, со скриншотами. Получается структурированный и обстоятельный документ внушительного объема. Формально все сделано правильно. Но если честно — кто это читает?
Привет, Хабр! Я Наталья Белова, аналитик ELMA365 из департамента CRM&BPM в «КОРУС Консалтинг». В этой статье расскажу, как научиться создавать инструкции, которые будут открывать и помогут пользователям легче адаптироваться к изменениям в привычной системе работы.
Почему типовые инструкции не решают проблемы
Если отбросить формальности, их главные задачи — помочь человеку принять изменения, быстрее освоить новые механизмы, избежать типовых ошибок, снизить зависимость от команды поддержки и аналитиков после запуска.
Внедрение новой системы всегда меняет привычный способ работы. У каждого пользователя уже есть своё понимание процессов и «автопилот». Поэтому любые изменения, когда нужно перестроиться, разобраться и научиться чему-то новому, требуют усилий. Если инструкция в этот момент выглядит как техническое описание интерфейса, она вряд ли станет помощником в решении проблем.
Загвоздка в том, что на деле именно так они обычно и выглядят:
Пишутся «от системы» и повторяют структуру интерфейса;
Не учитывают различия между ролями пользователей;
Создаются людьми, которые слишком хорошо знают систему и уже не видят ее глазами новичка;
Перегружены деталями;
Не фокусируются на реальных сценариях использования;
Почти не объясняют, как именно изменится повседневная работа после внедрения.
В результате документ существует, но им никто не пользуется. Пользователю проще спросить коллегу, написать в проектный чат или сразу обратиться в поддержку, чем открывать многостраничное руководство и искать нужное решение.
В какой-то момент в голову пришла мысль, что, возможно, проблема не в пользователях, которые «не читают инструкции», а в нас, которые продолжают писать их не о задачах человека, а о структуре системы. Так стало понятно, что нужно строить руководства от задач пользователя и реальных сценариев его работы.
Наш первый инсайт: делать такие руководства непросто
Когда мы впервые решили строить инструкции от пользовательских сценариев, это оказалось неожиданно сложно. Казалось бы, что может быть проще, чем изменить структуру документа? Но на практике пришлось пересобрать собственное мышление.
Мы привыкли описывать систему: разделы, объекты, кнопки, поля.
Теперь нужно было описывать работу человека в системе: его задачи, решения, точки ответственности.
Важный вывод: пользователя надо готовить к любым изменениям в привычной логике действий. Этот шаг часто игнорируют и сразу переходят к «нажмите кнопку», — но именно он снимает основное сопротивление и снижает тревожность.
Его цель — помочь пользователю через пошаговые действия с объяснениями «зачем», «что изменится», «что останется прежним» психологически и организационно подготовиться к новой логике работы.
Поэтому в нашей методологии появился отдельный подготовительный этап. Дальше расскажу о нем подробнее.
Шаг 1. Определите цель внедрения системы
Она должна быть сформулирована языком бизнеса, а не проектной документации. Пользователю важно понимать, зачем вообще появилась новая система и какую проблему она решает лично для него:
❌ Внедрение системы класса X для автоматизации процессов Y.
✅ Внедрение новой системы, чтобы сократить время обработки заявок/ сделать процессы прозрачнее/ убрать дублирование данных/ исключить потерю информации.
Шаг 2. Покажите, что изменится в работе
Сфокусируйтесь не на абстрактных формулировках, а на том, как именно изменится повседневная работа сотрудника.
Например:
Появится единое рабочее пространство для всех участников проекта;
Статусы задач теперь будут отображаться онлайн;
Часть рутинных задач станет автоматизированной;
Некоторые поля станут обязательными к заполнению;
Необходимо будет фиксировать результаты в системе.
Затем свяжите эти изменения с практическими сценариями: «После согласования больше не придется отправлять письмо — система сама уведомит следующего участника».
Шаг 3. Обозначьте, что НЕ изменится
Этот пункт часто недооценивают, а зря.
Люди легче принимают изменения, когда понимают, что новая система не обесценивает их опыт, не отменяет роль и не забирает зону ответственности.
Отдельно подчеркните, что сохраняется:
Зона принятия решений остаётся за руководителем;
Ответственность за корректность данных остаётся за исполнителем;
Регламент согласования не меняется, меняется только инструмент.
Такие акценты помогут начать воспринимать нововведения как рабочий механизм, который поддерживает уже существующие процессы.
Шаг 4. Объясните, какие проблемы решаются и какой результат ожидается
Если пользователь видит в инструкции решение реальной проблемы, которая каждый день мешает ему работать, то у него начинает формироваться реальное доверие к инструкции.
Говорите на языке «рабочих болей»:
Больше не придется вручную собирать информацию из разных источников;
Исчезнут «потерянные» заявки;
Уменьшится количество ручных операций;
Снизится риск ошибок из-за человеческого фактора;
Процесс согласования ускорится в Х раз.
Шаг 5. Разделите зоны ответственности системы и человека
В век повсеместной автоматизации особенно важно проговаривать, что будет делать система, а что по-прежнему останется за пользователем. Раздел помогает выстроить корректные ожидания, снижает количество вопросов после запуска и снимает один из скрытых страхов внедрения: «Теперь все будет делать система, а моя роль обесценится?»
Зафиксируйте три блока:
Что система выполняет автоматически: присваивает номера, контролирует сроки, отправляет уведомления;
Какие действия остаются за пользователем;
Где требуется решение, проверка или экспертная оценка человека.
Когда понятны цели и роли, можно переходить к практическим сценариям. В них нужно показать конкретные действия пользователя в системе.
Шаг 6. Определите роли пользователей
Разделение ролей помогает сделать инструкцию точной и не перегружать сотрудника лишней информацией, которая не относится к его зоне ответственности.
Это может быть разделение на:
Бухгалтера
Менеджера
Оператора
Руководителя
Администратора.
Для каждой роли необходимо сформировать и описать набор задач и действий в системе, а затем оформить отдельным разделом инструкции. Так пользователю будет проще найти нужную информацию и применить ее в работе.
Шаг 7 . Сформируйте список сценариев
Пользователь мыслит своими задачами, а не разделами системы, поэтому сценарии нужно формировать, отталкиваясь от его целей.
❌Работа со справочником контрагентов
✅Создать карточку нового клиента / зарегистрировать заявку / согласовать договор / сформировать отчет
Проще всего собрать список сценариев, если разложить бизнес-процесс на шаги и описать, что делает каждая роль.
Шаг 8. Опишите сценарии через задачу и результат
Пользователю важно понимать не только «куда нажать», но и к какому результату приведут его действия.
Попробуйте придерживаться общей структуры описания сценариев:
Какая цель у сценария;
В каких случаях он используется;
Какие действия пользователю нужно сделать вне системы;
Какие действия нужно сделать в системе;
Что изменится после выполнения всех шагов.
Шаг 9. Добавьте контрольные точки
Они снижают количество ошибок и помогают самостоятельно проверить себя без обращения за помощью.
Что стоит указать:
На что обратить внимание при выполнении шагов;
Как проверить, что действия выполнены корректно;
Какие статусы или изменения должны появиться в системе.
Шаг 10. Опишите типовые ошибки
Это один из самых востребованных блоков любой инструкции, потому что чаще всего пользователь ищет не «как сделать что-то», а «почему все пошло не так и как это быстро исправить».
Что важно включить в раздел:
Какие ошибки возникают чаще всего;
К чему они приводят;
Как их исправить.
Шаг 11. Продумайте и опишите нестандартные ситуации
Инструкция становится действительно полезной, когда в том числе помогает разобраться с тем, что выходит за рамки стандартного сценария.
Например, это может быть описание действий в случае, если возникла проблема, потому что:
Ответственный исполнитель отсутствует;
Документ нужно изменить после отправки;
Данные внесены с ошибкой;
Процесс остановился на согласовании.
Шаг 12. Объясните, как фиксировать проблемы грамотно
Даже при наличии подробной инструкции часть вопросов всё равно потребует обращения за помощью. Важно сделать этот процесс понятным и быстрым, чтобы снизить нагрузку на поддержку и сделать взаимодействие с ИТ-командой эффективнее.
В алгоритме можно описать следующие шаги:
С чего начать поиск причины;
Какую информацию подготовить для технической поддержки;
Куда и в каком формате обращаться за помощью.
Чек-лист: как понять, что инструкция получилась рабочей?
Проверьте ее по критериям:
Есть вводная часть, описывающая цели изменений или внедрения новой системы.
Пользователь может быстро найти нужный сценарий.
Сценарии исходят от целей, задач, ролей пользователей и включают ожидаемые результаты.
Есть раздел по решению типовых ошибок.
Есть раздел с описанием действий в нестандартных ситуациях.
Инструкция отвечает на вопрос «что делать?», а не «как устроено?».
Такой подход требует больше усилий на старте по сравнению с классическим «опишем меню и кнопки», при этом не исключает и описание интерфейсной части: настройки профиля, поиск, фильтры, стандартные возможности системы. Он дополняет его и делает осмысленнее и удобнее для пользователя.
В итоге вы получаете реальный инструмент адаптации, который помогает сотрудникам перестроить повседневную работу.
