Coastal Travel Marketplace

Контекст продукта

Coastal Travel Marketplace — это не просто каталог мест у воды. Внутри такой платформы одновременно живут несколько уровней: география, публичные локации, коммерческие объекты, предложения, pass-продукты, активности, маршруты, бронирования и операционная сторона поставщиков.

Пользователь может начать с простой задачи: найти пляж, beach club, day pass, активность или маршрут. Но за этим стоят разные типы данных и разные ожидания. Пляж может быть публичным местом без бронирования. Beach club может продавать лежаки, столы, события или pass-доступ. Маршрут не должен вести сразу в checkout. Offer card может быть не отдельной страницей, а выбором внутри detail page.

Поэтому основная задача кейса — показать, как сложная marketplace-логика превращается в понятную UX-архитектуру: search/catalog, карту, карточки, detail pages, offer selection, booking flow и account-side сценарии.

Public-safe redesign и Live Demo

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

В отличие от статичного case study, этот кейс имеет Live Demo. Оно собрано как portfolio-grade runtime environment: рабочая браузерная поверхность, где можно проверить ключевые сценарии, card families, map/list sync, responsive-поведение, detail pages, offer selection и booking flow.

Live Demo не является production SaaS. Его задача — показать, как дизайн-система, компоненты и данные могут работать вместе в интерактивной среде, а не заменить коммерческий продукт.

Продуктовая сложность и нормализация сущностей

Главная сложность marketplace-интерфейса — скрытая разнородность данных. На поверхности пользователь видит карточки и фильтры, но внутри продукта это разные сущности с разной логикой.

Пляж, побережье, beach club, day pass, конкретное предложение, фильтр “Pool”, бейдж “Luxury” и маршрут — это не один и тот же уровень. Если смешать их в общий тип “объект”, интерфейс быстро становится непредсказуемым: карточки начинают вести в разные сценарии, фильтры превращаются в маркетинговые теги, а offer-предложения получают лишний навигационный вес.

Поэтому UX-архитектура начинается с разделения смыслов:

• география как навигационный контекст;
• коммерческие объекты как provider / venue layer;
• offers и pass-продукты как выбор внутри объекта или поставщика;
• фильтры как пользовательское намерение;
• бейджи как краткое объяснение результата;
• статусы как отражение availability, transaction или moderation logic.

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

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

В продукте есть базовая географическая структура: страна, регион, побережье, пляж или физическая локация. Поверх неё появляется коммерческий слой: beach clubs, resorts, рестораны, pass-тарифы, активности, события и сервисы.

Важно не подменять одно другим. Публичный пляж может существовать как место без прямого бронирования, а рядом с ним могут находиться коммерческие предложения: лежаки, столы, day pass, yoga session, boat trip или вечернее событие.

Интерфейс должен сохранить географию как якорь, а коммерческие предложения показать как дополнительный слой рядом. Это помогает пользователю понять контекст места до того, как интерфейс начнёт вести к транзакции.

Коммерческий инвентарь и offer selection

Один поставщик может продавать разные типы инвентаря: места на пляже, restaurant table, pool pass, event ticket, activity slot или service package. У каждого типа предложения разные параметры: дата, время, количество гостей, вместимость, длительность, подтверждение, отмена, стоимость и availability.

Поэтому универсальный “Book now” для всего продукта не работает. Разные offer types требуют разных способов выбора параметров, но пользователь не должен ощущать, что каждый раз попадает в новый продукт.

Для этого offer selection отделён от checkout. Пользователь сначала настраивает предложение внутри detail page, затем подтверждённый выбор попадает в BookingWidget, и только после этого начинается booking flow.

Search / Catalog и map/list sync

Search / Catalog — один из ключевых интерфейсов продукта. Он должен работать сразу как поиск, каталог, фильтр-система, карта и вход в detail pages.

На desktop основной паттерн строится вокруг списка результатов и карты. Пользователь может сравнивать карточки, смотреть географический контекст, уточнять фильтры и переходить в detail page. Карта здесь не декоративный блок, а способ понять расстояния, плотность предложений и связь “место → рядом доступно”.

На mobile поведение меняется: карта, фильтры и результаты должны быть доступны через более компактные паттерны — bottom sheets, fixed actions, preview cards и map pins. Важно сохранить связь между активной карточкой, pin, фильтрами и текущим состоянием карты.

