Travel Marketplace Interface System

Product Context

CoastKey is conceived as a coastal travel marketplace. Users can compare destinations, open cards for places and services, review details and suitable offers, work with the map, and move naturally toward booking.

Behind that simple journey is a more complex model: geography, public locations, commercial inventory, offers, bookings, account scenarios, and B2B operations.

If such a product is designed as a set of separate screens, the connections between search, catalog, map, cards, details, booking, and the vendor workspace quickly become unclear. The work therefore focused on one interface system with a clear entity model, stable scenarios, component contracts, and runtime validation.

Scope of Work

The role in the original product work covered product UX/UI and design-system architecture.

The public CoastKey project is an NDA-safe redesign of that experience. It removes the original brand, client data, and commercial details while preserving product logic and interface structure.

The work was not limited to the visual layer. It involved understanding the product model, breaking it into scenarios, defining component boundaries, and assembling a system that could live in code as well as in design files.

The scope included marketplace-product analysis, consumer and operational journeys, card families, entity detail and booking scenarios, interface-system assembly, and rules for components, layouts, slots, and the boundary between UI, data, and scenario logic.

Another part of the work was assembling the interface system and fixing rules for components, layouts, slots, and boundaries between the interface, data, and scenario logic.

Live Demo

The Live Demo presents the product as a working demonstration environment rather than a static picture. It lets a reviewer open the main scenario, move from search to detail, inspect cards and map behavior, see responsive states, enter the B2B workspace, and follow part of the booking flow.

The public version contains no client data, commercial logic, or private materials. It is an independent demo product that communicates the structure of the system.

One Connected System

The product is assembled from several levels: a catalog for discovery and comparison, distinct card types, detail pages, a booking path, a vendor workspace, and a library of reusable components. These layers needed to work as one service while allowing the team to evolve each scenario independently.

Each level has its own structure, constraints, and states. The public experience must remain calm and legible; the vendor workspace needs greater operational density; booking should guide a decision progressively; and the Showcase should explain the component system without replacing the product.

Entity Model

The complexity is not the number of screens, but the fact that similar elements describe different things. A coastline, beach, club, day pass, individual offer, route, filter, and status cannot be treated as one generic type: each has a different purpose, properties, constraints, and next step.

The model therefore separates meaningful groups. Geography provides context; coastlines, beaches, and routes explain a place. A commercial venue shows where a service is available, while offers define specific choices such as price, conditions, availability, and restrictions. Filters, badges, and statuses remain supporting signals rather than independent product entities.

That distinction directly shapes the UI. A card shows signals appropriate to its type, a detail page reveals conditions and choices, and filters help users compare places and services on meaningful parameters without collapsing different entities into one structure.

Search / Catalog and Map

Search / Catalog is the central exploration scenario. Users switch entity types, refine filters, work with the map, compare options, and move to details. It demonstrates how search, navigation, a responsive grid, and cards work through a shared contract rather than as disconnected blocks.

Once entities are separated, the focus shifts to comparison. The list, map, filters, and active card must communicate one state: when a user refines parameters, both results and map pins change.

The map is part of the interaction scenario. It helps users judge distance, option density, and the relationship between places and available services. They can review results in split view, expand the map, select pins, see preview cards, and open a detail page without losing context.

On mobile this pattern becomes even more important. A travel service is often used to find places near the user or around a selected point, so the map needs a focused mode while retaining its connection to results through a bottom sheet, preview cards, filters, and a clear return to the list.

The pattern is familiar, but it needs to be assembled for CoastKey: list / split-map / map modes, the selected pin, active result, Search this area, favorites, detail links, and distinct card types all operate as one scenario.

No-results is also part of search. When filters or the visible map area yield no matches, the interface keeps the search context, explains the situation, and offers a next step: broaden the search, change filters, or view relevant recommendations.

Search logic lives outside visual components. Components receive prepared cards, filters, map pins, the selected item, detail links, favorites, and action handlers. That lets the presentation adapt to desktop, a full-screen map, or mobile without rewriting scenario rules.

Cards and Detail Pages

In CoastKey, a card is a short contract between an entity and the user’s next step. In a catalog it needs to quickly explain what is being viewed: a coast, beach, commercial venue, route, experience, or a specific offer inside a venue.

