Авиационная операционная система

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

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

Сценарий высоконагруженный: большой штат, много зависимостей, плотный набор ограничений и дорогая ошибка в расписании. Раньше такие процессы могли вестись вручную, затем их закрывали legacy-системы с интерфейсной логикой 90-х.

В кейсе теперь на первом плане интерфейсные кадры из Figma: карточка персонала, фильтры, пресеты и настройка колонок. Схемы ниже оставлены как рабочие материалы, чтобы не подменять продукт абстрактными картинками.

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

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

Подключился на поток бизнес-задач от аналитиков. Формальная зона — макеты для конкретных задач, практическая — собрать повторяемые паттерны, чтобы продукт перестал расходиться по модулям.

Я раскладывал задачи через ролевую модель: какая роль, с какими сущностями она работает, какой сценарий проходит. После этого защищал решения на ревью и передавал их в разработку. Это была team-based работа с лидом, другими дизайнерами и инженерами, не solo ownership claim.

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

В старой версии хедер собирал четыре разнородные группы: контент-переключатели, фильтры, переключатель роли, триггеры модалок. Пользователь не мог предсказать, что произойдёт по клику. Конфликты возникали даже на уровне статуса: выбран подраздел, у этого подраздела свой статус — всё это нужно было уместить в одной полоске.

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

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

Реальные операционные фильтры здесь — это не маркетплейс. Десятки параметров с вложенностями, условиями вида «И / ИЛИ» и группами. Без вложенности пользователь не мог собрать нужный запрос за разумное число кликов.

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

Замер UX-шага: путь от выбора фильтра до результата сократился с примерно ==7 кликов до 5==.

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

Я зафиксировал основные колонки как pinned и развёл уровни визуальной иерархии: ключевые поля — крупнее, вторичные — тише, статусы — отдельным слоем. Долго спорили по UI, в моменте казалось, что решение хорошее, дальше через шторминг приходили к более чистому варианту.

В старой версии модалки часто открывали другие модалки. Пользователь кликал туда-сюда, терял контекст и нагружался когнитивно. Между уровнями ещё и расходился UI.

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

Изменения для пользователей были не в декоративном 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.

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

Если важны интерактивные артефакты или production screenshots, их можно обсуждать только в отдельной NDA-границе. Публичная версия показывает product logic и доказательные артефакты, а не операционные детали.