Coastal Travel Marketplace

Product Context

Coastal Travel Marketplace is not just a catalog of places by the water. Inside a platform like this, several levels live at the same time: geography, public locations, commercial venues, offers, pass products, activities, routes, bookings, and the operational side for providers.

A user may start with a simple task: find a beach, beach club, day pass, activity, or route. But behind that are different data types and different expectations. A beach may be a public place without booking. A beach club may sell loungers, tables, events, or pass access. A route should not lead directly to checkout. An offer card may not be a separate page, but a selection inside a detail page.

That is why the main task of the case is to show how complex marketplace logic becomes a clear UX architecture: search/catalog, map, cards, detail pages, offer selection, booking flow, and account-side scenarios.

Public-safe Redesign and Live Demo

The public version does not show the original brand, commercial details, or confidential materials. Instead, it preserves the type of task, product logic, scenario structure, and interface decisions, while adapting the visual layer and part of the context for the portfolio.

Unlike a static case study, this case has a Live Demo. It is built as a portfolio-grade runtime environment: a working browser surface where key scenarios, card families, map/list sync, responsive behavior, detail pages, offer selection, and booking flow can be reviewed.

The Live Demo is not a production SaaS. Its purpose is to show how a design system, components, and data can work together in an interactive environment, not to replace a commercial product.

Product Complexity and Entity Normalization

The main complexity of a marketplace interface is the hidden heterogeneity of data. On the surface, the user sees cards and filters, but inside the product these are different entities with different logic.

A beach, coastline, beach club, day pass, specific offer, “Pool” filter, “Luxury” badge, and route are not the same level. If they are merged into one generic “object” type, the interface quickly becomes unpredictable: cards start leading to different scenarios, filters turn into marketing tags, and offer items gain unnecessary navigational weight.

That is why the UX architecture starts with separating meanings:

• geography as a navigation context;
• commercial venues as the provider / venue layer;
• offers and pass products as choices inside a venue or provider;
• filters as user intent;
• badges as a short explanation of the result;
• statuses as a reflection of availability, transaction, or moderation logic.

This approach helps keep the interface calm: the card shows a few important signals, the detail page reveals more information, and search/catalog remains a discovery tool rather than a set of random chips.

Geography and the Commercial Layer

The product has a basic geographic structure: country, region, coastline, beach, or physical location. A commercial layer appears on top of it: beach clubs, resorts, restaurants, pass tiers, activities, events, and services.

It is important not to replace one with the other. A public beach can exist as a place without direct booking, while nearby commercial offers may include loungers, tables, day passes, yoga sessions, boat trips, or evening events.

The interface should keep geography as the anchor and show commercial offers as an additional nearby layer. This helps the user understand the context of the place before the interface starts guiding them toward a transaction.

Commercial Inventory and Offer Selection

One provider can sell different types of inventory: beach places, restaurant tables, pool passes, event tickets, activity slots, or service packages. Each offer type has different parameters: date, time, number of guests, capacity, duration, confirmation, cancellation, cost, and availability.

That is why a universal “Book now” for the whole product does not work. Different offer types require different ways to choose parameters, but the user should not feel like they are entering a new product every time.

To support this, offer selection is separated from checkout. The user first configures the offer inside the detail page, then the confirmed selection appears in the BookingWidget, and only after that does the booking flow begin.

Search / Catalog and Map/List Sync

Search / Catalog is one of the key interfaces of the product. It must work at once as search, catalog, filter system, map, and entry point into detail pages.

On desktop, the main pattern is built around a results list and a map. The user can compare cards, understand the geographic context, refine filters, and move to a detail page. The map here is not a decorative block, but a way to understand distances, offer density, and the relationship “place → available nearby.”

On mobile, the behavior changes: map, filters, and results must be accessible through more compact patterns — bottom sheets, fixed actions, preview cards, and map pins. It is important to preserve the connection between the active card, pin, filters, and current map state.

Search state is moved into the runtime layer, which prepares data for visual components. This reduces coupling between the UI, map, filters, and routing, and helps keep interface behavior predictable.

Card Families

Cards in this product are not just a visual pattern. They show what exactly the user is seeing and which scenario is expected next.

The system uses different card families:

• Coast / Beach cards — help users move through geographic context;
• Venue cards — show commercial venues and their main signals;
• Pass cards — represent access to infrastructure or a package of services;
• Activity / Experience cards — focus on duration, format, and theme;
• Route cards — lead to a route, not to checkout;
• Offer cards — exist inside a detail page and help users choose parameters for a specific offer.

The shared visual language remains consistent: image, title, metadata, badges, favorite action, and CTA. But the priorities inside the card change depending on the entity type: in some cases location matters more, in others price, duration, availability, or route theme.

Detail Pages

A detail page is where the user moves from interest to understanding. That is why the page should not be built only around a hero image and a booking button.

The detail family works as a modular shell. Depending on the entity type, it may include a media header, overview, local navigation, amenities, offer groups, BookingWidget, map/location block, policies, reviews, and recommendations.

If an object does not have a certain type of data, the interface does not show empty sections or create false expectations. For example, some objects may have offer groups, others may have a map and related recommendations, and routes may have an itinerary and stop cards.

On desktop, the detail page can use sticky local navigation and a booking sidebar. On mobile, the same functions move into more compact bottom navigation and contextual sheets.

BookingWidget and Booking Flow

The BookingWidget works as a bridge between the detail page and checkout. It does not replace checkout and does not try to collect the entire transaction in one block. Its job is to show the confirmed selection: offer, date, time, number of guests, line items, and subtotal.

The booking flow is built as a single step-by-step scenario that can accept different offer types. The user moves through review, details, auth gate, payment, final confirmation, and confirmation screen.

