Progress Report’s Template module was restructured to fix years of accumulated configuration debt.
Context
Toddle is a curriculum planning and assessment platform initially built for IB schools, now catering to all major curriculums globally. Progress Reports is one of its most business-critical modules, used by 500+ schools, multiple times a year, to generate printable report cards for students and families across PYP, MYP and DP curriculums.
Module anatomy
Progress Reports is built around two layers:
Templates, which define the structure and configuration of a report card
Report sets, which are instances of a template created for a specific term and grade level.
School admins own both, they build and configure templates, assemble report sets from them, assign teachers and control when reports are locked and shared.
This case study is about the Report templates, where most of the configuration complexity lived. Two parts of that structure are worth understanding before the problem makes sense.
Progress Summary is a condensed view of student performance across all courses: schools that don’t want to surface detailed report data use it in place of full subject reports, making it one of the most-used sections in the template.
Course configuration is the most important section in the template, where schools organise their curriculum around courses, which can number 50 or more.
Problem
The pile of support tickets being raised by school admins had started to increase, not for missing features, but for ones that already existed. Configuration options were buried deep inside the template, contextual to where they lived but impossible to discover without knowing where to look. The customer support team had become a workaround.
Three things were broken:
Layout Configuration had quietly evolved from a simple show/hide panel into a half-baked data configuration surface, with related settings scattered across unrelated sections.
Progress Summary was visible under layout configuration but had no controls inside it. Admins could see the page, not configure it.
Course configuration had no workable model for schools running large course lists. Every course had to be configured individually, using an interaction pattern that was never built for that scale.
There was no mental model holding any of it together. Admins stopped trying to navigate the product themselves, customer support picked up the slack, and every new feature shipped made the underlying problem harder to fix.
Before touching anything, every data inflow and outflow in the system was mapped. Where each configuration was coming from. What triggered it. How frequently it was used. Who it belonged to.
Key Decisions
That map did three things:
Splitting the IA The configurations weren’t scattered randomly: some were decisions you made once at the start of a reporting cycle, others were decisions you made every time you opened a template. They had been living in the same place because nobody had drawn that line before. Once the line was visible, the split was obvious: Setup for the former, Layout Configuration for the latter. Where something lived now matched how often you needed it.
Opening up Progress Summary Progress Summary was the only section in the module with no configuration controls of its own. Its controls lived inside unrelated source sections: Subjects, Homeroom, Attendance. Nobody had named it as a problem because it had always been that way. It was one of the most-used patterns in the module, yet the only one that couldn’t be configured from within itself. Leadership pushed back: the surface was limited and the change felt like scope creep. The structural inconsistency was hard to argue against once it was visible. Progress Summary was made configurable, on the same terms as every other section.
Rethinking course configuration Schools running large course lists were configuring each course individually, using an interaction pattern built for a fraction of that scale. The observation was simple: schools kept the same data points for 80% of their courses and only modified the elective or additional ones. So the solution was built for that reality: a default layout all courses inherited, with course-specific overrides for the exceptions. Configuration cost dropped from touching every course to configuring once and overriding only when necessary.
Outcome
The redesign shipped without adding a single new feature. What it shipped was structure.
Admins had a clearer separation between setup-level decisions and template-level configuration. Progress Summary was no exception anymore: configurable from within itself, consistent with every other section in the module. Schools with large course lists had a configuration model that matched their actual scale.
Internally, the redesign gave the team a reusable rule: if a configuration was decided once per reporting cycle, it belonged in Setup; if it was adjusted while editing a template, it belonged in Layout Configuration. That rule removed ambiguity for designers and developers, making it easier to extend the module without reopening the same structural debate each time.
Support tickets around configuration did not disappear immediately, but the structural reason behind them was addressed. The product no longer needed customer support to act as the missing interface between admins and the system.
A later validation came through AI. When the redesigned system was provided as context to a model, it could read the UX patterns, understand the constraints, and build on top of them without ambiguity. A system that confuses humans will confuse AI too. This one no longer did.
Takeaway
That is what structural work actually buys you. Not a cleaner interface. Not better onboarding. A foundation coherent enough for the next thing to be built on, whether that next thing is a new feature, a new team member, or a model.