Денис Зеленых

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

Моя роль: Lead / Principal Product Designer.

Ответственность: UI-kit для Windows-приложения, рефакторинг дизайн-системы, организация работы дизайн-команды, сложные индустриальные интерфейсы, найм дизайнеров.

Продукты: Windows · Web · Android · iOS.

Подчинение: продуктовое и инженерное руководство.

Я отвечал за дизайн как системную функцию сразу в нескольких продуктах и платформах.

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

На старте: дизайн-система находилась на начальном уровне зрелости; интерфейсы разных продуктов развивались неравномерно; отсутствовал единый UI-фундамент, особенно для Windows-приложения; командам было сложно масштабировать решения.

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

Контекст рабочих сценариев: данные, инструменты и длительные сессии.

Бизнес- и продуктовые цели:

• Повысить консистентность интерфейсов между продуктами.
• Упростить разработку и поддержку UI.
• Снизить UX-долг.
• Обеспечить масштабирование продуктовой линейки.

Дизайн-цели:

• Разработать UI-kit для Windows-приложения.
• Рефакторить существующую дизайн-систему.
• Выстроить единые UX-принципы для всех платформ.
• Поддержать сложные сценарии нефтедобывающей отрасли.

Я отвечал за:

• Организацию работы команды продуктовых дизайнеров.
• Дизайн-надзор над 4 продуктами (Windows, Web, Android, iOS).
• Разработку UI-kit для desktop-приложения.
• Рефакторинг существующей дизайн-системы.
• Проектирование сложных профессиональных интерфейсов.
• Найм и онбординг дизайнеров.

Моя задача — превратить разрозненный дизайн в управляемую систему.

Единый фундамент: систематизация компонентов и паттернов.

1. UI-kit для Windows как точка стабилизации

Windows-приложение было самым сложным с точки зрения плотности данных, количества инструментов и длительности пользовательских сессий.

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

2. Рефакторинг дизайн-системы без остановки разработки

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

3. Сложные интерфейсы под профессиональных пользователей

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

4. Единые принципы для разных платформ

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

Я координировал работу дизайнеров на 4 продуктах, выстраивал процессы дизайн-ревью, участвовал в найме и оценке кандидатов, онбордил новых дизайнеров и задавал единые стандарты качества.

Дизайн-команда перестала быть «набором исполнителей» и стала продуктовой функцией.

• Создан UI-kit для Windows-продукта.
• Улучшена и стабилизирована дизайн-система.
• Снижено количество UX-расхождений.
• Упрощено масштабирование интерфейсов.
• Повышена предсказуемость дизайна для разработки.

• Интерфейсы стали более консистентными и управляемыми.
• Снизился UX-долг.
• Ускорилась разработка новых функций.
• Дизайн стал опорой для сложных инженерных сценариев.
• Команда получила чёткие ориентиры и процессы.

Проект усилил дизайн-функцию в компании, работающей в высоконагруженной индустриальной среде.

• В индустриальных продуктах UX — это инструмент эффективности.
• UI-kit и дизайн-система критичны для desktop-решений.
• Рефакторинг системы возможен без остановки бизнеса.
• Найм и процессы — часть ответственности дизайн-лида.

Этот кейс усиливает мой профиль как лидера дизайна в сложных enterprise- и индустриальных продуктах.

Правительство Москвы — заказчик городской цифровой экосистемы в сфере спорта и физической активности. В рамках проекта была разработана дизайн-система «Марафон», ставшая фундаментом для портала «Московский спорт» — цифровой платформы взаимодействия жителей с городской спортивной инфраструктурой.

Я отвечал за дизайн как системный инструмент городской цифровой среды, а не отдельный интерфейс.

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

До запуска портала взаимодействие было: фрагментированным, распределённым по разным каналам, сложным для горожан, трудоёмким для сотрудников и тренеров.

Также отсутствовал единый дизайн-фундамент, который позволял бы масштабировать продукт без постоянной пересборки интерфейсов.

