Designing a note taking feature to increase engagement and retention for Codecademy learners.
In May 2019, I collaborated with a Curriculum Product Manager to design and scope a note taking system for Codecademy learners. Because this project was unfortunately deprioritized halfway through working on it, this case study focuses more on research, ideation, and low-fi prototyping. For my high-fidelity work that got shipped at Codecademy, see my writing about redesigning onboarding!
My team has long-noticed that learners tend to exit Codecademy’s Learning Environment (LE) when they get stuck in the middle of a lesson. They deduced this is because learners forget previous material and go to external resources, like Google, to find what they’re looking for.
In response, the Learning Experience team proposed a note taking feature where learners can easily record notes and reference them later, without leaving Codecademy. The team believed this would:
In pedagogical research, note taking is known to increase student engagement and retention of learned material.
Many Codecademy already take notes on their own. Also, note taking functions as a more active learning aid than other ways of getting help on Codecademy (e.g. pressing the “Get Solution” button).
On the business side, note taking (as a form of user-generated content) would increase user retention by allowing users to invest value into Codecademy’s platform.
I started by looking at other platforms with note taking functionality.
Some were programs specifically designed for programmers (BoostNote, MedleyText), and some were general purpose apps that involved code snippet functionality (Notion, OneNote).
I also looked at Medium for its “Private Notes” feature, and ed-tech platforms like Coursera and Udemy, which allow you to bookmark notes during moments in their videos.
From this research, I saw opportunities for a note taking feature to:
Before prototyping an on-platform note taking app, I needed to understand how learners were already taking notes, off-platform!
Luckily, this research was well documented; many learners share their methods on social media.
I sat down with the Curriculum PM to elaborate on all potential use cases for taking notes, based on this research. We identified four main types of note taking behaviors and gave them each a name: Cheatsheet Maker, Documentation Maker, Commentary Maker, and Anything-Goes.
Identifying these four types gave us insights to how, and why, the act of note taking fits into our users’ learning journeys.
I then drafted out detailed user flows, imagining the ideal scenario for each type of note taker. Each flow documents:
Drafting all of these scenarios helped us understand what features to focus on. We decided to prioritize supporting three types of note takers: Cheatsheet Makers, Documentation Makers, and Anything-goes.
While those three note taking styles could be satisfied with simple CRUD (Create, Read, Update, Delete) functionality , the Commentary Maker was unlike the others due to its strong social focus.
Commentary also falls into the higher-level analytic and evaluative stages in learning. Meanwhile, the other types focus on retaining and applying knowledge–which were the problems we were more concerned with solving.
I brainstormed several possible variants for how a note taking feature could live in Codecademy’s Learning Environment, supporting learners who might want to create cheat sheets and documentation as they follow along a lesson.
I explored several ways a learner could enter into the note-taking feature:
I explored various layouts for notes:
I also explored several ways the notes could be organized, structurally:
After a few design critiques, desk chats with engineers, and check-ins with my PM, we identified key design decisions for the V1 release, and which features to prioritize later.
We settled on the draggable, resizeable popup format! It was important that the notes could be side-by-side with the learning content without covering up anything important — ruling out the expanded overlay and the side panel.
Ideally, we’d like to support the “As a Window/Tab” option because it would let the learner use their monitor space as they see fit – but after conversations with engineering, we realized there would be difficult synchronization complications to build around (what happens if multiple note tabs are open? Would they be able to sync?). For v1, the adjustable popup would allow a learner to take notes side-by-side while minimizing development costs.
I realized that the various organizational options for notes presented a tradeoff between flexibility and structure.
Originally, the project spec established that notes would automatically be set up according to the structure of learning material, either by track or module. We knew, from our Documentation Makers, that many learners create guides following courses and paths as they learn – but would creating hard separations for notes between items of curriculum be too constraining?
After a design critique, I decided to toss the track or module-based structure and go towards a freeform format to avoid being too prescriptive with how we thought learners would take notes. Organizing by track or module also presented potential complications, as the curriculum structure can often undergo changes.
At a mid-fidelity, I explored a freeform format that allows learners to create and reference whatever notes, in any track. Notes are listed chronologically, with most recent ones at the top.
While the notes aren’t divided by track or module, we could still use the curriculum as meta-info for an organizing system! When a learner takes a note, it becomes automatically tagged with information corresponding to the relevant languages and curriculum information.
This provides opportunity to contextually surface the notes most relevant to what they’re currently working on–without providing a hard structure.
It also allows learners to easily search their notes by topic, language, or course name.
If we continued this project, this moment would have been a great opportunity to conduct some user tests with real learners! It would’ve been valuable to present a low-fi prototype of our V1 feature release, to:
While I’m sad to not have carried this project out to fruition, I’ve learned a lot from the process! Specifically, I’m grateful for developing the confidence to push back on product specs and advocate for the user. I’ve strongly internalized that product design is not just a linear process of receiving a spec and creating mockups from it – I’m definitely challenged to see a product definition as something I have an active role in shaping.
If this gets built in the future, it’d be valuable to see how certain learning metrics (such as quiz scores, number of submits on exercises, number of days active) are impacted by whether or not learners use this note taking feature. From there, our team could validate our hypothesis that this note taking feature will increase engagement and retention.