The visual rhythm stays consistent—media, title, metadata, badges, favorite action, and CTA—but the primary signals change. Geographic cards emphasize location and context; routes emphasize duration and theme; commercial venues emphasize service type, price, availability, and conditions; offer cards emphasize the parameters needed before booking.

Cards are therefore not reduced to one universal template. Each family has variants for catalog, recommendations, favorites, map previews, and mobile, while data, links, favorites, and handlers come from the runtime layer. The component owns form, states, and hierarchy.

CoastBeachBeach ClubDay PassExperienceRoute

Card media

DesktopMobile

Coastal Area

Forte dei Marmi

Italy, Toscana

SunbedsFood & DrinkWater Activities+5

Forte dei Marmi brings together beaches, bookable coastal venues, Coast Pass access, hosted experiences, and route ideas for time by the water in Italy.

Explore coast

No-media states were designed explicitly. A venue without uploaded photos should not disappear from the catalog or lose its structure; cards retain metadata, the main action, and the path to detail, and available offers can still be selected.

A detail page continues the promise of its card. A coast or beach expands context, description, map, related places, and recommendations. A commercial venue adds services, conditions, offer groups, and the entry to BookingWidget. A route becomes a reading journey rather than a booking page. The family remains flexible while preserving shared navigation, media, sections, and responsive behavior.

One Family, Different Scenarios

A route remains part of the wider detail-page family: it shares the hero, local navigation, favorites, and links to related entities. Inside, however, it becomes a multi-day exploration journey rather than a service catalog or a single booking path. Users work through each day’s plan, categories, and individual stops in sequence.

Changing the day updates both the list and the map context. On desktop, route stops sit beside a pinned map: choosing a stop in either the list or map keeps the active state and focus in sync. On mobile, the same set of stops switches between the list and a full-screen map, with the selected stop opening as a preview without leaving the current day.

The map therefore retains the product’s shared pattern while solving a different problem. In search it supports comparison across results; in a route it connects one day’s stops to their travel order. A route has no standalone BookingWidget: booking appears only through related places and services.

Offer Selection and Booking Flow

Booking in CoastKey should not begin too early. Users first understand a place and its available options: what the place is, which services exist, how they differ, and which conditions matter before a decision. Offers can vary by date, time, guests, capacity, duration, cancellation rules, confirmation, and availability.

Selection therefore lives inside the detail page. The user opens an offer, sets its parameters, and only then adds it to BookingWidget. The interface does not rush payment or turn every service into a separate journey.

BookingWidget acts as the bridge between detail and checkout. Before a selection it remains inactive; after selection it shows a summary of line items, date, guests, and price. Several offers can be collected in one clear list before the booking journey begins.

The booking flow is one step-by-step path: review selected items, enter contact details, pass an account checkpoint, pay, and confirm. Users can build a local draft without registration, but pass an auth gate before payment and final confirmation, so discovery stays light and sign-in appears when it is understandable.

Commercial behavior is simplified in the public demo, but the structure reflects real states: an empty BookingWidget, selected offers, item removal, unavailable options, data checks, draft restoration after authorization, and an explicit final confirmation before creating a booking.

B2B Vendor Workspace

The B2B side is a dedicated workspace for providers. Here the user does not explore places; they manage what appears in the public experience: venues, services, availability, schedules, bookings, messages, team members, and payouts.

The interface needs a different density. The consumer side supports calm comparison, while the B2B workspace must quickly communicate business status: what is published, what needs attention, where new bookings exist, which dates are closed, which messages remain unresolved, and which areas are unavailable because of verification or role.

Rather than build every section as a unique screen, the workspace is decomposed into reusable layout patterns. One layer owns the overall frame, another owns navigation and account areas, followed by modular grids, internal sections, profile states, calendar surfaces, and tables.

These decisions are not limited to B2B. Profile, access-status, and user-verification patterns also support User Profile, vendor verification, and states where part of the interface remains closed until a role or account is confirmed.

To reduce onboarding load, setup is not one long form. A provider first selects the venue or offer type, then describes the place or service step by step—from basic information and operational conditions to media, rules, and trust-and-safety data. Draft saving, visible progress, and review before submission are part of the scenario.

This separates creation of a public entity from later configuration of offers, availability, prices, and booking rules. Access, publication, and daily operations remain distinct modes of work, assembled from shared layout layers, statuses, forms, work lists, and action panels.

