Dashboards often begin as a request to put several numbers on one screen. The harder work is deciding which questions the screen should answer and what someone can do with each answer.
I find it useful to treat the dashboard as one possible presentation of a stable data contract. The underlying service should define the measures, their provenance and the conditions under which they are valid. The interface can then decide how to arrange and explain them for a particular audience.
Keep meaning near the data
A chart should not be the only place where a measure gains meaning. Names, units, time boundaries and missing-data rules belong close to the query or service that produces the result. That makes another presentation—a report, an alert or a command-line view—less likely to reinterpret the same number.
This boundary also makes design changes cheaper. A team can replace a chart, group values differently or add a focused mobile view without rebuilding the calculation behind it.
Design for the next decision
The useful test for a dashboard is whether it helps someone decide what to inspect or change next. A smaller set of well-explained measures usually does that better than a dense wall of available data.