Case Study · Toddle · 2026
Context
Toddle Calendar is deeply embedded in a live institutional system — class schedules, curriculum deadlines, attendance, roles, and video conferencing all connect to it. A change to one event can propagate across 40 schools and affect 3,000 video meetings.
The 2.0 migration introduced a fundamental architecture change: Account → Schools → Classes. A large organisation could now have 10–100 schools under one account. This shift from single-school to multi-school was the primary driver behind almost every design decision.
I worked across four roles simultaneously: Product Designer, Product Manager, Product Strategist, and Technical Communicator — not because the team was small, but because the problems were interconnected and demanded one coherent point of view.
| User | Primary need |
|---|---|
| Families | Know their child's schedule from their own calendar app |
| Teachers | Manage class events, assignments, and meetings |
| Coordinators | Oversee events across a programme |
| District admins | Govern calendars across 10–100 schools |
The Problems
01 — Critical
Teachers at multi-programme schools could create an event that didn't appear in that school's calendar. Creation succeeded silently. The event was lost. Every "where did my event go?" support ticket traced to this. When a system fails silently once, you lose confidence in everything it shows you.
02 — District scale
"Holidays," "Holiday," and "School holiday" coexisted across schools in the same district. A district-wide event required contacting each school individually. No push mechanism, no audit trail, no bulk operations.
03 — Operations
Only the creator could edit a video meeting. If a teacher went on leave, a coordinator couldn't fix a broken Zoom link or cancel a session — even with full programme-level permissions. Schools running daily online classes were operationally blocked.
04 — Trust
At schools with 3,000+ video meetings per month, ICS feed generation was causing API timeouts. Users noticed stale data days after a subscription silently stopped working. No admin monitoring. No failure detection.
"A district admin who previously had to contact each of 40 schools individually can now push an event type update to all of them in 3 actions."
Key Decisions
Three approaches considered: mirror school admin panels (visibility only, no governance), flat shared taxonomy (eliminates local flexibility), or Draft → Publish → Push with read-only inheritance. Adopted the third. Account admins define and publish; schools inherit and cannot override; schools can still create local types. Matches PowerSchool's proven model. Handles specialisation — "DP Internal Assessment" is not relevant to a PYP school.
Three options: schools in filter panel (conflates filter with context switch), schools as tabs (tabs imply parallel persistent contexts), or school switcher with adaptive behaviour. Adopted the third. Single-school users see a static label — no dropdown, no visual noise. Multi-school users see a chevron. On mobile, a native bottom sheet. Same component, two behaviours, zero added complexity for the majority case.
The creator-only model was the most damaging operational failure. Fix: permission level determines edit access regardless of creator. Documented as a 5-step authorization algorithm — creator, account calendar manager, programme-level permission, class-level permission, deny — with 9 permission-combination test cases. Mirrors exactly how task editing already works in Toddle. Consistency was the anchor.
School-level scoping alone wasn't the solution — just the right boundary. Three additional levers: rolling window (14 days past to 60 days forward, cutting feed size 5–8×), role-scoped feed defaults (admins default to holidays, not every VM), and server-side pre-computation (cache feeds every 30 minutes). Eliminates on-demand generation timeouts at the architecture level.
What I Learned