Привет, коллеги. Меня зовут Александр Попов, я представляю группу продуктовых дизайнеров и UX‑исследователей группы компаний «Цифра».

Сегодня поговорим о теме, которая заставляет многих из нас чесать в затылке, — как измерить удовлетворенность пользователей в суровом мире enterprise‑продуктов? В том самом, где пользователи ваш продукт не выбирают, а получают его «в нагрузку» к своей работе. Это как со школьной формой: носить надо, нравится или нет — вопрос десятый. Но если форма жмет, трет и расползается по швам, учеба превращается в пытку.

Человек — существо адаптивное, поэтому пользователи b2b и enterprise‑систем научились находить красоту в самых неожиданных местах интерфейсов. У них нет возможности сменить рабочую среду, и они вырабатывают удивительные адаптационные механизмы.

Пользователи создают обходные пути, используют дополнительные инструменты (Привет, Excel!), разрабатывают неофициальные гайды и даже создают «теневые» процессы и альтернативные сценарии. Если система неудобна, пользователи эволюционируют: появляются локальные «гуру системы», которые знают все секретные трюки, обходящие проблемные этапы. Эти компенсационные механизмы — золотая жила для UX‑исследователя. Они подсвечивают реальные потребности пользователей и болевые точки системы лучше любых интервью

Проблема традиционных метрик в Enterprise‑среде

Мы привыкли оперировать красивыми и понятными метриками: Net Promoter Score, Retention Rate, Engagement. Клиент в восторге? Порекомендует нас друзьям! Пользуется нашим приложением каждый день? Отлично, мы его увлекли! Но что делать, если ваш пользователь — мастер участка Сергей Петрович, который обязан работать в вашей MES‑системе по приказу руководства?

NPS? Он бы с удовольствием порекомендовал бы сжечь ваш сервер, но у него нет выбора.

Retention? Он никуда не денется, пока не уволится.

Engagement? Сергей Петрович проводит в интерфейсах вашего продукта по 8 часов в день не потому, что это классно и ему весело, а потому что это его работа.

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

Специфика пользователей

Чтобы понять, как измерять их «счастье», нужно понять, кто они. У таких пользователей есть несколько ключевых особенностей:

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

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

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

• Как я уже писал выше, люди — существа изобретательные. Если система неудобна — они найдут обходные пути. Будут вести параллельный учет в Excel, записывать пароли на стикерах и использовать Telegram или Whatsapp для обмена файлами. И это не их вина, а наша недоработка.

Особенности измерения UX в промышленных MES-системах

MES‑системы (Manufacturing Execution Systems) работают в особенно жестких условиях. Здесь ошибка интерфейса может стоить не только времени, но и безопасности производства, персонала и окружающей среды. Операторы работают в условиях стресса, часто при высоких температурах, шуме, недостаточном освещении и в защитном снаряжении, что дополнительно усложняет взаимодействие с системой.

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

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

CASTLE как альтернатива HEART

Для оценки пользовательского опыта в b2c продуктах часто используют фреймворк HEART от Google (Happiness, Engagement, Adoption, Retention, Task Success). Но для enterprise‑мира он подходит слабо. К счастью, у нас есть свой замок! Nielsen Norman Group предложила альтернативу — CASTLE

CASTLE — это акроним, который идеально описывает, на чем нужно сфокусироваться в сложных корпоративных продуктах:

• Cognitive Load: когнитивная нагрузка. Сколько умственных усилий пользователь тратит на выполнение задачи? Ему нужно держать в голове кучу информации или интерфейс интуитивно понятен?

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

• Satisfaction: удовлетворенность. Да, она все еще важна, но измерять ее нужно иначе. Не «Нравится ли вам продукт?», а «Помогает ли продукт решать ваши рабочие задачи?».

• Task Efficiency: эффективность выполнения задач. Как быстро и успешно пользователи справляются со своими рабочими обязанностями с помощью системы?

• Learnability: обучаемость. Насколько легко новым сотрудникам освоить систему? Сколько времени уходит на обучение и как часто им нужна помощь?

• Errors: ошибки. Как часто пользователи совершают ошибки, насколько эти ошибки критичны и как легко их исправить?

То есть CASTLE смещает фокус с эфемерной «вовлеченности» на вполне конкретную и измеряемую продуктивность.

Как измерить ЗАМОК?

Основа основ — метрики эффективности. Если пользователи тратят на задачу вечность, ни о какой удовлетворенности речи быть не может:

• Time on Task (Время выполнения задачи): замеряем, сколько времени уходит у среднего пользователя на выполнение ключевой операции (например, создание отчета или привязку данных к объекту мнемосхемы).

• Task Success Rate (Процент успешного выполнения задач): какой процент пользователей доходит до конца сценария без посторонней помощи?

• Number of Steps to Complete Task (Количество шагов для выполнения задачи): сколько кликов, переходов и полей нужно заполнить для достижения цели? Чем меньше, тем лучше. Это вам не квест «найди выход из лабиринта».

Следующие на очереди — метрики удовлетворенности. Здесь мы используем адаптированные под нашу суровую enterprise‑реальность опросники:

• System Usability Scale (SUS): классика юзабилити‑тестирования. 10 вопросов, которые дают общую оценку удобства системы. Главное — правильно подать опрос, объяснив, что мы хотим сделать их работу проще, а не просто собрать галочки.

• Single Ease Question (SEQ): простой и мощный инструмент. Сразу после выполнения задачи задаем один вопрос: «Насколько легко вам было выполнить эту задачу?» со шкалой от 1 (очень сложно) до 7 (очень легко).

• Customer Effort Score (CES): похож на SEQ, но спрашивает, как много усилий пришлось приложить для решения задачи.

