Knowunity
2.5-week product design sprint
From recognition to recall
Designing a voice-based active recall experience that helps students demonstrate what they've actually learned.
Knowunity is an AI-powered learning platform that helps students study and prepare for exams. It brings together study materials, personalized study plans, quizzes, flashcards, mock exams, and an AI learning companion.
As part of a 2.5-week product design sprint with Yummy Labs, I explored how voice-based active recall could become part of Knowunity's exam preparation experience. The goal was to help students move beyond recognizing the correct answer and demonstrate their understanding by explaining concepts from memory.
Role
Product Designer
Timeline
2.5 weeks
Scope
Tools
01 / THE PROBLEM
Knowing the answer isn't the same as knowing the material.
Students have plenty of ways to study. They can review notes, flip through flashcards, and answer practice questions. But getting a question right doesn't always mean they understand the concept.
A student might recognize the correct answer when they see it, but struggle to explain that same concept without any prompts.
That distinction became the starting point for my exploration: how could Knowunity help students understand what they actually remembered, rather than just what looked familiar?
03 /THE OPPORTUNITY
Where should active recall happen?
Once I understood the difference between recognizing and recalling information, I needed to figure out where this experience belonged within Knowunity.
I explored three possible entry points: flashcards, quizzes, and mock exams. Each offered a different opportunity, but I wanted voice recall to feel like a meaningful part of studying rather than another feature students had to seek out.
Flashcards
Friction
Multiple-choice or revealing the answer is easier than speaking. Students might default to the familiar interaction instead of engaging with voice recall.
Opportunity
Students are already reviewing individual concepts, making it a natural moment to ask them to explain what they've learned.
Impact
Voice recall could become another study method rather than a meaningful way to assess understanding.
Quizzes
Friction
Multiple-choice questions are quick to answer, while recording takes longer. Mixing the two could disrupt the pace of a quiz, and partial answers introduce questions about scoring and feedback.
Opportunity
Quizzes already ask students to retrieve information and demonstrate what they know, creating a natural transition into voice recall.
Impact
Voice could interrupt an otherwise fast-paced activity and make the experience feel less cohesive.
Mock exams
Friction
Mock exams had lower completion than lighter study activities, meaning fewer students might reach the experience.
Opportunity
Mock exams create a more deliberate assessment context. Students are already testing their knowledge, making it meaningful to go beyond recognizing an answer.
Impact
Voice recall becomes part of a more intentional assessment experience, helping students distinguish between recognizing a concept and retrieving it from memory.
The direction I chose
Make recall the second round of a mock exam.
I chose mock exams because they offered the clearest context for moving beyond recognition. The experience would use two rounds: students first identify the correct answer, then explain the concepts they recognized in their own words.
03 /THE OPPORTUNITY
The trade-off
A smaller audience, a stronger context.
Mock exams may reach fewer students, but they provide a more deliberate assessment context where voice recall has a meaningful role.
03 /THE OPPORTUNITY
04 / DEFINE
Turning recognition into a recall experience.
I structured the experience around two rounds, then worked through what happens when students struggle to recall an answer. The challenge was making each step feel clear and manageable, without turning a missed response into a dead end.
The experience at a glance.
05 / INTERACTION
Making voice recall feel natural, not intimidating.
Voice introduces a different kind of interaction. Students aren't selecting an answer anymore; they're being asked to explain what they know out loud.
I focused on making that experience feel manageable. Students needed control over what they submitted, a chance to review what was captured, and feedback that helped them understand what to do next.
Giving students control while recording
Multi-step setup
Complex booking settings broken into manageable steps.
Review screen
A single place to review all listing details before publishing.
Edit affordance
Each section provides a direct way to edit corresponding step.
Letting students review before submitting
Multi-step setup
Complex booking settings broken into manageable steps.
Review screen
A single place to review all listing details before publishing.
Edit affordance
Each section provides a direct way to edit corresponding step.
Making feedback constructive
Multi-step setup
Complex booking settings broken into manageable steps.
Review screen
A single place to review all listing details before publishing.
Edit affordance
Each section provides a direct way to edit corresponding step.
Making missed answers part of learning
Multi-step setup
Complex booking settings broken into manageable steps.
Review screen
A single place to review all listing details before publishing.
Edit affordance
Each section provides a direct way to edit corresponding step.
05 / IN PRACTICE
A review step teachers could jump back into.
Setting up a booking meant working through a lot of configuration: time zone, minimum notice, available days and availability, refund policy, a toggle for whether refunds were allowed at all, and the policy text itself.
On one page that would have been a wall. We split it into steps, each with its own progress indicator, to keep the setup digestible. The founder's reference was Airbnb's listing creation.
At the end, teachers reviewed what they had entered. I designed each review section as a clickable container with an edit affordance, so a teacher could go straight to the step they wanted to change instead of walking backward through the whole flow, then land back on the review. This pattern was mine. It was not something Untitled UI gave us.
Multi-step setup
Complex booking settings broken into manageable steps.
Review screen
A single place to review all listing details before publishing.
Edit affordance
Each section provides a direct way to edit corresponding step.
Return to editing
Teachers return to the relevant step without starting over.
Selecting edit takes the teacher to the corresponding step. Nothing is edited inline on the review screen.
06 / REUSED
I reused the review-and-edit pattern for booking modifications. When a teacher needed to change the date, time, or hourly rate in response to a student's request, the review screen highlighted the proposed changes in green. This made it easier to see what had changed before confirming the update.
The original request before modification.
Updating the date, time, or hourly rate.
Modified values highlighted in green.
One pattern, two workflows: setting something up for the first time, and changing something that already exists.
06 / MORE APPLICATIONS
One system, across product and brand.
AUDIENCE MANAGEMENT
From lists inside events to one directory.
Students used to live inside individual events, so a teacher only ever saw the people attached to one thing at a time. The redesign brought everyone they had interacted with through Werk into a single directory, split across All, Subscribers and Students, with segments that are allowed to overlap.
Each person carries what a teacher actually needs: events attended and how many, tickets purchased, total paid, join date. From there a teacher can email the whole audience or just one segment.
WAIVERS & CONSENT
One place to say what's required.
Liability waivers and media releases were being handled separately. Werk supplied a generic version of each, so the job was not document management. It was making it clear what a teacher was asking of people.
Teachers could preview both documents and turn each requirement on or off independently, with helper text appearing to explain what it means when one is off. The documents were fixed, and nothing was signed or collected here.
Teachers could enable or disable liability waivers and media releases independently, with contextual guidance explaining each choice.
BRAND APPLICATIONS
Applying the design system across Werk's brand
Alongside the product, I designed Werk's landing page and marketing materials, applying the system's colors, typography, and visual direction across its public-facing brand.
Redesigned landing page
Marketing campaign assets
07 / BEYOND FIGMA
Taking ownership of the system beyond Figma
After the product lead left, I took ownership of the design system’s ongoing direction. That meant formalizing decisions that had previously lived mostly in Figma and making the system easier for engineering to reference during implementation.
I created a token file containing the system’s values, a Markdown document defining components and their usage, and a set of instructions outlining the standards developers should follow. The developer incorporated these files into their AI-assisted coding workflow, giving the AI a shared reference for how Werk’s interface should be built.
Figma remained the visual source of truth. These written resources gave engineering a clearer reference for the values, components, and standards behind the interface.
Design tokens documented as code, giving engineering a consistent reference for the system’s values.
Brand guide HTML
Design system documentation
Figma stayed the place to see what something should look like. These were the record of what it actually was, and what the rules around it were.
08 / WHERE IT LANDED
A direction everyone could build on.
Once we had adapted Untitled UI to Werk, the founders had a visual direction they were happy with. I could focus on solving product problems and designing new features within an established visual language, rather than revisiting aesthetic decisions each time.
The product became more cohesive, and new features had an established visual foundation to build on rather than starting from scratch each time.
Both light and dark themes shipped to Werk users. The visual language reached past the product into the landing page and marketing material.
By the end of my engagement, the design system had grown beyond a Figma component library. It included documented components, design tokens, and implementation guidelines that the engineering team could continue referencing as the product evolved.
One set of components, one set of semantic tokens, two themes in production.
09 / REFLECTION
The system grew faster than its documentation.
I was moving between features quickly, on limited hours, and maintenance happened alongside delivery rather than as its own responsibility.
02
Designers felt it most
Developers could carry on once they were told a component had changed. Finding things was the designer’s problem.
04
Ownership came late
The tokens, the documentation and the rules came together in the months I had left.
What would I do differently?
One central library, instead of components spread across project files.
The rules written down early, while the system is still small enough to hold in your head.
Regular passes over what already exists, so nobody rebuilds what is already there.
A way to see what changes in code when a component is redesigned.
The lesson for me is the timing more than the work. The system did its job, it supported a product that kept growing, and it gave design and engineering a shared vocabulary. Organizing it was the part that never got its own time until the end.