На уровне города и сервиса:

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

На уровне продукта:

• Разработать масштабируемую дизайн-систему.
• Спроектировать портал для пользователей.
• Создать бэкофисные решения для сотрудников и тренеров.
• Поддержать пользовательский контент и навигацию по городу.

• Формирование дизайн-стратегии продукта.
• Разработка дизайн-системы «Марафон».
• UX-архитектура портала и внутренних сервисов.
• Арт-дирекшн коммуникаций портала.
• Управление командой из 3 дизайнеров.
• Синхронизация дизайна с продуктовой и технической стратегией.
• Принятие ключевых решений совместно с CPO.

Моя задача — обеспечить устойчивость продукта на уровне системы, а не отдельных экранов.

1. Дизайн-система как фундамент экосистемы

«Марафон» проектировался не как UI-кит, а как продуктовая дизайн-система, которая поддерживает разные типы интерфейсов, масштабируется под новые сервисы, обеспечивает единый UX для пользователей и сотрудников, снижает стоимость и скорость разработки.

2. Разделение пользовательских и внутренних сценариев

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

3. Портал как городской сервис, а не сайт

«Московский спорт» проектировался как цифровой городской сервис: запись в секции и на мероприятия, посещение спортивных объектов, работа с картами и маршрутами, взаимодействие с сообществом. UX-архитектура строилась вокруг реальных жизненных сценариев горожан.

4. Контент, сообщество и модерация

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

5. Картографические интерфейсы

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

Команда из 3 дизайнеров работала над дизайн-системой, пользовательскими интерфейсами, бэкофисами и коммуникационными материалами.

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

• Разработана дизайн-система «Марафон».
• Сформированы UX-паттерны для GovTech-сервисов.
• Унифицированы интерфейсы портала и бэкофисов.
• Заложена масштабируемость под новые городские сервисы.

Дизайн стал частью городской цифровой инфраструктуры.

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

Проект стал стратегическим GovTech-продуктом, а не разовой инициативой.

• В городских сервисах дизайн — это инструмент управления сложностью.
• Дизайн-система — ключ к устойчивости GovTech-продуктов.
• UX напрямую влияет на вовлечённость и доверие граждан.

Этот кейс фиксирует мой опыт как директора по дизайну продукта в крупной городской цифровой экосистеме.

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

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

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

На старте отсутствовало: единое цифровое решение, понятный пользовательский сценарий зарядки, продуктовая логика с учетом условий использования (в пути, ограниченное время, стресс).

Дополнительно: продукт разрабатывался параллельно с инфраструктурой, бизнес-модель и гипотезы уточнялись по ходу разработки.

Нужно было создать устойчивый UX-фундамент для роста сети и функциональности.

На уровне бизнеса:

• Создать цифровой продукт, повышающий ценность сети зарядных станций.
• Сформировать доверие к новому бренду на раннем этапе.
• Заложить основу для масштабирования сети и сервиса.

На уровне продукта:

• Обеспечить простой и предсказуемый сценарий зарядки.
• Минимизировать ошибки и неопределенность пользователя.
• Создать продукт, готовый к быстрому развитию.

• Формирование дизайн-стратегии продукта.
• Построение UX-архитектуры ключевых сценариев.
• Управление командой из 8 дизайнеров.
• Принятие дизайн-решений на уровне продукта.
• Выстраивание взаимодействия с CEO и продуктовой командой.
• Запуск продукта с нуля до первой версии.

Я выступал владельцем дизайн-решений, а не только исполнителем.

1. Фокус на сценарий, а не на интерфейс

Проектирование начиналось от сценария зарядки. Мы ответили: «Что должен видеть и понимать пользователь в каждый момент зарядки?» Это снизило когнитивную нагрузку и сделало поведение приложения предсказуемым.

2. UX под реальные условия использования

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

3. Масштабируемая архитектура

