Tallo

Designing a Student Privacy Trust Center at Tallo

Product discovery case study: four weeks of reading FERPA, school data privacy agreements, COPPA, and state student-privacy law, turned into an access model and a permission management design for students, guardians, learning coaches, and schools.

A table titled 'Who has to say yes before a student is visible to an employer?' showing, for each age band from under 13 to 18 and older, who holds rights over school records, which federal minor-privacy law applies, and whose consent is needed for school-linked and personal accounts.

In September 2026, Tallo's director of product management told me it wasn't fair to ask me to become the company's expert on student privacy law. But someone had to understand FERPA and the schools' data privacy agreements well enough to write the requirements. I didn't see it as unfair. I'm not a lawyer, but a product manager who can't read the clause is a product manager who ships a feature that legal has to kill.

So I spent the next four weeks reading. This case study covers what I learned and the trust center design it turned into. The design is complete, but it hasn't been built.

The Goal: Safe and Compliant for Schools

Tallo is a career platform for young people, and more and more of its students arrive through their schools. The goal was to understand exactly what Tallo needed to do so a school could use it safely and in compliance with the law, and then to design the interface that would let schools, families, and students manage who can see and do what.

Before designing anything, I framed the problem as three jobs rather than a list of users: a gatekeeper job ("let me be sure this is safe before I let my kid in"), a coaching job ("help me help my kid"), and a pull job, where a student brings a parent in. The gatekeeper job decides whether the other two ever get used, so that's where the work started.

What the Research Found

I ran two structured research projects covering access models, identity, district feature controls, adult and minor safety, parent and learning coach linkage, sharing, employer visibility of minors, student privacy law, and school data privacy agreements. A fact-check pass verified every claim, and I read the primary sources myself wherever the answer mattered. A few findings shaped everything that came after.

FERPA Is About School Records, Not Age

Most people treat FERPA as a minors' privacy law. It isn't. FERPA governs school records, and it applies to an 18-year-old senior the same way it applies to a 14-year-old freshman. Protecting minors is a separate obligation that applies whether or not a school is involved.

That changed the data model. A single "FERPA student" flag tries to answer two different questions at once. The design splits it in two: whether this account holds school data (whose rules govern it), and how careful the product needs to be with this person because of their age. A student can have both, either, or neither.

Two Kinds of Accounts, Two Bodies of Law

Almost every "what does the law require" question had two answers. A school-linked account is governed by the school's settings and its data privacy agreement. A personal account is a consumer account under consumer law, with the protections every minor gets. So whether an account is school-linked has to be a first-class fact the product stores, not something it guesses at when someone asks.

Where the Data Came From Decides Who Controls It

The National Data Privacy Agreement, a standard template many districts sign, treats school-provided data and anything the vendor infers from it as the school's. That includes a course list, and it includes the skills a product derives from that course list. That data never transfers to the student, and turning 18 or graduating doesn't change that.

Student-created work, like a resume or a portfolio, is different. The school controls it while the relationship is active, but it's the one kind of data a student can take with them, once it's actually transferred to their control. A prefilled "confirm this is right" screen doesn't turn school data into student data, and none of the 17 products I checked tries that. If a student wants a school fact in a personal account, they type it in themselves, and the product labels it as self-reported.

Age Bands, and Why Each Line Sits Where It Does

Under 13 is COPPA territory, which requires verifiable parental consent. From 13 on, federal law requires nothing in particular, but a growing set of state design codes, like Maryland's Kids Code, requires a high level of privacy by default for minors. Rights over school records move from the parent to the student at 18 or when the student starts college, whichever comes first.

Within those lines, I drew one more at 16. A 16- or 17-year-old with a personal account can choose to make their profile public and opt in to being found by employers, starting from a private default. Federal child labor rules let a 16-year-old work any non-hazardous job, and major consumer platforms already let 16- and 17-year-olds relax settings without a parent. The law requires a private default for teens, not a lock, and a career platform that hides every working-age teen from employers stops being useful to them. Younger teens on personal accounts stay locked down, because there's no verified parent to ask.

And when the age is unknown, the product assumes the student is under 18. School records beat self-reported birthdays.

Parents Can Restrict, but They Can't Expand

This was the most counterintuitive finding. Under a school's data privacy agreement, a parent's consent stacks on top of the school's authorization. It never replaces it. The agreement's disclosure clause has no exception for parent consent, so showing a school-linked student to an employer is a disclosure the school has to authorize first, not a setting a parent can flip.

Where the law offers no consent route, the product shouldn't offer one either. California's student privacy law allows no route for employer visibility at all, even with parent or student consent. Texas allows disclosure for an employment purpose the student or a parent requests. Georgia rewrote its rule in July 2026 to require explicit consent from a parent or a student over 13. I kept these differences in a policy table rather than in code branches: take the strictest rule as the floor wherever it's cheap, and vary by state only where the strictest rule would make the product useless somewhere else.

Even where a parent's consent is the missing piece, a parent portal is the wrong place to ask for it. Published studies put the share of parents who ever log in to a school portal between about 15 and 50 percent, and the share using it on a typical day in the low single digits. If consent requires a portal login, almost no student ever gets the feature. Consent the school already collects at enrollment works better, and so does a one-time request a student sends a parent, for one named action.