Состояние поиска вынесено в runtime-слой, который подготавливает данные для визуальных компонентов. Это снижает связность между UI, картой, фильтрами и маршрутизацией и помогает сохранять предсказуемое поведение интерфейса.

Card Families

Карточки в этом продукте — не просто визуальный паттерн. Они показывают, что именно пользователь видит и какой сценарий ожидает дальше.

В системе используются разные card families:

• Coast / Beach cards — помогают двигаться по географическому контексту;
• Venue cards — показывают коммерческие объекты и их основные сигналы;
• Pass cards — представляют доступ к инфраструктуре или пакету услуг;
• Activity / Experience cards — фокусируются на длительности, формате и тематике;
• Route cards — ведут к маршруту, а не к checkout;
• Offer cards — существуют внутри detail page и помогают выбрать параметры конкретного предложения.

Общий визуальный язык сохраняется: изображение, заголовок, метаданные, бейджи, favorite action и CTA. Но приоритеты внутри карточки меняются в зависимости от типа сущности: где-то важнее location, где-то price, где-то duration, где-то availability или route theme.

Detail Pages

Detail page — это место, где пользователь переходит от интереса к пониманию. Поэтому страница не должна строиться только вокруг hero image и кнопки бронирования.

Detail family работает как модульный shell. В зависимости от типа сущности он может включать media header, overview, local navigation, amenities, offer groups, BookingWidget, map/location block, policies, reviews и recommendations.

Если у объекта нет определённого типа данных, интерфейс не показывает пустые секции и не создаёт ложных ожиданий. Например, у одних объектов могут быть offer groups, у других — карта и связанные рекомендации, у маршрутов — itinerary и stop cards.

На desktop detail page может использовать sticky local navigation и booking sidebar. На mobile те же функции переносятся в более компактные bottom navigation и контекстные sheets.

BookingWidget и booking flow

BookingWidget работает как мост между detail page и checkout. Он не заменяет checkout и не пытается собрать всю транзакцию в одном блоке. Его задача — показать подтверждённый выбор: offer, дату, время, количество гостей, line items и subtotal.

Booking flow строится как единый пошаговый сценарий, который может принимать разные типы предложений. Пользователь проходит review, details, auth gate, payment, final confirmation и confirmation screen.

Auth gate не появляется в начале discovery. Пользователь может исследовать каталог, читать detail pages и сравнивать варианты без регистрации. Авторизация появляется там, где она объяснима: перед оплатой, финальным подтверждением и сохранением booking continuity в аккаунте.

Account-side UX

После бронирования пользовательский сценарий не заканчивается. Для marketplace-продукта доверие формируется не только до оплаты, но и после неё.

Account-side логика включает reservations, reservation detail, payments, notifications, messages, favorites, reviews и privacy/security. Эти разделы помогают пользователю понимать статус бронирования, возвращаться к деталям, видеть документы, управлять оплатой, общаться с поставщиком или поддержкой и контролировать данные аккаунта.

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

B2B Vendor Logic

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

Этот слой нельзя воспринимать как простую админку. Для владельца важны бизнес-обзор, готовность объектов, выплаты и команда. Для staff — ежедневные операции: подтверждения, календарь, availability, лимиты инвентаря, сообщения и клиентские запросы.

Даже если Live Demo сфокусировано на B2C, B2B-модель важна для целостности кейса. Она объясняет, откуда берутся availability, правила бронирования, статусы, цены и ограничения, которые пользователь видит в публичном интерфейсе.

Визуальный язык

Визуальный слой построен вокруг спокойного curated marketplace: больше воздуха, чистая сетка, аккуратные бейджи, image-led карточки и сдержанная типографика.

Travel & hospitality продукт не должен выглядеть как перегруженный checkout-сервис. Пользователь сначала должен понять место, атмосферу, условия и доступные варианты, а уже потом перейти к бронированию.

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

Empty states, no-photo states и no-results states рассматриваются как нормальная часть продукта. Они должны сохранять структуру интерфейса и давать пользователю понятный следующий шаг, а не выглядеть как ошибка или временная заглушка.

Дизайн-система и компонентная модель