UX и UI проектировались как система, готовая к добавлению новых сценариев без переписывания базовой логики.

Команда состояла из 8 дизайнеров разного уровня. Я распределял зоны ответственности, выстроил единый подход к UX-решениям, ввел дизайн-ревью и общие принципы принятия решений.

Моя задача была не «сделать самому», а обеспечить целостность продукта.

• Заложена базовая дизайн-система.
• Сформированы UX-паттерны для ключевых сценариев.
• Определены правила масштабирования интерфейсов.
• Задан подход к работе с состояниями и ошибками.

• Запущен полноценный мобильный продукт с нуля.
• Сформирована устойчивая UX-архитектура для развития.
• Дизайн стал опорой для продуктовых решений, а не декоративным слоем.
• Команда получила четкие ориентиры для масштабирования продукта.

Продукт стал цифровым фундаментом для развития сети электрозаправок.

• Ранние дизайн-решения критически влияют на устойчивость продукта.
• Проектирование сценариев важнее проектирования экранов.
• В условиях неопределенности дизайн-лид должен задавать направление.

Проект закрепил мой подход к дизайну как системному инструменту продукта и бизнеса.

DLS — корпоративная цифровая экосистема, разработанная в рамках стратегии импортозамещения и ориентированная на рынок БРИКС. Продукт — коробочное решение, разворачиваемое on-premise.

Экосистема включает модули управления задачами, звонков, чатов с тредами, AI-ассистента и служебных сервисов. Платформы: Windows, Linux, macOS, iOS, Android, Web.

Я отвечал за дизайн как системную функцию в enterprise-продукте, находящемся в активной разработке и масштабировании.

Продукт создавался в условиях отказа от зарубежных enterprise-решений, высоких требований к безопасности, on-premise-развертывания, сложной структуры заказчиков и параллельной разработки модулей.

Ключевой вызов — единый, масштабируемый и предсказуемый UX для кроссплатформенной экосистемы, развиваемой несколькими командами.

Бизнес-цели:

• Создать конкурентоспособную enterprise-платформу для рынка БРИКС.
• Обеспечить масштабирование продукта без деградации UX.
• Снизить стоимость и время разработки новых модулей.
• Обеспечить управляемость дизайна на уровне всей экосистемы.

Продуктовые цели:

• Разработать единую дизайн-систему.
• Обеспечить консистентный UX на всех платформах.
• Встроить дизайн в процесс активной разработки.
• Поддержать развитие новых продуктов внутри экосистемы.

• Формирование дизайн-стратегии всей экосистемы.
• Построение и управление дизайн-департаментом.
• Разработка и внедрение дизайн-системы.
• Выстраивание дизайн-процессов.
• Синхронизация дизайна с продуктом и разработкой.
• Контроль качества решений на уровне всей платформы.

1. Дизайн-система как обязательная инфраструктура

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

2. Кроссплатформенность как принцип

UX проектировался сразу под desktop, mobile и web-контексты.

3. Enterprise-UX и безопасность

Учитывались роли и права доступа, корпоративная рутина, предсказуемость и контроль действий.

4. Масштабирование экосистемы

Дизайн-система и процессы позволили новым модулям запускаться быстро при сохранении единого UX.

Сформирована структура направлений, зоны ответственности, дизайн-ревью, синхронизации и взаимодействие с продуктом и разработкой.

Дизайн стал частью продуктового управления, а не сервисом.

• Создана масштабируемая дизайн-система.
• Выстроен полноценный дизайн-департамент.
• Дизайн интегрирован в процесс активной разработки.
• Экосистема получила единый UX-фундамент.
• Система использована для разработки отдельных продуктов вне ядра.

Проект стал долгосрочной платформой, а не разовой реализацией.

• В enterprise-продуктах дизайн — это инфраструктура.
• Дизайн-система критична для масштабирования.
• Управление дизайном важнее отдельных интерфейсных решений.
• Без процессов дизайн не переживает рост продукта.

