Activity Planner: A Ground-Up Redesign for Homeschool Planning
Time4Learning's Activity Planner is how families plan 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.
Time4Learning's most-used tool, redesigned from scratch — research, spec, and build.
• 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
The Activity Planner is how parents map out a school year for their kids, and how those kids log in and work through it day to day.
I was Time4Learning's first UX designer. On this project I owned research, interaction design, visual design, and the functional requirement documents development built from — seven of them, covering every screen and state in the tool. A product manager pushed hard on the thinking and asked the right hard questions; one more colleague joined near the end to review specs. The wider product team grew to six once development started, and I stayed the only designer on it throughout.
Who Was This Really For
A user base ranging from confident, decade-long homeschoolers to parents who'd never planned a school day in their life.
• 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 Are 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.
• 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.
Keeping a limit we no longer needed
The old tool let parents create up to six plans per student — a workaround, really, for parents whose kids moved at different speeds in different subjects. Six separate plans was how you got math five days a week and history on Tuesdays.
The new planner solved that properly. You could reschedule anything by hand, drag a week's work into a single day, and shape the schedule however you wanted. The six-plan limit was now unnecessary.
We kept it anyway.
The visual redesign was already a significant change for parents who'd been using the old tool for years. Removing a familiar capability at the same moment — even one made redundant — would have meant two disruptions at once, and the second would have looked like a downgrade. So the limit stayed, along with the extra design work of supporting default and non-default plans. The single-plan version was designed and ready for a later release, once parents had settled into the new tool.
It cost us complexity we didn't need, in exchange for a transition parents could absorb.
Two ways to do everything important.
Parents could reschedule by dragging an activity or through a menu on the activity itself. This started as an accessibility requirement — drag-and-drop shuts out anyone with limited range of motion, and it's unreliable with a screen reader. It ended up being the thing that made rescheduling work on a phone, where dragging across a week view is miserable. One decision, two payoffs.
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.
What Changed for Parents
What the new tool does 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.
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.
Outcomes
[headline — depends on what the numbers say]
• Rolled out in phases: first to 100 users, then to the full user base
• Post-launch feedback survey — [X% / key finding]
• [support ticket volume, if available]
• [adoption or usage figure, if available]
The phased rollout was deliberate. A hundred users first meant we could catch problems while the blast radius was small, and it gave us real feedback from people using the tool for actual school years rather than test scenarios. Then the full rollout.
Feedback was mostly positive. [Placeholder — replace with the actual survey result.] The calendar view drew the strongest response, which tracked with the research: 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. [Optional: confetti demo, MoSCoW adoption, anything else worth noting.]
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.
Three things I'd carry forward.
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, keyboard navigation, and alternative interaction paths were written into the requirements as conditions, which meant they could be checked against what got built. When the calendar dropdown came back inaccessible, 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.
Get Athos Pro