# Booking Performance Dashboard

Designing the metrics surface hotel partners use to see where their revenue actually comes from — direct bookings or third-party suppliers.

- **By**: Zineb Lahrach — https://zinebla.com
- **Context**: Travel technology · hotel distribution platform
- **Role**: Product Designer — interface design, data visualisation, design system
- **Focus**: Dashboard Design, Data Visualisation, Design Systems, UX Design

## At a glance

- Four-card KPI row separating volume from revenue, and direct from third-party
- Combined line-and-bar win rate chart over a daily time axis
- A hover tooltip that carries win rate and deviation together, split by channel

## The problem

A hotel selling rooms through a distribution platform has revenue arriving from two very different directions. Some of it comes through third-party suppliers, who take a margin. Some of it is direct, where the hotel keeps more of the value. Those two numbers behave differently, respond to different decisions, and matter to different people inside the business.

Most analytics screens flatten that distinction. They show one revenue figure, one chart, one trend line, and leave the person reading it to work out which half of their business moved. The design problem here was not "show the metrics" — it was to make the direct-versus-supplier split legible at a glance, without making the screen feel like a spreadsheet.

## Structuring the numbers

The top of the screen is a row of KPI cards, and the order is doing deliberate work. Number of Bookings comes first, as a volume count with no currency attached. Then Third party suppliers and Direct sit next to each other, both in euros, so the comparison is immediate and requires no arithmetic from the reader. Price follows.

Each card carries a coloured icon tile rather than a coloured number. That keeps the figure itself in a single high-contrast weight — the number is the thing you read, and the colour is the thing that helps you find the card again on the second visit. Cards are given generous internal padding and a light border rather than a heavy shadow, so a row of four reads as one band of information rather than four competing objects.

The labels stay in sentence case and plain language. "Third party suppliers" is longer than an abbreviation would be, but it needs no glossary, and a dashboard that needs a glossary gets abandoned.

## The win rate chart

Below the KPI row, win rate is plotted as a line across a daily axis, with bars underneath for the channel split. The combination is intentional: the line answers "is this getting better or worse", which is a shape question, and the bars answer "which channel drove it", which is a comparison question. Asking one chart to do both jobs usually produces a chart that does neither.

The y-axis runs 0–100% with gridline labels at twenty-point intervals, and the plot area carries a faint dot grid instead of full rules. The dots give the eye enough structure to judge height without drawing lines that compete with the data itself.

Bars sit desaturated until the day is hovered, at which point the two channels resolve into distinct colours. Until you ask a specific question, the chart shows you the trend; once you point at a day, it shows you the breakdown.

## Making the tooltip carry the comparison

The tooltip is where most of the design effort went, because it is where the actual question gets answered. Hovering a day surfaces a small panel headed with the date, then the win rate for that day, then deviation on its own line, then a legend keying the two channels by colour.

Putting deviation directly beneath the headline rate matters. A win rate of 48.9% means very little alone; 48.9% with a deviation of 11.3% tells you how much to trust it. Separating those two figures across different interactions — or worse, different screens — is what makes people stop believing a dashboard.

The hovered day is also marked in the plot itself: a highlighted column band, a dot on the line, and the date label pinned below the axis. Three coordinated signals, so the connection between the pointer and the panel is never ambiguous.

## What I would explore next

The clearest open question is comparison over time. The current view answers "how did this period go" well, but not "how does this period compare to the last one", which is usually the next thing someone asks.

The second is density. The layout is comfortable at desktop width, and the right design question is what to drop first — not how to shrink everything equally — when the same information has to survive a narrower screen.

---

Canonical HTML version: https://zinebla.com/work/booking-performance-dashboard