Only 20% There

Classcraft's teacher editing experience had a significant gap. Of the originally scoped editing functionality, only about 20% had been built. Teachers, understanably, were expecting something closer to the full 100% envisioned.

The obvious response was to commit more resources toward closing that gap, but reduced engineering capacity made a full build-out unrealistic in the near term. That constraint opened up for the possibility to pressure-test whether or not the original plan was right in the first place, before committing to build out the rest.

What we had built, and would have continued building, exposed the same internal authoring forms we used to create Classcraft content to teachers directly. Instead of editing, we were asking teachers to become full content authors, giving them granular control over questions, answers, images, etc. It required them to enter an editing flow, complete a separate publishing process, and only then could they teach the session. It placed a lot of time requirement on teachers with limited availability in their day-to-day, and it shifted a lot of authorship responsibility onto them when we were supposed to be the content experts. We decided to find out what teachers actually needed before we built any more of it.

Give Them What They Want

We brought in our research team and asked them to do three things: surface any existing feedback on the current editing experience, pull any research that had informed previous editing decisions, and gather relevant external knowledge on teacher workflows.

What came back reframed the problem immediately. Across thousands of feedback data points, four needs repeatedly emerged, ranked by frequency:

• Delete or hide slides was the single most requested capability. Teachers wanted to remove distracting transition screens, skip content they weren't planning to cover, or cut interactive activities they were running as pen-and-paper instead.
• Add content came in second. Teachers wanted the ability to bring in supplemental resources from HMH's Discover tool, content covered in the Teacher's Guide but not surfaced in Classcraft, or occassionly external material of their own.
• Resequence content covered reordering slides, merging sessions, or splitting a session to teach across two class periods.
• Augment content was the most granular ask and similar to what we were already doing. It focused on editing or adjusting individual slide content.

The hierarchy told a clear story. The most wanted feature was also the simplest, to hide what teachers didn't need, whereas the least requested category, granular editing, aligned closely to what we had been building. We were delivering complexity where teachers were asking for control.

Will The Real Session Please Stand Up?

There was a second, less visible problem running underneath all of this, but equally as impactful. Every time a teacher edited a session using the existing form-based workflow, it created a new version of that session in the database. Managing those versions required significant engineering overhead. And the complexity compounded quickly: a teacher might want different versions of the same session for different class periods. Co-teachers might need shared access. And underneath all of this, we needed to protect the original authored content, HMH's Core Curriculum, as the canonical, unmodified version.

The more we mapped out the versioning implications, the more it became clear that we were dealing with an architectural approach that would get harder to manage the more teachers used it, not easier. Any solution we proposed needed to resolve this, not work around it. [IMAGE OF OPP/SOL TREE]

The Bigger Picture

While we were working through the editing problem, a separate team was building something called the Content Store: a centralized repository of all HMH-produced content that learning experience designers could query, with AI assistance, to build lesson content dynamically based on subject matter, standards, and instructional needs.

This mattered to our work in two ways. First, if teachers could tap into the Content Store, it would give them a powerful, structured way to add new content to their sessions, directly addressing the second most-requested editing feature. Second, the Content Store team had landed on the same form-based Plankton workflow for their editing needs, which meant any architectural rethinking we did had implications beyond just teacher editing.

Tracking this parallel workstream shaped how we thought about the solution space. We weren't just solving for teacher editing in isolation, but were navigating a broader platform question about how content gets created, modified, and owned.

Two Paths Forward

Our team developed two distinct solution approaches, each representing a different philosophy about what teacher editing should fundamentally be. The plan would be to A/B test these with actual users and engineers.

The first, which we called In-Player, was an evolution of the existing approach. Teachers would edit content directly within the session player view but lean on AI-assisted augmentation to do more of the heavy lifting. It preserved the original mental model (here is your session, modify it), but also preserved the original versioning problem.

The second, referred to as The Playlist, took an entirely different angle. Instead of editing the session directly, teachers would curate from it, building a new, teacher-owned sequence alongside it. This left the original source untouched, but shifted the mental model to something more like: here is your content library, build your session from it. And because teachers were building something new rather than modifying something existing, the versioning problem dissolved almost entirely.

The Playlist

The Playlist approach resolved several problems at once, which is usually a sign that a design decision is onto something real. First, the versioning problem, as already stated, was rather elegantly circumnavigated. The core curriculum stayed intact while teachers were given full control over their remixed playlists.

Second, the engineering lift was reduced. Favoriting content and saving them into a reordered sequence is a lightweight operation compared to building and maintaining editable forms for structured content. That meant we could ship meaingful functionality quikcly and wihtout overburneding an already stretched-thin engineering team.

And it hit the two most-requested teacher needs in the right order. The initial phase would provide teachers with a way to hide/delete and resequence content, the most requested feature. Subsequent planned releases would integrate Content Store access (scheduled to ship before teacher editing) to add new content directly to their playlists. The complexity scaled naturally with our release schedule.

There was also something pedagogically honest about the approach. Teachers aren't authors! They don't want to rewrite curriculum, they just want to teach their class as effectively as possible. The Playlist model respected that distinction. It gave teachers genuine control over their instructional sequence without asking them to become curriculum authors.

Where It Landed

Although the project reached a clear directional recommendation in the Playlist approach, a leadership transition shifted the company's near-term priorities before work could continued.

As the roadmap was being paused for realignment, our product owner incorporated the Playlist concept into a platform vision prototype built in Figma Make to orient incoming leadership. In that prototype, the content library sits alongside the instructional sequence — teachers pick from it, build their playlist, and teach from what they've curated, with the original content always available but out of the way. Our concept became the backbone of the platform's future vision gameplan, not just a solution to a specific editing gap.