Skip to main content

Building Better Dashboards in Insights

How to design dashboards that are focused, easy to navigate, and built around the right questions — not everything you could show.

Written by Ashley Dehertogh

The most effective dashboards in Insights are not the ones that show the most data. They are the ones that answer a clear set of questions, guide the reader through a logical flow, and make it easy to know what to do next. This guide covers how to design dashboards that work — for the people who use them and for the AI assistant that can help explore them.

Know who you are building for

Before you add a single tile, be clear on who will use this dashboard and how. A dashboard built for a revenue manager who reviews it every morning should look very different from one built for a general manager who checks in weekly.

Ask yourself:

  • Who opens this dashboard and how often?

  • What decisions or reviews does it support?

  • How comfortable is this person with data — do they need a guided read, or do they want to explore freely?

If you are building for a mixed audience, focus on the most common use case. You can always build a more detailed dashboard for power users separately.

Start with questions, not data

The most common mistake when building a dashboard is starting with the data — pulling in everything that seems relevant and arranging it until the page looks full. The result is a dashboard that shows a lot but answers very little.

Start instead with two or three clear business questions. Write them down before you add anything:

  • What am I trying to understand when I open this?

  • What would I want to know within the first thirty seconds?

  • What decision or review does this support?

Example — Pick-Up Analysis

Instead of "show everything about bookings," the questions might be:

  • How is pick-up pacing versus the same time last period?

  • Which future periods are accelerating or slowing?

  • Which segments are driving the change?

  • Are there specific dates that look unusually strong or weak?

Those four questions tell you exactly which tiles belong on the dashboard — and which do not.

If a tile does not help answer one of the core questions, it probably does not belong on this dashboard.

A dashboard is not a spreadsheet

The single biggest design trap in Insights is trying to recreate an Excel spreadsheet as a dashboard — every stay date, every segment, every metric, for every day of the year, all on one canvas.

Spreadsheets are designed for exploration. You scroll, filter, and drill into whatever row or column you need. A dashboard is designed to surface answers. It should tell you what is happening, surface the most important signals, and give you a path to go deeper when something needs investigating.

If you want to see every day's OTB, budget, and forecast broken down by segment — that belongs in a workbook. A workbook lets you query and explore freely. A dashboard should present the output of that thinking: the trend, the comparison, the key exception. Not the raw grid.

  • Dashboard: answers a recurring question, shared for regular review, loads quickly, guides you to what matters

  • Workbook: explores an open-ended question, used for one-off or deep investigation, designed for full data access

If you find yourself planning to download the dashboard and continue working in Excel, ask whether a scheduled workbook export would serve you better. Dashboards and workbooks are different tools — using the right one makes both more useful.

Build a flow, not a catalogue

Good dashboards tell a story. They start somewhere, move through a logical sequence, and finish somewhere. A user who opens a dashboard should know immediately where to look first and what to do next.

Most analysis naturally moves from high-level signals into deeper detail. Your dashboard should reflect that progression:

  1. High-level outcome or trend — What is happening overall? Start with a KPI or summary chart that sets the context.

  2. Contributors — What is influencing that change? A breakdown by segment, channel, or period.

  3. Diagnostics — Where exactly is this coming from? A table or date-level view for specific periods or outliers.

Example — Pace & Performance dashboard

  • Section 1: OTB this year vs. last year — the headline read

  • Section 2: Pick-up trend by segment — what is driving the delta

  • Section 3: Stay-date breakdown — which specific nights look strong or weak

A user can orient themselves at section 1 and go as deep as they need to. Position your most important insight at the top — this is where attention lands first. Use tile size and section headers to signal what deserves the most focus.

Curate what you show

A dashboard does not need to show every metric it contains. Keep the number of charts focused — a smaller number of well-chosen tiles is almost always more useful than a large grid of everything that could be relevant.

A tile can include additional measures in its underlying query that provide useful context without displaying all of them on screen. For example:

  • A chart showing Revenue may also include Units and ADR in the query — these appear in tooltips and are available to the Dashboard Agent when answering questions

  • A chart showing Occupancy may also carry Capacity and Units for context

  • A trend line may include prior-period measures for comparison without displaying them as separate lines

This keeps the dashboard visually focused while preserving analytical depth. The same principle applies to filters — include the ones most users need most of the time. If you are adding a filter "just in case," ask whether it is earning its place.

Curate for clarity, not completeness. Strong dashboards prioritise signal over noise — the goal is not to reduce information, but to organise it so answers are easy to reach.

Test before you share

Before sharing a dashboard with your team, walk through it as a first-time user:

  • Can you answer the core question within thirty seconds of opening it?

  • Is it obvious where to look first?

  • Are there tiles that require explanation to be useful?

  • Does the filter set make sense — do filters control the tiles you expect them to?

If a dashboard needs explaining every time it is shared, it is doing too much of the explaining in conversation and not enough in its own design.

Why this matters for the Dashboard Agent

The Dashboard Agent uses the dashboard as its starting context. When a dashboard is well curated — clear questions, logical flow, focused tiles — the agent can understand what the analysis is about, connect insights across tiles more effectively, and give you faster, more accurate answers to follow-up questions.

If a dashboard is overloaded or unfocused, the agent will reflect that — both users and the agent will struggle to navigate it.

In practice, good dashboard design improves the experience for everyone: the person reviewing it, the team sharing it, and the AI assistant helping to explore it.

Did this answer your question?