Внутренние системы — учёт, заявки, склад, кабинет менеджера, панель диспетчера — проектируются по другим правилам, чем сайты. Здесь у человека нет выбора: он работает в этом интерфейсе каждый день по восемь часов, и цена неудобства измеряется не потерянным визитом, а рабочим временем всего отдела. Лишний переход, повторяющийся сто раз в день, превращается в часы.
Чем отличается от сайта
| Сайт | Бизнес-приложение |
|---|---|
| Нужно привлечь и убедить | Нужно ускорить работу |
| Посетитель случайный и неподготовленный | Пользователь обучен и работает ежедневно |
| Воздух, крупные элементы, иллюстрации | Плотность данных важнее декоративности |
| Один-два основных сценария | Десятки сценариев и несколько ролей |
| Ошибка — потерянный визит | Ошибка — испорченный документ, заказ или отгрузка |
| Первое впечатление решает | Решает скорость на сотом повторении |
| Обучения нет | Есть обучение, но чем меньше, тем лучше |
Принципы, которые работают
- Скорость важнее эффектов. Никаких анимаций на списках из тысячи строк. Задержка в полсекунды на переключении вкладки за день превращается в потерянные минуты, а ощущается как «система тормозит».
- Клавиатура — полноценный способ работы. Переход между полями табуляцией в логичном порядке, сохранение по сочетанию клавиш, ввод данных без перехода к мыши. Опытный оператор работает вслепую, и любое место, где приходится тянуться к мыши, замедляет его.
- Плотные таблицы. Фиксированная шапка, сортировка по столбцам, настраиваемый набор колонок, сохранение фильтров между сеансами. Человек, вернувшийся после обеда, должен увидеть тот же отбор, что оставил.
- Массовые операции. Выделить сто строк и выполнить действие разом. Отсутствие такой возможности — самая частая причина, по которой сотрудники ведут параллельный учёт в таблицах.
- Отмена вместо подтверждений. Вопрос «вы уверены» на каждом шаге перестают читать через неделю. Возможность откатить действие защищает лучше.
- Понятные ошибки. Сообщение должно говорить, что именно не так и что сделать, а не «операция не выполнена».
- Сохранение промежуточного состояния. Длинная форма, потерянная из-за случайного закрытия вкладки, — это не только испорченное настроение, но и повторный ввод.
Роли и права
В бизнес-системе одно и то же окно открывают кладовщик, менеджер по продажам, бухгалтер и руководитель. Попытка показать всем всё приводит к интерфейсу, в котором каждый видит десятки ненужных ему полей и кнопок и тратит время на поиск своих трёх.
Проектировать нужно от роли: что человек делает чаще всего, то и стоит на первом плане, остальное убирается в дополнительные разделы. При этом права на данные и вид интерфейса — разные вещи: скрыть кнопку недостаточно, ограничение должно проверяться на сервере. Мы регулярно встречаем системы, где действие «недоступно», но выполняется прямым запросом.
Полезно заранее продумать, что видит руководитель. Обычно ему нужны не те же экраны с большим набором прав, а сводка: сколько заявок в работе, где просрочка, что требует решения.
Работа с данными: объёмы и крайние случаи
Интерфейс, собранный на демонстрационных данных, ведёт себя иначе на боевых. Проверять нужно заранее.
- Список из десятков тысяч записей: работает ли постраничная выдача, не грузится ли всё разом.
- Длинные названия и адреса: не ломают ли они таблицу и не обрезаются ли так, что нельзя различить две записи.
- Пустые состояния: что видит человек, когда данных ещё нет, и понятно ли, что делать дальше.
- Одновременная работа: что происходит, если два сотрудника редактируют один документ.
- Медленный ответ сервера: показывает ли интерфейс состояние ожидания или выглядит зависшим.
- Выгрузка: можно ли получить текущий отбор файлом, не обращаясь к разработчику.
Плотность и читаемость
Плотный интерфейс часто путают с тесным. Разница в том, что плотность достигается уменьшением отступов и служебных элементов, а не уменьшением шрифта до нечитаемого размера. Оператор, который проводит за экраном рабочий день, устаёт от мелкого текста быстрее, чем от прокрутки.
Что помогает уместить больше данных без потери читаемости: выравнивание чисел по правому краю и моноширинные цифры, чтобы столбцы сравнивались взглядом; разделение строк тонкими линиями вместо чередующейся заливки; вынос редких действий в контекстное меню строки, а не в отдельную колонку кнопок; сокращение служебных надписей, которые повторяются в каждой строке. Отдельно стоит дать возможность настроить набор и ширину колонок — у разных ролей разные потребности, и универсального набора не существует.
Полезная деталь, о которой забывают: строка должна оставаться различимой при наведении и выделении, иначе на широком мониторе легко потерять, какую именно запись вы редактируете.
Ошибки, которые дороже всего обходятся
- Интерфейс скопирован с сайта: много воздуха, крупные карточки, десять записей на экран вместо пятидесяти.
- Нет поиска по спискам или он ищет только по точному совпадению.
- Каждое действие требует перехода на отдельную страницу с потерей контекста.
- Нельзя вернуться к прежнему значению: история изменений не ведётся, и разобраться, кто и что поменял, невозможно.
- Обязательные поля, которые в реальной работе часто неизвестны, — сотрудники начинают вписывать в них прочерки и мусор.
- Сообщения об ошибках написаны языком разработчика и содержат технические коды вместо объяснения.
Как проектировать, если система заменяет таблицы
Чаще всего внутреннюю систему заказывают, когда учёт уже ведётся в таблицах и перестал справляться. Это удобная отправная точка: в таблицах видно, какие поля реально заполняют, какими значениями пользуются, где сотрудники завели свои обозначения и костыли. Мы начинаем с их разбора, а не с чистого листа.
- Собрать все файлы, которыми пользуется отдел, включая личные копии на компьютерах сотрудников.
- Отметить поля, которые заполнены реже чем в половине строк, и выяснить, нужны ли они вообще.
- Найти места, где данные дублируются между файлами, — это будущие справочники.
- Спросить, что сотрудники делают вне таблиц: переписка, звонки, бумажные подписи. Эти шаги придётся либо учесть, либо сознательно оставить снаружи.
- Договориться, что переносится из истории, а что остаётся в архиве. Полный перенос обычно дороже пользы от него.
Главный риск на таком проекте — сделать точную копию таблицы в веб-интерфейсе. Копия не даёт выигрыша: те же поля, тот же ручной ввод, только медленнее. Смысл появляется там, где система берёт на себя проверки, связи между записями, статусы и напоминания.
Что проверять на приёмке
Мы принимаем такие системы не по списку реализованных функций, а по сценариям работы. Берём самую частую операцию и считаем, сколько действий она занимает: количество нажатий, переходов и переключений между мышью и клавиатурой. Дальше проверяем работу целиком с клавиатуры, поведение на реальном объёме данных, возможность отменить ошибочное действие и понятность сообщений об ошибках человеку без технического образования. Отдельно — что видит каждая роль и не может ли она сделать то, что ей не положено.
Хороший признак готовности: сотрудник, которому показали систему пятнадцать минут, выполняет типовую операцию без подсказок. Если для этого нужна инструкция на десять страниц, дело не в обучении, а в интерфейсе.
Нужна помощь
Мы проектируем и разрабатываем внутренние системы — учёт, заявки, склад, кабинеты сотрудников — с расчётом на ежедневную работу и реальные объёмы данных. Обсудить разработку информационной системы можно начиная с разбора текущих процессов.