The Live Demo shows how one interface system can scale from a consumer marketplace into an operational workspace: different density, priorities, states, and stricter layout rules, without making the user feel that they have entered a different product.

Visual Language

The marketplace visual language uses a calm palette, soft shadows, a clear grid, and restrained typography. Generous space, precise badges, and expressive cards keep the interface light while retaining useful information density.

Search, detail pages, booking, the vendor workspace, and the Showcase need different density, yet remain parts of one service through a shared rhythm, tone, and accent system.

In a travel service, users first understand the place, atmosphere, conditions, and available options. Action hierarchy therefore separates navigation, comparison, and genuine intent to book.

The interface tone reinforces that logic through brief labels, calm states, guidance close to the action, and no unnecessary pressure while a user is still choosing.

Design System in Code

CoastKey’s design system is a working interface model in code. It owns more than visual rules: it clarifies where base UI ends, where a product entity begins, when a component becomes a block, and when a decision belongs to page composition.

Its foundation is a shared interface language of tokens, typography, dimensions, states, and base controls. Above it sit product patterns for cards, filters, offers, map, booking, account, and specialized scenarios; higher still are the blocks and page layouts that assemble catalog, detail, booking, and the vendor workspace.

This avoids turning every screen into a one-off assembly. Components stay reusable because they receive prepared data and understand their states, slots, and constraints. The same rules can assemble scenarios in Live Demo, Showcase, and contract documentation.

Runtime Adapters and Contracts

One of the system’s core rules is that product components do not import source data or generated runtime files directly. They remain a controlled visual layer that receives prepared structure.

Runtime adapters assemble route state, permissions, selected filters, media, favorites, booking drafts, and action handlers. Components own interface anatomy: variants, states, slots, accessibility, and accurate rendering of the supplied data.

That approach keeps logic from spreading across screens. New surfaces are assembled through a contract: which data arrives from the runtime layer, which states the component supports, and where responsibility changes hands.

A component records its owner, public API, slots, variants, states, token relationship, and Showcase coverage. A layout records the page structure: sidebars, content width, responsive behavior, zone placement, height constraints, and slot boundaries.

Component Showcase and Reference Surfaces

CoastKey has a dedicated Showcase layer that complements Live Demo and validates the interface system outside a single user journey. Components, blocks, and page layouts can be reviewed across states, viewport sizes, and content variations.

The public Component Showcase brings together accepted system levels: base UI, product components, larger blocks, page layouts, B2C/B2B surfaces, and validation notes. Reference surfaces are more precise inspection pages for component families, adapter relationships, open states, edge cases, and coverage in real code.

Together, Live Demo shows how a scenario works in the browser, Showcase explains the system and validates repeatable parts, and GitHub holds architecture rules, implementation examples, and boundaries between components, runtime, and the public demonstration.

Design-to-Code Workflow

Figma remains a working design layer where structure, visual language, behavior variants, and future component boundaries are formed.

The design system connects to implementation at the process level. Decisions from Figma become code rules, component boundaries, page layouts, and runtime validation, so visual work can be reviewed against real states, data, and responsive behavior.

Validation happens in runtime. A component needs to match the visual idea, support responsive states, receive real parameters, work in Live Demo, and be inspected separately in Showcase or a reference surface.

AI-assisted workflow is part of that process, while key decisions remain human-led: product logic, visual quality, acceptance criteria, layer boundaries, and final QA. AI can speed up repository orientation, source analysis, small implementation steps, boundary checks, documentation drafts, and handoff notes. Its value is not the fact of using AI, but the control around it: every change has a layer, owner, rules, validation, and a clear handoff.

The Design Engineering, Agent OS, and Process pages explain how this workflow is organized and why the combination matters for product interfaces.

Result

The case demonstrates a managed interface system with a clear hierarchy. Every surface is described as a connected level of one system, so the team can see where a scenario begins, which states a component must support, which data comes from runtime, and which rules govern behavior.

That has a practical effect on product evolution: new surfaces are easier to assemble from described components, patterns, and ownership boundaries. Design is easier to validate in implementation, and changes are easier to discuss through scenarios, states, data, and behavior.

The design system becomes part of the full process rather than an end in itself: a living working structure with its own lifecycle, tasks, and checks that supports more deliberate product and interface decisions.