Lesson Plan Page Redesign

Designing clarity and speed for real teacher workflows

Overview

As part of a broader RethinkEd platform rebuild, nearly 2,000 lesson modules were created by restructuring unified, multi-part lessons so that each component could stand alone and be delivered independently. I worked on improving the Lesson Plan page – the primary interface through which teachers access and deliver that content – to better align with how educators actually prepare, teach, and assign lessons.

The work unfolded in two phases. First, I worked within the constraints of an active platform rebuild – authoring and QAing content at scale, identifying product issues, collaborating with Product and Engineering on fixes, and advocating for improvements to the teacher experience. Later, I returned to the problem independently to explore the deeper workflow issues that the original project couldn't resolve.

Role
Curriculum design · UX advocacy · Product QA · Independent product design

Collaboration
Content · Product · Engineering · UX

Scope
Lesson planning · Content authoring · Resource preview · Delivery workflows

Platform scale
Nearly 2,000 modular lesson components

VISUAL 1 – Product evolution
I now think this should be a single composed visual, not three independent giant screenshots:
Legacy platform → Rebuild proposal → Phase 1 iteration
The point isn't to inspect every pixel. It's to establish the evolution in about 10 seconds.

Challenge

The rebuild was solving a real problem. The legacy platform was difficult to navigate even with substantial familiarity, and lesson overview, instruction, and supporting materials were fragmented across separate destinations. The new platform brought those pieces into a more integrated experience while restructuring nearly 2,000 lesson modules so individual components could stand alone and be delivered independently.

That was meaningful progress – but the new content model also introduced new experience questions.

The Lesson Plan page – the primary interface through which teachers access those modules – was designed almost entirely without input from the content team, a group of former classroom educators who understood firsthand how teachers prepare and run lessons and who had direct knowledge of how each material in the library was written and intended to be used.

By the time the content team was consulted, foundational interaction decisions were already established. I was eventually given access to the existing Figma file to improve what I could within that model, focusing on teacher-facing hierarchy, content variability, consistency, and clarity. Larger changes to the core flow were out of scope before launch.

At the same time, I was experiencing the platform from another side: I spent significant time working directly in its authoring tools, personally modularizing, uploading, and QAing hundreds of pieces of curriculum content. That gave me visibility into how decisions made in the authoring system and content model surfaced in the teacher experience – and exposed problems that weren't always visible from the interface alone.

VISUAL 2 – Phase 1 iteration
This is where I'd show your Self-Care for Focus iteration, but not the entire tall page as a heavily annotated graphic.
I'd probably show the reduced full-page preview plus 3–4 readable detail callouts:
  • content-aware hierarchy
  • teacher-facing visual language
  • consistent metadata patterns
  • removal of redundant grade selection
Then we can mention the structural requests in prose rather than making another graphic.

From Design Feedback to Product QA

As real curriculum moved through the system, I created and maintained a platform issue tracker based primarily on problems I identified while authoring and QAing content, along with feedback surfaced by the broader content team. The issues spanned both the authoring experience and teacher-facing product – from navigation and resource behavior to assignment states, language switching, presentation, printing, and content rendering.

Those findings fed into Product's development backlog and Engineering ticketing process. In weekly working sessions with Product, Engineering, Content, and sometimes UX, we reviewed outstanding issues, clarified intended behavior, discussed technical constraints, and determined what could be fixed within the existing system.

Many issues were resolved through that process. Others – including richer authoring controls, more flexible content layouts, and changes to resource-preview behavior – remained constrained by the platform's existing architecture or project scope.

VISUAL 3 – QA → Product → Engineering
I think this earns a visual now.
But not screenshots of Excel or Azure.
Something extremely simple:
Authoring + QA
↓
Issues documented
↓
Weekly cross-functional review
↓
Product backlog / Engineering tickets
↓
Fix, defer, or identify as a larger product question

Potentially one tiny real example underneath, such as the Spanish-material behavior or assignment-state issue, to prove this wasn't theoretical.
This is especially useful for Wayfinder because it demonstrates design/product work continuing through implementation, without us ever having to say “I collaborated cross-functionally” as an empty résumé phrase.

What Shipped – And What Remained

The relaunched platform was a substantial improvement over the experience it replaced. Instructions and materials now lived within a shared modular lesson structure, and many issues identified during authoring and QA were resolved before or after launch.

But some of the harder workflow questions remained.