Кейс фиксирует мой опыт как Design Director, выстраивающего дизайн-функцию в корпоративной экосистеме.

М-код — самостоятельный продукт на базе дизайн-системы DLS «Пиксель». Он демонстрирует масштабируемость системы за пределами исходной платформы.

Ключевая проверка зрелости дизайн-системы: можно ли запускать независимые продукты без пересборки UX и визуального языка.

М-код — отдельный бизнес-контекст и сценарии при едином UX-фундаменте с DLS.

Стратегические:

• Проверить масштабируемость дизайн-системы DLS.
• Сократить время запуска нового продукта.
• Сохранить UX-консистентность между продуктами.
• Снизить стоимость дизайна и разработки.

Продуктовые:

• Быстро запустить самостоятельный продукт.
• Адаптировать паттерны под новые сценарии.
• Избежать фрагментации пользовательского опыта.

• Контроль применения дизайн-системы «Пиксель».
• Адаптация UX-паттернов под новый продукт.
• Сохранение консистентности с экосистемой DLS.
• Дизайн-надзор и принятие ключевых решений.

Моя задача — проверить дизайн-систему на прочность.

1. Использование системы без кастомной ветки

Работа в рамках существующих компонентов и паттернов с фиксацией слабых мест системы.

2. Адаптация без разрушения системы

Новые сценарии расширяли паттерны и возвращались обратно в систему.

3. Консистентность UX между продуктами

Пользователь DLS должен легко ориентироваться в М-коде без переучивания.

• Дизайн-система «Пиксель» пригодна для повторного использования.
• UX-паттерны выдерживают новые контексты.
• Время вывода продукта на рынок сокращается.
• Дизайн становится активом компании.

• Запущен продукт без пересборки дизайна.
• Подтверждена зрелость дизайн-системы.
• Снижены издержки на дизайн и разработку.
• UX-консистентность сохранена.

М-код стал доказательством жизнеспособности дизайн-системы DLS.

• Дизайн-система проверяется новыми продуктами.
• Масштабируемость важнее визуального разнообразия.
• Дизайн-система — бизнес-инфраструктура.

Кейс усиливает мой профиль как Design Director, создающего дизайн-платформы.

«Пиксель» — дизайн-система для кроссплатформенной экосистемы DLS и последующих продуктов (включая М-код). Система создавалась в условиях активной разработки с фокусом на масштабирование и устойчивость UX.

Экосистема DLS — кроссплатформенный продукт и набор модулей. Без системы это означало бы расхождение UX, рост стоимости разработки и потерю управляемости дизайна.

«Пиксель» создавался как инфраструктура, а не набор компонентов.

Продуктовые:

• Единый UX для всей экосистемы.
• Поддержка кроссплатформенности.
• Ускорение разработки модулей и продуктов.
• Снижение UX-ошибок.

Организационные:

• Встроить дизайн в процесс разработки.
• Упростить коммуникацию дизайна и разработки.
• Сделать дизайн масштабируемой функцией.

• Архитектура дизайн-системы.
• Принципы и ограничения системы.
• Техническая логика компонентов и паттернов.
• Интеграция системы в разработку.
• Управление командой из 2 дизайнеров.
• Процессы поддержки и развития системы.

1. Компоненты как система

Компоненты проектировались с четкими состояниями и правилами использования для разных платформ.

2. UX-паттерны как основной актив

Навигация, сценарии и работа с состояниями стали ядром системы.

3. Кроссплатформенный подход

Решения проектировались сразу для desktop, mobile и web.

• Система стала инфраструктурой для экосистемы DLS и новых продуктов.
• Снижение расхождений и ускорение разработки.
• Единый UX для модулей и платформ.

• UX-паттерны важнее визуальных деталей.
• Кроссплатформенность требует системного проектирования.
• Дизайн-система живет только в продукте.

«Марафон» — дизайн-система для цифровых сервисов города Москвы и фундамента портала «Московский спорт» и внутренних систем.

