Scatter Plots in a Business Dashboard: What Does One Dot Actually Compare?
Use a scatter plot when your business question concerns the relationship between two measurements made on corresponding observations. Before commissioning the chart, define what one dot represents and how its two values are paired. A convincing upward pattern is not proof that changing one measure will cause the other to improve.
This is a guide to specifying an exploratory report, not a statistical assessment of your business or a claim that a chart has already revealed a useful opportunity.
Pair measurements from the same observation
The NIST handbook on scatter plots describes plotting values of one variable against the corresponding values of another. The horizontal and vertical coordinates belong together. That relationship is the starting point, not a decorative choice made after two columns have been selected.
Consider a hypothetical repair business investigating whether more complex jobs tend to take longer. One dot could represent one completed repair, with an agreed complexity measure on the horizontal axis and its elapsed completion time on the vertical axis. This is an invented example, not evidence about a real team.
Write the observation unit explicitly. A dot for each job is different from a dot for each team’s monthly average. The latter collapses variation inside each team and answers a different question. Do not match a list of complexity values to a separately sorted list of durations merely because both lists contain the same number of entries. Match them through the actual observation identity.
Define the two measures before drawing the axes
Specify each measure’s meaning, unit and observation period. Active labour time, elapsed calendar time and time waiting for customer approval are not interchangeable definitions of duration. A complexity score also needs an owner and a consistent interpretation.
NIST describes scatter plots as a way to investigate linear and nonlinear relationships, changes in variation and outliers. The report should therefore support inspection, not just stamp a verdict of “good correlation” on every selection.
My recommendation is to name the question above the chart and label both axes in ordinary language. State whether the displayed points are individual observations or aggregates. If filters change the included population, keep that scope visible. Readers should not have to infer the denominator or time period from the surrounding dashboard menu.
Missing measurements are not coordinates at zero
Agree what happens when one member of a pair is absent, invalid or not yet available. Placing an unknown duration at zero invents a measurement. Dropping the entire observation silently can make the remaining pattern look more complete than it is.
A useful starting requirement is to show the count of included pairs and a separate explanation of exclusions. If the business needs a missing-data list, make that an explicit, permission-aware view. These are proposed product requirements; the NIST page does not implement data cleaning or access rules for your app.
Also test repeated identical pairs. Several jobs can occupy the same position. A single visible mark does not necessarily mean a single job. Ask how the chosen chart reveals overlap without pretending to change the underlying values. The appropriate method depends on the actual data and supported devices, so agree it using a representative sample rather than prescribing an effect for every dashboard.
A pattern is a reason to investigate, not a causal conclusion
NIST explicitly warns that association does not imply causality and that a scatter plot cannot prove cause and effect. Keep that boundary in the report’s title, annotations and accompanying explanation.
In the hypothetical repair report, a relationship between complexity and duration would not by itself prove that a particular process change will reduce delays. Nor would an isolated point justify blaming a staff member. Inspect how the observation was measured and what other conditions differ before acting.
A trend line, if commissioned, needs a stated interpretation and a reviewed method. Do not automatically add a straight line to every cloud of points. NIST’s examples include nonlinear relationships as well as linear ones. A line can be a model of an association, not a measured path that the jobs actually travelled.
These distinctions matter when screenshots leave the app. Include enough context in the agreed export that a dot cloud is not forwarded as an unqualified claim about causes or individual performance.
Inspect groups without losing the comparison
The NIST guide describes conditioning plots that examine the relationship between two variables according to a third variable. For a business app, this can motivate a useful question: are different job types being mixed into one view?
Decide whether readers need a combined view, separate panels or a deliberate filter. A group distinction must have a real data basis. It should not be invented to make the pattern look cleaner. Keep definitions and units consistent when comparing groups, and make any deliberate scale differences clear.
The technical ability to split a chart does not prove that a subgroup is large enough or comparable enough for a particular business conclusion. If the report will drive consequential decisions, include appropriate analytical review in the project scope rather than asking the interface to certify the conclusion.
Accept the pairing before accepting the styling
Use harmless synthetic observations for the web-app acceptance criteria. Include distinct pairs, identical pairs, an unusually positioned pair and observations missing either measure.
- Each dot can be traced to the correct observation or explicitly defined aggregate, subject to access permissions.
- Changing the displayed sort order does not pair a value with the wrong observation.
- Axis names, units, period and included population match the report definition.
- Unknown values are not substituted with measured zeros, and exclusions are explained.
- Overlapping observations receive the agreed treatment without silently changing their stored measurements.
- Group selection, accessible explanation and any permitted data table describe the same population.
- Any fitted line and exported context preserve the association-versus-causation boundary.
These are proposed acceptance checks, not a browser test or statistical analysis already performed for this article. Bring a sample of the paired observations and the decision you hope to investigate to a reporting-app discussion.
Questions worth settling early
Can we compare two monthly averages instead of individual jobs?
You can commission an aggregate-level comparison, but name it that way. The dot would then represent the defined month or group, not an individual job. Conclusions about the aggregate do not automatically describe every underlying observation.
Should the dots be joined?
Not by default for an unordered set of jobs. NIST describes both connected and unconnected variants and explains a preference for unconnected points to avoid interpolative artifacts. Decide whether a connecting line has an actual meaning in your report rather than inheriting it from a chart template.
Does a strong-looking pattern tell us what to change?
No. It can identify an association worth investigating. A business intervention needs evidence and judgement beyond the scatter plot itself.
Source and limits
The NIST page was read on 26 October 2026. It supports the paired-variable definition, exploratory purposes, conditioned views, noncausal interpretation and discussion of connected versus unconnected points. Data matching, missing-value handling, permissions and acceptance rules above are commissioning guidance, not features verified in an existing app.