Светлана Першай — UX/UI дизайнер

01 · Контекст

Сложность продукта —
в связях между объектами

Платформа автоматизирует инженерные вычисления и хранит «цифровой след» всей разработки. За одним расчётом тянется длинная цепочка связанных сущностей:

документ → целевые показатели → цифровой макет (DMU) → субмодель → симуляция → очередь → результат → отчёт → новая итерация

Систему используют инженеры-расчётчики, системные инженеры и руководители направлений. У каждого свой срез одних и тех же данных, и виртуальных испытаний за сутки могут быть сотни.

Инженер должен в любой момент видеть, где он находится, с каким объектом работает и к какому этапу относится его действие.

02 · Сущности системы

Карта системы
и четыре опорные сущности

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

Карта сущностей CML-Bench: рабочее пространство, вычислительная инфраструктура, моделирование, контент, администрирование и поддержка — **Карта сущностей CML-Bench.** По клику можно открыть схему в большем масштабе.

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

Целевой показатель `TARGET`

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

Условие нагружения `LOADCASE`

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

Симуляция `SIMULATION`

Расчётный вариант: субмодели, задачи, файлы и ключевые результаты. Порождает вычислительные задачи и наследников — новые варианты конструкции. Каждый результат жёстко связан со своим вариантом модели.

Очередь `QUEUE`

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

03 · Что я делала

Полный цикл на функциональном блоке

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

ИсследованиеРабочие процессы пользователей, сценарии, информационная архитектура

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

СостоянияЗагрузка, ошибки, пустые экраны, статусы расчётов

Передача в разработкуМакеты, спецификации, авторский надзор и дизайн-ревью

Спецификация модального окна просмотра лога с выносками: выбор лога, число строк, поиск, размер и дата файла, скачивание, интервал и кнопка обновления, окно просмотра с resize — **Так выглядела передача в разработку.** Каждый контрол сопровожден выноской: поведение, подсказки, источник данных. На примере — модальное окно просмотра лога расчёта.

04 · Исследование

От запросов пользователей
и аналогов — к гипотезам

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

Запросы я не переносила в интерфейс напрямую. Объединила повторяющиеся темы в гипотезы и уже их проверяла с пользователями.

Запросы пользователей

В бэклоге было 129 записей: проблемы, предложения и вопросы по разным частям CML-Bench. Я объединяла похожие запросы и смотрела, какие темы возвращаются чаще и в каких сценариях они мешают работе.

Таблица запросов и предложений пользователей CML-Bench с описанием проблемы, приоритетом и ссылкой на экран — **Бэклог пользовательских запросов.**

Аналоги

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

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

Карта гипотез

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

Карта десяти исследовательских гипотез CML-Bench, собранных из пользовательских запросов и анализа аналогов — **Карта гипотез до проверки.**

Опрос и проверка на рабочих сценариях

Дальше я провела восемь индивидуальных удалённых сессий с действующими пользователями CML-Bench. Сначала уточняла их рабочий контекст, затем давала практические ситуации и просила проговаривать ход действий.

8 пользователейДействующие инженеры и пользователи CML-Bench с разными рабочими сценариями.

Рабочий маршрутПроект → модель → запуск расчёта → очередь → ошибка → результат → отчёт.

Задания строила вокруг ситуаций

Формулировка «откройте Queue» проверяет скорее знание интерфейса. Поэтому я задавала ситуацию из работы:

«Коллега попросил проверить, как продвигается его расчёт. Покажите, как вы это сделаете».

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

Итоговая картина

После проверки гипотезы разделились на три группы: подтверждённые, неподтверждённые и те, для которых данных пока не хватило.