Система создана для масштабируемых GovTech-продуктов с большим количеством ролей и сценариев.

Городские сервисы — высокая сложность, разные аудитории и интерфейсы. До появления системы интерфейсы развивались фрагментарно и теряли консистентность.

«Марафон» создавался как инфраструктура, а не UI-кит.

Продуктовые:

• Единый UX для городской экосистемы спорта.
• Поддержка развития портала и внутренних сервисов.
• Сокращение стоимости и времени разработки.
• Повышение предсказуемости интерфейсов.

Организационные:

• Встроить дизайн в продуктовый процесс.
• Упростить взаимодействие дизайна и разработки.
• Создать устойчивый фундамент для масштабирования.

• Архитектура дизайн-системы.
• UX-принципы и ограничения.
• Системные паттерны.
• Внедрение в разработку.
• Управление командой из 2 дизайнеров.
• Дизайн-ревью и контроль соответствия системе.

1. UX-паттерны как основа

Паттерны навигации, записи, работы с состояниями и картами стали ядром системы.

2. Поддержка разных ролей

Учитывались публичные интерфейсы, бэкофисы, админ-сценарии.

3. Доступность и читаемость

Высокая читаемость, предсказуемость поведения и минимизация когнитивной нагрузки.

Система развивалась параллельно разработке портала, с дизайн-ревью и обратной связью от реального использования.

• Создана масштабируемая дизайн-система GovTech-уровня.
• Ускорено развитие портала и внутренних сервисов.
• Обеспечен единый пользовательский опыт.
• Снижена нагрузка на дизайн и разработку.

• В GovTech дизайн-система — инструмент управления сложностью.
• UX-паттерны важнее визуальных деталей.
• Масштабируемость критичнее уникальности.

Кейс фиксирует мой опыт как Design System Tech Lead.

Macron CRM — B2B CRM-система для управления логистическими процессами: перевозками, заказами, статусами, контрагентами и аналитикой.

Я отвечал за проектирование enterprise-уровня CRM для высоконагруженных процессов.

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

Нужен был интерфейс, помогающий принимать решения, а не просто отображать данные.

Бизнес-цели:

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

Продуктовые цели:

• Единая CRM-система для логистики.
• Упрощение работы с большими объемами данных.
• Поддержка разных ролей пользователей.
• Расширяемость под новые сценарии и рынки.

• UX-стратегия продукта.
• Архитектура CRM-системы.
• Ключевые UX-решения и паттерны.
• Управление командой из 3 дизайнеров.
• Синхронизация дизайна с бизнес- и техтребованиями.

1. CRM как инструмент принятия решений

Фокус на приоритизации проблем, контроле сроков и минимальных шагах до действий.

2. Ролевая архитектура

Разные роли получали свои сценарии и приоритеты информации.

3. Работа с большими объемами данных

Умная фильтрация, дашборды, визуальные индикаторы отклонений.

4. Обработка исключений

Сценарии сбоев и задержек как нормальная часть процесса.

Команда из 3 дизайнеров работала над интерфейсами операторов и менеджеров, паттернами и компонентами.

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

• Создана CRM-система с нуля.
• Упрощены операционные процессы.
• Повышена прозрачность логистики.
• Снижена нагрузка на операторов.
• Заложена архитектура для масштабирования.

• В enterprise-CRM UX — инструмент управления сложностью.
• Проектирование под роли критичнее универсальных интерфейсов.
• Хороший дизайн снижает операционные риски.

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

Я отвечал за перезапуск публичного цифрового канала и проектирование внутренних сервисов.

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

Цифровая часть сервиса не соответствовала масштабу офлайн-процессов.

На уровне бизнеса и сервиса:

• Восстановить доступ к почтовым услугам.
• Обеспечить международное взаимодействие в новых условиях.
• Повысить доверие через цифровые каналы.
• Создать основу для цифровизации.

На уровне продукта:

