Platinum Electro
Platinum Electro — web-платформа для моделирования, расчётов и анализа электроэнергетических систем. Продукт создавался для промышленных предприятий, служб режимов, лабораторий электростанций, проектировщиков и консультантов.
Внутри продукта инженер строит электрическую схему, задаёт параметры оборудования, рассчитывает установившиеся режимы, токи короткого замыкания и уставки РЗА. Ошибка в интерфейсе здесь влияет не только на удобство. Она может исказить сценарий работы специалиста и привести к неправильной интерпретации расчёта.
- Сфера
- энергетика / B2B / импортозамещение
- Роль
- Lead UX/UI, продуктовый дизайнер
- Команда
- 1 PM, 6 BI, 2 SE, 1 UX/UI, 4 backend, 6 frontend, 2 QA, 4 DevOps
- Формат
- web-платформа для инженерных расчётов
- Аудитория
- энергетики, проектировщики, службы режимов электросетей
- Год
- MVP, 2025
О продукте
Проект стартовал как российская платформа для моделирования электроэнергетических систем. В качестве отраслевого ориентира рассматривались решения уровня PowerFactory, но команда проектировала продукт под свои сценарии, web-технологии и требования российских промышленных предприятий (АО «Системный оператор Единой энергетической системы», Группа «ФосАгро»).
Сложность была в предметной области. Пользователь работает не с обычной формой или таблицей, а с моделью энергосистемы: схемой, оборудованием, связями, расчётами, ошибками, предупреждениями и результатами анализа.
На старте у команды уже был базовый прототип, собранный аналитиками и разработчиками. Он помогал проверить функции, но интерфейс больше отражал внутреннюю структуру системы, чем реальный ход работы инженера.
Что я сделал
Я начал с погружения в энергетику: изучал принципы работы энергосистем, терминологию, типовые сценарии расчётов, ограничения и логику работы с электрическими схемами. Параллельно смотрел аналогичные продукты, включая PowerFactory и ETAP, чтобы понять, какие паттерны уже привычны инженерам, а какие можно улучшить.
На встречах с аналитиками и инженерами я разбирал сценарии до конкретных действий: как создаётся схема, как соединяются элементы, где инженер ожидает увидеть ошибку, как он проверяет результат, что считается допустимым поведением интерфейса с точки зрения расчётной безопасности.
Спорные решения проверял через обратную связь. В Telegram-группе с аналитиками и инженерами РЗА я задавал короткие вопросы, собирал мнения по вариантам и просил показать реальные примеры из практики. Так я совмещал количественную проверку в формате быстрых опросов и качественную проверку через разбор рабочих ситуаций.
После этого я собирал черновые схемы, wireframes и интерактивные макеты в Figma. Часть идей быстро отбрасывалась, потому что при проверке оказывалась удобной на экране, но слабой в инженерном сценарии. Рабочие варианты я презентовал стейкхолдерам, объяснял логику решений и фиксировал правки для следующей итерации.
Ключевые UX/UI-решения
Рабочий холст для схемы
Основной сценарий продукта строится вокруг схемы энергосистемы. Поэтому интерфейс должен был поддерживать построение, редактирование, соединение и анализ элементов на холсте.
Я прорабатывал механику соединения линий, перемещения объектов, отображения областей энергообъектов, добавления устройств РЗА и связи элементов между собой.
Таблицы и древовидные структуры
В продукте много данных: параметры оборудования, вложенные сущности, результаты расчётов, справочники и связи. Обычная таблица быстро становится перегруженной, если не задать правила отображения.
Я проектировал табличные и древовидные компоненты так, чтобы инженер мог работать с большим количеством параметров, раскрывать нужные уровни вложенности и не терять связь между объектом на схеме и его данными.
Параметры элементов
Большая часть инженерной работы происходит в параметрах выбранного элемента. Для каждого объекта нужно задать принадлежность к подстанции, узлы начала и конца, тип, состояние, параметры нейтрали и другие данные, которые влияют на расчётную модель.
Я вынес параметры в правую панель, чтобы пользователь мог редактировать элемент и одновременно видеть его место на схеме. Это сохраняет контекст: инженер понимает, какой объект выбран, с какими узлами он связан и как изменение параметров отразится на самой схеме.
Структуру панели разделил на вкладки и смысловые группы (аккордеоны). Такой подход помогает не смешивать разные уровни информации в одной длинной форме и быстрее находить нужный набор параметров.
Отдельно проработал поля со связями: объект, начало, конец, тип. Для них нужны не обычные текстовые поля, а управляемый выбор из модели сети.
Информационное окно
Инженеру нужен журнал действий за текущую сессию: ошибки, предупреждения, успешные операции и контрольные точки. Это помогает понять, что произошло с моделью и почему расчёт дал конкретный результат.
Я проработал логику информационного окна, где события не смешиваются в один поток, а помогают пользователю восстановить ход работы.
Проверка схемы
При работе с большой схемой инженер может не сразу заметить ошибку: незаполненный параметр, оборванную связь, отсутствующий тип элемента или некорректную настройку объекта. Такие проблемы часто проявляются только на этапе расчёта, когда пользователю уже сложнее понять, где именно нарушена логика модели.
Для этого в продукте появился функционал проверки схемы. Инженер запускает проверку, а система анализирует модель и собирает найденные проблемы в боковом окне: ошибки, предупреждения, пропущенные параметры и связи, которые требуют внимания.
Боковое окно работает как навигация по проблемам. Пользователь видит список замечаний, может перейти к конкретному месту на схеме или открыть параметры нужного элемента. Это помогает не искать ошибку вручную по всей модели, а последовательно пройти только те участки, где система нашла проблему.
Отдельно была заложена логика автоисправления. Если часть ошибок можно исправить без участия инженера, система делает это сама: например, заполняет очевидные значения или восстанавливает технические связи по доступным данным. Всё, что требует инженерного решения, остаётся за пользователем.
Так проверка схемы стала рабочим инструментом перед расчётом. Она помогает инженеру быстрее привести модель в корректное состояние, снизить количество ручных проверок и сохранить контроль там, где автоматическое решение может быть рискованным.
Показ энергообъектов
На большой схеме инженер работает не только с отдельными элементами, но и с целыми энергообъектами: подстанциями, узлами, участками сети и связанными группами оборудования. Когда таких объектов становится много, пользователь может быстро потерять границы между ними и начать воспринимать схему как один общий набор линий и устройств.
Для этого был проработан режим отображения энергообъектов. Пользователь включает нужный слой в панели «Вид и данные», после чего на схеме появляются цветные рамки с подписями объектов. Рамка показывает, какие элементы относятся к конкретной подстанции или участку сети, а подпись помогает быстро считать название без перехода в параметры.
Цвета рамок помогают разделять несколько энергообъектов на одном холсте. Это особенно важно для крупных схем, где таких областей может быть десятки или сотни.
В настройках можно управлять составом отображения: показать соединения, энергообъекты, РЗА, а также выбрать состав подписей. Например, оставить минимальные подписи для чистого вида схемы или включить полную информацию, когда нужно проверить данные по элементам.
Такой режим помогает инженеру быстрее ориентироваться в модели, проверять структуру схемы и видеть границы объектов без ручного поиска по параметрам каждого элемента.
Результат
За первые 4 месяца я довёл дизайн от технического прототипа до рабочей интерфейсной концепции продукта. У команды появился понятный визуальный и сценарный каркас: рабочий холст, правила отображения элементов, подход к таблицам, логика информационного окна, сценарии для РЗА и стандарты отображения результатов расчётов.
Для меня этот кейс важен тем, что он показывает работу дизайнера в сложной предметной области. Здесь мало «нарисовать красиво». Нужно быстро разобраться в инженерной логике, задавать точные вопросы, проверять гипотезы на экспертах и превращать абстрактные требования в интерфейс, с которым можно работать.
Я умею заходить в сложный B2B-продукт с незнакомой предметной областью, поэтому уверенно выступил в роли ведущего UX/UI-дизайнера и продакт-дизайнера. Значительно развил навык общения с инженерами на одном языке, проверял решения через практические примеры и удерживал баланс между бизнес-целью, технической реализацией и удобством пользователя.
Полное описание кейса
PDF может загружаться дольше из-за большого количества экранов.