In this project, I designed and allowed educators to create learning checkpoints for students. The system can remember each student's learning progress, so when students log back into the page, they don't have to restart from the very beginning. Also, the students can get motivated by tracking their checkpoints to complete the lessons.
The Oppia platform now offers over 2,000 lessons to more than 1 million learners worldwide.
It provides valuable out-of-school learning materials, and all users can select and access lessons from the learner's dashboard,
which is the sole entry point for accessing Oppia lessons.
Learners cannot resume lessons from where they left off in their previous session.
Learners are more likely to lose motivation if they cannot track their learning progress.
It is difficult for educators to track learners' progress and provide targeted directions.
Checkpoints are mini-milestones inserted through lesson cards to allow users to track, save and retrieve their learning progress.
For Learners, they can use checkpoints to
1. track their learning progress;
2. save their learning progress for the next return.
For educators, they can set no more than 8 checkpoints to track students' learning progress and give directions.
Learners and Educators are two main user groups expressed their needs to track learning progress.
Age: 7 - 14
Location: worldwide
Age: 18+
Location: worldwide
Work type: volunteers
There are two user cases that students and educators expect to check the learning progress:
Once logged in, they may want to check their progress overview to decide which lesson to continue or start.
As shown in the diagram above, users can get into the lesson page by either one click (Path B) or two clicks (Path A) from the upper-level topic page. Why do users need two clicks if one click can do the same thing?
There are three levels of information for their math course:
Topic > Story > (Chapter = Lesson)
However, the formation architecture and wordings here are still too complicated for users to understand the hierarchy, which may cause misunderstanding when they start to track their learning progresses.
When taking the lessons, they may want to check their learning progresses to know where they are.
The lesson page has three exclamation icon buttons, each opening a different modal. Aside from the flagged feedback box, the two rounded info buttons both display basic lesson details. However, information like the brief intro, learning progress, and creator list are repeated in both. Can we consolidate this to make the page cleaner?
After clarifying the "checkpoint" definition and knowing about the target user groups and current problems, I asked "How might we..." questions to guide the following solution ideation process.
The simpler the information hierarchy, the easier learners can navigate to the targeted lessons.
Stories need to be considered as a way to teach the "topic" instead of another level of information. Since there is only one story in each topic, we decided only to use "topic" to represent this level of information.
Topic > Story > (Chapter = Lesson)
Topic > Lesson
After simplifying the course structure, I reconsidered user case 1. If students can access lessons directly from the topic page or via the story page, why not combine them? Merging these pages also makes it easier to add a progress indicator, helping users choose which lesson to start.
The logic behind the solution is similar to the last one: if two info buttons might be misleading, why not combine them?
Something added: I borrowed the iconic apple graphic from the previous design so users can easily locate the info button. Since most users are under 12, adding fun graphics can boost engagement with the UI.
Something removed: The top info button was removed to clean up the nav bar, with its content merged into the bottom info modal.
Something changed: I updated the feedback button icon in the top right to a new style from Material 3 symbols. The old exclamation mark icon, now used to indicate a failed message, could confuse users.
Too many similar buttons on the page may mislead users or cause confusion.
Buttons are combined or modified to give clearer directions to users.
After discuss with the PM about other content in the info modal, we all agreeed that moving the progress bar to the Info Modal 1 makes more sense because it's the only distinctive information in the Info Modal 2.
We also allowed unregistered users to save their progress via email or link, so they can resume lessons later without losing their place.
The system will allow both registered and unregistered users to save their learning progresses.
I coordinated with researchers to test the optimized experience of accessing lessons and saving learning progress with five users aged 8 to 13, compared to the current experience on the website. The results are as follows:
The simplified information hierarchy and the optimized experience effectively reduce the time users spend on the lesson list page to access lessons.
After integrating lesson information into one modal, all users could find their learning progress there, and 4 out of 5 successfully saved it before exiting.
However, only 2 out of 5 could resume their unfinished lessons, highlighting the need to improve progress visualization.
After resolving the question - "where to show and save learning progress?", our team started to look back to the "checkpoints".
For registered users or those returning with a progress link, the system shows where they last left off. They can resume from the last checkpoint or restart the lesson.
Registered users can view their progress via the lesson info button in the bottom bar. The system automatically saves their progress, so manual saving isn't needed after logging in.
In the same info modal, unregistered users can save their progress by clicking the button below the progress bar and use the saved link to resume from the last checkpoint within 72 hours.
Even for a same user flow, it might have multiple possible situations, depending on the group of users, times of processing, etc. The design need to be flexible for all these situations.
Users, and even designers might have a stubborn mental model about some UI elements and layouts they might frequently see, which could be misleading for some new concepts. In this case, designers need to think more about WHY and HOW questions about the design concept before making the design decisions.
Most of the design decisions made in this project were based on assumptions and heuristic analysis in team meetings. We created our personas from the UX research team's interviews and observations, but the same methods need to be conducted again to verify the design for further design iterations, especially after getting data from the test launch.
The edits and improvements for the Oppia design guideline can never stop. In the next step, we will coordinate with teams from other projects and the design managers to incorporate new UI elements into Oppia's design guideline for the consistency across projects and the efficiency of future design works.