• Разработать сайт с нуля.
• Спроектировать внутренние сервисы.
• Создать почтовый ID.
• Обеспечить масштабируемость.

• Дизайн-стратегия проекта.
• UX-архитектура публичных и внутренних сервисов.
• Управление командой из 3 дизайнеров.
• Синхронизация с продуктовой и технической логикой.
• Работа в условиях регуляторных ограничений.

1. Сайт как цифровой хаб

Фокус на понятной навигации, ясных сценариях и снижении нагрузки на офлайн-отделения.

2. Проектирование в условиях ограничений

Сценарии и архитектура адаптированы под санкционные и инфраструктурные ограничения.

3. Почтовый ID

Единый цифровой идентификатор связал публичные и внутренние сервисы.

• Сайт полностью переработан и запущен с нуля.
• Восстановлена возможность международного взаимодействия.
• Создан почтовый ID.
• Улучшено взаимодействие пользователей с сервисом.

Проект дал инфраструктурный эффект, выходящий за рамки интерфейсов.

• В инфраструктурных продуктах дизайн — инструмент устойчивости.
• Ограничения усиливают роль системного мышления.
• UX напрямую влияет на доверие.

ДонБилет — платформа для продажи билетов на самолеты, поезда и автобусы в условиях ограниченной инфраструктуры.

Я отвечал за визуальный и продуктовый фундамент платформы — от бренда до архитектуры интерфейсов.

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

Ключевая задача — создать доверие и предсказуемый пользовательский опыт.

Бизнес:

• Запустить единый сервис продажи билетов.
• Обеспечить доверие к бренду.
• Создать основу для масштабирования.

Продукт:

• Спроектировать архитектуру web-платформы.
• Унифицировать сценарии покупки.
• Минимизировать пользовательские ошибки.

1. Единая логика покупки

Сценарии для авиа, ж/д и автобусов унифицированы.

2. Архитектура как основа масштабирования

Проектирование началось с сущностей и пользовательских потоков.

3. Бренд как инструмент доверия

Фирменный стиль поддерживал ощущение надежности и не отвлекал от действий.

• Запущен новый билетный сервис с нуля.
• Создан единый пользовательский сценарий.
• Сформировано доверие к продукту.
• Заложена архитектура для роста.

• В транзакционных сервисах архитектура важнее графики.
• Бренд усиливает UX только при интеграции в продукт.
• Проектирование с нуля требует стратегии и интерфейсов одновременно.

ЭлСИ — компания, разрабатывающая нейроимпланты. Экосистема включает аппаратные импланты и цифровые интерфейсы для врачей и пациентов.

Я отвечал за проектирование критически важного пользовательского опыта в медпродукте, создаваемом с нуля.

Два разных пользователя (врач и пациент), разные контексты использования, ограничения моторики, высокая цена ошибки и необходимость предсказуемого управления имплантом.

Продукты создавались параллельно с аппаратной частью.

На уровне медицины и бизнеса:

• Безопасное и понятное управление имплантом.
• Снижение риска ошибок.
• Встраивание в рутину врача.
• Повышение качества жизни пациентов.

На уровне продукта:

• Два приложения: врач и пациент.
• Учет физических ограничений пользователей.
• Масштабируемость под новые сценарии лечения.

1. Разделение продуктов по контексту

Отдельные интерфейсы для врача и пациента.

2. UX с учетом двигательных ограничений

Крупные элементы, простые сценарии, отказ от сложных жестов.

3. Безопасность и предсказуемость

Подтверждения, состояния и контроль действий.

• Созданы два продукта с нуля: мобильный и планшетный.
• Интерфейсы учитывали реальные ограничения пользователей.
• Снижены риски пользовательских ошибок.
• Создан устойчивый UX-фундамент для линейки имплантов.

• В медицинских продуктах UX — часть терапии.
• Проектирование начинается с ограничений пользователей.
• Ответственность дизайн-лида выше, чем в большинстве digital-продуктов.

