People don't read screens. They scan them.
Eye-tracking studies have shown for twenty years what every web writer eventually feels: people don't read screens the way they read books. They scan in patterns — F-shaped on dense pages, in chunks where attention lands. They skip over walls of text. They read the first sentence of a paragraph and decide whether to read the rest. Writing as if your reader will absorb every word is the most common eLearning mistake there is.
Lead with the conclusion.
Manual writing builds toward a point. Screen writing puts the point first. "Before approving a refund, confirm three things" beats "When considering whether to approve a customer's refund request, there are a number of factors that should first be confirmed." If the learner reads only the first sentence — which they often will — they should have the takeaway. Everything that follows is reinforcement, not setup.
Front-load the meaningful words.
Eye-tracking research is unambiguous: readers focus on the start of each line, then drop attention as the line continues. Open with the verb or the noun that carries the meaning. "Click Submit when finished" beats "When you have finished, click the Submit button." Pad the start of a sentence with throat-clearing ("It is important to remember that..." / "Please note that...") and you've burned the learner's attention before reaching what matters.
Short paragraphs are read. Long ones aren't.
Two or three sentences per paragraph. More than that, the paragraph reads as a wall and gets skipped. This isn't dumbing down — it's matching the medium. Even good readers skim long blocks on screens. Break the content into smaller pieces and the same words get absorbed; combine them into one block and they get lost.
Concrete beats abstract, every time.
"Use professional language" is abstract — every reader interprets it differently. "Don't use slang or shorthand abbreviations like 'lol' or 'tbh'" is concrete. Screen readers — both human and assistive — handle concrete instructions better. Abstract writing demands the reader stop, interpret, and decide. Concrete writing leaves nothing to decide.
Part two
Speak to the learner. Use the words they'd use.
Manuals and policies are written in a corporate third-person — "the employee", "the user", "the customer". Screen writing is direct. Second person, active voice, present tense. The learner reads "you" and feels addressed; the learner reads "the employee" and feels described.
Use "you", not "the employee" or "the user".
Direct address closes the distance between the writer and the reader. "When you receive a complaint, document it within 24 hours" lands harder than "When an employee receives a complaint, the employee must document the complaint within 24 hours." Second person also forces clarity — it's harder to be vague when you have to address someone specifically.
Active voice over passive.
"We review every entry" beats "Every entry is reviewed". Active voice is shorter, names the actor, and reads faster. The exception is when the actor genuinely doesn't matter or shouldn't be named ("The form was submitted at 3pm") — but in eLearning, the actor almost always matters. Someone has to do the thing the course is teaching. Name them.
Use contractions.
"Don't" beats "do not". "You'll" beats "you will". "It's" beats "it is". Contractions read warmer, faster, more like spoken language — which is the register screen writing wants. The formal "do not" register is right for legal contracts and some compliance text. For everything else, it sounds like a lecture.
Match your audience's vocabulary, not your industry's.
Industry jargon ("stakeholder alignment", "actionable insights", "operationalise") tests poorly because most learners don't use those words at home. They use the words their teammates use, the words from emails and Slack messages. Write for that vocabulary. If you must use a term of art, define it once on first appearance and trust the learner to remember it. Don't reuse a defined term as if it's everyday vocabulary.
Read your draft aloud.
This is the cheapest writing test there is and the one writers skip most often. Read each paragraph out loud. Where you stumble, the reader will stumble. Where it sounds robotic, it reads robotic. Where you take a breath because the sentence is too long, the reader's attention has already wandered. Five minutes of reading aloud catches more issues than an hour of re-editing in your head.
Part three
When to break the rules.
The rules above are defaults, not absolutes. Some content needs different treatment.
Legal and compliance text
When the exact wording is dictated by regulation, you may be stuck with corporate third-person and the passive voice. Don't fight the legal team about every comma. Do fight to frame the legalese — write a short paragraph in screen-friendly voice explaining what the section covers, then quote the regulatory text verbatim. The learner gets both: a path through the formal language and the formal language itself.
Quotes and case studies
Quotes from real people should sound like real people. Don't sanitise testimonials into corporate copy. "We were drowning in compliance training" is a quote. "Our team was experiencing significant burden related to compliance training requirements" is not. If a case study character is meant to feel real — see writing engaging scenarios — let them talk like a person.
Highly technical procedures
Step-by-step instructions for technical procedures can — and should — sound technical. "Configure the SSL certificate via the admin console" is right. "Set up your secure thing on the admin page" is wrong. Use the actual names of the things being configured. Precision wins when imprecision could break something.
Screen writing is its own discipline. Concise, direct, second-person, active. Lead with the point, front-load meaning, keep paragraphs short, use concrete words. Read everything aloud. You'll write less than you would for paper — and the learner will read more of what you wrote.