Engineering
10 min read

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.

Building Mobile Apps for Education: UX Lessons from Marathon Kids and LivingTree
DP

Dibyank Padhy

Engineering Manager & Full Stack Developer

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.

Found this helpful? Share it with others

DP

About the Author

Dibyank Padhy is an Engineering Manager & Full Stack Developer with 7+ years of experience building scalable software solutions. Passionate about cloud architecture, team leadership, and AI integration.