Designing Safe Student Access in Music Education Software
Allowing students to access an online system is never just a technical decision.
It involves real questions about:
• age and consent,
• student safety,
• privacy boundaries,
• and how much control schools and teachers should retain.
In My Music Studio, student access has been designed deliberately and conservatively — prioritising safety, clarity, and explicit consent over convenience.
This article explains the principles behind that design.
The core problem
Students sit in a unique position:
• They are active participants in learning.
• They are often minors.
• They exist within overlapping relationships between teachers, parents, and schools.
A system that treats student accounts as “just another user type” quickly runs into problems:
• blurred consent boundaries,
• accidental access,
• unclear responsibility when something goes wrong.
The goal with student access in My Music Studio was not simply to allow it — but to make sure that access is appropriate, intentional, and reversible.
Separating identity, consent, and access
A key design decision was to treat these as three distinct concepts, rather than collapsing them into one.
A student can:
• exist in the system,
• be legally consented,
• and even authenticate,
without automatically being allowed into the platform.
This separation allows the system to answer important questions independently:
• Who is this student?
• Has consent been granted (or is it required)?
• Is access currently allowed for this school?
By keeping these concerns separate, the platform avoids accidental access and supports more nuanced, school-specific decisions.
Age-aware, school-controlled consent
Consent requirements are not hard-coded globally.
Instead:
• each school defines its own age of consent,
• student age is derived from date of birth,
• and eligibility is evaluated per school, not per student globally.
This matters because:
• a student may be old enough to self-manage access at one school,
• but still require parental consent at another.
Consent is requested only when required, and is handled explicitly — never implicitly.
Explicit parental consent, handled safely
When parental consent is required, it is:
• initiated by the teacher,
• scoped to a specific student and school,
• time-limited,
• and auditable.
Parents receive a secure, single-use consent link that allows them to:
• review what access means,
• explicitly grant or deny permission,
• provide a typed name as an e-signature.
Consent responses are recorded with:
• timestamps,
• source,
• and response metadata.
No consent is assumed. No access is inferred.
Activation is deliberate — not automatic
Even after consent is granted (or age requirements are met), student access still requires explicit activation.
This means:
• teachers remain in control of when a student gains access,
• access can be delayed, enabled, or revoked per school,
• and no student is silently added to the platform.
Revocation is also explicit:
• a revoked student can authenticate,
• but will not be routed into the system for that school,
• and revocation always overrides age or consent.
This design prevents edge cases where access lingers unintentionally.
One login, multiple schools — safely
Students may legitimately belong to multiple schools.
The system supports this while maintaining strict boundaries:
• one login identity per email,
• multiple student records per school,
• access evaluated independently for each relationship.
A student can be:
• active in one school,
• consented but inactive in another,
• and revoked in a third —
without those states interfering with one another.
Clear role boundaries at login
After signing in, the system resolves roles deliberately.
If a user has:
• teacher access,
• parent access,
• student access,
they are either:
• routed automatically when unambiguous, or
• shown a clear role chooser when multiple roles exist.
Students are never redirected into teacher areas, and access is always gated by explicit eligibility checks.
Designing for responsibility, not just features
Student access is often treated as a checkbox feature.
In My Music Studio, it’s treated as a responsibility.
That means:
• conservative defaults,
• explicit consent,
• school-level control,
• and systems that make it difficult to do the wrong thing by accident.
The result is a model where:
• students are protected,
• parents are respected,
• teachers retain authority,
• and access is always intentional.
This approach takes longer to design — but it scales more safely, and it reflects the care expected in an educational context.