ScaleYou Insights
Students who sit their exams on paper get a score back and nothing else. Insights turns the same answer sheet into feedback they can act on.
My Role
Founding Designer
Research to QA, 3+ years
Team
Founders (CEO, CTO)
Engineers · design interns
What did I do?
Supervisor · Evaluate · mockup with the live screen, sample data
Colleges run JEE, NEET and CET mocks on paper. Students get a total and nothing to act on.
Every result stays private until a person has reviewed it. Publishing is its own, deliberate step.
Founding designer since Jan 2023: research, strategy, UX, prototyping, front-end and QA.
2 institutions and 250+ students since 2023. The 2026 rebuild is tested end to end on synthetic data; its first observed exam is next.
A score is not feedback.
A student in a Tier 2 or Tier 3 city writes a JEE, NEET or state CET mock on an OMR sheet. They learn their total, their positive and negative marks, and nothing else. There is no question-by-question breakdown, no sense of which concepts are weak, and no guidance on what to do next.
A student on a digital platform gets chapter-level analysis, a rank and a list of what to revise. That gap is the product.
I joined ScaleYou as its founding designer in January 2023 and have owned the product’s design since, from the first research conversations to the screens, the front-end and QA. I worked with the founders (our CEO and CTO), the engineers and a small group of design interns. This case study covers both versions: the product we took to colleges first, and the rebuild I led in September 2026.
- 01
Jan 2023
Joined as founding designer
- 02
Version 1
Research, a one-month sprint, a live product
- 03
2025
Supervisor, student and faculty designed in Figma
- 04
Sept 2026
Rebuild, 16 documented phases
- 05
Next
One real exam, observed
Change what happens after the exam, not the exam.
Colleges weren’t going to stop testing on paper, and they shouldn’t have to. So the product had to act as a bridge between offline testing and digital analytics: personalised, granular feedback at scale, without disrupting the workflow an institution already runs. What it had to earn in return: a competitive advantage, brand loyalty and long-term retention.
That workflow touches four people, and each needs something different from the same answer sheet.
Supervisor
Runs the college’s exams: writes papers, prints them, scans the sheets, publishes results.
Faculty
Sees which questions their own students got wrong, and which chapters to reteach. Only their own batches.
Student
Sees their own result, chapter-level strengths and weaknesses, and where they stand in the batch.
Super admin
ScaleYou staff. Onboards colleges and gives the first people access.
Who we’re really up against
Not another learning app. A ₹3-lakh OMR machine, and the vendor who services it.
From our September 2026 product review. The comparison that matters is with the machine the college already pays for, not with online test platforms.
We went straight to the source.
We couldn’t design this in a vacuum. We spoke with the students who needed feedback and the educators overwhelmed by manual grading. What we found shaped our UI priorities.
What motivates you most after a test?
How do you prefer to see your performance metrics?
What device do you use to access study material?
How much time do you spend reviewing mistakes?
Would you share your test score among friends?
What’s the hardest part about paper tests?
Fig 01 — Early conceptual mind map
One month, research to build.
The first version was planned as a one-month sprint. Research and student conversations came first. By the second half, design and build ran in parallel while we were still testing concepts.
Three kinds of people read a result.
Once we had talked to enough people, the answers fell into three groups. They shaped the next part of the strategy.
Personas from our user conversations
Wants to know their exact rank among peers immediately.
Needs a question-by-question breakdown of their mistakes.
Emotionally invested in score variance.
Just wants to verify they passed the baseline cutoff.
Only checks metrics if prompted by a competitive friend.
Not very emotionally invested.
Doesn’t have time to learn complex new software.
Wants to upload a spreadsheet and get instant charts.
Needs to identify the weakest concepts of the entire class.
The student portal, designed in 2025
In 2025 I designed the student side in Figma: a dashboard, a detailed report, and a mobile web version of it. The student flow is still clickable.
Fig 02 — Student dashboard · Figma, 2025 · mockup
The same report, sized for the phone a student actually has.
Every section of the desktop report was redrawn for a 412px-wide screen: the score card, score and subject analysis, difficulty, chapters and strength. Mockup of the Figma design.
Explorations: how should a score feel?
For the class distribution chart I tried three directions: a celebratory header with a percentile, a neutral median with low and high markers, and the two combined. Each one puts a different message first.
Chart explorations. Figma, October 2025.
The faculty view
Teachers got a class-level test analysis: the score distribution, highest, lowest and average, question difficulty, then chapter-by-chapter analysis for each subject.
Four rules I held the rebuild to.
In September 2026 I rebuilt Insights around four product rules, written into its brief. Every screen has to keep them.
Nothing is guessed.
A double-marked bubble is reported, not resolved. A sheet printed for another paper is refused, not scored. In an exam product, a confident wrong answer is worse than an honest gap.
“In progress” is not “needs attention”.
A half-written paper is normal work. The warning colour is kept for things that are actually broken, so it keeps its meaning.
Sets are orderings, not copies.
Set B holds the same questions in a different order. Same count, same marks, same content are true by construction, not something a supervisor has to check.
Records, not channels.
The product sends no email, SMS or WhatsApp. A “communication” is a note that a call happened, and the screen says so where it matters.
A result needs a review before it becomes feedback.
What broke
A scan session lived inside one screen. Close the tab and there was no record a sheet had been read, and no way to correct one. One bad photo in a batch of forty meant starting the batch again.
What I changed
Every sheet became a record: its photo, what was read from it, whether anyone corrected it, and whether it became a result. A correction never means typing a score. A person says which bubble was marked; the marks follow from that set’s answer key.
The photo stays beside what was read from it. Publishing is a separate card at the top, locked until every sheet is saved. Sample data.
Saving and publishing do different jobs
Saving makes a result durable but private. Publishing releases the reviewed version to students and faculty. If a saved answer is corrected, the earlier release is withdrawn until the supervisor publishes again, and an outdated session can’t publish over newer marks.
- 01
Read the sheet
Photo and detected answers, side by side.
- 02
Review & correct
Confirm the bubbles; the marks recompute.
- 03
Save privately
Stored once the server confirms. The paper locks.
- 04
Publish results
The reviewed version goes to students and faculty.
Every failure says what to do next
A sheet that fails stays in the list and says why, whether it can be corrected, whether reading it again would help, and what to do instead.
A sheet from another paper is refused
Each sheet carries a four-digit test code, printed pre-darkened. A sheet from another paper is excluded instead of scored as plausible nonsense. The chance of a collision slipping through drops to 1 in 10,000, from a certainty.
An unreadable photo stays in the batch
The failed sheet stays in the batch with a reason and a next step. One bad photo no longer means redoing the whole batch.
A failed save stays unsaved
A sheet is only marked saved once the server confirms it. Until then it reads unsaved, and it can be retried.
The printed sheet is part of the interface.
Browser printing rescaled the answer sheet to fit its own margins, which moved every bubble away from where the scanner looks. Papers and sheets are now drawn straight into a PDF from the same layout the scanner reads, so the two can’t drift apart.
Each student’s sheet comes pre-printed with their roll number and the test code, which removed the biggest source of sheets that couldn’t be matched. A 180-question NEET paper fits on one sheet and read 180 of 180 from an angled photo in testing.
Both generated by Insights: the Set A question paper and a pre-printed answer sheet. Student and answers are sample data.
Let a long paper stay a work in progress.
The constraint
A 180-question paper gets written over several sittings, and out of order. Questions, answer keys and sets are never all finished at the same moment.
The decision
Creating a test is one short, linear screen. Everything after is a tabbed workspace, with a readiness panel beside the work that separates what blocks printing from what is merely worth checking.
“Fix before printing” (a missing answer key) is kept apart from “Worth checking” (an unmapped chapter). Sample data.
Sets share one question pool
The Sets tab spells out what is guaranteed across sets, and flags the one thing that isn’t: scrambled options mean each set needs its own answer key.
Import refuses to guess
Teachers can paste a paper they already have. When an answer names an option the question doesn’t have, the importer flags it instead of filing something plausible.
The same workspace on a phone
Insights runs on web and mobile. Every screen was checked at 390px wide, and an automated check walks 23 screens and fails on any sideways scroll.
Every paper, from first draft to printed set.
180 questions, written over several sittings.
Set B: the same questions in a new order.
Live supervisor screens at 390 × 844, sample data · mockups.
Give the result a reading order.
A result is a number; an analysis is what to do about it. The 2026 report answers the questions in the order a student asks them.
- 01Where do I stand against everyone who sat it?
- 02What stands out?
- 03How did my marks split: correct, wrong, blank?
- 04Which subjects and chapters carried or cost me?
- 05Where am I actually strong, across every paper?
- 06How do I do as questions get harder?
- 07What should I do next?
- 08Every question, my answer beside the right one.
Nothing is invented
A paper only one person has sat shows no class average, because the only average available would be their own score. A question with no chapter mapped counts as unmapped, not filed somewhere plausible.
No clock
The report never claims how long anyone spent on a question. An OMR sheet records the answer, not the time it took.
The “what to do next” advice is drawn from the student’s own paper, not a template. Whether it’s the right advice for a given student still needs checking with teachers.
The printed report, sketched first
Alongside the screens, the report a college can print started as sketches on paper: what a student should get back from one exam (marks, rank, class average, strong and weak chapters, a teacher’s note). Then it became an A4 layout.
Sketches, then the A4 layout. Figma, September 2026.
What changed when the details pushed back.
From the 2025 designs to the 2026 product, plus the bugs a closer look caught on the way.
From a wizard to a workspace.
The 2025 supervisor design was a step-by-step wizard: exam details, tag faculty, then questions entered one form at a time, then upload the question paper, the answer key and a folder of OMR photos and press Start analysis. The 2026 product keeps the whole paper in one workspace, and turns evaluation into reviewing every sheet. Drag to compare.
A strong chapter showed up under “needs more work”.
Doing well in
• Rotational Motion — 90 out of 100 right
Needs more work on
• Rotational Motion — 90 out of 100 right
Why it happened
Ranking chapters from weakest to strongest always produces a “weakest” chapter, even when every score is good. With few chapters mapped, the same one landed in both lists.
The fix
One threshold, 70%, in one place. Both lists split at it, so they can’t overlap, and all four screens that show strengths read the same value.
The lesson
The student dashboard had already been fixed. The printed parent summary hadn’t. When a fix lands, search for the pattern, not the screen.
Two buttons that checked nothing.
Before
- 01Complete the paper
- 02Mark paper ready
- 03Finalise paper
- 04Print
The side panel said “This paper is ready to print” while the paper still refused to print.
After
- 01Complete questions and one set
- 02Print or scan
- 03First saved sheet locks the paper
Readiness comes from the work itself. The lock moved to the first moment anything is scored against the paper.
The buttons existed to freeze questions and answer keys before students sat the paper. That rule still holds; it just happens at the right moment now, instead of being a ceremony a supervisor had to remember.
Show the whole library before asking for a chapter.
The 7,000+ question library was briefly split by chapter to save bandwidth. The picker then opened on the thirty-odd questions a college had written itself, and the library looked missing. It compresses to about 1.2 MB, so the split came out: the picker now pages through everything, and filters narrow it.
Five students, not four hundred.
The demo used to open on four colleges and 400 students, which hid the product behind its own data: you can’t tell whether a number is right when you can’t count the students it came from. The default institute now has five students written to five shapes: strong, average, struggling, a paper half left blank, and one who hasn’t sat anything yet. The large institute is still one click away for testing scale.
What it has done, and what’s still unproven.
Since 2023, the exam-to-insight workflow I designed has been used across 15+ institutional exams, replacing fragmented OMR and traditional approaches.
The 2026 rebuild, tested end to end
On 16 September 2026, one automated run took a corrected result all the way through, each role in its own browser session:
Supervisor
31/40 → 27/40
Corrects a saved scan
Student
27/40
Opens their result after release
Faculty
67.5% of marks
Sees the released result
Synthetic data on local Firebase emulators. It proves the correction-and-release flow works; it doesn’t measure usability or learning.
Stress-tested before a real exam
In a September design and engineering review, the scanner was attacked with nine kinds of damaged scan (photocopies, JPEG artefacts, a 180° rotation, a thumb over a corner mark, a crease, faint pencil) plus a corner-drift sweep. It never produced a confident but wrong read. Every corrupted scan failed loudly.
What’s next
One real exam, observed: in the hall with a stopwatch, building nothing, then fixing whatever that exam actually reveals.
The best design work here made the product easier to trust.
Insights connects a screen to things outside it: a printed question, a pencil mark, a teacher’s judgement, a student’s revision plan. A small inconsistency anywhere in that chain travels the whole way, and ends up on a sheet a parent is handed.
Two habits came out of it. Review the whole journey after changing a rule, because fixing a label on one screen means nothing if its printed twin still disagrees. And prefer an honest gap to a confident guess, in the product and in how I talk about it.