But there is another question schools should be asking:
What does the design of the technology make possible in the first place?
That distinction — policy versus design — may be one of the most important procurement questions we can ask about educational technology.
A current example
This week, San Francisco City Attorney David Chiu sent Meta a cease-and-desist letter after researchers identified more than 350 paid advertisements across Facebook, Instagram and Threads promoting AI tools capable of generating sexualized or non-consensual imagery involving minors.
Meta says the advertisements violated its policies and that the offending ads have been removed. That’s the right reaction, and I am not interested in using this as another opportunity to say, “Meta bad.” That gets us nowhere.
Meta has policies prohibiting this material. The important question is what happens when a platform becomes so large, interconnected and complex that enforcing those policies becomes an enormous ongoing task.
There is a larger lesson here for education.
A policy tells us what should happen. Design determines what can happen.
And sometimes the better solution is not another rule, another setting or another moderation system.
Sometimes it is to eliminate an unnecessary capability altogether.
Start with the learning objective
Imagine we are evaluating a VR system for a school. Instead of beginning with:
- What can this headset do?
perhaps we should begin with:
What does this student actually need this headset to do?
- Does the learning experience require an individual social identity?
- If not, why create one?
- Does it require an advertising ecosystem?
- Almost certainly not.
- Does it require detailed tracking of the student's body?
- Sometimes.
- But often it does not.
- Does it require a continuously connected external ecosystem?
- Sometimes, maybe.
But perhaps the lesson itself could simply be stored on the device.
This is design-based risk reduction.
Instead of constantly managing what students are allowed to do, we ask whether some of those possibilities needed to exist at all.
Privacy policies are not privacy architecture
Consider tracking.
Modern VR devices can collect extraordinarily detailed information because sophisticated sensing is required for many advanced applications.
That can be tremendously useful.
If a learner is practising welding, surgery, equipment repair or another highly physical procedure, accurate positional and hand tracking may be essential.
Use it.
But if a 12-year-old is standing inside a virtual cell learning how mitochondria work, why would we need detailed biometric movement data?
The answer shouldn't be:
“Don't worry. Our privacy policy explains how we handle it.”
The first question should be:
Why are we collecting it?
That is the difference between privacy policy and privacy architecture.
A good policy tells you how information will be protected.
A privacy-first design asks whether the information ever needed to exist.
The same applies to safety
Recent legal settlements and legislation increasingly require technology companies to introduce protections for younger users.
For example, Meta's proposed settlement with U.S. states includes time limits, nighttime restrictions, limits on notifications during school hours, stronger parental controls and age-assurance measures.
California has now gone further, adopting additional restrictions around addictive platform features for minors.
These measures matter. But notice what many of them are doing. They are controlling existing functionality.
- Limit the notifications.
- Limit the hours.
- Limit the feed.
- Verify the user's age.
- Give parents more controls.
All reasonable responses to a consumer platform that already exists.
Education gives us another option.
Don't introduce unnecessary functionality in the first place.
A learning platform doesn't necessarily need an infinite feed.
- It doesn't need likes.
- It doesn't need followers.
- It doesn't need advertising.
- It doesn't need strangers.
- It doesn't need notifications designed to bring the learner back.
- It doesn't necessarily need an identity beyond whatever information is required for learning.
And if those things aren't there:
- Teachers don't have to supervise them.
- Administrators don't have to disable them.
- Parents don't have to configure them.
- IT doesn't have to manage them.
Every unnecessary feature creates another responsibility
This is where design connects directly to teacher burden.
When consumer technology is brought into education, schools often begin removing things.
- Disable this.
- Block that.
- Create restricted accounts.
- Configure privacy.
- Install device management.
- Lock the student into one application.
- Control the store.
- Push the correct content.
- Prevent access to everything else.
Then monitor the devices to make sure everyone remains where they are supposed to be.
Eventually, the system becomes workable.
But we should stop occasionally and notice what just happened.
We took technology designed to do many things and employed teachers, IT systems and management software to stop it from doing most of them.
There may be circumstances where that makes perfect sense.
But it should not automatically be considered the best architecture for education.
Made for education starts with subtraction
There is a tendency in technology to equate more features with a better product. Education frequently needs the opposite. Good educational design may involve deliberately removing things.
- No advertising.
- No unnecessary social interaction.
- No unnecessary accounts.
- No unnecessary tracking.
- No unnecessary data collection.
- No app-store distractions.
- No dependency on continuous internet access when learning can happen locally.
- No requirement for the teacher to become the operator of the technology.
That isn't technologically unsophisticated. It is purposeful design. The sophistication is deciding what not to include.
This should become part of procurement
When schools evaluate educational technology, I think we need to add another column to the procurement checklist.
- Not simply:
- What are your privacy policies?
- But:
- What data does your design make it possible to collect?
- Not simply:
- What parental controls are available?
- But:
- Why are those controls necessary?
- Not simply:
- Can administrators disable social features?
- But:
- Why does an educational device need them?
- Not simply:
- Can an MDM lock students into the right application?
- But:
- Why were they somewhere they shouldn't be in the first place?
- And not simply:
- Can this technology be made safe and manageable for education?
- But:
- Was it designed that way from the beginning?
That is the conversation I believe we need to have about VR in education.
- Policies matter.
- Compliance matters.
- Controls matter.
But they come after design.
The better question is whether we can remove unnecessary risk, complexity and teacher burden before the device ever reaches the classroom.
Because the safest setting is sometimes not another setting… it is designing the system so the setting was never needed.
That is the difference between technology that can be made workable in education and technology that was made for education.
#SensibleVR #VRinEdu #VRPrivacy #VRPolicy
