Mobile-first courses: how to build a course people actually finish on a phone

You recorded your course on a laptop. You tested it on a laptop. You showed it to friends — on a laptop. Your student opens lesson three on a bus, holding the phone in one hand, one earbud in, 40% battery left.

That is not an edge case. It is the default learning scenario for an adult who studies between work and family. And almost every part of a desktop-built course works worse on a phone — sometimes not at all.

A phone is not a smaller screen, it is a different scenario

• Sessions are short. Ten minutes in a queue, not two hours in the evening. A 40-minute lesson does not compress — it simply never starts.
• One hand, one thumb. Anything requiring precision gets mistapped.
• Sound is often off. Video without captions becomes a silent slideshow.
• Mobile data, not Wi-Fi. A 500 MB 4K file is a "later" decision that never arrives.
• Context switching. A call comes in and the student returns two hours later. If progress was not saved, they start over — once.

The conclusion: a lesson must be something a person can start and finish in one short session.

Video: vertical is optional, length is not

Mobile video does not mean vertical — landscape 16:9 works fine when the phone is rotated. What actually matters:

Length. Cut lessons into 5–8 minute pieces. Not because of "short attention spans", but because an 8-minute lesson gets tapped in a queue while a 45-minute one gets postponed. One lesson, one complete idea.

On-screen text size. A slide built for a projector needs a magnifying glass on a phone. Test it: look at the slide on a phone at arm's length. Unreadable? Double the font and delete half the text.

Captions. Not an accessibility extra — the thing that makes your video watchable on public transport. AI transcription handles a 15-minute video in minutes; you only proofread names and terms.

Adaptive quality. Video should be served in multiple renditions (360p / 720p / 1080p) so the player downgrades on a weak connection instead of spinning forever.

Resume position. The player must remember where the student stopped. Without it, every return means hunting for the right minute — and after the second time, they quit.

Materials: PDF is the worst mobile format

A 12-page PDF workbook looks solid on desktop. On a phone it is a document you have to zoom and scroll sideways.

• Put the main content in a text block inside the lesson, not as an attachment. Text reflows; PDF does not.
• Keep PDFs only for things people actually print: checklists, templates, forms.
• Tables wider than 3–4 columns are unreadable — repack them as "parameter — value" lists.
• Check external links: half of those "convenient" dashboards are dead on mobile.

Technical details that cost you completion

1. Input font size of at least 16px. Anything smaller makes Safari on iOS auto-zoom on focus. The screen jumps, the student leaves.
2. Tap targets of ~44×44 points minimum (Apple's guidance). Two links side by side in one line guarantee mistaps.
3. The bottom 10% of the screen belongs to the browser bar. A "Next" button hidden under it does not exist.
4. Autoplay with sound is blocked by mobile browsers. Do not build the lesson around it.
5. Long forms. An 8-field signup means calling up the keyboard eight times. Cut it to name, contact, button.

Assignments: shoot them, don't upload them

A student on a phone has no "report.docx". They have a camera and notes. If your homework flow requires uploading a document from a computer, you have moved submission to "when I sit at my laptop" — which means never.

Formats that work on mobile: a photo straight from the camera; a voice note or a 60-second video; plain text in the answer field; a cloud link the reviewer opens themselves. The harder it is to submit, the fewer submit — and a submitted assignment is the strongest predictor that a student will finish.

Reminders: push, Telegram or email

Mobile students barely read email on a phone — it gets opened at work alongside forty other messages.

• Telegram messages are the shortest path to attention: a notification, one tap, and the student is in the lesson — especially when the link points at a specific lesson, not the homepage.
• Browser push works but needs a permission most people decline.
• Email is still good for long-form: weekly summaries, breakdowns, announcements. Just not for "come back and finish the lesson".

The rule: one link that leads exactly where the person stopped.

A 20-minute checklist

Take a real phone (not a browser emulator) and walk the student path: sign-up and login — how many fields, does the screen jump; first lesson — how many seconds until video starts; thumb scrubbing — do you hit the right minute; leave and return — was progress saved; open a PDF — readable without zoom; submit homework — can you use the camera; find the next lesson — how many taps.

Every step that made you wince is a place where a student stops for good. This is not a design question, it is a money question: someone who never finished your first course will not buy the second.

How CREO handles this

We built CREO so that the mobile scenario is the baseline, not a responsive afterthought. The gamification that keeps completion at 70–80% works precisely because short lessons, streaks and progress are visible from a phone at any moment. Funnels and reminders run through Telegram. Homework is submitted from the camera. Payments go through WayForPay and Stripe. Over 100,000 students have already learned on our products, and support replies in about 15 minutes on average.

Beta testing starts in August 2026. Join the early-access list at platform.creo.ua — beta testers get MCP-driven school management, the sales page builder and the CRM first.