MDCAT Preparation EdTech Case Study

A test-prep platform for students sitting MDCAT, ECAT and SAT. Practice, recorded lectures and mock tests in one place, across a marketing site, a web app and a mobile app.

I owned product design end to end: research, flows, the design system, and the final UI for all three surfaces.

Students had no shortage of questions to answer. They had no idea which ones were worth answering next.

Practice was disconnected from progress: you could sit ten tests and still not know whether Chemistry or Biology was costing you the most marks.

I went through the prep apps students already used and found the same pattern in most of them: a large question bank, a score at the end, and nothing in between.

Scores told students how they did. None of them told students what to do next. That gap set the direction: the product would be judged on its analytics, not its question count.

Several sessions with the founders and the academic team to agree what the product was for before anything was drawn.

We settled three things: four test types (subject, chapter, grand, custom), one shared progress model across web and mobile, and free practice with paid depth rather than a hard paywall.

I interviewed students preparing for MDCAT and SAT about how they actually revise between tests.

Three things came up repeatedly. They abandon tests midway and want that to be recoverable, not punished. They retake the same questions without noticing they are repeating mistakes. And a single overall percentage tells them nothing. They think in subjects, chapters and topics, so the analytics had to as well.

I mapped the full journey before the UI: land, pick a course, take a test, review it, and act on the review.

The edges got the most attention, because they are where students lose trust: exiting a test, finishing early, reporting a broken question, resuming an aborted attempt, and jumping to a specific question mid-test.

Three surfaces, one system. Shared tokens, one accent red carrying every primary action, and a severity scale of green, amber and red that means the same thing in a score, a progress bar and a difficulty row.

Cards, filter pills, stat tiles, the test player chrome and the confirmation dialogs were built once and re-used, so the mobile app reads as the same product as the web app rather than a port of it.

The analytics screen took the most rounds. It started as one overall view and kept failing the same way in review: students could see a weak score but not the topic behind it.

It ended as four nested levels: overall, subject, chapter, topic. The layout is the same at each level, so drilling down never means learning a new screen. Question Review was added late, once it was clear that seeing which specific questions you keep missing was the thing students wanted most.

The landing page leads with outcomes and named universities, because trust is the first thing a parent paying for prep is looking for.

The web app is the study surface: dashboard, practice zone, the test player with its passage-and-question split, and post-test review down to per-question detail. The mobile app carries the same model into a phone: the analytics, the practice zone and the test player all survive the smaller screen without losing a level of depth.

Three surfaces shipped on one system: a marketing site, a web app and a mobile app, covering MDCAT, ECAT and SAT practice alongside recorded lectures and mock tests. Cards, filter pills, stat tiles, the test player chrome and the confirmation dialogs were built once and re-used, so the phone reads as the same product rather than a port of the web app.

The product settled into the shape the research pointed at: the review screen became the destination and the test became the thing that feeds it. What I cannot tell you is whether students drilled past the second analytics level. I designed four and validated none, and that is the first gap I would close.

The analytics were the product. Everything that made this work came from treating the review screen as the destination and the test as the thing that feeds it.

What I would do differently: I designed the four analytics levels before validating that students would drill past the second one. That was a guess that happened to hold, and it should have been a test.