Единая система бэкофиса и CRM-интерфейсов для управления заявками на гранты и государственное финансирование.

Проект реализован для направлений Московское образование и Московское здоровье.

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

Город и управление:

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

Продукт:

• CRM для управления заявками.
• Удобные бэкофисные интерфейсы.
• Поддержка разных ролей и сценариев.
• Масштабируемость под новые программы.

1. Проектирование под роли

Операторы, эксперты, руководители, администраторы — свои сценарии и приоритеты.

2. Прозрачный жизненный цикл заявки

Архитектура построена вокруг состояний заявки.

3. CRM как инструмент решений

Интерфейсы ориентированы на анализ и приоритизацию, а не ввод данных.

• Создана система управления грантовыми заявками.
• Снижена операционная нагрузка.
• Повышена прозрачность процессов.
• Ускорено принятие решений.

Проект стал частью цифровой инфраструктуры управления городом.

• В GovTech UX определяет эффективность процессов.
• CRM-системы требуют проектирования под роли и решения.
• Дизайн-система — ключ к масштабируемости.

Work Here — HR-платформа и CRM для подбора персонала, объединяющая вакансии, резюме и инструменты управления процессом найма.

Я отвечал за проектирование комплексного HR-продукта с CRM и публичной платформой.

На рынке отсутствовали интегрированные инструменты, объединяющие вакансии, резюме и HR-воронку. Work Here решал эту задачу как экосистема.

Бизнес:

• Повысить эффективность найма.
• Сократить ручные операции.
• Создать конкурентный HR-продукт.
• Увеличить вовлеченность пользователей.

Продукт:

• Модульные интерфейсы HR-CRM.
• Простота поиска вакансий.
• Управление кандидатами и коммуникациями.
• Масштабируемая архитектура.

1. CRM как центр управления наймом

Единая база кандидатов, воронка, коммуникации и автоматизация.

2. Воронка кандидатов

Карточки кандидатов, фильтры и интеграции с источниками данных.

3. Баланс соискателя и работодателя

Разные сценарии для соискателей и HR-команд.

• Создан комплексный HR-продукт с CRM.
• Улучшены процессы найма.
• Снижена загрузка рекрутеров.
• Повышена вовлеченность обеих сторон.

• CRM — ядро HR-стратегии.
• UX должен облегчать работу с данными.
• Баланс интересов сторон критичен.

Work Here Mobile — приложение для соискателей, дополняющее web-продукт и HR CRM.

Я отвечал за проектирование mobile-опыта как полноценной части платформы.

Поведение соискателей смещено в mobile: короткие сессии и быстрые отклики. Многие HR-продукты дублируют web без адаптации.

Задача — создать mobile-first опыт, встроенный в экосистему.

Бизнес:

• Увеличить вовлеченность соискателей.
• Повысить частоту возврата.
• Ускорить отклики.

Продукт:

• Mobile-first сценарии поиска.
• Синхронизация с web и CRM.
• Минимальный путь до отклика.

1. Mobile-first сценарии

Быстрый скролл, сохранения, отклик в 1-2 шага.

2. Упрощенная архитектура

Приоритизация контента и действий без потери смысла.

3. Синхронизация с CRM

Статусы откликов и история взаимодействий доступны в mobile.

• Запущено мобильное приложение Work Here.
• Увеличена вовлеченность соискателей.
• Ускорен процесс отклика.
• Создан фундамент для развития mobile-направления.

• Mobile-UX требует отдельной стратегии.
• Упрощение — это приоритизация, а не потеря функциональности.
• Экосистемный подход критичен для HR-платформ.

Gipfel — онлайн-ритейлер товаров для дома и HoReCa. Я отвечал за UX-архитектуру каталога, раздел HoReCa и бренд-медиа.

• Повысить конверсию и средний чек.
• Выделить HoReCa как отдельный сегмент.
• Развить бренд-медиа и вовлеченность.
• Обеспечить визуальную консистентность.

