Most dashboards fail not because of bad data, but because no one asked the right questions before building them. This Domo community roundtable brings together four practitioners to share how they think about dashboard design from the ground up — before a single card gets placed.
Why It Matters
Dashboard sprawl is a real problem: dashboards that get built, shared, and promptly ignored. Without a deliberate design process, you end up answering the question you thought someone was asking instead of the one they're actually trying to answer. This session unlocks a repeatable framework for designing dashboards that get used — by the right people, for the right decisions.
What You'll Learn
- Distinguish between reporting and analytics to set the right scope before you build
- Use the 5 Whys method to surface what a stakeholder actually needs versus what they asked for
- Apply color, layout, and labeling principles to direct attention to what matters
- Decide when wireframing saves time and when it slows you down
- Organize cards, name KPIs, and structure content so dashboards are self-explanatory
Four Frameworks for Building Dashboards That Get Used
Chris Willis opens by drawing a hard line between reporting (here's what happened) and analytics (here's what it means). The distinction shapes everything downstream — including which persona you're designing for. Chris frames design as a search problem: you're not decorating data, you're searching for the layout and framing that helps a specific person make a better decision. His most actionable concept is purpose-driven design — every element on a dashboard should earn its place by connecting to a decision someone actually makes.
Devin LuBean introduces the 5 Whys as a user interview technique. When a stakeholder says "I need a sales dashboard," the real need is usually two or three whys deeper. Devin also walks through five criteria for dashboard success — a checklist-style gut-check you can run before you publish anything. On wireframing, his take is nuanced: it's worth the time when stakeholders have strong opinions about layout, and skippable when you have enough trust to iterate live.
Rachel R shifts to the perceptual layer — how color and layout communicate priority before a viewer reads a single number. She draws a useful distinction between dashboards built for making decisions versus dashboards built for getting a sense of where things stand, arguing these require fundamentally different designs. Her segment on labeling — metric name versus the business question the metric answers — is particularly sharp and directly applicable.
Jason Longhurst closes with tactical tips: consistent card naming conventions, what makes a KPI visually "beautiful" (and why it matters for trust), a preview of Domo's Themes and Styles features, and a look at DDX for collecting data input directly inside a dashboard.
Taken together, the four segments build a full design process: start with user intent, validate with structured questioning, apply visual hierarchy, then polish the details.
