Dashboard Design Principles for Data Analysts

A dashboard succeeds when someone who opens it understands the situation within seconds and knows where to look next. Most dashboards fail that test, not because the data is wrong but because of design: too much on the page, numbers without context, charts that distort values, and colour used as decoration. Stephen Few's short paper on dashboard pitfalls catalogued these problems years ago (Few: common pitfalls in dashboard design), and they remain the most common faults in dashboards built today. The principles below address them one by one.

1. Design for one audience and a few questions

Before choosing a chart, write down who the dashboard is for and the three to five questions they need answered. Microsoft's dashboard guidance starts in the same place: consider the audience and the key metrics that help them decide (Microsoft Learn: dashboard design tips). A dashboard for a sales director and one for a warehouse supervisor may use the same data but should look completely different. When a stakeholder asks for "everything", the job is to find out which decisions they make and design for those.

2. Fit the essentials on one screen

Exceeding the boundaries of a single screen is the first of Few's pitfalls. Anything below the fold is often never seen, and comparisons across scrolled sections are hard to make. Microsoft's guidance likewise suggests avoiding scroll bars. If everything will not fit, the dashboard is trying to answer too many questions: split it by audience, or move detail into drill-through pages.

3. Give every number context

A number alone cannot be judged. Revenue of 1.46 million says nothing until the reader knows the target, last month's figure or the same month last year. Few lists inadequate context as a pitfall for exactly this reason. Pair every KPI with at least one comparison, show the direction of change, and label periods explicitly. Round sensibly: showing revenue to two decimal places adds noise, not information, the pitfall of excessive precision.

4. Choose charts that encode values accurately

A chart is only useful if its shapes show the relationships between values without the reader having to read the numbers. Few's paper illustrates this with a pie chart whose slices cannot be compared without their labels, next to a bar chart of the same data that shows the relationships at a glance; encoding quantitative data inaccurately is another of his pitfalls. Lengths and positions along a common scale are the easiest to compare. That gives practical rules:

Bars must start at zero, because their length is the value. Gauges and dials use a lot of space to show one number and a target; a bar with a marker shows the same in a fraction of the space.

5. Arrange content in reading order

Most readers scan from the top left. Microsoft's guidance advises putting the highest-level information at the top left and adding detail in the direction people read. A reliable layout: KPI cards across the top, the main trend below them, and breakdowns underneath. Group related items, align them to a grid, and keep the same positions across related dashboards so readers learn where to look. Poor arrangement and failing to highlight what matters are both on Few's list.

6. Use colour sparingly, meaningfully and accessibly

Colour should carry meaning, not decoration: a neutral grey for most marks, and one highlight colour for what needs attention, such as the current period or a KPI below target. Two accessibility checks matter.

Contrast. Web accessibility guidelines require a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text (W3C: contrast minimum), and at least 3:1 for graphical objects needed to understand content, such as chart marks (W3C: non-text contrast). Pale grey labels, popular in modern designs, often fail. The ratio can be computed with the formula the guidelines define:

def luminance(hex_colour):
    def channel(c):
        return c / 12.92 if c <= 0.04045 else ((c + 0.055) / 1.055) ** 2.4
    r, g, b = (int(hex_colour[i:i + 2], 16) / 255 for i in (1, 3, 5))
    return 0.2126 * channel(r) + 0.7152 * channel(g) + 0.0722 * channel(b)

def contrast(foreground, background="#FFFFFF"):
    lighter, darker = sorted((luminance(foreground), luminance(background)), reverse=True)
    return (lighter + 0.05) / (darker + 0.05)

palette = {"pale grey labels": "#BBBBBB", "mid grey labels": "#999999", "dark grey labels": "#595959",
           "bright green status": "#2ECC71", "bright red status": "#E74C3C", "dark blue title": "#1F4E79"}
for name, colour in palette.items():
    ratio = contrast(colour)
    verdict = "passes for text" if ratio >= 4.5 else "large text and chart marks only" if ratio >= 3 else "fails"
    print(f"{name:<20} {colour} on white: {ratio:4.1f}:1 -> {verdict}")

pale grey labels     #BBBBBB on white:  1.9:1 -> fails
mid grey labels      #999999 on white:  2.8:1 -> fails
dark grey labels     #595959 on white:  7.0:1 -> passes for text
bright green status  #2ECC71 on white:  2.1:1 -> fails
bright red status    #E74C3C on white:  3.8:1 -> large text and chart marks only
dark blue title      #1F4E79 on white:  8.7:1 -> passes for text

Both greys that look elegant fail even the 3:1 threshold, and the bright green often used for "on track" fails too. The bright red is acceptable for chart marks and large text but not for small labels. Running a palette through a check like this takes seconds and prevents a dashboard that part of its audience cannot read.

Colour vision. A red-versus-green status is invisible to many readers with colour vision deficiencies. Okabe and Ito's colour universal design guidance recommends avoiding reliance on red-green contrast, choosing colours that also differ in brightness, and avoiding pale, low-saturation colours for small marks (Okabe and Ito: colour universal design). Never let colour be the only signal: add a symbol, a label or a position.

7. Remove decoration

Background images, 3D effects, heavy borders, shadows and logos in every panel compete with the data for attention. Few calls this cluttering the screen with useless decoration. A good test: remove an element; if nothing is lost, leave it out.

A review checklist

Test with real users: ask them to answer the dashboard's questions and watch where they hesitate. Building your first interactive dashboard shows how to test that the numbers behind the design are right, and data visualization best practices goes deeper into individual charts.

Dashboard creation in Excel, data visualisation and storytelling, and interactive Power BI dashboards are part of the Data Analytics course.

Sources

• Common Pitfalls in Dashboard Design — Stephen Few, Perceptual Edge, 2006
• Tips for designing a great Power BI dashboard (Microsoft Learn) — Microsoft Learn
• Understanding Success Criterion 1.4.3: Contrast (Minimum) (W3C) — W3C Web Accessibility Initiative
• Understanding Success Criterion 1.4.11: Non-text Contrast (W3C) — W3C Web Accessibility Initiative
• Color Universal Design (Okabe and Ito) — J*FLY