Ai-powered mobile app
Nalu*
Designed for personalized learning and AI-driven quizzes.
// Context and Problem
Nalu is a mobile EdTech app built for working professionals who take courses but need proof they actually understood the material - not just a certificate of completion.
The core problem: people finish lessons without knowing if the content stuck.
Nalu's job isn't to give people more content to sit through. It's to build a guided path to real comprehension, using AI-generated quizzes that confirm understanding instead of just tracking progress.
I ran this project solo, end to end — market research, target audience and competitive analysis, a design system built from scratch with tokens, prototyping, and usability testing. From initial concept through developer handoff.
What I set out to do:
1. Research the market, audience, and competitors to find where the app's real value lives for users 2. Design a UX and design system from the ground up that makes that value visible at every step — from lesson to AI quiz 3. Prototype and test the experience to understand how that value converts into a paid subscription
Competitive Research
To find where that confirmation actually happens, I looked at the competitors. For them, the quiz is mandatory to pass the course and provides several attempts.
Nalu has a different focus — honest confirmation of understanding, and that's its central AI feature: questions are generated fresh every time, and answers get shuffled, so you can't memorize or guess.
And the quiz is optional for completing the lesson — which means if someone chooses to take it and does so consciously, that's proof the material was understood. That's where the real value of the app lives.
User Segments
To find out where the feeling of "I actually get this" was breaking down, I went and talked to people directly — not what they were studying, but why. From in-depth interviews, I built 3 personas: the Goal-Closer, the Practical Pragmatist, and the Fast Competitor. Goal-Closer. Highly sensitive to course structure and to the feeling of "I closed this topic out." She wants everything tight and structured, no filler, short blocks.
02
Practical Pragmatist
Highly sensitive to the quality of tasks and feedback: if the feedback feels off or shallow, trust drops fast.
03
Fast Competitor
Picks things up quickly, doesn't want empty repetition. A self-directed learner, willing to dig for understanding herself — search, notes, AI.
I designed more than 7 scenarios across the project.
In this case I'm walking through just one - the most critical.
Next, I moved to a User Journey Map — to pinpoint exactly where along this path the Goal-Closer might drop off.
Next,wo issues opened up.
The first: the one that worried me most: what happens when someone answers wrong. The second, and after a lesson, it's unclear what comes next.
Product goal
Give users who answer incorrectly on the quiz a clear path back to the material for the specific topic they got wrong.
Research goal
Understand how users look for a way to work through a topic they missed, right there on the quiz results screen — and what path back to the material they expect to find.
To conduct the qualitative research, I defined five user profiles with different motivations, recruited people who matched those profiles, and sat them in front of the prototype. I asked them to think out loud, and that's when it got uncomfortable:
All 5 could see the correct answer — and not one of them understood why it was correct.
Retrying turned into guessing. Everyone spotted the "Try again" button, but nobody read the "Something to review" block as an action. The person was left alone with their mistake, with no idea where to go next.
That's where the idea that shaped the whole project came from: people don't need a score telling them how much they know — they need a direction.
The same logic caught up with the result metric. The test surfaced it: 4 of 5 confused "Depth of understanding" with the percentage of correct answers — one number produced four different readings.
Two metrics side by side didn't sharpen the picture, they argued with each other.
So I kept one — a clear percentage — and tucked "how it's calculated" under an icon: it doesn't weigh down people who already get it, but it opens an explanation for those who want to dig in. And I added a passing threshold — "you need at least 75%" — so the person has a clear reference point instead of an abstract score: did they close the topic, or is it worth coming back to.
Where does a person even expect to start the check: at a clear button, or somewhere in the list of lessons?
You can't settle that with opinions, so I showed the course page to 27 people and asked them to tap where they'd go on their own. 89% chose the "Check your understanding" button; 7% went for the item in the lesson list. The button became the primary way into the quiz, and the list item stayed as a secondary route.
The design system is a story of its own. There wasn't one, so I built it from scratch, and from day one for both platforms: iOS and Android.
The tokens also carried the handoff: developers got real values instead of a picture.
The value turned out to be not in "finishing the course," but in the moment of "now I actually get it" — and it holds precisely because the quiz can't be skipped through without thinking.
We made the way into the check impossible to miss and backed it with a number. And the moment after a wrong answer showed the real thing: behind that button, people aren't looking for a score, they're looking for a direction. That's what Nalu is worth building for.