Загружаю страницу…
★ flagship · 2025 · флагман
Большая внутренняя система для авиационной команды: много ролей, плотные таблицы, настройки и состояния. Я помог собрать навигацию, фильтры, карточки и модальные сценарии так, чтобы пользователь быстрее понимал, где он находится и что делать дальше.
role
Продуктовый дизайнер в команде: переводил входящие бизнес-задачи в ролевые сценарии, защищал паттерны хедера, фильтров, таблиц и модалок на ревью и готовил решения к разработке вместе с лидом, дизайнерами и инженерами
что изменилось
Типовой путь стал короче на два шага
year
2025
tags
Энтерпрайз · Планирование · Несколько ролей
§ 01 · Контекст
Внутри продукта планировщики собирают расписание рейсов и назначают экипажи: КВС, второго пилота, бортпроводников и старших бортпроводников. Параллельно живут модули обучения, графиков, окон под полёты, общих событий и связок рейсов.
У каждой роли — свой кабинет. Пилоты и бортпроводники видят свои планы, могут запрашивать отпуск, больничный, выходной и обучение. Руководители скорее просматривают и изучают данные.
Сценарий высоконагруженный: большой штат, много зависимостей, плотный набор ограничений и дорогая ошибка в расписании. Раньше такие процессы могли вестись вручную, затем их закрывали legacy-системы с интерфейсной логикой 90-х.
§ 02 · Интерфейс
В кейсе теперь на первом плане интерфейсные кадры из Figma: карточка персонала, фильтры, пресеты и настройка колонок. Схемы ниже оставлены как рабочие материалы, чтобы не подменять продукт абстрактными картинками.
§ 03 · Проблема
Главная проблема была не в одном экране, а в том, что похожие задачи решались по-разному в разных модулях. Хедер смешивал контент-переходы, фильтрацию, переключение роли и запуск модалок. Пользователь не мог заранее понять, что произойдёт по клику.
Та же разрозненность проявлялась дальше: в таблицах горизонтальный скролл уносил критические колонки за край экрана, фильтры были устроены слишком плоско для операционного домена, а модалки расползались в цепочки вложенных окон.
§ 04 · Роль
Подключился на поток бизнес-задач от аналитиков. Формальная зона — макеты для конкретных задач, практическая — собрать повторяемые паттерны, чтобы продукт перестал расходиться по модулям.
Я раскладывал задачи через ролевую модель: какая роль, с какими сущностями она работает, какой сценарий проходит. После этого защищал решения на ревью и передавал их в разработку. Это была team-based работа с лидом, другими дизайнерами и инженерами, не solo ownership claim.
§ 05 · Как смотреть артефакты
Главные изображения в кейсе теперь показывают реальные интерфейсные фрагменты из Figma с закрытыми персональными данными. Схемы ниже оставлены как рабочие материалы: они помогают понять, как решение раскладывалось по хедеру, фильтрам, таблицам и модалкам.
§ 06 · Решение № 01 · Навигация
В старой версии хедер собирал четыре разнородные группы: контент-переключатели, фильтры, переключатель роли, триггеры модалок. Пользователь не мог предсказать, что произойдёт по клику. Конфликты возникали даже на уровне статуса: выбран подраздел, у этого подраздела свой статус — всё это нужно было уместить в одной полоске.
Новая концепция: левая часть — общая информация о модуле и переход между подразделами плюс часть общих действий. Правая часть — только функции, которые влияют на контент текущего раздела.
Часть функций я не вынес ниже по иерархии сознательно: вертикальное пространство в продукте важнее горизонтального, и плодить дополнительный уровень интерфейса было нельзя.
§ 07 · Решение № 02 · Фильтры
Реальные операционные фильтры здесь — это не маркетплейс. Десятки параметров с вложенностями, условиями вида «И / ИЛИ» и группами. Без вложенности пользователь не мог собрать нужный запрос за разумное число кликов.
Я перебрал концепты, в финале вернулся к существующей логике как ядру: оставил её, доработал деталями, переработал поведение. Фильтр стал отдельным самостоятельным функциональным слоем, который повторно применяется в каждом крупном модуле.
Замер UX-шага: путь от выбора фильтра до результата сократился с примерно ==7 кликов до 5==.
§ 08 · Решение № 03 · Таблицы
Таблицы были самым плотным местом. Горизонтальный скролл уносил критические колонки за край экрана, иерархии не было, элементы слипались. Подходы к таблицам в разных модулях расходились — каждый раз решали заново.
Я зафиксировал основные колонки как pinned и развёл уровни визуальной иерархии: ключевые поля — крупнее, вторичные — тише, статусы — отдельным слоем. Долго спорили по UI, в моменте казалось, что решение хорошее, дальше через шторминг приходили к более чистому варианту.
§ 09 · Решение № 04 · Модалки
В старой версии модалки часто открывали другие модалки. Пользователь кликал туда-сюда, терял контекст и нагружался когнитивно. Между уровнями ещё и расходился UI.
Стандартизировал большой формат модального окна. Сценарий, который раньше требовал двух-трёх переключений между уровнями, поместился в один большой формат с внутренними секциями. Универсальный паттерн для типовых форм.
§ 10 · Сигналы эффекта
Изменения для пользователей были не в декоративном UI, а в предсказуемости сценариев: хедер разделил контекст и действия, фильтры начали выражать вложенность, таблицы удержали критические поля, а модалки перестали вести по цепочке вложенных окон.
Local UX measure: типовой путь от выбора фильтра до результата описан как примерно 7 кликов → 5. Это замер сценария, not product KPI.
Qualitative feedback: руководству и заказчику понравился новый вид продукта. Это feedback signal, not quantified metric.
Прямых продуктовых KPI в raw answers нет, поэтому публично не заявляю business impact, adoption, time saved или support reduction.
§ 11 · За NDA
Реальные интерфейсы, реальные данные пилотов, внутренние имена модулей и чувствительный клиентский контекст остаются под NDA. В портфолио — только структурные схемы решений без раскрытия конкретики.
Если важны интерактивные артефакты или production screenshots, их можно обсуждать только в отдельной NDA-границе. Публичная версия показывает product logic и доказательные артефакты, а не операционные детали.