Data viz problems I've solved, and what I'd try next.
Revenue management is a numbers job: thousands of listings, 365 prices each, a market that moves every day. These are the interaction problems in that data I've worked on at PriceLabs, each with what shipped and what I'd explore with more creative freedom.
Thousands of listings × 365 days, on one screen
The problem. Portfolio managers paged the multi-calendar month by month, lost the column they were reading, and switched pages to compare a listing with its market.
What shipped
- Infinite scroll instead of pages, so you never lose your place.
- An annual view: twelve months at once to spot seasonal gaps.
- Switchable KPI overlays (occupancy, ADR, demand) on the grid; off for small hosts.
- Hover columns that keep the date you are reading lit across thousands of cells.
With more freedom
- Horizon charts per row: a year of occupancy in one 24 px band, so 200 listings fit a screen.
- Semantic zoom: pinch from year to month to day, with detail appearing as cells grow.
- Brush to act: drag across dates on the chart itself to select and override them.
Three numbers, up to 3× apart
The problem. The base price tool offered three suggestions with no guidance on which to trust and no view of what a price would do to the year.
What shipped
- One market-based recommendation for most users, with the reasoning visible.
- Where you sit in the market: a distribution of comparable listings with your price marked.
- Instant yearly feedback before committing. An A/B test on how we explain it lifted acceptance by +4.3 points.
With more freedom
- A what-if slider that morphs the whole year's price curve as you drag, with the recommendation as a soft magnet.
- A confidence band instead of a single number, so "about $144" reads honestly.
- A beeswarm of comps you can hover to see each comparable listing.
Every portfolio measures revenue differently
The problem. One team tracks revenue on the books by month, another ranks listings, another watches occupancy pacing against last year. Fixed dashboards couldn't cover all of it.
What shipped
- A pivot-table model (rows, columns, values) revenue managers already think in.
- A live spreadsheet preview so the shape of the report shows before it runs.
- Templates for the common questions, with "create your own" first.
With more freedom
- Sparkline columns in report tables, so trend and value read together.
- Chart suggestions from the report's shape: a time column suggests pacing curves; a ranking suggests a slope chart.
- Ask the report in plain language and get the view back, editable.
Signals that stayed inside the algorithm
The problem. PriceLabs' Pulse algorithm knew when a listing was missing settings or underperforming its market. Hosts didn't, and found problems late.
What shipped
- Alerts as chips in the listings table and calendar header, next to the data they're about.
- Severity sets the order: critical (blocks pricing), warnings, recommendations.
- One fix per alert, resolved in place.
With more freedom
- A revenue-at-risk treemap of the portfolio: area is money at stake, colour is severity.
- A resolution timeline showing how fast alerts get fixed, to make the habit visible.
Comparing a listing with its market
The problem. Market data lived on a separate page with long, unreadable competitor titles, so comparing your price with the neighbourhood meant switching context.
What shipped
- Neighbourhood data in the pricing calendar, prototyped as a real app shell.
- Readable nicknames for competitor listings instead of long titles.
With more freedom
- Pickup (pace) curves against the market, the chart revenue managers sketch on whiteboards.
- A hexbin map of comps coloured by price, with your listing pinned.
Shipped work is described from the linked case studies. Concepts are my own explorations with sample data, not PriceLabs features.