Гипотеза	Откуда появилась	Что показала проверка	Статус
H1. Навигация повторяет модель данных, а не рабочий процесс	Около 19 запросов о деревьях, путях и связях между объектами + разбор навигации в аналогах.	В рабочих сценариях пользователи теряли родительский объект и восстанавливали путь по памяти.	Подтвердилась
H2. Статусы и ошибки не подсказывают следующий шаг	Около 24 запросов о failed, логах, rerun и непонятных технических состояниях.	Сам статус был виден, но не всегда было понятно, на каком этапе возникла проблема и требуется ли действие пользователя.	Подтвердилась
H3. Очередь и вычислительные ресурсы непрозрачны	Около 16 запросов о поиске задачи, позиции в очереди и вычислительных ресурсах + сравнение аналогов.	При поиске своего или чужого расчёта пользователям не хватало связи с проектом, фильтров и понятного состояния ресурса.	Подтвердилась
H4. Сравнение вариантов и целевых показателей требует лишних переходов	Около 18 запросов о матрицах, графиках, отчётах и Target Values.	Чтобы сравнить варианты, приходилось держать контекст нескольких экранов и вручную сопоставлять значения.	Подтвердилась
H5. Повторяющиеся операции замедляют работу	Около 28 запросов о массовых действиях, автоматизации и повторяемых операциях.	Одни и те же действия приходилось повторять для нескольких объектов по отдельности.	Подтвердилась
H6. Важные действия, вложения, комментарии и уведомления недостаточно заметны	Около 18 запросов об обнаружимости и около 20 о совместной работе; темы частично пересекались.	В плотных рабочих экранах служебная информация конкурировала с действиями и контекстом совместной работы.	Подтвердилась
H7. Недостаток встроенной документации и онбординга критично влияет на эффективность	Прямые пользовательские запросы на справку и объяснение сценариев.	Для действующих пользователей проблема проявлялась, но этой выборки недостаточно, чтобы делать вывод об онбординге новичков.	Нужна отдельная проверка
H8. Права доступа и аутентификация создают системную задержку	4 прямых обращения + разбор того, как права устроены в аналогичных системах.	Проблема есть, но сильно зависит от роли и конкретного процесса. Данных недостаточно для общего вывода.	Нужна отдельная проверка
H9. Цвета и иконки сущностей сами по себе помогают не потерять контекст	Предположение из существующего интерфейса и практик аналогичных систем.	В рамках основных сессий нельзя было отделить эффект цвета и иконок от структуры экрана. Нужна отдельная проверка распознавания и доступности.	Нужна отдельная проверка
H10. Текущее дерево достаточно хорошо объясняет связи между сущностями	Предположение о существующей структуре дерева и запросы, связанные с навигацией.	Не подтвердилось: пользователям не хватало полного дерева, подсветки пути, нескольких reference и связи между итерациями.	Не подтвердилась

05 · Дизайн-решение

Что поменяла
по итогам исследования

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

H1 + H10 · Контекст и путь по системе

Навигацию перестроила по этапам работы инженера. На экранах появился контекст родительских объектов, а переходы связали проект, модель, расчёт, результат и следующую итерацию.

Схема инженерного цикла: инициатор, документ, цели, DMU, субмодель, симуляция, результат, отчёт и новая итерация — **Путь инженера.** Работа не заканчивается результатом: он сравнивается с целевыми показателями, приводит к изменению модели и новому расчёту.

Контекст на странице симуляции

Во Flow-блоке виден состав расчётного варианта. Таблица наследников связывает текущую модель со следующими итерациями.

Страница симуляции sim_4: блок Flow с субмоделями, задачами, файлами, ключевыми результатами и отчётами, поля Path и Name, таблица наследников — **Страница симуляции.** Сверху — Flow-блок со счётчиками (субмодели, задачи, файлы, ключевые результаты, отчёты), ниже основные поля и таблица наследников: из одного варианта вырастают следующие.

H1 · Связи между требованиями и расчётами

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

Библиотека требований: дерево IR Reflectivity с поиском, справа карточка целевого показателя — критерий Interval, границы 40 и 70, единица % — **Целевые показатели в интерфейсе.** Слева требование задаётся критерием и интервалом (здесь 40–70 %), справа показатели собираются в группы с настраиваемыми параметрами.

Экран группы целевых показателей: Flow со счётчиками, параметры групп, конфигуратор параметров — **Целевые показатели в интерфейсе.** Слева требование задаётся критерием и интервалом (здесь 40–70 %), справа показатели собираются в группы с настраиваемыми параметрами.

H3 · Очередь и вычислительные ресурсы

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

Ранняя версия очереди: одиночный селект группировки, задачи разложены по кластерам — **Очередь задач.** Один селект заменён панелью группировки и фильтров. Карточки можно собирать по проектам и вычислительным узлам.

Переработанная очередь: панель «Group & Filter» с группировкой по проектам и набором фильтров — **Очередь задач.** Один селект заменён панелью группировки и фильтров. Карточки можно собирать по проектам и вычислительным узлам.

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

H4 · Сравнение вариантов на одном экране

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

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

H5 + H6 · Действия и совместная работа

Повторяющиеся операции собрала в одно меню и разделила по области действия: текущий объект, выбранные строки или таблица целиком. Ручное решение по цели фиксируется вместе со статусом, комментарием и историей — важный контекст совместной работы не теряется.

Меню действий: операции над объектом, над выбранными элементами и над таблицей — **Фиксация изменений.** Каждое ручное изменение статуса цели сохраняет автора, дату и комментарий.

Страница Loadcase целиком и модальное окно решения пользователя с историей изменений статусов — **Фиксация изменений.** Каждое ручное изменение статуса цели сохраняет автора, дату и комментарий.

06 · Дизайн-система

UI Kit, собранный с нуля
при переезде в Figma

