Проектирование интерфейсов для рабочих систем и сложных процессов

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

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

Чем это отличается от дизайна сайта

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

Что мы делаем

1. Смотрим, как работают сейчас. Садимся рядом с тем, кто делает работу руками, и молча наблюдаем. Это дает больше, чем любое интервью: люди не рассказывают о том, к чему привыкли.
2. Считаем действия. Сколько шагов занимает основная операция сегодня и сколько может занимать. Это единственная честная метрика в такой работе.
3. Проектируем сценарии, а не экраны. Начинаем с пути целиком: принять, оформить, закрыть. Экраны появляются как следствие, а не наоборот.
4. Рисуем состояния, а не идеальную картинку. Пусто, одна запись, три тысячи записей, загрузка, ошибка, нет прав, длинное название. Именно эти состояния занимают половину разработки.
5. Проверяем на людях. Даем задание словами и молчим. Каждое место, где человек замешкался, — находка. Трех-четырех человек достаточно: дальше замечания повторяются.
6. Передаем в разработку. Экраны с подписями: откуда берется значение, что происходит по нажатию, кто это видит. Такой прототип заменяет десятки страниц описания интерфейса.

Где теряется время в рабочих интерфейсах

Принципы, по которым проектируем

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

Что мы отдаем

Типовые задачи, с которыми приходят

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

Как проверяем, что стало лучше

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

1. Время основной операции. Замеряется до и после, на одних и тех же людях и на реальных данных. Это главная цифра.
2. Количество действий. Клики и нажатия на путь целиком. Легко посчитать и трудно оспорить.
3. Доля ошибок. Сколько операций приходится переделывать или исправлять задним числом.
4. Время на обучение нового сотрудника. За сколько человек начинает работать самостоятельно. В системах с текучкой это иногда важнее скорости.
5. Обращения в поддержку. Сколько вопросов «а как тут» приходит после запуска и о чем они.

Где здесь искусственный интеллект

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

Сроки и стоимость

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

Частые ошибки

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

Работаем и с существующими системами

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

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

Дальше по теме