Knowunity Voice Recall
The problem: Students finishing practicing a session feeling like they know it, but recognizing an answer isn’t the same as producing it from memory. Nothing in Knowunity’s Exam Plan asks a student to retrieve and say a term before the real exam does.
The solve: Build out an optional voice-based active-recall step inside the Exam Plan. The student explains a key term out loud and the app replies in text confirming what's right, while nudging with a hint on what's missing, and never letting a wrong turn become a dead end.
My role: Solo design sprint, end to end. I owned the concept, flow, UI, and the working prototype build, then ran user testing and iterated the design against the findings.
Project Highlights
Example of the voice record flow.
Example of the text fallback.
Example of the the score summary.
Why the Design was Successful
-
The first version showed the hint right alongside a partial result, and testers just read it and repeated it back instead of trying to recall. I moved the hint behind a "Get a hint" tap, so a genuine second attempt by recalling can take place.
-
Testers hesitated to submit an answer they couldn't see, and some defaulted to typing just to stay in control. Showing a read-only transcript before submit removed that anxiety without giving them anything to game, protecting voice as the primary path instead of the fallback.
-
Every screen keeps skip, retry, and a one-tap "Type instead" fallback available. A student on a train, in a shared room, or just blank on an answer always has a way forward instead of getting stuck or dropping out.
Key Metrics
✅ 74% completion rate for the full recall step
🗣️ 82% of test sessions completed by voice rather than the text fallback
Learnings
Language matters more with a younger audience.
It’s more likely that a younger person who is told their answer is wrong won’t try harder, they’ll skip and move on. Partial answers lead with what they got right, and negative language is never used even when the correct answer has to be fully revealed.
Rewards are less important than the achievement.
The XP number was originally big enough to pull focus away from the actual result. Toning down the XP let the real achievement lead, and users could better prioritize what they still needed to work on in the session.
Designing for practice ≠ designing for a test.
The concept only works if students don’t feel they’re being graded. Having real accountability with zero pressure was the tension that shaped the entire design: generous scoring, guided hints, and no blocked paths.
The Larger Story
Knowunity is a studying app students use to revise for exams. Flashcards, quizzes, and video explanations are organized into a personalized "Exam Plan" for each subject, with "Knowie" as the app's mascot and in-app helper. This sprint added one new step inside that Exam Plan: instead of just reviewing a term again, a student explains it out loud, and Knowie responds in text. What follows is how that idea got found, chosen, built, and changed by testing.
The Illusion of Mastery
The work begin with an audit of the existing Exam Plan looking for moments a student feels they know something without ever having retrieved it. Finishing a revision card, passing a multiple-choice quiz by recognition, flipping a flashcard and generously self-grading were all current paths leading to this illusion of thinking a student really knows the material. Re-reading and recognition both build false confidence; only producing an answer cold breaks it. Nothing in the existing flow did that.
Choosing a Concept
I storyboarded two directions and stress-tested each against the can't-speak path. Concept A was a standalone bottom sheet for practicing, while concept B was an in-path, hint-laddered step. The bottom sheet lost the students who needed it most by living outside the Exam Plan they were already in. The in-path version won because it kept retrieval part of studying, not a separate exercise bolted on beside it.
Designing Inside Knowunity’s System
Rather than inventing a new visual language, I extracted the real Knowunity design system (colors, type, spacing, radius, and how Knowie's mascot and card/list patterns actually compose) directly from Knowunity's Figma file, and built every new screen (the mic affordance, the recording and result states, the hint ladder) as an extension of that system, not a graft from a different app.
Building With AI, Not Just Designing With It
The prototype itself was built in collaboration with Claude Code rather than by hand-coding every screen. Before any code existed, I had Claude interview me screen by screen to turn my flow into a written build spec, which forced decisions on edge cases (a misheard transcript, an empty recording, a network error) before they became implementation guesswork. Each screen was then built one at a time against a design-token reference file extracted from the real Knowunity Figma file, screenshotted, and compared side-by-side against the source frame until it matched. The result: a working, deployed click-through prototype (Next.js on Vercel) built and iterated in days, not weeks, that stayed disciplined to a real design system instead of drifting into generic AI-generated UI.
Testing and what Changed
User testing surfaced two changes that mattered more than anything else. First, the hint ladder as originally designed didn't ladder — it dumped the follow-up question and the hint on the same screen, so testers' eyes went straight to the hint and skipped the retrieval attempt entirely. Gating the hint behind an explicit tap fixed it. Second, testers wanted to see what they'd said before committing to it — the original design surfaced the transcript only after processing, which read as a loss of control. Moving the transcript before submit resolved it. Smaller fixes followed: clearer attribution between the student's and Knowie's chat bubbles, a switch from hold-to-record to tap-to-record after testers fumbled the end of a hold gesture, and toning down the XP moment so studying stayed the focus, not the score.