Materials initially opened in a modal, preserving the Lesson Plan underneath. That behavior was later changed so materials opened in a separate player page. The change introduced a more significant context-loss problem: previewing a resource now takes teachers away from the lesson entirely, with no consistently predictable path back to where they were.

The modular structure also introduced a scoping question that was never fully resolved. A teacher might work through the full "My Emotions" lesson across several days, or only run its Practice module today. Print, Assign, and Present could plausibly apply at the lesson, module, or even individual-material level – but those actions don't necessarily mean the same thing at each scope.

Rather than treating these as isolated interface bugs, I conducted a post-launch audit to separate problems that could be addressed through incremental UI changes from those that required deeper reconsideration of navigation, interaction, or the underlying content model.

That audit became the starting point for the second phase of this project.

VISUAL 4 – Post-launch audit
This is where the live My Emotions page + selected audit findings belongs.
And I'd keep it ruthlessly focused. Probably 3–4 findings, not every problem you documented.
The strongest candidates still seem to be:
  • material preview breaks lesson context
  • materials can't be evaluated alongside instruction
  • information density is difficult to control
  • delivery scope remains ambiguous
This visual answers why Phase 2 exists.

my Role

My contribution crossed content design, product QA, UX advocacy, and independent product design.

  • Modularized, uploaded, and QA'd hundreds of curriculum components, giving me direct visibility into both the authoring system and teacher-facing experience.

  • Created and maintained a platform issue tracker and worked with Product and Engineering through recurring cross-functional sessions to clarify problems, assess feasibility, and support fixes through implementation.

  • Iterated on the Lesson Plan interface within the established interaction model, using real curriculum variability and input from former educators to advocate for clearer teacher workflows.

  • Conducted a post-launch audit to identify where remaining friction came from interface execution versus deeper navigation, workflow, and content-model decisions.

  • Continued the work independently, redesigning the experience around the structural problems the original project couldn't resolve.

My curriculum background gave me visibility into both sides of the experience: how teachers would use the lesson and how its content was authored, structured, and maintained behind the interface. That made it possible to identify problems that weren't visible from the UI alone.

Reframing the Page

The independent redesign shifts the Lesson Plan page from displaying lesson content to functioning as a flexible teacher workspace.

I preserved the useful architecture the rebuild had established – lesson → module → material – rather than replacing it simply because I could. The redesign instead focuses on what teachers can do within that structure: understand the lesson, control how much information is visible, inspect resources without losing context, and move between different levels of preparation without being forced through a single sequence.

VISUAL 5 – Full independent redesign
This is the hero payoff.
Your complete redesigned My Emotions page, relatively small as a document preview with click-to-enlarge.
I'd give this more visual prominence than any of the historical full-page screenshots.

Design Strategy

Rather than starting with layout changes, I focused on clarifying the experience principles the Lesson Plan page needed to support given real teacher workflows and platform constraints.

Design for Teacher Workflow, Not System Architecture

Teachers don't approach a lesson in one predictable way. A teacher encountering a lesson for the first time needs different information than one who has taught it repeatedly. Available classroom technology changes how materials are delivered. Some teachers are evaluating a lesson, others are preparing to teach it, and others are returning only to print or assign a specific resource.

Without behavioral data showing which patterns were most common, optimizing the interface around one assumed sequence would risk making the page less useful for everyone else. I instead designed for flexibility – preserving orientation while allowing teachers to control how deeply they move through the content.

Keep Materials in Context

The most direct problem with the current experience is that accessing a material takes teachers away from the lesson. Every time they preview something, they lose their place.

Teachers need to be able to assess a lesson quickly – to understand what they are walking into, what each material is for, and how the pieces fit together. Asking them to navigate away, click back, and reorient themselves repeatedly shifts cognitive load onto the user in a way that erodes confidence in the platform over time.

A modal would preserve more context than the current separate player, but it still makes the material and its instructions mutually exclusive views. A fixed side panel could keep both visible, but limits teachers to one resource at a time and competes for horizontal space.

The solution I landed on is an accordion within the materials column of each module card. When a teacher clicks a material, a preview expands inline in the right-hand column – below the material's title, within the card – while the lesson text remains fully visible on the left. Multiple materials can be open at the same time: a teacher can have the scenario cards and the teacher resource both visible while reading through the activity steps, without toggling back and forth. If a teacher needs a closer look at a specific material, they can expand the preview without leaving the lesson context entirely.

Inline expansion has its own cost: opening several resources increases the length of the page and pushes later content farther down. I accepted that tradeoff because each resource remains anchored to the module and instructions that give it meaning, while teachers can collapse individual previews or entire modules as they finish working with them.

