Most writing about mobile learning treats the phone as an option: a convenience for people who travel, a second screen for people who already have a first one. For the population this guide is about, that framing is wrong in a way that changes every decision downstream.
A picker, a counter assistant, a line operator, a cleaner, a driver, a temp on their first shift: none of them has a desk. Most have no company laptop, and a large share have no company email address either. There is no evening at a home computer where the outstanding module gets finished, because there is no account to log in with. The phone is not the preferred channel. It is the only one that reaches these people at all.
That single fact carries consequences that are easy to skip past, and in Belgium and the Netherlands two of them are legal.
The channel question comes before the design question
Before anyone argues about module length or video, settle a more basic question: through what route does an instruction physically arrive at a person who has no company device and no company mailbox?
There are four candidates and only one scales. A printed sheet reaches everyone but proves nothing and cannot be updated. A screen in the break room reaches whoever looks at it. A back-office PC shared by a whole site reaches people one at a time, and only when the office is free, which on a busy floor is never. A link on the phone in the person's pocket reaches everyone, at any hour, in any language, and leaves a record.
Across multiple sites and shifts, the fourth is the only route that gets the same instruction to the third shift at site fourteen. Everything else here is about making that route work honestly.
No company device, no company email, and a private phone in between
Here the Benelux differs from the American framing that dominates this topic online, and it differs in a way that gets projects stopped.
Asking a worker to use their own phone for work is more sensitive here than it is in the US. It ends up on the agenda of the ondernemingsraad in the Netherlands and the CPBW or the vakbondsafvaardiging in Belgium, and it is raised as a fairness question rather than a technical one: whose device, whose subscription, whose data allowance, whose time.
Be precise about the status of that argument. There is no verified legal source establishing a general BYOD rule for training in either country, so nobody should be told there is one. Treat it as what it is: a practical and industrial relations question. You cannot win it by pointing at a statute, and you cannot ignore it either, because a works council that feels a cost has been quietly moved onto workers will slow the rollout whether or not it can block it.
The workable position is short. Require no installation, no private account, and no payment by the worker, in money or in data allowance they notice. Keep a shared alternative available at each site so the private device stays genuinely optional. Consult before you launch, not after somebody complains.
Two provisions that do carry weight here
Two things in Benelux law bear directly on this, and neither is about the device.
Dutch Arbobesluit art. 7.11a requires that the instructions for equipment are brought to workers' attention in comprehensible form. Comprehensible is doing real work in that sentence. A PDF manual attached to an email, opened on a five inch screen in a language the reader does not use at home, is not obviously comprehensible, and the burden of showing that it was sits with the employer.
Belgian Codex art. I.2-21 requires that every worker receives sufficient and appropriate training relating to their workpost or function, and adds two conditions that are usually left out of vendor material: the training happens during working time, and the cost is not borne by the worker.
Read those two together and the phone question sharpens. Mobile delivery is an excellent answer to comprehensibility, because it puts the instruction at the point of use in the person's own language. It is a poor answer to the working time condition if what actually happens is that a module lands at 21:00 and gets finished on the sofa. The channel is right; the scheduling has to be right with it.
Working time is a scheduling decision, not a platform setting
The honest version of mobile-first says this out loud: putting training on a phone makes it possible to train people at any moment, and the fact that you can does not mean you may.
So schedule it. Give the module a window inside paid time and say so when you assign it. Tell shift supervisors the five minutes are theirs to allocate, the same way a handover or a stock count is. Check completion timestamps occasionally: if a site's completions cluster after the last shift ends, you have found a scheduling problem there rather than a motivated workforce. That costs nothing beyond deciding it once and telling managers, and it removes the most common objection this kind of programme meets in a Benelux consultation.
Designing for a screen held in one hand
The device changes the content, not just the container. The rules are unglamorous and they hold up.
Length first. Frontline attention comes in gaps of a few minutes, between a delivery and a queue. A module needing twenty uninterrupted minutes gets started repeatedly and finished rarely. Three to five minutes is not a stylistic preference, it is the size of the available gap.
Text density second. A paragraph that reads comfortably on a laptop is a wall on a phone. Two or three sentences per block, one idea each.
Interaction third. Tapping works. Typing does not, on a phone, standing up, wearing gloves. Multiple choice with large targets, image based questions, the correct and incorrect result side by side: those survive the device. Drag and drop and long free text do not.
Language fourth, and it is not cosmetic. On a mixed floor the module has to arrive in the language each person actually reads, or comprehensible in the sense of art. 7.11a is not being met for part of the shift.
The device to test on is the oldest one on the floor
Testing on the communications manager's new phone tells you nothing. Borrow the cheapest current Android handset sold in your markets and run the whole thing on it: on cellular data rather than office Wi-Fi, in the browser the phone shipped with, in portrait, one handed. Then repeat it as a learner rather than an administrator. Take the invitation from wherever a real worker would get it, open the module, get a question wrong, come back an hour later and check nothing was lost. Most of what breaks in a mobile rollout breaks in that first ninety seconds, and none of it shows up in a demo run on a laptop.
Two things are worth checking specifically because they are frequently missed: whether the manager view also works on a phone, since a site manager without a desk is in exactly the same position as the crew, and how somebody without a company mailbox receives their invitation in the first place. That second one is a question to put to any vendor in writing before you sign, because the answer determines whether half your population can be reached at all.
Putting this together in Aristotl
Aristotl was built for this population rather than adapted to it, which shows up in a few concrete properties.
Everything runs in the browser. There is no app to install on a private phone, which removes both the IT problem and the consent problem in one step. The same link opens on a phone, a shared tablet in the back office, or a desktop, so the alternative device you keep available for anyone who prefers it is not a separate build.
Modules are short by construction. Your own procedures, handbooks and instructions are converted into three to five minute units with knowledge checks, which is what makes them finishable in a real gap rather than in a hypothetical one.
Content is translated per worker, so one assignment reaches a mixed floor in the languages people actually read. Completion is recorded per person, site, role and version, and can be exported, which matters less for the training itself than for the moment somebody asks you to demonstrate that an instruction was given.
Test it with the phone in your own pocket
Pick one procedure that currently reaches your floor as a printed sheet or an email nobody opens. In a demo we build it as a mobile module and you open it the way a worker would, on your own handset, on mobile data, standing up. If it does not work there, it does not work.