Activity Planner: A Ground-Up Redesign for Homeschool Planning
Time4Learning's Activity Planner is how families map out a homeschool year — and the old version was built on technology that had been blocking good design decisions for years. Parents had been asking for a calendar view they couldn't have. Planning around a vacation meant deleting a plan and rebuilding it by hand.
Company: Time4Learning, a PreK-12 online homeschool curriculum used by families across the U.S. and internationally
My role: UX Designer, sole UX/UI on the project
Team: 3 in design (myself, a product manager, one reviewer near the end); 6 in development
Timeline: ~8 months design, ~1 year development
I was Time4Learning's first UX designer, and the only designer on this project: parent research and competitor analysis, prioritization, interaction and visual design across three breakpoints, and seven functional requirement documents covering every screen and state. A product manager pushed hard on the thinking and asked the right hard questions; one more colleague joined near the end to review specs. It shipped in phases and is still the tool families use today.
Who This Was Really For
A user base ranging from confident, decade-long homeschoolers to parents who'd never planned a school day in their life.
Activity Planner user archetypes: by experience and by how much they adjusted their plans
Primary: homeschooling parents, from complete beginners to years-deep veterans
Secondary: students, who work through the plans their parents build; developers, who had to build and maintain it; customer service, who fielded the calls when something didn't work
Circumstance: many chose homeschooling deliberately; others, including a wave of new users around COVID-19, hadn't
Reach: families across the U.S. and internationally
That range was the constraint that shaped most decisions. A shortcut a veteran would love could strand a first-timer. Enough guidance to steady a beginner could insult someone on their tenth year.
And planning a school year is rarely the only thing a parent is doing. It sits on top of a job, other kids, and for many, learning to homeschool at all. The legacy tool was genuinely useful — but it added weight instead of taking it off.
The Problem We Were Solving
The tool worked. The cost wasn't one big problem — it was fifty small ones.
• No calendar — a flat list of activities, for an entire school year
• No progress view inside the planner; checking meant leaving for a separate Progress Reports tool, which showed activities completed or pending but never how the plan overall was going
• Activities marked complete didn't always show as complete, leaving parents unsure whether the work had registered
• Parents were getting thrown out of the tool while working
• No route to the course map without a separate trip to Lesson Plans
• Adding or removing a course meant updating the planner again, by hand
• Planning a vacation meant deleting the plan and rebuilding it
• Switching between kids meant leaving the planner and starting over
Some of this was breakage and some was friction, but the effect was the same. One more manual step, one more thing to double-check, one more moment of wondering whether you'd done it right or the tool had failed you — and no clear way to tell which. A 2018 review of the old tool captures the shape of it: a parent describing how the planner's rigid pacing would split a lesson and its quiz into separate weeks, leaving her working around the tool instead of with it.
It also hadn't been touched visually in years. Still functional, but dated enough to undercut confidence in a tool parents were trusting with their kid's school year.
Research & Process
Research gave us the list. Prioritization gave us the plan.
Feature priorities in five groups, from must haves to archived
• Surveyed parents at scale, sorted every response in Trello
• Pulled known complaints from customer service — both a compiled list and the recurring themes they'd been hearing on calls
• Prioritized with an adapted MoSCoW pass — Must haves, Nice to haves, Delights, Phase 2, Archived
• Analyzed seven competitors, direct and adjacent
• Tested Figma prototypes with a small group, one flow at a time, before code
• Recruited real parent volunteers to test the beta
Very little of what came back surprised us. We knew this product and we knew where it hurt — the survey and the support complaints mostly confirmed a picture we already had. The surprises came later, on the solution side: finding a way to fold two disconnected tools into one flow, or realizing that a feature parents had asked about for years was finally possible on the new stack.
What the research did give us was a defensible order. The prioritization framework was new to the company, and adapting it mattered more than importing it. Standard MoSCoW's "should have" and "could have" didn't fit what we were sorting, so the middle became Delights — a short list of small, deliberate touches worth building even though nothing depended on them — and Phase 2, for ideas we designed properly but knew we weren't ready to ship. Naming those categories is what let us say no later without re-litigating every decision.
Competitor research turned out to matter more than expected. The direct homeschool planning tools either buried parents in dense calendars or made rescheduling a single assignment into a five-option decision. The broader platforms — Khan Academy, IXL — hadn't attempted day-by-day year planning at all. And a support chat from one competitor, dated inside our research window, has their own rep telling a parent that scheduling around holidays and vacations was still "coming soon." We were already building it.
Decisions & Tradeoffs
The decisions that don't show up in a screenshot.
Letting parents finish the year on the old tool
Thousands of families were mid-year on the legacy planner when the new one was ready. Forcing everyone over would have meant interrupting school years in progress; leaving them alone indefinitely would have meant maintaining two planners forever.
We set a date instead. The legacy tool stayed available for six months with a clear end date, and parents could export their existing plan to PDF or Excel before it went away. New users never saw the old tool at all — they landed straight in the new one, with no path back. Existing users got the same new start page, plus a link to their old plans and an invitation to try the new planner.
The detail I care most about is the export. Ending access to a tool is one thing; ending access to a year of someone's records is another, and a parent who'd built a plan in the old system had a right to keep it.
The retire notice, which told parents to download their records before the old planner closed
Rescheduling by dragging an activity to another day
Rescheduling through a menu
Other decisions worth noting
Designed for desktop, tablet, and phone in parallel. Mobile-first, as it's usually practiced, tends to produce a desktop layout that's just the phone one stretched out. I work the other direction: desktop first, but once a screen is 75-80% there, I mock the tablet and phone immediately. If something doesn't hold up small, the desktop version gets reworked — all three resolve together instead of two being adapted from one. For patterns we hadn't built before, we looked at how established calendar apps solved the same problem on a phone, and pulled developers into short conversations early, before we committed to something that couldn't be built. Once the control library existed, every new screen started at all three sizes.
Color coding that met contrast requirements. Subject colors were already established elsewhere in the product, so we wanted colored tiles carrying the subject color with white text. Two of the six failed contrast. Darkening them fixed the ratio and wrecked the palette — the colors were technically ours, but they didn't look like us anymore, and one of them landed somewhere we couldn't ship. What worked: black text on white tiles, subject color as an accent line across the top. Contrast passed, subjects still readable at a glance, brand intact.
Help in the moment. The prevailing view internally was that good design shouldn't need explaining. That's true for consumer software with shallow feature sets. It's not true for a tool where a parent schedules an academic year across several children — Confluence is intuitive in places and still runs an entire learning center. But the more useful reframe wasn't help versus no help. We had plenty of help: blog posts, long video tutorials, a whole library of it. What we didn't have was help at the moment someone needed it. So every page got a contextual link that opened to the relevant section rather than the top of a general help page, and the long tutorials were cut into short task-specific clips, since retention drops off sharply with length. Answering the question where the question comes up, in other words — which is a different problem than having answers somewhere.
Example of Contextual Help link, top right
What Changed for Parents
What the new tool did that the old one couldn't.
A calendar, finally. The tool parents had been asking about for years. Week and day views, arrow navigation, a month calendar in the sidebar for jumping around. Planning a school year stopped being a list to read and became a schedule to look at.
Time off that redistributes itself. Select the days on a calendar — a holiday, a week away, a Friday off every week — and the remaining activities redistribute across what's left. Previously this meant deleting the plan and rebuilding it. The page was laid out like the school-year calendars districts send home as PDFs, since that's the format parents already knew how to read.
Time Off page, laid out like a school-year calendar
Switching between children without leaving. A dropdown in the sidebar. Previously: exit the planner, reselect the student, navigate back in.
The calculator and the planner, joined. The old tool had two disconnected features: a calculator that showed how many activities per day and week a date range produced, and the planner itself, which required entering everything again from scratch. Now you set the dates, check which days of the week you're schooling, see the breakdown, and build the plan from that same screen. The breakdown stays available in settings afterward, so parents can test a change against the real plan before applying it.
Course changes that don't strand you. Add a course to a student and the system asks whether to add it to the plan, linking straight to the right settings page. Previously, adding a course meant going into the planner separately and digging through settings to find where.
Progress in one place. A bar in the sidebar showing activities completed against the total. No separate tool, no interpretation required.
Print layouts built for paper. Printing wasn't a fallback for parents — it was part of how many of them worked. Some ran the school day off a printed sheet rather than a screen, especially with several kids. Some handed a child their own schedule for the day. And some needed printed records for state homeschooling requirements, where documenting instruction isn't optional. The layouts were designed for those uses rather than being a screen grab of a calendar.
Confetti. When a student finished a plan, the parent's next login opened on a celebration with a Celebrate button that fires confetti again as many times as anyone wants, and an Update Courses CTA for what comes next. Students got their own version. It was one of the Delights from prioritization, and one of the few things in this project I wasn't sure development could pull off — it turned out to be straightforward, and we demoed it to the whole company.
The celebration when a student finishes a plan
Outcomes
What shipped, and what I can say about it
The rollout was phased: a hundred users first, then the full user base. The small group meant we could catch problems while the blast radius was small, and it gave us feedback from people using the tool for real school years rather than test scenarios.
A post-launch feedback survey went out. I no longer have access to the results, so I won't characterize them with numbers I can't show. What I can say is that feedback was mostly positive and the calendar view drew the strongest response — which tracked with the research, since it was the thing parents had asked about for years and the thing the old technology had made impossible.
There was a learning curve, and we expected one. The tool was a substantial change for parents who'd used the old planner for years, and a redesign that requires no adjustment usually means nothing much changed.
Internally the reception was strong. The confetti moment was demoed to the whole company, and the prioritization framework we adapted for this project was picked up for later work.
Public reviews since launch describe the planner in terms that match what we set out to do. Parents mapping a schedule and seeing what's completed each day, families teaching several children at once finding it manageable, and time off adapting the schedule automatically. Against the competitive landscape at the time, the approach to scheduling, rescheduling, and time off remained among the strongest in the category.
Reflection
What I'd take into the next one.
Specs are how you make a decision survive. The accessibility work on this project didn't succeed because I cared about accessibility. It succeeded because contrast ratios and alternative interaction paths were written into the requirements as conditions, which meant they could be checked against what got built. When something came back not matching, there was a document to hold it against. Intent that only lives in a designer's head isn't reviewable, and it doesn't survive handoff.
Disagreement is more useful when it arrives with evidence. The help section survived because I could show why the "good design needs no explanation" principle applies to shallow consumer software and not to a tool where a parent schedules a full academic year. That argument worked because it came with research rather than conviction. I had a manager willing to change course when the reasoning held up, which is not a given, and it's part of why the project went as well as it did.
The hard part wasn't finding the problems. We knew this product and we knew where it hurt. The survey and support complaints largely confirmed what we already understood. What took the time was deciding what to build, in what order, and what to deliberately leave alone — keeping a six-plan limit we no longer needed, holding a redesigned single-plan flow for a later release, sunsetting the old tool on a schedule parents could absorb. Restraint was most of the work.
Screens shown as originally designed. The product has since been rebranded.
Next Case Study
A 20-year-old homeschooling site, redesigned for clarity and built so the editorial team can run it.