Dynamind — Scaling Personal Attention
A two-sided EdTech platform that gives one mentor the leverage to deliver personalised, data-driven tutoring to many students — turning every score into a specific next step.
Year:
2021-2023
Tools:
Figma, Miro, Protopie
Category:
Ed-Tech
Schools & coaching
Signed on as pilot partners —
early validation
2 apps, 1 system
30 students
Interviewed first-hand to ground the
student-facing learning loop
Problem
Decades of research point to the same uncomfortable truth: a student with a dedicated one-on-one tutor dramatically outperforms the same student in a crowded classroom — Bloom's "Two Sigma" effect, where a 50% student can cross 98% with personal attention. The problem is that personal attention doesn't scale. It's gated by a tutor's time and a family's budget, so the students who most need it rarely get it.
Dynamind set out to close that gap for the Indian exam-prep market (JEE / NEET / CUET, grades 8–12). But the deeper we looked, the clearer it became that "more content" wasn't the problem
Context
Personal attention doesn't scale. A tutor can only watch, diagnose, and coach so many students at once. Past that ceiling, feedback gets generic and students fall through the cracks.
Tutors run a business, not just a classroom.
Independent mentors spend as much energy finding students, setting assessments, tracking progress, and marketing themselves as they do teaching — across a scatter of disconnected tools.
Students see scores, not next steps.
A percentage tells a student how they did, not what to do next. Without a bridge from "result" to "specific fix," practice stays busy but aimless.
The founders framed Dynamind as an AI tutoring product. Research reframed it as a leverage product. The value wasn't replacing the mentor — it was giving one mentor the tools to feel personal at scale, and giving each student a loop that converts every result into a concrete action.
That reframing changed the whole design brief from "build a tutoring app" to a single design question:
What gives one mentor the leverage to stay personal across many students — and turns every student's score into a specific next step, inside the tools they already use daily?
Everything after this — the assessment builder, the practice loop, the analytics — is an answer to that question.
Solution
Dynamind is a two-sided platform built on one principle: a closed loop between mentor and student. What a mentor authors becomes a student's personalised path; what a student does flows back as the mentor's insight. The core design challenge was serving two opposite jobs — creating versus consuming — inside one coherent system and design language.
Information architecture. Each module is anchored by a persistent bottom navigation of 4–5 core destinations, so the user's primary jobs are always one tap away and the two experiences stay structurally parallel.
Key Screens
User Goal
Area
Phone-OTP signup, verified profile
Establish credibility
Onboarding & Profile
Question bank, sections, difficulty, marking, preview
Create reusable tests, fast
Assessment Authoring
Add / import / invite
Bring students in
Student Management
Student & Assessment reports
Spot who needs attention
Analytics
Classrooms + Chat
Stay connected
Community
Banners, cards, brochures
Grow the practice
Marketing toolkit
Mentor module — the tutor's operating system
Designed around the job: "set work, see who needs help, and grow my practice."
Key Screens
User Goal
Area
Grade / Exam / Target-year setup
Set goal & exam
Onboarding & Profile
Take, Review, Solutions
Practise & review
Assessment
Gamified topic practice
Build a study habit
DOJO
Strengths / weaknesses → Correction Plan
Diagnose & Act
Performance
Predicted rank + Percentile
Gauge standing
Rank Predictor
Follow, Classrooms, Chat
Stay connected
My Teachers / Community
Student module — the personalised learning loop
Designed around the job: "know where I stand, and what to do next."
My Role
→ Sole UI designer for the entire platform — every screen across both the Mentor and Student modules.
→ Owned user flows, wireframes, interaction design, and clickable prototypes (Figma + ProtoPie).
→ Built and maintained the design system — type scale, colour tokens, and reusable components used across both modules.
→ Co-led research, including first-hand interviews with 30 students; joined a brief that founders had already scoped, and translated it into the end-to-end product structure.
Impact
Commercial validation: an initial contract covering multiple schools and individual coaching institutes was signed off on the pilot — strong early traction for a pre-scale product.
Adoption reality: the mobile app reached ~500 downloads, with in-school usage skewing to the companion web app (same flows and structure I designed) — a channel insight, not a hidden failure.
Shipped: the product launched and ran a real school pilot; I was with the company through that phase.
Key Decisions
What we almost did: a single long "create test" form, or letting tutors upload a PDF question paper.
What we did instead: a Sectioned builder with a reusable Question Bank, per-question difficulty tagging and negative marking, and a Save-draft → Preview → Send-for-review path.
Why: tutors build assessments repeatedly, under time pressure. A form digitises the task; a builder scales it — reuse cuts effort, and the preview/review gates catch errors before students ever see them. This is the mentor's highest-frequency job, so it earned the most structure.
What we almost did: fold practice into the same assessment flow — just another quiz.
What we did instead: a distinct gamified, topic-wise practice mode with instant correct/incorrect feedback, quality-scored questions, and streaks/points, decoupled from high-stakes tests.
Why: mixing daily practice with graded evaluation raises anxiety and slows the feedback loop. Separating them lets practice be frequent, low-pressure, and habit-forming, while assessments stay meaningful.
What we almost did: present scores and percentages — a digital report card. What we did instead: a loop — Areas Excelled / Areas of Weakness → Correction Plan / remedial actions → per-assessment "areas of improvement" → peer comparison.
Why: students read scores, not diagnoses. The design value is in telling them what to do next, which is the literal operationalisation of "personal attention" — the mentor's coaching, encoded into the interface.
Deep Dive
Context
Dynamind serves the Indian competitive-exam market, where students juggle school, coaching, and self-study across JEE/NEET/CUET prep. Tutors — often independent or small institutes — are the trusted relationship, but they're stretched thin and tooled poorly. When I joined, the founders had already defined the product vision and a feature list; my job was to make it real, usable, and coherent, and to ground the student-facing side in evidence.
Problem Statement
"How might we design a system that lets one mentor deliver personalised, data-driven attention to many students — and turns each student's results into a clear, actionable next step?"
Attention hits a ceiling.
One tutor can't personally diagnose dozens of students at once.
The tutor's workflow is fragmented.
Creating tests, tracking progress, and reaching students lived in separate tools.
Scores aren't actions.
Students received results with no built-in "what next."
Two audiences, one system.
Mentors and mentees have opposite jobs but must share one coherent product.
Research
Phase 01 — Inherited requirements
The founders provided a scoped feature set and market thesis. I pressure-tested it against real student behaviour rather than taking it as given.
Phase 02 —Student interviews
I ran first-hand interviews with 30 students to understand how they study, react to feedback, and use existing prep apps.
Phase 03 — Behaviour mapping.
I mapped the study loop — practise → assess → react → repeat — to find where students dropped off or lost direction.
Design Pillars
Leverage over
replacement
Amplify the mentor, don't automate them away
Every score has a
next step
No result without a recommended action.
Practice is low-stakes, assessment is high-stakes
Keep them psychologically separate.
One system, two coherent experiences
A shared design language serving opposite jobs.
Features
Assessment Authoring — Creating a test is the tutor's most frequent and most time-consuming job, so this flow got the most structure. Instead of a blank form, it works like a builder: the tutor sets up the paper with cascading course → grade → subject → topic → chapter filters, adds a cover image, and pulls questions from a reusable Question Bank — or adds new ones that are saved back for next time. The design goal was to make the tenth assessment far faster to build than the first.
Questions are organised into sections, support multiple types (single-choice, integer, and more), and carry per-question difficulty tags and negative marking, so a paper can mirror the real exam it's preparing students for.
Key design details:
A staged path — Save-draft → Preview → Send-for-review — so nothing reaches a student unchecked, and a half-built paper is never lost.
Preview shows the student's-eye view, letting the tutor catch errors before publishing.
One-tap sharing into classrooms, closing the loop from authoring to delivery without leaving the flow.
Dojo — Gamified Practice —Dojo is deliberately kept apart from graded assessments. The insight from research was that mixing daily practice with high-stakes testing makes students practise less — so Dojo is a low-pressure space for topic-wise micro-practice, designed to be opened for a few minutes at a time and to build a daily habit.
Each question gives instant feedback — a clear correct/incorrect state the moment an answer is submitted — so the learning loop closes immediately rather than at the end of a test. Questions are quality-scored, keeping the practice pool relevant to the student's level.
Key design details:
Instant right/wrong feedback with an explanation path, turning every attempt into a micro-lesson.
Streaks and points to reward consistency, not just correctness — nudging return visits.
A report-issue path on each question, so students help keep the bank accurate.
Dojo Analytics tracks momentum — topics enrolled, points earned, and leaderboards — making progress feel visible.
Performance Analytics — This is the screen that turns the whole product's promise — personal attention — into something a student can act on alone. The design principle was simple: no score without a next step. Rather than a report card, it's a loop that moves the student from "how did I do?" to "what do I do now?"
It opens with an at-a-glance overall performance view, then breaks results into Areas Excelled and Areas of Weakness so strengths and gaps are separated, not averaged into a single number. A trend graph shows whether things are improving over time, and each assessment carries its own "areas of improvement."
Key design details:
A Correction Plan that converts weak areas into concrete remedial actions — the diagnosis-to-action handoff.
Per-assessment breakdowns, so a dip is traceable to a specific test and topic, not a vague feeling.
Compare-with-a-friend, adding gentle social motivation without turning learning into a public ranking.
Rank Predictor — For exam aspirants, a raw mark means little — the real question is "where do I stand against everyone else sitting this exam?" Rank Predictor answers exactly that. The student takes a timed mock test, and the result is reframed from a score into a competitive position.
The result screen returns a predicted rank range (e.g. JEE Mains 7400–8200) rather than a false-precision single number, a question report breaking down correct / incorrect / unattempted, and a concise result summary (marks, attempted, accuracy). A percentile bell-curve then places the student visually within the wider cohort.
Key design details:
A range, not a single rank — honest about prediction being an estimate, which also lowers anxiety.
A direct path to re-attempt and to review solutions, so the prediction leads back into study rather than ending the session.
Accessibility is a baseline, not a finishing step. Looking back with a sharper lens, the areas I'd change first are the ones I'd now treat as non-negotiable against WCAG 2.1 AA: contrast on the teal-on-navy palette, and correct/incorrect states carried by colour alone (they need an icon or label so they work for colour-blind users too). I'd also revisit the dense analytics screens, where a bar or trend line often reads faster than a donut. The lesson isn't "add accessibility later" — it's design inclusively from the first frame, because in the market I'm building for now it's an expectation, not a nice-to-have.
The real challenge was one system serving two opposite users. Mentors create; students consume. Holding one design language coherent across two opposing jobs — without either side feeling like an afterthought — was harder than any single screen. It pushed me to design the shared system first (tokens, components, navigation model) and the individual screens second. That systems-first habit is what let a small team ship a large, consistent product.
Adoption is a design problem, not only a marketing one. The product won strong commercial interest, yet real in-school usage centred on the web app rather than mobile. That gap taught me the most: where and how people actually reach a product is part of the design brief. Next time I'd validate the primary channel early and design mobile as the companion it turned out to be — reading distribution, not just the interface.
I'd close the loop with evidence. We shipped and piloted, but without a tight measurement loop behind it. Given the chance again I'd define success metrics up front — task completion for assessment creation, practice-return rate for Dojo, action-taken rate off the Correction Plan — and run structured usability testing against them. Shipping is the start of learning, not the end of it; pairing design decisions with evidence is the discipline I'm carrying into my next role.
