KhooshsafarKhooshsafar

Khoshsafar is a travel and accommodation-booking platform. I joined from the early stages and designed the guest experience, host panel, and back office. My work extended from requirements and product proposals to interface design, design systems, and collaboration during development.

The guest and host site is ready for release, while the back office is in the final stage of development. This case study covers how the product and its design decisions took shape; no outcomes from public use have been reported.

The problem and goal

Guests needed clear information about properties, capacity, pricing, cancellation terms, and booking status. Hosts needed to register their properties, correct application issues, and manage reservations, calendars, and income. Operations needed a workspace for reviewing properties and tracking requests.

The goal was to connect these three experiences so that registration, review, booking, and support states were clear, and each role knew what action was available next.

My role and collaboration

The team consisted of me, a full-stack developer, and the CEO. I designed all the areas described here. I wrote PRDs for the website and CRM, carried out product discovery and competitor analysis, defined journeys, designed UX/UI, documented the work, and built the website’s design system.

I proposed design, product, and business decisions with supporting reasoning. The CEO reviewed them and approved most of the proposals. Development was handled by the full-stack developer; final business approval remained with the CEO.

Scope and how we explored it

The first phase focused on accommodation and the core guest, host, and operations journeys. Tours, AI trip planning, and advanced integrations were kept for later. I documented requirements, roles, flows, states, and acceptance criteria in the website and CRM PRDs.

We explored scenarios using fictional personas simulated with AI models. No real people participated, and this was not user research or usability testing. A potentially long and difficult host-registration process emerged as a risk. Showing the current step and progress became a design hypothesis for reducing uncertainty; its effectiveness has not been tested with real hosts.

Finding and choosing a stay

The main journey starts with a destination, dates, and guest count, then moves through search, filters, results, and property details. The requirements put pricing basis, capacity, amenities, rules, and cancellation terms before the booking request. Returning from property details should preserve the search and filters.

Mobile and desktop share the same core tasks, with controls adapted to the available space—for example, a bottom sheet for mobile filters and a booking summary suited to each screen size.

A request is not a confirmed booking

Where host approval is required, sending a request does not confirm the booking. Waiting for the host, approval, and waiting for payment need distinct states. The PRD also defines the next action for response deadlines, payment deadlines, rejection, and expiry.

The approved product model allows up to three active requests for overlapping dates. When one is confirmed, the others close without a penalty. This is a defined product rule, not a measured improvement in booking success.

Following up an uncertain payment

The payment contract separates successful, failed, and uncertain results. For an uncertain result, it defines an “Under review” status, a tracking reference, and a support route. Another payment is blocked until the result is resolved.

The interface should not promise a review or refund time without an approved financial policy. The guest sees the status and follow-up route, while financial review and support have an identified owner.

Showing progress during registration

In response to the hypothetical risk around registration length, I added the current step and progress to the flow so hosts could see where they were. The aim was to reduce uncertainty about the remaining steps, not to claim a proven reduction in anxiety or drop-off.

Registration collects property details, location, capacity, amenities, photos, ownership, pricing, and rules. Draft saving, validation, and review before submission are also defined in the PRD; these requirements are separate from the hypothesis raised by the AI scenario exercise.

Separating a property group from its units

For a hotel or ecolodge, shared information is entered once, while each unit has its own capacity, price, calendar, and inventory. Publishing a unit depends on approval of both the unit and its property group.

This model affects host registration and the guest’s choice: the selected unit must connect to the same price and inventory in the booking. The PRD documents this relationship; some handoff details remained open in older versions.

Managing the property

The host panel covers properties, bookings, calendars, messages, wallet status, and settlements. Incomplete, under-review, correction-required, and active states offer different actions, so hosts know whether to continue registration, make corrections, or manage the property.

Reviewing a request without losing the queue

The CRM experience includes a queue summary, search and filters, a table, and a quick preview. The preview is intended to let an operator inspect a request without losing their place or filters; full handling continues in that request’s details.

This structure is designed for someone monitoring several requests who needs to identify status, ownership, and urgency.

Separating work status from access

The PRD distinguishes specialist, supervisor, manager, and senior-manager roles. A specialist’s own case, a teammate’s case, and an unassigned case do not offer the same actions: handling their own case, limited viewing of a teammate’s case, and taking an unassigned case.

For temporary supervisor handling, the original owner and temporary handler are shown separately. Roles are connected to visible information, permitted actions, and history. Technical permission enforcement belongs to development.

Connecting host corrections to internal review

Property review is divided into areas such as location, amenities, images, documents, pricing, and rules. Correction requests have specific reasons. On resubmission, changed areas are identified for review, while approvals for unchanged areas are retained.

I designed both sides: hosts need to understand what to correct, and operators need to inspect that same change. Final approval and publication are defined as separate actions with history.

Errors and recovery

For recoverable errors, the requirements preserve response text and user selections. When access is revoked, sensitive information must not be retained. First-use empty states, empty filtered results, connection loss, and conflicts have different responses. These are behavioral requirements, not successful test results.

A dedicated website system

I built the website design system with primitive and semantic variables for color, spacing, and corner radius. Semantic spacing has mobile and desktop modes; the grid covers mobile, tablet, and desktop.

Alongside general controls, it includes property cards, guest count, date range, price summaries, booking controls, and guest and host calendars. The booking-control example has mobile and desktop versions, enabled and disabled states, and variable-bound color, radius, and shadow.

Adapting Fluent 2 for the back office

For the back office, I used Fluent 2 as a starting point: I selected the needed components, adapted and optimized them for Persian, and built the product-specific components. The file documents Kalameh typography with Persian line heights, zero letter spacing, and separate roles for headings, body text, labels, and data.

It includes compact, comfortable, and spacious display densities, plus rules for mixed content such as numbers, identifiers, and dates. Status, priority, table, filter, and property-review components connect these foundations to CRM operations.

Documenting behavior

Handoff included more than the appearance of screens. The PRDs define roles, flows, states, business rules, and acceptance criteria. Readiness is considered at flow and page level, so having a design does not imply that every behavior is ready.

The guest and host site is ready for release; the back office is in the final stage of development. The current output covers these three experiences, two PRDs, and two design systems: a dedicated website system and a Fluent 2 adaptation for the internal workspace.

There are no reported public-use outcomes, changes in booking rate, or changes in host-registration completion. The progress display responds to a design hypothesis and still needs evaluation with real hosts.