“Data-driven” has become one of the safest phrases in higher education. It appears in strategies, board papers and funding bids. We reassure ourselves that we are data-driven. We celebrate dashboards. We track metrics. We monitor trends. And all of that is positive. It signals seriousness about accountability and performance. But there is a subtle distinction that rarely gets discussed. Being data-driven is not the same as being data-designed. And the difference matters more than most institutions realise.
The Comfort of Being Data-Driven
At its simplest, being data-driven means we look at the numbers before making decisions. We use evidence to shape direction. We review KPIs. We respond to trends. When something shifts, we interrogate the dashboard.
That is a healthy discipline.
But it is also reactive by nature. Data is generated, presented, interpreted and acted upon. The underlying system that produces it often sits quietly in the background, unquestioned.
We focus on what the data says. We rarely pause to consider how the data was constructed.
What It Means to Be Data-Designed
Being data-designed shifts the focus from outputs to architecture.
It asks: have we intentionally designed the structures that generate our data? Or have they evolved incrementally, shaped by legacy decisions, system constraints and operational workarounds?
A data-designed institution pays attention to definitions before dashboards. It understands where data originates, how systems connect, and who owns which elements of the model. It recognises that metrics are not neutral artefacts, they are products of design choices.
Dashboards are visible. Architecture is not. But architecture determines what is possible.
Why This Distinction Becomes Visible Under Pressure
The difference between data-driven and data-designed institutions often only becomes obvious during moments of structural change.
- A regulatory reform.
- A funding shift.
- A move toward modular or episodic provision.
- A new reporting requirement.
In those moments, some institutions adapt with relative ease. Others discover that definitions are inconsistent, ownership is unclear, and manual reconciliations have become structural dependencies.
Being data-driven helps you respond to change.
Being data-designed helps you absorb it.
It reduces reliance on heroic spreadsheets. It clarifies accountability. It strengthens regulatory confidence. It creates resilience rather than reactivity.
Data Design Is Not a Technical Detail
It is tempting to treat data architecture as a systems issue, delegated to IT or registry.
But design intention is a leadership responsibility.
Leaders shape incentives, governance structures and institutional priorities. They determine whether data definitions are formalised, whether ownership is explicit, and whether architecture is periodically reviewed rather than assumed.
The strategic questions are simple but uncomfortable:
Are our definitions consistent across faculties?
Do we know where informal workarounds sit?
If we rebuilt our reporting from scratch, would we structure it the same way?
These are not technical questions. They are design questions.
As I explore in my Data Fluency Framework, institutional capability depends not just on access to data, but on shared understanding of how it is constructed and governed:
https://thedatagoddess.com/data_fluency_framework/
Fluency begins with design awareness.
A Simple Reflection
If your dashboards disappeared tomorrow, would you understand your data architecture well enough to rebuild them cleanly?
If the answer is uncertain, your institution may be data-driven.
But it may not yet be data-designed.
And in a sector facing increasing structural complexity, that distinction is becoming harder to ignore.