Дизайн сервиса частных авиаперевозок: как объединить разные роли и сценарии в одном интерфейсе

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

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

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

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

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

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

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

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

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

В бизнес-авиации разные участники процесса привыкли работать с разным представлением времени. Летный персонал использует UTC, а сотрудники, которые общаются с клиентами и пассажирами, — локальное время точки вылета или прилета. Если показать время в непривычном для конкретной роли формате, возрастает риск ошибки.

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

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

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

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

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

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