The word 'dashboard' is overloaded to the point of meaninglessness in software design. I have seen everything from a single KPI card to a 40-panel analytics display called a dashboard. In financial software specifically, dashboards exist for one purpose: to help someone make a decision or take an action. If a user looks at a dashboard and walks away without deciding or acting, the dashboard has failed. Regardless of how much data it displays or how visually polished it looks.
Over my career, from the real-time trading dashboards for investment firms I built at GFT to the reporting dashboards I built in Data Studio as an intern at iRestify, I have designed and iterated on a fair number of dashboards for financial and operational data. This post distills the principles and patterns that have held up across all of them.
Start with the Decision, Not the Data
The most common mistake I see in financial dashboard design is data-driven design. A stakeholder asks for a dashboard, lists all the data they want to see, and the designer arranges that data in panels. The result is a dashboard that is comprehensive but not useful. It answers many questions that no one was asking and is silent on the questions users actually have.
My starting point is always a decision inventory. What decisions does this user make? On what frequency? With what level of urgency? A branch manager checking a morning operations dashboard makes different decisions, and needs different information, than a credit analyst reviewing a loan portfolio. The fact that both are looking at financial data is almost irrelevant to the design.
Take a loan portfolio dashboard for a credit analyst. The primary daily decisions: which accounts are drifting toward delinquency, which applications have been sitting in review past the service target, and where the portfolio stands against its risk and volume limits. Three decisions. Everything on the dashboard gets evaluated against whether it supports one of those three. If a data point does not connect to any of them, it does not belong on the primary dashboard. It goes to a drill-down view accessible on demand.
Information Hierarchy: The F-Pattern Is Not Enough
Most UX guides recommend designing for F-pattern reading behavior. Users scan the top of the page, then down the left side. This is accurate for editorial content. For decision-support dashboards, the reading pattern is different: users scan for anomalies, not for information in reading order. They are looking for something that is wrong, unexpected, or requires action.
This changes information hierarchy fundamentally. The most important information on a financial dashboard is not the most prominent number. It is the number that is out of normal range. Design for exception highlighting rather than for comprehensiveness. Status indicators, threshold-based color changes, and trend arrows are more valuable than precise numbers when the primary use case is exception detection.
In practice, I design financial dashboards with three zones of visual weight. Zone one is the exception zone. Items that require action or attention, always at the top or prominent left position. Zone two is the status zone. Current state of key metrics, confirming that normal operations are proceeding. Zone three is the context zone. Historical trends and comparative data that help interpret the first two zones.
KPI Card Design: What Actually Matters
KPI cards are the most common element in financial dashboards, and they are also the most commonly designed poorly. A KPI card that shows only a number tells the user almost nothing. A KPI card that shows a number in context tells the user whether to be concerned.
The elements I include in a well-designed KPI card: the current value (primary), the comparison reference (versus last period, versus target, or versus budget), the directional indicator (up/down/neutral arrow), the magnitude of change (percentage or absolute), and the time period the value covers. That is five pieces of information in a compact card. The design challenge is arranging them so the most decision-relevant piece, usually the comparison and direction, is the most visually prominent, not the absolute number.
Color conventions on KPI cards must be used carefully in financial applications. Red does not universally mean bad in finance. A red indicator on loan loss reserves might mean the reserve is below required levels. Clearly bad. A red indicator on a cost center might mean costs are higher than budget. Usually bad. A red indicator on a revenue metric might mean revenue is above target, which is good. The color must be consistently keyed to the direction of the deviation from the desired outcome, and the desired direction must be contextually appropriate for the metric.
Choosing the Right Chart Type
Chart type selection is one of the most consequential decisions in dashboard design, and it is frequently made based on aesthetics rather than data structure. Here are the chart choices I reach for in financial dashboard contexts and why:
- Line charts: For continuous time-series data where the trend and rate of change matter. Loan portfolio balance over time, daily transaction volume, interest rate movements. Do not use bar charts for time series when the trend line is the message.
- Bar charts (grouped or stacked): For comparing discrete categories or periods. Comparing revenue by product line, or showing this month vs last month vs budget across multiple metrics. Stacked bars work when the part-to-whole relationship is meaningful; grouped bars work when direct comparison between categories is the priority.
- Sparklines: For status indication rather than analysis. A small line chart inside a KPI card tells you the recent trend without requiring a full chart. For dashboards with many KPI cards, sparklines add significant context at minimal visual cost.
- Tables with inline visualization: For data that requires precision. When users need to know exact values and compare across many rows, a table with inline bar charts or colored cells is more useful than a chart. Financial professionals often need the actual numbers, not just the shape of the data.
- Scatter plots: Use sparingly and only when the correlation between two variables is the actual question being answered. For credit risk analysis or portfolio analysis, scatter plots are powerful. For operational dashboards, they are usually the wrong choice.
Real-Time Data Display Patterns
Financial dashboards increasingly need to display real-time or near-real-time data. Market data, payment processing volumes, active session counts. These values change continuously. Designing for real-time data introduces specific UX challenges that static dashboards do not have.
The most important principle: do not animate every data update. If a number changes every second, animating each change creates visual noise that makes the dashboard exhausting to monitor for extended periods. My rule is to animate a value change only when its magnitude exceeds a threshold you define per metric. Set that threshold from what normal movement looks like for that metric: a price that ticks every second needs a much wider band than a daily approval count. Small fluctuations update silently, significant movements draw attention through animation.
Data freshness indicators are essential on real-time dashboards. Users need to know whether the data they are looking at is current or stale. This is especially critical in financial contexts where acting on stale data can have monetary consequences. I display a last-updated timestamp in relative terms ('Updated 3 seconds ago') with an absolute timestamp available on hover. If the data feed is delayed or interrupted, I display a visible staleness warning rather than silently showing old data.
// Staleness detection service
@Injectable({ providedIn: 'root' })
export class DataFreshnessService {
private readonly STALE_THRESHOLD_MS = 30_000; // 30 seconds
isStale(lastUpdated: Date | null): boolean {
if (!lastUpdated) return true;
return Date.now() - lastUpdated.getTime() > this.STALE_THRESHOLD_MS;
}
freshnessLabel(lastUpdated: Date | null): string {
if (!lastUpdated) return 'Data unavailable';
const secondsAgo = Math.floor((Date.now() - lastUpdated.getTime()) / 1000);
if (secondsAgo < 5) return 'Just now';
if (secondsAgo < 60) return `${secondsAgo} seconds ago`;
return `${Math.floor(secondsAgo / 60)} minutes ago`;
}
}Progressive Disclosure for Complex Datasets
Progressive disclosure is the practice of showing summary information first and revealing detail on demand. For financial dashboards, this is not just a design preference. It is a necessity for managing cognitive load on data-dense screens.
My progressive disclosure hierarchy for financial dashboards: level one is the summary dashboard showing KPIs and exceptions, level two is the metric detail view showing the full time series, breakdown by sub-category, and contextual comparison data, level three is the transaction-level or record-level detail, accessible only when the user has a specific investigative need.
The navigation between these levels must be efficient. Clicking on a KPI card should go directly to the relevant level-two view for that metric, not to a generic analytics page. Clicking on an anomalous data point in a chart should surface the underlying records that explain the anomaly. These contextual drill-down paths reduce the investigative time required for a user to understand what is happening, which is the core value proposition of the dashboard.
The GFT Experience: Real-Time Dashboards for Investment Firms
At GFT, I built real-time trading dashboards for investment firms with Angular, D3.js and WebSockets, keeping data latency under one second. This was a particularly instructive context because traders and analysts are sophisticated users with very specific information needs and very little patience for lag. A dashboard designed for a casual consumer banking user is wrong for them. The information density needs to be higher, the time to key information needs to be lower, and the data has to be visibly current.
The most valuable lesson in that context was about freshness. When data moves every second, the display has to make staleness impossible to miss: a feed that silently stops updating is worse than one that shows an error, because someone will act on the stale number. The other lesson was restraint in animation. With D3.js it is easy to animate every tick, and doing so makes a screen unwatchable within minutes.
A dashboard that shows everything is optimized for no one. Design for the decision, not for the data.
Accessibility in Data Visualization
Financial dashboards have an accessibility problem that is specific to data visualization: charts are inherently visual, and their meaning is inaccessible to screen reader users who receive only the chart's alt text. This is a real gap that most dashboard designers and developers do not adequately address.
My current practice: every chart includes a tabular data view accessible via a toggle, so screen reader users can access the underlying numbers. Chart alt text is not 'Bar chart showing revenue data'. It is a concise summary of the key insight: 'Revenue increased 12% month-over-month, reaching $4.2M in June, the highest value in the past 12 months.' The alt text tells the story the chart is telling, not just what type of chart it is.
Color is never the only indicator of meaning in my financial dashboards. Every status that uses color also uses an icon or a text label. This is both an accessibility requirement and a practical usability improvement. Dashboards are frequently viewed on monitors with poor color calibration, in bright office environments, or by users who have color vision deficiency. Designing for these conditions benefits all users.
References
- WCAG 2.1 non-text contrast. https://www.w3.org/WAI/WCAG21/Understanding/non-text-contrast
- Apache ECharts. https://echarts.apache.org/en/index.html
- Chart.js. https://www.chartjs.org/