Дизайн-система в этом кейсе собрана не только как визуальная библиотека, но и как working component model.

Она делится на несколько уровней:

• Product UI Kit — базовые элементы: buttons, fields, chips, badges, controls, overlays, menus, states;
• Product Components — карточки, offer rows, reservation rows, notification rows, payment methods, filter units;
• Component Blocks — search toolbar, filter panels, hero media header, detail blocks, BookingWidget, account sections;
• Page Layouts — правила сборки Home, Search / Catalog, Detail Pages, Booking Flow и Account pages;
• Runtime adapters / View-model layer — слой, который подготавливает routes, map/list state, filters, selected offer, booking draft и source-backed labels для UI.

Такое разделение помогает не смешивать визуальный компонент, бизнес-логику, route state и data projection. UI получает подготовленные props, а runtime layer отвечает за данные и состояние.

Live Demo

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

• разные card families в одном поисковом пространстве;
• связь карты и списка;
• detail pages, собранные из source-backed блоков;
• offer selection и BookingWidget;
• booking flow;
• responsive-поведение;
• empty / no-photo / no-results states.

Этот формат помогает проверить не только внешний вид, но и качество компонентной модели: где нужны отдельные компоненты, где достаточно layout rules, где данные должны готовиться adapter layer, а где UI не должен владеть бизнес-логикой.

Live Demo остаётся portfolio-grade демонстрацией, а не production SaaS. Его задача — показать, как продуктовая логика, UX-архитектура, дизайн-система и frontend-aware workflow могут быть связаны в одной runtime-среде.

Product Design Pipeline

Работа над кейсом двигалась от продуктовой модели к рабочей интерфейсной системе.

Сначала была разобрана доменная модель: география, объекты, поставщики, offers, filters, badges, booking, account-side сценарии и B2B-логика. Затем эта модель была переведена в screen families: Home, Search / Catalog, Detail Pages, Booking Flow, Confirmation, Account Hub и supporting surfaces.

После этого были спроектированы ключевые UX-паттерны: map/list behavior, card families, offer selection, BookingWidget, auth gate, checkout steps и account-side continuation. На основе этой структуры сформирован визуальный язык и компонентная модель, а затем собрана runtime-демонстрация.

Финальный слой — документация и reference surfaces: component ownership, product contracts, page layout rules, validation notes и handoff logic.

Ключевые UX-решения

Разделить географию, объект, offer и фильтр.

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

Сделать Search / Catalog единым engine.

Вместо разных страниц для каждого типа сущности используется единая поисковая логика с разными data scopes и card families.

Не превращать каждый offer в отдельную страницу.

Offer — это выбор внутри объекта или поставщика. Он может иметь сложные параметры, но не должен ломать публичную навигацию.

Встроить auth gate в booking flow.

Регистрация не мешает discovery. Она появляется только тогда, когда пользователь переходит к оплате и сохранению бронирования в аккаунте.

Проектировать edge states как нормальные состояния.

No photo, no results, no inventory и no reviews — не ошибки, а штатные сценарии marketplace-продукта.

Проверить дизайн-систему в runtime.

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

Результат

В результате получился public-safe portfolio case, который показывает несколько уровней работы:

• продуктовый анализ сложной travel marketplace-модели;
• UX-архитектуру для B2C и B2B-сценариев;
• card families, search/catalog, map/list behavior и detail page logic;
• offer selection, BookingWidget и booking flow;
• account-side UX;
• дизайн-систему, собранную в коде;
• Live Demo как проверяемую runtime-поверхность;
• frontend-aware подход к handoff и компонентной архитектуре.

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

Место инжиниринга в продуктовом процессе

В сложном продукте дизайн быстро проверяется реализацией. Если модель карточек, состояний, layout rules или runtime boundaries продумана поверхностно, это проявляется в коде: появляются одноразовые компоненты, локальные стили, дублирующиеся состояния и нечёткие контракты данных.

В этом кейсе design engineering используется как способ проверить UX-архитектуру через рабочую интерфейсную систему. Продуктовая логика переводится в сценарии, компоненты, page layouts, adapters и reference surfaces. Это помогает сделать интерфейс понятным не только для пользователя, но и для команды, которая должна его развивать.