Операционный контур

Продукт: авиационная операционная система под NDA.

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

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

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

Граница результата: один типовой путь в фильтрах стал короче с 7 до 5 шагов. Это замер конкретного интерфейсного пути, не бизнес-KPI.

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

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

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

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

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

Я разложил работу на простой путь:

1. Пользователь попадает в нужный контекст.
2. Сужает данные до рабочего набора.
3. Читает таблицу или карточку.
4. Выбирает действие.
5. Проверяет, что изменилось.

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

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

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

Продукт уже строился на Ant Design и существующей дизайн-системе. Она давала базовые компоненты и общую визуальную опору.

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

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

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

Минимальный набор для сильной версии:

1. Общая карта продукта: роли, сущности, сценарии и части интерфейса.
2. Карта работы в Figma: сколько направлений и итераций было в работе.
3. Схема: существующая дизайн-система -> сложные сценарии -> единые паттерны взаимодействия.
4. Отдельный блок по хедеру: варианты, финальная логика, ограничения по месту.
5. Отдельный блок по фильтрам: концепты, дерево условий, путь 7 -> 5.
6. Отдельный блок по таблицам: плотность, закрепленные колонки, статусы, настройки представления.
7. Отдельный блок по модалкам: цепочка вложенных окон против большого рабочего окна.
8. Отдельный блок по повторяемым сценариям: фильтры, таблицы, модалки, настройки представлений, возврат к контексту.
9. Финальная карта: какие паттерны взаимодействия стали одинаковыми в разных модулях.

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

Я проверял это через несколько решений:

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

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

Для операционного контура этот путь выглядит так:

1. Понять текущий раздел и выбранную сущность.
2. Сузить данные до рабочего набора.
3. Прочитать строку, статус и ограничения.
4. Выполнить действие.
5. Вернуться в исходный контекст и проверить результат.

Каждая часть интерфейса отвечает за свой кусок этого пути. Хедер держит ориентацию. Фильтры собирают запрос. Таблица помогает читать состояние. Модалка проводит через действие. Общие правила интерфейса удерживают повторяемость.

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

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

Я разделил хедер на две зоны:

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

Так хедер перестает быть случайным набором функций. Он становится короткой картой текущего состояния.

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

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

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

По фильтрам было много вариантов. В финале мы не стали ломать текущую логику ради красивой новой схемы. Оставили ядро, доработали детали, пересобрали поведение и сделали путь более управляемым.

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

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

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

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

Я раскладывал таблицу по тому, как ее реально читают:

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

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

В первую очередь я смотрел на простые вещи:

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

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

Дизайн-система в продукте уже была. Я не собирал базовую библиотеку компонентов. Моя зона была в другом: повторяемые паттерны взаимодействия для сложных сценариев.

В разных модулях снова и снова появлялись похожие задачи:

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

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

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

Отдельные решения важны, но кейс должен собираться в один путь.

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

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

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

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

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

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

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

Для публичного слоя подходят:

• figma-1-28075-preset-modal.png как самый безопасный прямой источник по механике пресета после финальной визуальной проверки;
• figma-1-28062-presets-panel.png после кадрирования и очистки;
• презентационные сцены, явно подписанные как объясняющие артефакты;
• очищенные фрагменты, где убраны лица, имена, даты, контакты, адреса и поля с персональными данными.

Я пересобирал не отдельный экран, а повторяемую логику авиационного операционного продукта. Хедер помогал понять, где пользователь находится. Фильтры собирали рабочий запрос. Таблицы помогали читать статусы и ограничения. Большие модалки вели через действие без потери контекста.

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

• Какие авиационные скриншоты можно окончательно показывать после очистки?
• Оставляем публичное название Операционный контур или добавляем русское уточнение про авиационный контекст?
• Какие сущности безопасно называть: рейс, экипаж, обучение, план, событие?
• Есть ли подтвержденный путь для 7 -> 5 с точными шагами?
• Что ставим в первый экран: модалку пресета, очищенный фрагмент интерфейса или черновой кандидат обложки?
• Какие Figma-доски и итерации можно безопасно показывать крупно, чтобы кейс не выглядел как четыре маленькие задачи?
• Какие артефакты делаем первыми: карту масштаба работы, схему "дизайн-система -> сценарии -> паттерны взаимодействия", хедер, фильтры, таблицу, модалку или карточку границы источников и NDA?

Ниже отдельный слой объясняющих артефактов: флоу, рабочие компромиссы и JTBD. Они не заменяют source-материалы, а помогают публично показать логику без раскрытия NDA.