The auth gate does not appear at the beginning of discovery. The user can explore the catalog, read detail pages, and compare options without registering. Authorization appears where it is explainable: before payment, final confirmation, and saving booking continuity in the account.

Account-side UX

After booking, the user scenario does not end. For a marketplace product, trust is formed not only before payment, but also after it.

Account-side logic includes reservations, reservation detail, payments, notifications, messages, favorites, reviews, and privacy/security. These sections help the user understand booking status, return to details, view documents, manage payment, communicate with the provider or support, and control account data.

For these scenarios, a calm tone is important: booking cancellation, disputed statuses, documents, payments, and privacy actions should not look like an aggressive transactional interface.

B2B Vendor Logic

The B2B side is connected to B2C through data, but it solves different tasks. The provider manages venues, inventory, schedule, prices, cancellation rules, bookings, messages, team, payouts, and publication statuses.

This layer should not be treated as a simple admin panel. For an owner, business overview, venue readiness, payouts, and team matter. For staff, the focus is on daily operations: confirmations, calendar, availability, inventory limits, messages, and customer requests.

Even if the Live Demo is focused on B2C, the B2B model is important for the integrity of the case. It explains where availability, booking rules, statuses, prices, and constraints seen by the user in the public interface come from.

Visual Language

The visual layer is built around a calm curated marketplace: more breathing room, a clean grid, precise badges, image-led cards, and restrained typography.

A travel & hospitality product should not look like an overloaded checkout service. The user should first understand the place, atmosphere, conditions, and available options, and only then move to booking.

That is why the interface supports the transactional path, but does not pressure the user. Cards and detail pages help compare and understand, while the CTA hierarchy separates navigational actions from real booking intent.

Empty states, no-photo states, and no-results states are treated as a normal part of the product. They should preserve the interface structure and give the user a clear next step, rather than looking like an error or temporary placeholder.

Design System and Component Model

The design system in this case is built not only as a visual library, but also as a working component model.

It is divided into several levels:

• Product UI Kit — base elements: buttons, fields, chips, badges, controls, overlays, menus, states;
• Product Components — cards, 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 — rules for assembling Home, Search / Catalog, Detail Pages, Booking Flow, and Account pages;
• Runtime adapters / View-model layer — the layer that prepares routes, map/list state, filters, selected offer, booking draft, and source-backed labels for the UI.

This separation helps avoid mixing visual components, business logic, route state, and data projection. The UI receives prepared props, while the runtime layer is responsible for data and state.

Live Demo

The Live Demo works as a verifiable browser surface for key interface scenarios. It shows:

• different card families in one search space;
• the connection between map and list;
• detail pages assembled from source-backed blocks;
• offer selection and the BookingWidget;
• booking flow;
• responsive behavior;
• empty / no-photo / no-results states.

This format helps verify not only the look, but also the quality of the component model: where separate components are needed, where layout rules are enough, where data should be prepared by an adapter layer, and where the UI should not own business logic.

The Live Demo remains a portfolio-grade demonstration, not a production SaaS. Its purpose is to show how product logic, UX architecture, design system, and frontend-aware workflow can be connected in one runtime environment.

Product Design Pipeline

The work on the case moved from the product model to a working interface system.

First, the domain model was analyzed: geography, venues, providers, offers, filters, badges, booking, account-side scenarios, and B2B logic. Then this model was translated into screen families: Home, Search / Catalog, Detail Pages, Booking Flow, Confirmation, Account Hub, and supporting surfaces.

After that, the key UX patterns were designed: map/list behavior, card families, offer selection, BookingWidget, auth gate, checkout steps, and account-side continuation. Based on this structure, the visual language and component model were formed, and then the runtime demonstration was assembled.

The final layer is documentation and reference surfaces: component ownership, product contracts, page layout rules, validation notes, and handoff logic.

Key UX Decisions

Separate geography, venue, offer, and filter.

This decision became the foundation of the entire architecture. The user can see these elements side by side, but the system needs to understand them separately.

Make Search / Catalog a single engine.

Instead of separate pages for each entity type, the product uses one search logic with different data scopes and card families.

Do not turn every offer into a separate page.

An offer is a choice inside a venue or provider. It can have complex parameters, but it should not break public navigation.

Embed the auth gate into the booking flow.

Registration does not interrupt discovery. It appears only when the user moves to payment and saving the booking in the account.

Design edge states as normal states.

No photo, no results, no inventory, and no reviews are not errors, but regular scenarios in a marketplace product.

Verify the design system in runtime.

The Live Demo shows how the interface works not only on a polished static screen, but also in the browser: with data, states, responsiveness, and transitions.

Result

The result is a public-safe portfolio case that shows several levels of work:

• product analysis of a complex travel marketplace model;
• UX architecture for B2C and B2B scenarios;
• card families, search/catalog, map/list behavior, and detail page logic;
• offer selection, BookingWidget, and booking flow;
• account-side UX;
• a design system built in code;
• Live Demo as a verifiable runtime surface;
• a frontend-aware approach to handoff and component architecture.

The case does not use real commercial metrics, the original brand, or confidential materials. Its value is that it shows the logic of decisions, the structure of the interface, and a way to assemble a complex product as a verifiable system rather than a set of static screens.

The Role of Engineering in the Product Process

In a complex product, design is quickly tested by implementation. If the model of cards, states, layout rules, or runtime boundaries is considered only superficially, it shows up in code: one-off components, local styles, duplicated states, and unclear data contracts appear.

In this case, design engineering is used as a way to verify UX architecture through a working interface system. Product logic is translated into scenarios, components, page layouts, adapters, and reference surfaces. This helps make the interface understandable not only for the user, but also for the team that has to evolve it.