Времени заняло:
4 года
Команда:
Designer x2, Product Owner, Product Analytic x4, Frontend Developer х8, Backend Developer х6, QA Team, Product Manager x3, Tech Lead, Head of Engineering
Моя роль:
Senior Product Designer
Мой скоуп:
UX-research, UX/UI/IxD, IA, Prototyping, Design system, UX writing, Mentoring
Контекст:
Инжиниринговый дивизион Росатома. 5 продуктов в линейке Multi-D, команды по 30–50 человек, 1000+ пользователей на действующих стройках по всему миру.
Что это за система
Строительство атомной станции занимает около двух десятилетий. Каждое действие на площадке: заливка плиты, приёмка партии арматуры, закрытие месяца работ подрядчика — это отдельная запись в плане.
Записей больше ста тысяч, они связаны зависимостями. Если зависимость не учтена, задержка одной работы переносит сроки всех следующих за ней.
Сначала исследования
Спроектировать интерфейс здесь нельзя, не разобравшись в работе пользователей. Чем занимается методолог планирования, на основании чего инженер на площадке принимает или оспаривает данные, что происходит между отчётом подрядчика о выполнении и подтверждением этого выполнения.
В документации этого нет.
Я договорился о еженедельных созвонах с десятью самыми активными пользователями, их руководителями и методологами. Не исследовательский спринт с дедлайном, а постоянный формат: одни и те же люди каждую неделю на протяжении четырёх лет.
Поездка в Египет
Я съездил на действующую стройку АЭС.
На созвоне пользователь описывает процесс, которому обязан следовать по регламенту. На площадке видно, как он работает фактически. Расхождения между этими двумя версиями и есть материал для проектирования.
Пользователи работали в Экселе
Отчётность, ежедневная рутина и согласования велись в таблицах. Пользователи работали в них годами и делали это быстро.
Очевидное решение — заменить Эксель на специализированный интерфейс. Я предложил другое: сохранить привычные механики и перенести их в продукт.
Переучивание тысячи человек на новые механики означало бы падение скорости работы на длительный период, а параллельное ведение данных в Экселе продолжилось бы.
Этот проект под NDA
Я смогу показать лишь малую часть разрешенных к показу экранов с обезличенной информацией.
Древо работ
Основная структура продукта. Каждая запись соответствует работе на площадке: заливка, поставка, приёмка. Записей больше ста тысяч, вложенность до пяти уровней.
Остальные разделы продукта показывают те же данные в другом представлении.
Календарная сетка
Механики Эксель-таблицы: навигация с клавиатуры, выделение диапазона, протяжка значений по столбцу.
Каждое отклонение от привычного поведения таблицы обсуждалось отдельно. Планировщик выполняет эти действия несколько тысяч раз за смену, и любое дополнительное движение увеличивает время работы.
Диаграмма Ганта
Те же данные во времени: длительности и зависимости между работами. Основной сценарий — посмотреть, какие работы сдвинутся при переносе сроков одной из них.
Детальная карточка
Все данные по одной работе на одном экране. Используется на этапе, когда пользователь перешёл от просмотра списка к принятию решения по конкретной записи.
Дизайн-система для пяти продуктов
Ядру планирования требовались компоненты, которых не было в готовых библиотеках: плотные редактируемые таблицы, элементы таймлайна, узлы дерева.
Я собрал на базе Ant Design компонентную базу и внедрял её постепенно. Команды подключались по мере необходимости, потому что использовать готовые компоненты было быстрее, чем разрабатывать свои.
Параллельно вёл джунов и раз в неделю проводил дизайн-воркшоп.
Итоги
100 000+ записей в плане · 1000+ пользователей · 5 продуктов на одной дизайн-системе
Я пришёл к пользователям, которые вели стройку атомной станции в Экселе.
Спустя четыре года человек на площадке открывает древо работ, чтобы спланировать, какой бетон и куда заливать завтра.
