CASE STUDY 02 / 04

End-to-end leadInteraction designUI/UX QA

Extending business-trip booking from flights to hotels.

Mbiztravel extended its booking experience to support hotels alongside flights, inside the same trip, approval and document trail. Starting from the PM’s brief, I led the process through UI, UX and product QA, with another designer supporting UI execution.

Role: End-to-end design lead · UI/UX QA
Worked with: PM (brief), a designer (UI execution)
Status: Design · UI/UX QA
Platform: Web · buyers & travel agents

Mbiztravel Hotels: annotated product screen

Annotated screen from the Mbiztravel design file. Travel-agent names are blurred; the hotel listing is sample data from the file.

The 30-second version

The problem

Mbiztravel started with flights only. Listings, detail pages and documents all assumed an order was a flight.

My contribution

I led the design process from the PM’s brief to QA, and ran UI, UX and product QA. Another designer supported UI execution.

Status

Design and UI/UX QA. Production metrics are not included in this case study.

Who it’s for

One business trip, three parties involved.

A government business trip usually means a flight and a hotel, with the same travellers, travel order and budget.

Agency buyers

Create the trip, book, and download the voucher and e-receipt.

Approvers

Approve the trip level by level before orders are processed.

Travel agents

Sell hotels with their own margins and payment terms, and process the bookings.

The problem

Business need, user need, design response.

Hotels had to fit a product built around flights, for buyers and travel agents alike.

Business need

Hotels alongside flights

Mbizmarket Travel serves hotel bookings, not only flights. Registered travel agents sell hotels with their own margins and payment policies, and each hotel transaction produces its own order, invoice, payment and platform-fee documents.

User need

One trip, one approval, clear proof

Buyers book hotels for the same trip and travellers, approvers sign off on the trip, and agents need the stay details on every document.

Design response

Trip first, hotels inside it

The trip holds the bookings, travel agents are compared inside each hotel result, and one accommodation-type marker runs through every document.

Role, team & status

My contribution and collaboration.

I owned the design process from the brief to QA. Leading the process didn’t mean drawing every screen: another designer handled part of the UI execution.

My part

Process lead and QA

Took the PM’s brief through design to QA, and ran UI, UX and product QA.

Other designer

UI execution

Supported the execution of the UI screens.

Brief

Set the brief the design worked from.

Key decisions

Three decisions in the design.

The trip is the container, bookings come after.

The call: People create one trip in four steps: details, estimated cost, travel documents and travellers. Approval runs on the trip, then flight and hotel orders are created under it.
Why: One travel order covers the whole trip, so approval sits on the trip rather than on each order.
For comparison: Approval on every order.
Trade-off: Flight and hotel orders still each produce their own order, invoice, payment and platform-fee documents.

Illustration made for this page from the design file.

Compare travel agents inside the hotel result.

The call: Under each hotel in the results, the travel agents selling it are listed with their price, payment-term label and corporate discount label.
Why: The same hotel is sold by several agents at different prices and terms.
For comparison: One price per hotel, with agents chosen later in checkout.
Trade-off: Result cards get taller.

Illustration made for this page from the design file. Travel-agent names are blurred.

One accommodation-type marker everywhere.

The call: An accommodation-type column and filter were added to approvals, orders, invoices, payments and platform fees on both buyer and agent sides. Hotel orders show a stay-details box and a voucher status.
Why: The same marker everywhere keeps buyers and agents reading an order the same way.
For comparison: Separate hotel menus next to the flight menus.
Trade-off: Busy tables gain a column; the filter splits flights and hotels in one click.

Illustration made for this page from the design file.

Testing & results

QA, outcome and what to measure.

My QA role, what the design covers, and the indicators worth tracking. Production metrics are not included in this case study.

UI, UX and product QA

I ran UI, UX and product QA.

Design scope

Hotel booking in the trip flow

Hotel search, trip creation, tiered approval, orders, invoices, payments, platform fee, voucher and e-receipt are covered in the design and the feature documentation.

Measure next

Bookings and support

Booking completion, errors in guest data, and how often buyers or agents need help.

Looking back

One trip already means one approval. One invoice per trip is the next question.

Each hotel booking still creates its own order, invoice, payment and platform-fee documents.

Screens

From creating a trip to booking the room.

Screens from the Mbiztravel design file, shown in browser frames. Traveller and user details are blurred.

NEXT · CASE STUDY 03 / 04