OCAD University Student Analytics Dashboard

Administrative staff were making decisions off a patchwork of static reports with no single source of truth.

119 individual reports existed across SAP and Slate with no consistent format, no cross-system integration, and refresh cycles too slow to support timely decisions. Teams duplicated effort and spent time managing report logistics instead of acting on insight. Before any interface decisions could be made, the work was a data problem: the insights staff needed did not exist in any one place. I built SQL queries to join datasets across systems using shared keys — for example, calculating average enrolment by combining retention and completion reports that had never been connected before.

A single enrolment prototype

After 15 or more interviews and contextual inquiries with admin staff, I started narrow: a comprehensive view focused entirely on enrolment. It surfaced student population, major, year, transfer status, average enrolment, and average FTE (credit load), with filters for year and term. Nothing had been aggregated this way before. When I presented it to the Vice Provost and CTO, their reaction was immediate. They said they had never been able to pull a high level enrolment overview that quickly and started using it on the spot. That reaction confirmed the appetite was real and raised the bar for the next version.

Expanding the scope revealed a structural problem

Encouraged by that reception, I extended the same approach to demographic and financial data — adding country of origin, immigration status, gender, sexual orientation, funding type, and location. I brought it back as one expanded dashboard combining enrolment, demographics, and financial aid in a single view. The feedback was honest: the data was valuable and staff wanted all of it, but the dashboard had become overwhelming. Too much in one place made it harder to act on any of it. The problem was not the data. It was the structure.

Two use cases, four dashboards

I redesigned around two distinct use cases that had emerged from how staff were actually engaging with the data. The first was operational: departmental staff who needed to work quickly, pull snapshots, and act on current year data. For them I built three focused dashboards covering enrolment, demographics, and funding, each scoped to the current academic year. The second was strategic: senior leadership who needed longitudinal context. For them I built a fourth dashboard spanning historical data going back to the 1940s when the university's records were digitized in the 1970s.

Four Power BI dashboards deployed across departments through Microsoft Fabric, built on composite SQL models joining data from SAP, Slate, and legacy systems. Three operational dashboards scoped to the current academic year for enrolment, demographics, and funding — designed for speed and daily use. One executive dashboard with full historical data spanning decades for institutional planning. AODA compliant layouts, responsive filtering, and a consistent visual language across all four.