A Learning Coach Isn't Always a Legal Guardian

Online schools use "learning coach" for the adult who supports a student day to day. That's often a parent, but it can be a relative or an older sibling. FERPA's definition of a parent includes a guardian, or a grandparent raising the child, but not a sibling. A school sign-in proves who someone is. It doesn't prove what authority they have.

So the design has two lanes. Any adult a student chooses can get a read-only view of exactly what the student shares, whatever the student calls them. Only a guardian of record, as recorded by the school, can restrict settings or give consent. A learning coach who isn't the guardian of record can look but not change anything.

Sharing Depends on Who Performs the Disclosure

A student downloading their resume and sending it to their mom is the student's act. A student typing their mom's email into a form and having the product send it is the vendor's disclosure, which for a school-linked student needs authorization. Same outcome, different legal question. The design favors sharing the student performs: download, the phone's share sheet, or a link the student sends themselves, with every share limited to one item, expiring by default, and revocable from one list.

From Research to Permission Management

The research turned into a single access model that every other product doc builds on, and a permission management interface on top of it. The design principles carry well beyond Tallo:

  • Settings nest downward. A district sets on, off, or "let schools decide," a school decides what the district left open, a guardian can only turn things off for their own child, and the student chooses within all of that. Nothing loosens from below. It's the same shape districts already know from the tools they use.
  • Every lock says who set it. "Set by your school," "Set by your family," "Because you're under 18," and "This changes when you turn 18." A locked setting is greyed out with a reason. It doesn't silently disappear and look broken.
  • Admins set policy, not individual students. Students who need special protection, like a custody order, are flagged by the school in its own systems, and that flows in through the roster.
  • Private means the profile doesn't appear to exist. To anyone not authorized, a private profile looks exactly like a profile that doesn't exist.
  • Deny by default, enforced on the server. A switch that only hides something in the browser is worse than no switch.
  • Explain as much as you control. Most of the trust happens in words. Say "moderated," never "monitored," and check every claim against what the system actually enforces.
  • Build guardian controls because schools need to see they exist, not because parents will log in weekly, and measure it that way.

The design included screens for students, guardians, counselors and other read-only viewers, school admins, and district admins, along with a change history modeled on FERPA's record-of-disclosures rule, a review students go through when they turn 18, and the epics and stories behind it. The wireframes stay with Tallo.

How I Worked Through the Law

Two things kept this from turning into four weeks of reading with nothing to show for it.

First, I wrote for product people, not lawyers. The first deliverable was a plain-language brief whose stated goal was to make the eventual conversation with counsel sharper and shorter, followed by working answers to the questions the product team actually needed answered. Where the law was unclear, I built on the more protective option and wrote down what would make us revisit it. Every doc kept its "reading, not ruling" caveats, and when a verification pass found that hedges had been sanded off between the research and the summary, they went back in.

Second, I triaged the legal questions instead of handing them all to counsel. About 160 questions across 30-plus documents came down to about 47 distinct ones, in four tiers: ask now, ask when the work starts, proceed on a working answer that only counsel can loosen, and park. Anything about something already happening went to the first tier, because not asking doesn't protect anyone.

I used AI research agents for the breadth, with a separate fact-check pass on every claim; across the main project, that was 1,009 claims. The judgment about what the findings meant for the product stayed mine.

What It Proved, Unshipped

The trust center is designed and specified, but it hasn't been built. The research and the access model are useful either way, because they answer the questions every school-facing feature runs into.

The best test came a month later. A designer asked why one of my mockups worked the way it did, and I could explain the four different ways that screen could go depending on FERPA, the school's data privacy agreement, the parent's consent, the student's age, and the state they live in. Four weeks earlier, I couldn't have told you most of that.

Every product that serves minors through schools runs into these questions eventually. The ones that get them right treat privacy as part of the product's architecture, not a settings page added at the end.

This case study describes my product reading of public law. It isn't legal advice.

FAQ: Student Privacy for Ed Tech Products

Does FERPA require an ed tech company to give parents a login?

No. FERPA's inspection right is owed by the school, and the regulation lets a school meet it with a copy of the records or another arrangement. What a vendor always owes is a complete, prompt export to the school, so the school can meet its own obligations. Any parent access a product adds sits on top of that.

Can a parent consent to an employer seeing their child's profile?

For a student whose account is linked to a school, a parent's consent alone isn't enough. Under a typical school data privacy agreement, the school has to authorize the disclosure first, and then the state's rules decide whose consent is also needed. In some states, no consent route exists at all.

What's the difference between a learning coach and a guardian?

A learning coach is a support role, and it can be a parent, a relative, or an older sibling. A guardian is a legal relationship. A product should let any adult a student chooses see what the student shares, but only a guardian of record, as recorded by the school, should be able to restrict settings or give consent.

Sources

Public primary sources behind the legal claims above. Statutes and agreements change, so check the current text before relying on any of them.

Federal law

School data privacy agreements

State law

Research and platform policy

Related Case Studies

Dealing with something similar?

Through Fieldway, I help product and engineering teams figure out what's broken – whether that's a delivery problem or a strategy problem – and build a concrete plan to fix it.

Learn more at fieldway.org