Summer 2019 ✿ Product design

Codecademy Note Taking

Designing a note taking feature to increase engagement and retention for Codecademy learners.

A mid-fidelity prototype of the final direction for this project.

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!

The Problem

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.

A Case for Note Taking

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:

1. Improve knowledge retention for their learners.

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).

2. Improve product stickiness.

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.

Competitive Research

I started by looking at other platforms with note taking functionality.


Different platforms I researched, grouped by type!

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:

  • Create an easy way to capture code snippets and support syntax highlighting,
  • Integrate seamlessly in learning by associating notes with their corresponding curriculum content.

Analyzing Note Takers

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.


Learners sharing their processes for hand-writing notes.

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.

Exploring Scenarios

I then drafted out detailed user flows, imagining the ideal scenario for each type of note taker. Each flow documents:

  • What would prompt them to take a note?
  • How would they enter the note taking feature?
  • How (and where) would they reference their notes later on?


A birds eye view of all the high level user journeys. The yellow line circles around the features we planned to build for V1.

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.


Bloom’s Taxonomy, Vanderbilt University Center for Teaching

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.

Design Exploration

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.

Entry Points

I explored several ways a learner could enter into the note-taking feature:

  • An icon in the top menu
  • A button in the bottom menu, similar to the “Get Help” Button
  • And from highlighting a piece of learning content, like a code snippet.



I explored various layouts for notes:

  • A side panel
  • An adjustable, draggable popover
  • A new window/tab
  • And as an expanded overlay.


Notes Organization

I also explored several ways the notes could be organized, structurally:

  • By learning track (a Course or a Path)
  • By the module (a subsection of each track)
  • And finally a more freeform, user-defined method where learners create their own structure.


Narrowing the Design

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.

Deciding on a form

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.

Flexible, with just enough structure

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.


While the “highlighting and adding to notes” feature didn’t make it to our proposed V1, I strongly believed our V1 should at least support syntax highlighting to allow learners to add code snippets in their documentation and/or cheat sheets.

This provides opportunity to contextually surface the notes most relevant to what they’re currently working on–without providing a hard structure.



The filter provides a way to surface notes corresponding to a certain item of curriculum, in this case: the Learn Python 3 course. This can also be the default view when a learner open up Notes in a course that they’ve already written a note in.

It also allows learners to easily search their notes by topic, language, or course name.


Next Steps

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:

  • Reassess our assumptions about what users expect out of a note-taking feature
  • Answer usability-related questions needed to bring the design to a higher fidelity


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.