Diagnostic Learning Analytics

I redesigned an LMS reporting experience to help administrators move from static report exports toward in-product investigation. The proposed workflow brought guided setup, live validation, filtering, sorting, and summary signals into the LMS, reducing a fragmented and repetitive process across internal and external tools.

This reduced the modelled reporting journey from 11 stages to 5 and the estimated time to insight from 40 minutes to 20. The redesign advanced reporting from descriptive output toward diagnostic capability, helping administrators move more quickly from stakeholder questions to actionable insights.

Organizations use learning management systems to support employee performance. Courses, curriculum, reminders, compliance paths, and assessments are configured so employees can build skills, complete required training, and meet organizational standards.

Reporting is the feedback layer of that system. It helps learning teams understand whether training is working, where employees may be falling behind, and where managers, instructors, HR, or L&D teams may need to intervene.

The existing reporting experience supported basic historical reporting. LMS admins could select a data source, choose fields, configure filters, schedule reports, and export results. This was useful for answering “what happened,” but it did not sufficiently help users understand why performance gaps were happening or what they should investigate next.

The broader product ambition was to move LMS reporting up the analytics maturity curve. The long-term goal was to support more mature insights and eventual recommendations, but the immediate opportunity was to strengthen the diagnostic layer: helping users investigate performance gaps instead of only exporting historical data.

The existing reporting workflow treated reports primarily as outputs. Admins configured a report, generated or exported it, then moved into spreadsheets or other tools to understand what the data meant. This created extra work and made follow-up questions harder to answer quickly.

This was especially limiting because reporting often began with an open-ended stakeholder question, not a clearly defined report request:

The reporting experience needed to support this investigative process. Instead of assuming that admins already knew the exact report they needed, the product needed to help them start from a question, shape the right data view, identify patterns, and share findings.

Opportunity question:

How might we help training administrators investigate gaps in employee learning without relying on static report exports?

Analytics maturity had to happen in stages because more advanced insights depend on a reliable reporting foundation.

Prescriptive analytics requires several layers beneath it: clean report creation, understandable data fields, reliable filters and sorting, usable templates, trustworthy previews, and summary signals that users can trace back to the underlying data. Without those foundations, recommendations would feel opaque or unreliable.

Several constraints shaped the work.

First, the redesign had to work within existing reporting architecture. Data sources, fields, filters, sort rules, scheduling, templates, and exports already existed. The work needed to improve the experience without breaking core reporting behavior.

Second, the primary users were not data analysts. LMS admins often managed courses, curriculum, learner support, compliance, and reporting at the same time. They needed reporting tools that were guided, visual, and forgiving.

Third, reporting workflows extended beyond the LMS. Admins often used spreadsheets to consolidate exports, compare data, clean up views, and prepare findings for stakeholders. The product could not replace every spreadsheet workflow at once, but it could reduce unnecessary handoffs by bringing more validation and diagnosis into the LMS.

Finally, the work needed to be released in stages. This phase focused on the next realistic step: moving from descriptive reporting toward diagnostic reporting.

Discovery included LMS admin interviews, analysis of reporting workarounds, and review of complex spreadsheets that admins used to organize and interpret exported data outside the LMS.

These artifacts showed that reporting was not a single in-product task. It was a workflow that moved across requests, clarification, report configuration, exports, spreadsheet analysis, and stakeholder communication.

The swimlane diagram helped map this workflow across overlapping platforms and roles. A requester or manager might identify a performance problem and ask for a report. The LMS admin would then clarify the request, decide which report or data source to use, configure fields and filters, export results, analyze the data in Excel, and share findings back to the requester.

This revealed that the LMS supported only part of the job. The most important diagnostic work often happened around the product, not inside it.

The primary user was the LMS Reporting Admin. This user could also be an LMS admin, instructional designer, HR partner, or learning operations owner. Their responsibilities included building and updating courses, managing day-to-day LMS operations, and responding to reporting requests from leadership or instructors.

They were often non-technical, relied on templates or visual tools, and did not always know which fields mapped to which metrics. Reporting was only one part of their job, so they needed to answer data questions quickly and confidently.

A representative scenario centered on low training completion. A manager notices that completion is low for the Sales team. Rory, the LMS admin, pulls a completion report. Leadership then asks why completion is low. Rory may need to drill down by department, course, time period, region, cohort, reminders, or engagement signals.

Rory’s role was not just to pull reports. She translated open-ended stakeholder questions into evidence-backed insights that helped leadership understand where support was needed and what action to take next. The platform needed to better support this strategic work, instead of treating reporting as a static export task.

LMS admins were not just building reports. They were translating messy performance questions into data views that other people could act on.

A manager might ask, “Why is completion low?” But the admin has to translate that question into report logic:

The old workflow assumed users knew exactly what report they needed before they started. In reality, admins often figured out the right report while building it.

This created the key design shift:

The redesign focused on creating the next layer of analytics maturity: a reporting workflow that could support diagnosis.

Rather than treating reporting as a final export, the new direction helped users start from a stakeholder question, choose a useful reporting path, configure the right data, preview results, identify patterns, and share findings.

4. Diagnostic filtering and sorting

After deciding which information to include in the report, filters and sorting helped admins turn that data into findings.

Admins could narrow results by department, course, learner group, status, due date, completion date, or time period to investigate where a performance issue was concentrated. Rather than scanning large datasets, they could progressively reduce the scope of the report and compare different segments of the data.

For example, if completion was low, an admin could filter by department, sort by overdue status, and compare results across teams or courses to determine where the issue was occurring.

Why this mattered

Field selection helped admins decide what information was relevant. Filters and sorting helped them investigate it. Together, they supported a more diagnostic workflow by helping users move beyond “What happened?” and toward “Where is it happening?” and “What pattern explains it?”

The redesign established the diagnostic foundation needed to advance reporting along the analytics maturity curve toward prescriptive insights. By bringing report setup, validation, investigation, and pattern identification into the LMS, it reduced the modelled workflow from 11 stages to 5 and the projected time to actionable insight from 40 minutes to 20.

To evolve from diagnostic to prescriptive analytics, the product first needed reliable data structures, trusted reporting logic, and clear relationships between performance gaps and their likely causes. Once these foundations were established and validated, the system could begin recommending appropriate actions with greater accuracy, transparency, and user trust.