UI-паттерны для промышленных информационных систем

Главные идеи#

Чем отличаются такие системы#

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

Паттерны отображения#

Проблема	Паттерн
Сущности вложены до трёх уровней, в них тысячи позиций	Иерархическое представление, которое раскрывается по требованию и не перегружает экран
Вложенные структуры внутри таблицы	Упрощённое дерево в строках таблицы
Порядок строк важен для выбора, как в очереди	Таблица без пагинации, чтобы был виден весь порядок
Большие таблицы	Закреплённые шапка, ключевой столбец и нижняя строка (футер)
Итоги нужны при прокрутке	Промежуточные итоги или средние значения в нижней строке таблицы
Выделенные строки ушли за пределы экрана при прокрутке	Видимый счётчик выделенных строк
Многие кнопки повторяют одно и то же слово	Действия сгруппированы под одной общей подписью
Строки или ячейки выделены цветом	Легенда, которая объясняет цвета

Функциональные паттерны#

Редактирование сущности с вложенной структурой в одном месте, без переходов между экранами.
Каскадные поля: поля формы, которые считывают значения других полей и заполняются сами.
Зависимые списки: варианты в раскрывающемся списке зависят от значений, выбранных в другом месте формы.
Адаптивные формы: структура формы меняется в зависимости от выбранного значения.
Упорядочивание строк перетаскиванием с сохранением нового порядка.
Порядок выбора: фиксируется не только то, какие строки выбраны, но и в каком порядке.
Фильтры по диапазону дат, которые находят записи, чей период пересекается с выбранным диапазоном.
Фильтры по скрытым атрибутам: фильтрация по атрибутам, которые не выведены в столбцы.

Случай посложнее: элементы управления, зависящие от статуса#

Частый запрос — включать и отключать элементы управления в зависимости от бизнес-статуса объекта, например запрещать редактирование после утверждения. Учебные материалы указывают на трудность: сделать это настраиваемым и при этом не перенести бизнес-логику во фронтенд. Относитесь к этому как к явному проектному решению, которое нужно принять вместе с командой разработки, а не как к мелочи.

Как применять#

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

Чек-лист для ревью#

Таблицы сохраняют заголовки и ключевые столбцы видимыми при прокрутке.
Пользователь видит, сколько строк выделено, даже если они за пределами экрана.
У каждого цветового кода есть легенда, и цвет никогда не бывает единственным сигналом.
Для зависимых полей и списков записаны правила.
Для фильтров по датам указана логика диапазона.
Разрешённые действия по статусам задокументированы.
Прототип опробован на объёмах данных, как в рабочей системе.

Пример#

«Мастерская», вымышленная сеть веломастерских, делает для управляющих экран заказа запчастей. В каталоге три уровня (модель велосипеда, узел, запчасть) и несколько тысяч запчастей. Аналитик специфицирует:

раскрывающуюся иерархию с поиском;
таблицу заказа с закреплённой шапкой и нижней строкой, в которой показана сумма заказа;
раскрывающийся список поставщиков, в котором есть только поставщики, у которых выбранная запчасть есть в наличии;
фильтры по дате поставки, определённые как «пересекается с выбранной неделей»;
счётчик выделенных строк для массовых изменений;
модель состояний, по которой строки заказа нельзя редактировать после того, как заказ отправлен поставщику.

Затем прототип тестируют на полном каталоге, а не на выборке.

Источники и что почитать#

Учебные материалы по бизнес-анализу (практические примеры и шаблоны): каталог типовых задач UI и UX из промышленных информационных систем.