Каталог и навигация выстроены для быстрого поиска. HoReCa — отдельная архитектура. Бренд-медиа встроено в пользовательский путь.

• Каталог стал понятнее и удобнее.
• HoReCa сегмент выделен как самостоятельный.
• Усилено бренд-медиа и вовлеченность.

• В e-commerce структура важнее визуала.
• Проф. сегменты требуют отдельной архитектуры.
• Бренд-контент работает, когда встроен в UX.

Медиапортал о студенческом спорте России. Я отвечал за UX/UI-стратегию, архитектуру сценариев и визуальный язык.

• Повысить вовлеченность и время сессии.
• Обеспечить понятную навигацию по контенту.
• Сделать портал адаптивным и читаемым.

Переработка информационной архитектуры, навигации и визуального языка для массивов контента.

• Портал получил устойчивую структуру.
• Улучшилось восприятие материалов.
• Снизилась сложность навигации.

• В контентных продуктах структура важнее графики.
• UX-архитектура — главный инструмент консистентности.
• Дизайн должен быть гибким и масштабируемым.

Коммуникационный дизайн для промышленной экосистемы СИБУР: маркетинговые и имиджевые материалы, онлайн и офлайн каналы.

• Усилить целостность бренда.
• Повысить качество коммуникаций.
• Выстроить управляемый процесс дизайна.

Повторяемые визуальные паттерны, унификация носителей, системная работа с маркетингом.

• Повышена целостность коммуникаций бренда.
• Сократилось время подготовки материалов.
• Дизайн стал масштабируемым процессом.

• Системность важнее разовых креативов.
• Дизайн-лид работает на стыке бренда и процессов.
• Управление качеством — ключевая ценность.

МТС Медиа — контентная платформа экосистемы МТС. Я отвечал за арт-дирекшн и качество визуальных коммуникаций портала.

Визуальная адаптация под контент, ускорение производства без потери качества, работа в формате партнера.

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

• Арт-дирекшн — ответственность за финальный результат.
• В подрядных проектах критична автономность.

Коммуникационный и маркетинговый дизайн для продуктов и инициатив экосистемы VK.

Работа в жестких бренд-ограничениях, масштабирование креативов, партнерство с маркетингом.

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

• В BigTech-коммуникациях критичны скорость и точность.
• Арт-дирекшн снижает издержки.
• Подрядчик может быть партнером бизнеса.

HR-порталы и сайт найма для массового рекрутинга в fashion-ритейле.

HR-порталы как продукт, отдельный сайт найма как хаб, упрощение восприятия под мобильные сценарии.

• Улучшена конверсия кандидатов.
• Усилен бренд работодателя.
• Упрощено масштабирование кампаний.

• HR-дизайн — продукт с метриками.
• Простота критична для массового найма.
• Сильные коммуникации снижают нагрузку на рекрутинг.

RCC — логистическая компания. Я отвечал за айдентику и дизайн контейнеров как ключевых бренд-носителей.

Высокая контрастность, индустриальная маркировка, масштабируемость и устойчивость к эксплуатации.

• Создан фирменный стиль компании.
• Контейнеры вышли на международные маршруты.
• Бренд получил физическое присутствие по всему миру.

• Индустриальный брендинг должен быть функциональным.
• Физические носители требуют другого мышления.
• Сильный бренд работает в реальных условиях.

HR-портал на HH.ru для транспортно-логистической группы FESCO. Фокус на эффективности входа кандидатов.

Портал как этап воронки найма, максимальное использование ограничений платформы, масштабируемые шаблоны.

• Запущен HR-портал FESCO.
• Повышена читаемость и привлекательность вакансий.
• Упрощено масштабирование HR-коммуникаций.

• HR-порталы — продукт с воронкой и метриками.
• Даже в рамках ограничений можно делать сильный UX.
• Системный подход снижает нагрузку на HR.