This case study is intentionally limited to public product context and high-level problem identification. The solution is protected under NDA, so I cannot discuss internal research, proposed directions, unreleased designs, implementation details, roadmap, or outcomes.
Overview
My role focused on understanding the design challenges shared by Schoolwork and Classroom as two mature education products continued to evolve. This page describes only the public product context and broad constraints involved.
Product context
Schoolwork supports learning over time: teachers create assignments and assessments, distribute activities, review work, and understand student progress. Classroom supports the live lesson, helping teachers organize students, guide devices, share materials, and move through an agenda together.
The apps belong to the same education ecosystem, but they serve different moments and carry different consequences. The challenge was to understand where familiarity between them could reduce cognitive load without obscuring the distinct work each product supports.
Schoolwork class view
Classroom classes view
The challenge
Both products had years of history, established workflows, and a wide range of interface states. Similar needs could appear across the apps while being expressed through different hierarchy, terminology, or interaction patterns.
At the same time, Liquid Glass introduced broader questions about material, depth, layering, and legibility. A visual evolution needed to account for dense classroom information without treating the two products as though they solved the same problem.
How can two products feel related without making them behave the same?
Technical constraints
I collaborated with engineers and product managers to identify technical constraints that could affect future projects and ideas. These conversations helped surface the realities of evolving mature applications, including dependencies, platform considerations, and legacy code built up over many product cycles.
The important problem was understanding where an idea intersected with existing architecture and established behavior. The specific constraints, decisions, and resulting direction remain confidential.
Information and states
Teachers may need to scan classes, activities, students, progress, device states, exceptions, and time-sensitive actions within the same view. Loading, offline, permission, selection, review, and error states add another layer of complexity beyond the ideal interface.
Those states can also have meaningful consequences: an action may affect one student, an entire classroom, or student-facing work. Clear hierarchy, scope, and feedback are therefore fundamental product concerns.
Schoolwork assignment view
Classroom student view
Accessibility and scale
The products must support teachers working under time pressure and students with a wide range of abilities, environments, and device configurations. Hierarchy cannot depend on color alone, and changing content or material cannot compromise contrast or clarity.
Layouts also need to accommodate larger text, localized strings, student and class names, teacher-authored content, variable class sizes, and different input methods. A pattern that works in one idealized view may not remain understandable under those conditions.
NDA boundary
The solution, research findings, internal artifacts, design decisions, implementation, and outcomes are under NDA and are not shown here. The imagery on this page is limited to publicly available Apple product views.