Системное проектирование туристического маркетплейса

Контекст и проектная задача

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

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

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

Модель продукта и UX-архитектура

География и коммерческий слой

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

Географическая сущность может быть полезна без коммерческого предложения: пользователь изучает побережье, пляжи и окружение. Bookable inventory появляется на другом уровне — у подготовленного объекта или услуги с действующими Offer, правилами доступности и связью с поставщиком. Это разделение сохраняет широкий discovery-сценарий и одновременно не превращает каталог в открытый справочник непроверенных услуг.

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

• Coast и Beach формируют discovery-контекст и могут существовать без коммерческого предложения.
• Vendor и публичный объект связывают место, услуги и поставщика.
• Offer хранит конкретные условия выбора: цену, доступность, время и ограничения.
• Route использует те же сущности как точки маршрута и сохраняет собственную последовательность и навигацию.

Карточки и подробные страницы

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

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

Подробная страница продолжает обещание карточки. Coast и Beach раскрывают географию и связанные места; коммерческий объект добавляет условия, услуги и Offer-группы; Route становится сценарием чтения маршрута. Общая навигация, медиа-зона и адаптивные правила связывают эти страницы в одно семейство без универсального шаблона для разных задач.

Связанные пользовательские сценарии

Поиск, фильтры и карта

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

Карта помогает оценить расстояния, плотность вариантов и связь между местами и доступными услугами. В desktop split view выбранный pin, активный результат и preview-карточка синхронизированы. Пользователь может расширить карту, изменить область поиска и перейти к деталям без потери фильтров и выбранного контекста.

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

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

Route Detail

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

В поиске карта помогает сравнивать варианты общей выдачи, а в Route Detail связывает точки одного дня с порядком движения. На мобильном тот же набор точек переключается между списком и полноэкранной картой. У маршрута нет собственного BookingWidget: связанные bookable stops переводят пользователя в стандартный сценарий объекта и предложения.

Offer selection и Booking Flow

Бронирование начинается после того, как пользователь разобрался с объектом и доступными вариантами. Offer selection собирает параметры конкретной услуги: дату, время, количество гостей, вместимость, длительность, правила отмены, способ подтверждения и доступность.

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

Booking Flow проводит выбранное предложение через review, контактные данные, account checkpoint, оплату и подтверждение. Гостевой пользователь может подготовить локальный draft, а auth gate появляется перед платёжным шагом и возвращает его к сохранённому состоянию без автоматического подтверждения.

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

Общая система для B2C и B2B

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

Access, onboarding и publishability

В B2B-контуре разделены доступ в систему, подготовка сущностей к публикации и ежедневная работа. Регистрация отвечает на вопрос, кто получает доступ; onboarding — что именно поставщик публикует; workspace — как он управляет уже работающим присутствием и бронированиями.

Public-facing объект и bookable inventory создаются на разных шагах. Поставщик получает доступ, проходит необходимые проверки, создаёт объект, добавляет предложения и правила доступности, отправляет материалы на moderation. Только подготовленные и одобренные сущности становятся видимыми и доступными для бронирования в B2C.

Setup разбит на последовательные участки вместо одной длинной формы. Пользователь выбирает тип объекта или предложения, добавляет основную информацию, операционные условия, медиа, правила и trust/safety-данные. Черновик, прогресс, предварительная проверка и review-state поддерживают возврат к незавершённой работе.

Операционное рабочее пространство

Vendor Workspace показывает другой уровень плотности и приоритетов. Здесь важно быстро увидеть, что опубликовано, какие действия ожидаются, где появились бронирования, какие даты закрыты, какие сообщения не обработаны и какие разделы ограничены ролью или проверкой аккаунта.

Рабочая зона собрана из повторяемых layout-паттернов: общего shell, навигации и account-зон, модульных overview-сеток, внутренних разделов, календарных и табличных поверхностей, status и action panels. Паттерны профиля, доступа и проверки применяются и в пользовательском аккаунте, и в vendor verification.

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

CoastKeyOnboarding и публикация

Здесь будет показана цепочка access → object setup → inventory setup → moderation → public visibility и bookability.

CoastKeyСвязь B2C и B2B

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

Компоненты и проверка в реализации

От продуктового решения к компонентной модели

Интерфейсная система строилась по уровням: foundations и Product UI Kit задают базовые правила, Product Components описывают повторяемую продуктовую анатомию, крупные блоки собирают законченные участки сценария, а Product Page Layouts фиксируют композицию страниц и потоков.

Эта структура следует продуктовой логике. Семейства карточек фиксируют разные информационные приоритеты сущностей; filter containers отделяют механику панели от taxonomy и выбранного состояния; map shells задают композицию без присвоения логики карты; booking components разделяют выбор предложения, сводку и пошаговое оформление.

• Product UI Kit — контролы, состояния и базовые продуктовые примитивы.
• Product Components — карточки, элементы выбора и повторяемые продуктовые единицы.
• Component Blocks — фильтры, media headers, booking и другие законченные части сценария.
• Product Page Layouts — правила сборки поиска, подробных страниц, Booking Flow и Vendor Workspace.

Runtime boundary и проверка

Граница между интерфейсом и runtime-логикой оформлена через adapters и UI-контракты. Компоненты владеют анатомией, вариантами, состояниями, слотами и доступностью; адаптеры передают подготовленные данные, навигацию, callbacks, session и map state.

Для Search / Catalog адаптер связывает taxonomy фильтров, результаты, избранное, выбранный pin и режим карты. Detail adapter собирает модель объекта, медиа, Offer, booking callbacks и переходы. Компоненты получают готовый контракт и могут менять responsive-представление без переноса продуктовой логики в визуальный слой.

Для повторяемого компонента фиксируются публичный API, варианты, состояния, slots, связь с токенами и проверочная поверхность. Для layout описываются состав зон, responsive-перестройка, ограничения и точки подключения сценария. Это позволяет обсуждать изменение через его владельца и контракт, а не через копию конкретного экрана.

Live Demo проверяет связные сценарии в работающем интерфейсе, Showcase показывает компоненты и layouts изолированно, а репозиторий фиксирует contracts, владельцев и правила проверки. Эти поверхности дополняют кейс, но остаются самостоятельными источниками публичных доказательств.

CoastKeyСлои интерфейсной системы

Здесь будет схема Product UI Kit → Product Components → Component Blocks → Product Page Layouts → runtime adapters.

CoastKeyСвязь дизайна и реализации

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

Результат и публичные материалы

В результате многослойная модель marketplace была собрана в связанную B2C/B2B-систему. Семейства сущностей и сценариев получили явные границы, повторяемые интерфейсные решения были вынесены в компоненты и layouts, а ключевые связи проверены в работающей реализации.

• Связный discovery- и booking-сценарий от поиска до подтверждения.
• Отдельная B2B-архитектура для публикации и операционной работы поставщиков.
• Компонентная система с зафиксированными состояниями, вариантами и границами ответственности.
• Три независимые поверхности проверки: Live Demo, Showcase и техническая документация.

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