Используя метрики когнитивной нагрузки, постараемся понять, не «взрывается» ли у пользователя мозг от нашего интерфейса?

• NASA Task Load Index (TLX): серьезный опросник из аэрокосмической отрасли. Помогает оценить нагрузку по шести шкалам: умственная, физическая, временная нагрузка, восприятие успешности, усилия и уровень фрустрации. Идеально для сложных, критически важных систем.

• Количество обращений в службу поддержки: если на техподдержку сыпется шквал вопросов по одной и той же функции, это верный признак того, что с ней что‑то не так.

Иногда пользователи молчат, но их поведение красноречивее любых слов. Тут нам помогут косвенные индикаторы удовлетворенности.

Золотая жила инсайтов — анализ техподдержки:

• Количество и тип обращений: какие проблемы возникают чаще всего? Они связаны с техническими сбоями или с непониманием интерфейса?

• Частота повторных обращений: если один и тот же пользователь обращается с одной проблемой несколько раз, значит, решение неэффективно.

• Категоризация проблем: разделяем тикеты по темам (UI, баги, запросы на фичи). Это помогает выявить самые больные места продукта.

Поведенческие метрики

• Частота использования обходных путей: пользователи выгружают данные в CSV, чтобы потом обработать их в Excel? Поздравляю, вы создали отличный экспортер вместо инструмента аналитики.

• Использование дополнительных инструментов: пользователи держат открытым калькулятор рядом с вашей системой? Возможно, стоит встроить его прямо в интерфейс.

Методы сбора данных

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

• Логирование ключевых событий в системе даст объективные данные о времени выполнения задач, количестве шагов и ошибках.

• Короткие SEQ, CES‑опросники, встроенные прямо в интерфейс.

• Интервью с пользователями: их боли и радости, а также «костыли», которые они используют.

• Контекстуальные и полевые исследования. Понаблюдайте за пользователем в его естественной среде обитания. Вы увидите то, о чем он никогда не расскажет в интервью. Это как смотреть National Geographic, только про инженеров.

Но просто собрать метрики недостаточно. Нужно выстроить процесс:

• Определите ключевые задачи. Какие 2–3 операции в исследуемом контексте пользователи выполняют чаще всего?

• Выберите релевантные метрики. Не пытайтесь измерить всё и сразу. Начните с 2–3 самых важных метрик для каждой задачи.

• Создайте базовые показатели. Проведите оценку всех ключевых процессов и сценариев, где UX‑проблемы наиболее болезненны. Замерьте текущее состояние дел — это точка отсчета.

• Измеряйте показатели регулярно. Например, это можно делать раз в квартал.

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

• Поэтапно добавляйте новые метрики и группы пользователей. Делайте это постепенно, чтобы не перегружать дашборд и команду. Так вы сможете проверять ценность каждой новой метрики, сохранять понятность, качество данных и адаптироваться к изменениям продукта. Группы пользователей — это сегменты (например, новички и опытные, мобильные и десктопные, или сменный персонал, диспетчеры), их выделяют для того, чтобы точнее видеть различия в поведении и находить конкретные зоны роста.

Связь с бизнес‑показателями: ROI от улучшения UX

Улучшение UX в enterprise‑продуктах напрямую влияет на деньги, поэтому самое важное — донести ценность нашей работы до бизнеса.

• Снижение времени обучения: быстрее обучили сотрудника — быстрее он начал приносить пользу и генерировать прибыль.

• Уменьшение количества ошибок: меньше ошибок — меньше финансовых и репутационных потерь.

• Повышение производительности: сотрудники успевают делать больше за то же время.

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

Истории успеха или немного кейсов:

История первая, или случай на металлургическом производстве

Проблема: Операторы производственных линий тратили по 45 минут на смену для регистрации данных о партии препаратов в MES‑системе. Сложный интерфейс требовал переключения между множеством экранов, а критически важные поля для валидации были разбросаны по разным вкладкам.

Метрики:

• Время регистрации партии: 45 минут

• Количество ошибок ввода данных: 23% записей содержали ошибки

• SUS score: 39 баллов

• Количество обращений в поддержку: 18 в неделю

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

Результат:

• Время регистрации партии сократилось до 15 минут (снижение на 67%)

• Количество ошибок уменьшилось до 4%

• SUS score вырос до 71 балла

• Обращения в поддержку сократились до 5 в неделю

• ROI проекта составил 420% за первый год благодаря снижению брака и ускорению производственного цикла

История вторая, или случай на автозаводе

Проблема: Мастера смен в сборочном цехе испытывали трудности с планированием производства и мониторингом хода выполнения плановых показателей. Система требовала множественных подтверждений для каждого действия, а критически важная информация о состоянии линии была разбросана по разным модулям.

Метрики:

• Время планирования смены: 35 минут

• Количество ошибок в планах: 12% планов требовали корректировки

• Customer Effort Score: 4.2 из 7 (высокие усилия)

• Частота использования бумажных дублей: 78%

Решение: Создание единого дашборда для мастера смены с визуализацией состояния всех линий, который является встроенной функциональностью в платформе ZIIoT, где агрегируются все данные. Благодаря этому планирование с помощью drag‑and‑drop интерфейса упрощается, конфигурирование системы оповещений о критических событиях добавлено на единый экран.

Результат:

• Время планирования смены сократилось до 12 минут (снижение на 66%)

• Количество ошибок в планах уменьшилось до 3%

• Customer Effort Score улучшился до 2.1 из 7

• Использование бумажных дублей снизилось до 15%

• Увеличение выработки на 8% благодаря более точному планированию.

В заключение

Измерять удовлетворенность «пленников» наших интерфейсов — задача сложная, но важная. Забудьте о поверхностных метриках вовлеченности. Эффективность, продуктивность и когнитивная нагрузка — вот наши три кита.

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