Building Mobile Apps for Education: UX Lessons from Marathon Kids and LivingTree
UX design lessons from building two K-12 education apps serving 70K+ users - covering accessibility, offline support, and designing for multiple user types.
Dibyank Padhy
Engineering Manager & Full Stack Developer
Table of Contents
Education Apps Have Unique UX Challenges
Building apps for K-12 schools is fundamentally different from building consumer apps. Your users range from 6-year-old children to 60-year-old administrators. Your deployment environment ranges from brand-new iPads to hand-me-down Android phones with spotty WiFi. And your adoption depends on convincing three different stakeholder groups - teachers, parents, and school administrators - that your app is worth their time.
Having built Marathon Kids (50K+ users, fitness tracking) and LivingTree (20K+ users, school social network), I have accumulated a set of UX principles specific to education technology that I wish someone had told me before I started.
Lesson 1: Design for Three User Types Simultaneously
Education apps have a unique challenge: the same app must work for fundamentally different user types with different goals:
Teachers need efficiency - they are logging data for 25+ students at once. Every extra tap is multiplied by the size of their class.
Parents need simplicity - they check the app for 2 minutes while commuting. Information must be immediately visible.
Administrators need oversight - they want aggregate data, trends, and compliance reports across the entire school.
In Marathon Kids, we initially built one interface for everyone. It was mediocre for all three groups. The breakthrough was building role-specific home screens:
Teacher home screen: Batch activity logging with class roster, today's stats, quick-add buttons
Parent home screen: Their child's progress card, recent activities, milestone celebrations
Admin home screen: School-wide dashboard, participation rates, teacher engagement metrics
Lesson 2: Offline-First is Non-Negotiable
School WiFi is notoriously unreliable. Gymnasiums and outdoor areas - where Marathon Kids is actually used - often have no connectivity at all. An app that requires internet access is an app that fails at the worst possible moment.
We implemented a full offline-first architecture:
All data is stored locally in SQLite via WatermelonDB (for React Native)
Changes are queued and synced when connectivity returns
Conflict resolution uses a last-write-wins strategy with server timestamps
Users see a subtle indicator when they are offline, but the app works identically
Lesson 3: Accessibility is Not Optional
School apps must be accessible. This is both a legal requirement (Section 508, ADA compliance) and a moral one - schools serve students and parents with diverse abilities.
Every interactive element must be reachable and operable via screen readers (VoiceOver/TalkBack)
Color alone should never convey meaning - always pair color with icons or text labels
Touch targets must be at least 44x44 points - small children and users with motor impairments need larger targets
Text must be scalable - respect system font size settings, never use fixed font sizes
Test with real assistive technology users, not just automated tools
Lesson 4: Gamification Works (When Done Right)
Marathon Kids is fundamentally a fitness tracking app, but what drives engagement is gamification. Children love earning badges, reaching milestones, and seeing their progress visualized. But gamification can backfire if it creates unhealthy competition or makes slower children feel bad.
Our approach:
Personal progress over competition: Badges are earned for personal milestones, not for beating others
Effort-based rewards: Celebrate consistency (10 days in a row) not just achievement (fastest mile)
Class goals: The whole class works together toward a shared goal, encouraging cooperation
No public leaderboards: Progress is visible only to the student, their teacher, and their parents
Lesson 5: Onboarding Must Be Instant
Teachers have zero patience for complicated setup processes. If your app requires more than 3 minutes to get started, adoption will fail. Period.
In LivingTree, we reduced onboarding to:
Teacher receives an email invitation with a magic link
One tap to install from the app store
Magic link auto-logs them in and pre-populates their class roster from the school's SIS integration
They are posting content within 60 seconds of first opening the app
Lesson 6: Push Notifications Are a Privilege
Parents will uninstall your app the moment it sends too many notifications. We learned this the hard way when our initial notification strategy - every activity logged, every message received - caused a spike in uninstalls.
Our revised strategy: only notify for things that require action or celebrate milestones. A child reaching 100 miles? Notify. Teacher posted a class photo? Notify. Activity logged by the teacher? Silent update in the app, no notification.
The Impact
These UX principles transformed our adoption metrics:
Marathon Kids: Teacher weekly active usage went from 34% to 78% after the role-specific redesign
LivingTree: Parent onboarding completion went from 45% to 89% after the magic link flow
Both apps: App store ratings improved from 3.2 to 4.6+ stars
Education technology has the potential to genuinely improve lives - helping children stay active, connecting families with schools, and reducing the administrative burden on teachers. But only if we build it with deep empathy for the diverse users and challenging environments these apps operate in.
Stay Updated
Get notified when I publish new articles on engineering, AI, and leadership. No spam, unsubscribe anytime.