VISUAL 6A – Contextual materials
This should be a large readable crop, not another whole-page screenshot.
Show:
  • instructions on left
  • material(s) open on right
  • two materials open simultaneously
  • optional small inset showing hover/Expand
This one is important enough that the reader should actually be able to read the UI.

Use Progressive Disclosure Without Hiding Structure

Teachers come to the lesson plan page at different stages of preparation. Some are reading through a lesson for the first time to decide whether to use it. Others are deep into prep and need to move quickly between specific materials. Both are valid, and the page needs to support both.

Modules and individual materials can therefore be expanded independently. A teacher exploring a lesson can expose its full structure, while someone already familiar with it can collapse completed sections and move directly to the resource they need.

The hierarchy remains visible even as the amount of information changes: lesson → module → material → expanded material.

VISUAL 6B – Progressive disclosure
I think 6A and 6B can potentially become one visual system rather than two huge graphics.
For example:
Collapsed module → open module → material preview → multiple materials open
That would explain the interaction model much better than another paragraph.

Define Delivery Scope Before Designing It

Teachers using a lesson that spans both print and digital delivery face a real coordination problem: some materials can only be printed (cards are not assignable), some are digital-only, and some can go either way. Where those constraints fall isn't always obvious from a material's name alone.

This wasn't a hypothetical problem introduced for the redesign. Questions about Print, Assign, Present, and what should be available at different levels had already surfaced during the original platform work.

I explored the different use cases at the lesson, module, and material level, but couldn't justify a new control model without better evidence about how teachers actually make those decisions. Rather than designing false certainty into the interface, I kept the existing lesson-level Print, Assign, and Present actions and treated scope as an explicit research question.

The unresolved question isn't simply where to put another button. It's what teachers believe they are acting on when they select it.

Key Design Decisions

  • Keep lesson instructions and supporting materials visible together rather than forcing teachers to switch contexts.

  • Allow multiple resources to remain open when comparison or simultaneous reference is useful.

  • Use progressive disclosure at both the module and material level so information density can adapt to the teacher's familiarity and task.

  • Preserve the existing lesson → module → material architecture where it remains useful rather than redesigning structure for its own sake.

  • Keep lesson-level delivery actions until research can establish whether module- or material-level controls would better match teacher expectations.

What I'd Validate Next

The redesign resolves problems I could substantiate through direct product work, content expertise, QA, and the post-launch audit. Other decisions need evidence from teachers using the page.

I'd prioritize three questions:

1. How do teachers understand delivery scope?
When they choose Print, Assign, or Present, do they expect to act on the entire lesson, the current module, or an individual material?

2. Does contextual material preview reduce navigation friction without creating new problems?
I'd test whether teachers can move between instructions and resources efficiently, how often multiple resources need to remain visible, and whether page length becomes problematic as previews accumulate.

3. How does information need change with familiarity?
I'd compare first-time and returning users to understand which content they need immediately, what they routinely collapse or skip, and whether the progressive-disclosure model supports both without obscuring important information.

I would combine moderated usability testing with product analytics – observing how teachers prepare and deliver real lessons while measuring resource-preview behavior, module expansion, delivery actions, and navigation patterns at scale.

Reflection

This project changed shape several times – and that is part of what makes it meaningful to me.

The first phase taught me how much product understanding can come from working directly with the system behind an interface. Authoring and QAing curriculum at scale exposed connections between content structure, platform behavior, and teacher experience that weren't visible from a screen alone. Working through those issues with Product and Engineering also reinforced the difference between a fixable bug, a system constraint, and a product question that needs deeper investigation.

The second phase has been about applying that understanding without assuming that freedom from the original constraints means everything should change. Some of the rebuild's decisions were worth preserving. Others created friction that only became clear once real content moved through the system. And some questions still need evidence before they should be designed at all.

My curriculum background is central to how I approach product design. Knowing how content is created and knowing how it is used produces better product decisions – especially in education, where the interface, instructional model, classroom context, and underlying content system are inseparable.

Designing for teachers requires acknowledging time pressure, fragmented attention, and the cumulative cognitive load of a job that asks a lot. It means resisting the urge to add features and instead asking what would get out of the way. It also means being honest about uncertainty and knowing when the next design decision should begin with research rather than another screen.

Clarity is not just a usability goal. It is a signal of respect. Experiences that reduce friction and support orientation allow educators to focus their energy where it belongs – on teaching.