Проект застал переход команды из Photoshop в Figma. Старые макеты я не переносила: заново собрала атомарную систему.

Четыре уровня Bench UI Kit

Уровень 1

Атомы

Базовые неделимые элементы интерфейса. Из них складываются визуальный язык и основные правила системы.

Уровень 2

Молекулы

Небольшие комбинации атомов, которые вместе решают одну пользовательскую задачу.

Уровень 3

Организмы

Самостоятельные составные блоки, объединяющие несколько молекул в устойчивый сценарий.

Уровень 4

Шаблоны

Структура страницы из организмов. Определяет иерархию, сетку и поведение контента.

Страница Atoms из Bench UI Kit: header, footer, блоки, статусы, переключатели, состояния загрузки — **Страница «Atoms».** Хедер и футер модалного окна, блоки, состояния (default, active, disable, hover), свитчи и статусы загрузки файла. Каждый элемент существует в одном месте и переиспользуется.

Документация и разметка компонентов

Рядом с мастер-компонентом я разместила матрицу всех вариантов и подписала оси: по горизонтали — тип, по вертикали — состояние. Правила использования хранились в базе знаний команды, а UI Kit служил наглядной картой компонентов.

Атомы для таблицы: флаг и лейбл с матрицами вариантов по типу и состоянию, рядом мастер-компонент — **Размеченные компоненты.** Оси подписаны (тип по горизонтали, состояние по вертикали), поэтому по одному взгляду видно, какие комбинации существуют и как называются.

Страница модальных окон UI Kit: размеры M и L, окна создания сущностей, выбора DMU и мультивариантов — **Размеченные компоненты.** Оси подписаны (тип по горизонтали, состояние по вертикали), поэтому по одному взгляду видно, какие комбинации существуют и как называются.

Страница Table из UI Kit: варианты ячейки по типу контента и границам, столбцы, готовая таблица — **Самый нагруженный компонент — таблица.** Ячейка размножается по типу контента (текст, дата, ссылка, флаг, лейбл, кнопка, картинка) и по границам, из ячеек собираются столбцы, из столбцов таблица. Одна ячейка правится централизованно.

Цвет как место в процессе

Поверх UI Kit я собрала систему сущностей. Для каждой задала иконку, семантический цвет, устойчивое название и одинаковое представление в дереве проекта, хлебных крошках, заголовках, таблицах и карточках. Цвета идут по спектру: тёплые обозначают начало процесса, холодные — его конец.

Инженер узнаёт объект до того, как прочитал подпись. Но цвет не остаётся единственным носителем смысла: рядом всегда иконка и текст.

Спектр сущностей

начало процессаконец процесса

Ключевые сущности

Project#A35631

Loadcase#E5804C

DMU#F6CF34

Submodel#66A171

Simulation#5FB693

Key result#59B3CB

Cluster#8E9BC5

Queue#A58FCC

Report#A087C8

У каждой сущности есть основной и приглушённый вариант: приглушённый уходит в заливки и неактивные состояния.

Состояния и статусы

Created Processing New Failed Success #5FB693 · Warning #EDB85A · Error #CF5554 · Info #358AD7

Легенда матрицы

none

fit

warm

cool

cold

Пять ступеней близости к цели. Та же шкала работает в таблице сравнения вариантов.

Кнопки

Семь семантик. Состояния на примере Primary:

Поля

Default

Focus

Valid

Invalid

Disabled

Фрагмент библиотеки. Хексы и состояния из макетов проекта; вёрстка выше воссоздана по ним.

P.S. Цена такой палитры

Двадцать пять сущностей — это двадцать пять цветов, и различимость соседних ступеней спектра держится на иконке и подписи. Сейчас я бы проверила спектр на симуляторе дальтонизма и, возможно, сократила бы число самостоятельных цветов, сгруппировав сущности по этапам процесса: один тон на этап, оттенок на объект внутри него.

Иконки под каждую сущность

Готовых наборов для DMU, субмодели, солвера и вычислительного узла не было, поэтому иконки я рисовала сама. Они должны были различать объекты одного уровня, а не превращать их в похожие силуэты.

Набор иконок сущностей и действий системы, отрисованных в едином линейном стиле — **Иконографика системы.** Единый линейный стиль, одна сетка, разные силуэты для объектов одного уровня.

07 · Результат

Интерфейс следует
логике инженера

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

Что подтвердили после изменений

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

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

CML-Bench получила официальный статус SPDM-системы в реестре российского ПО.

SPDM-платформадля инженерных расчётов

Сложность продукта —в связях между объектами

Карта системыи четыре опорные сущности

Целевой показатель TARGET

Условие нагружения LOADCASE

Симуляция SIMULATION

Очередь QUEUE