An education product usually has four kinds of people in it. A student who is learning. A teacher or tutor who is teaching and getting paid. A parent who is paying and worrying. And an administrator at the institute who has to make the whole thing add up.
They share one database and almost nothing else. The mistake nearly every EdTech product makes is to design the student experience properly, then serve the other three a version of it with different data in the same layout.
The navigation is where you declare the roles
On the Your-Tutor marketing site, the navigation splits the two audiences at the top: find a tutor, and become a tutor. Neither has to wade through the other.
That is a small decision with a long tail. A visitor sorts themselves in the first two seconds, and every page after that can be written for one reader instead of hedging between two. A site trying to sell tutoring and recruit tutors in the same hero writes sentences that do neither well.
It also sets the expectation that this is a product with sides, which is more honest than a single door that forks three screens later.
One object, four sentences
Here is the exercise we run at the start of a multi-role brief. Take the central object in your product — for a tutoring platform, a session — and write the sentence each role would say about it.
The student says: I have maths at four o’clock and I need the link.
The tutor says: I have three sessions today, one is a new student, and I get paid on Friday.
The parent says: did last week’s session happen, was it any good, and what have I spent this month.
The administrator says: forty sessions ran, two were cancelled late, and one tutor is not filling their slots.
Four sentences, four screens. Same object, same record, same API. The moment you can write those sentences you can stop arguing about whether the parent needs their own dashboard, because the sentence is obviously not answerable from the student’s.
The two sides are different shapes, not mirrored screens
The Your-Tutor web app is built around the hardest step, choosing a tutor. That is a comparison task, so the screen is a filter panel beside a result list and nothing else. Hourly rate is a two-handle range slider, availability is a day-by-day checklist, and gender, verified status and student level collapse into the same column to keep the panel short. Filters change the list in place; there is no separate results page to travel to.
Each result carries only what someone actually compares: photo, name, the subject and certification line, two lines of biography with a read-more, the hourly rate, the star rating and the hours taught. Rate and rating sit in a fixed right-hand column so they line up down the page and can be read without reading a single row.
The student learning app is a different shape entirely. It opens on a question — what do you want to learn today — with search under it and subjects as a short illustrated list. A student who knows what they need is one tap away; a student who does not can browse.
Comparison against intent. Copying either layout onto the other would have produced something worse than both.
Share the component, not the layout
What both sides do share is the tutor card. In the student app, tutors use one card shape throughout: photo, rating, hours taught, experience and hourly rate in the same positions every time, so two tutors can be compared without re-reading either.
That is the right level at which to share work across roles. The card is one component with one set of rules, and it appears in search results, in a subject listing and in a booking confirmation without being redrawn.
The layouts around it differ per role. The component does not. Products that get this backwards — sharing page templates and forking components — end up with four slightly different tutor cards and one dashboard that fits nobody.
The parent is the role that pays and the role designed last
Parent dashboards are the weakest part of most education products and one of the most valuable. A parent is not a supervisor with read access to the student view. Their questions are different: did the session happen, is progress real, what has this cost, and is the person teaching my child who they say they are.
That last one is why the verified filter and the certification line matter on the tutor side. Trust signals designed for the buyer are not decoration; they are the parent’s half of the product appearing in the student’s half.
A parent view built from those four questions is small — a recent sessions list, an attendance and progress summary, a spend figure, and the tutor’s credentials — and far more useful than a copy of the student dashboard with the student’s name on top.
The administrator is running an operations tool
The fourth role gets designed last and then gets designed as a report. An institute administrator is doing operations work: which sessions ran, who did not turn up, which tutors are underbooked, what gets invoiced.
That is a different discipline from the rest of an EdTech product, and it is closer to the dashboards we cover in SaaS product and dashboard design than to anything on the student side. Lists that sort, status that reads down one edge, one action per screen. Treat it as an operations tool that happens to be about learning, not as a student screen with more rows.
When the model is unfamiliar, say it in plain words
Multi-role products often invert something people expect, and the marketing has to carry that.
The Enrol hiring marketplace sells an inverted model, so the headline says it plainly — get matched with a job you love, anywhere — and the sub-line spells out the mechanic: companies apply to you, with salary details upfront. Sign up for free is the only primary button on the page. Everything else is a quiet secondary, because one page cannot ask for two decisions at once.
If your platform asks parents to book and pay while students choose, or lets tutors set their own rates, that mechanic is the thing to state in the first three lines. Multi-role products fail in the market for the same reason they fail in the interface: nobody could tell whose product it was.
One check to run on your own product
Take the single most important object in your system — a session, a class, an assignment — and write the one sentence each role would say about it, in their words, as they would say it to a friend.
Then open your product and see how many of those sentences can be answered on the first screen that role lands on. Every sentence that cannot is a screen you have not designed yet, and it is almost always the parent’s.
Multi-role systems are the substance of our EdTech product design work, and a live platform can go through our free 15-point UX audit if you want the gaps ranked for you.
Questions we get asked about multi-role EdTech
Should parents get their own login or share the student account?
Their own, from day one. Shared logins destroy the record of who did what, make progress reporting meaningless, and force one interface to be both age-appropriate and financially detailed. A linked parent account costs a little more to build and removes a whole category of support problem.
One app for everyone, or separate apps per role?
One product, separate entry points. Splitting into different apps duplicates messaging, sessions and payments across codebases, and people who hold two roles end up installing twice. Split the navigation and the landing screen, share the components and the data.
How much of the student experience should the teacher see?
What they need to teach, and no more. A tutor needs the schedule, the student’s level and history, and the messages. Turning a teaching tool into a surveillance dashboard changes how students use the product, and the thing they stop doing first is asking questions.
Where do you start when all four roles need work?
With whichever role’s failure kills the account. In tutoring that is usually the tutor, because an empty supply side ends the product however good the student app is. In school software it is the administrator, because they renew the contract.
How do you test with students?
Short moderated sessions with real students on real devices, usually five per round, before and after the design. Students will not tell you a screen is confusing, but you can watch them stop.