В корпоративной системе «средний пользователь» не существует: собственник смотрит отклонения от плана, эксперт — очередь своих задач, линейный сотрудник — одно поле для ввода. Когда всех троих сажают в один интерфейс с равными правами на экране, каждый начинает вести свой Excel рядом. Это не проблема дисциплины, это проблема проектирования.
Признаки того, что систему обходят
- Параллельные таблицы: сотрудники выгружают данные из системы, чтобы считать в Excel.
- Скриншоты вместо выгрузок: информацию передают изображениями, потому что так быстрее, чем найти в системе.
- Двойной ввод: одно и то же значение вводится и в систему, и в свой файл — «на всякий случай».
- Система живёт для отчётности: её заполняют к контролю, а работают по другим источникам.
Если хотя бы два признака на месте, проблема не в мотивации сотрудников. Значит, интерфейс заставляет делать лишние действия, а данные на экране не отвечают на рабочий вопрос. Переобучение это не лечит — лечит перепроектирование сценариев.
Роль — это набор решений, а не должность
Проектировать интерфейс по названиям должностей бесполезно: два менеджера с одинаковой должностью решают разные задачи. Мы описываем роли через решения, которые человек принимает, и данные, которые ему для этого нужны.
- Руководителю нужны отклонения и динамика: где план не выполняется и на сколько, что требует вмешательства сегодня.
- Специалисту нужна очередь работы: что пришло, что просрочено, что от него ждут прямо сейчас.
- Линейному сотруднику нужен один короткий сценарий: отсканировать, отметить, подтвердить — без выбора из десяти полей.
- Администратору нужны правила и справочники: как настроено, кто имеет доступ, что менялось и когда.
Что проверяем на пользователях до разработки
Прототип стоит дешевле кода, поэтому основные сценарии проверяются до разработки — на реальных людях, с реальными данными и на их рабочих местах. Проверять нужно не «нравится — не нравится», а три вещи.
- Находит ли человек нужное сам, без подсказок: где посмотреть статус, куда нажать, чтобы согласовать.
- Не ошибается ли он системно: если трое из пяти путают поле, проблема в интерфейсе, а не во внимательности.
- Укладывается ли сценарий в реальное время: сколько действий до результата и сколько на это уходит у сотрудника.
Для сложного B2B-инструмента мы провели UX-аудит, подготовили редизайн и дизайн-систему, а основные сценарии проверили на 10 пользователях. Найденные проблемы исправили до того, как решение ушло в выпуск, — на этом этапе правка интерфейса стоит часы, а не месяцы переделок в коде.
Что должно быть готово до первой строки кода
- Карта сценариев по ролям: кто чем пользуется каждый день, а кто заходит раз в месяц.
- Прототипы ключевых экранов, проверенные на пользователях, с зафиксированными выводами.
- Описание состояний: пустой список, ошибка, нет доступа, данные ещё грузятся, операция в процессе.
- Дизайн-система и компоненты: одинаковые элементы ведут себя одинаково на всех экранах.
- Спецификации для разработки: что происходит при каждом действии и где берутся данные.
Дизайн-система здесь не про красоту. В системе, которая живёт годами, она отвечает за предсказуемость: разработчик берёт компонент и описание поведения вместо того, чтобы каждый раз изобретать кнопку заново, а новый специалист понимает интерфейс без обучения.
Интерфейс, которым пользуются?
Проведём UX-аудит текущей системы или спроектируем интерфейсы под роли: сценарии, прототипы, проверка на пользователях и дизайн-система до старта разработки.