Redesigning Our Learning Environment: Process

Introduction

Since its conception, Codecademy has been a great resource for people to start learning how to code. However, committed to providing much more than a starting point, last year Codecademy launched a larger Web Developer content plan designed to teach people the skills they need to get jobs. The newest course we released as part of this plan, Make a Rails Application, also introduced an entirely new learning environment. This post is the first of two that explore the process the Design team underwent in creating this new platform and the lessons we learned along the way.

The Objective

The main challenge we faced in designing our new learning environment was that we had to look past what we were attempting to teach next — in this case, Ruby on Rails — and design a platform that was flexible enough to teach any programming language. Flexibility then became an integral part, and in fact a requirement, of the new platform.

The main challenge we faced was to design a platform that could teach any programming language.

The Process

The Modular Framework

Evolution of the Codecademy learning environment.

Having experimented with a combination of a card-based interface (version 3 in the image above) which focused on concept learning and our traditional coding environment (version 2), we concluded that despite the advantages of each format, the user experience was ultimately disjointed and even confusing. We then set out to create a coherent experience that would leverage the advantages of both formats.

The first step towards providing this experience was to separate the interface into two parts: (1) the shell, which incorporated global elements such as navigation, progress, and course information, and (2) the workspace, which contained the actual lesson content, and learning and development tools. A persistent shell would serve as an anchor and guide for users, while the workspace would potentially be changing constantly throughout a course.

Exploration of different models for flowing through content. In the end, Model D proved to be the most effective in terms of providing flexibility.

In developing the workspace, we explored several models that attempted to integrate the card-based interface and our traditional coding environment. We opted for a fully integrated model (Model D, pictured above), which leveraged the advantages of modularity, and allowed us to surface different components as the user needed them.

While the Header and Navigation elements comprise the shell, the workspace consists of a flexible 3 x 2 grid.

Ultimately, the workspace was developed with an underlying 3 x 2 grid contained within the shell. The responsive grid allows us to populate the interface with up to 6 different modules at any given time — from a code editor or a browser, to a phone emulator or an interactive infographic. Having the ability to determine, at an exercise level, which modules to surface (as well as the layout in which they appear) opened up a world of possibilities for our Content team, who would no longer be limited by the static layout of our previous coding environment.

While the grid allows for more layout permutations, these modalities became our Content team’s initial toolset.

Detailed Interactions and Visuals

With a modular system in place, we moved on to defining the different modules that could be placed in the grid. Collaborating with our Content team, we determined a list of modules the learning environment would support: (1) Lesson Content & Support, (2) Code Editor, (3) Terminal, (4) Browser, (5) Visual Aids, and (6) File Navigator.

We are not only teaching people how to code, but also how to use the tools developers use every day.

Throughout the design process, we looked at real development tools to dictate the functionality of the development tools of our learning environment. We studied the tools our own Engineering team uses every day, and we took a lot of cues from software that already exists. However, we had to take into account that our interface had to double as a teaching tool as well, so we made some compromises in order to provide a better learning experience for our users.

Each module’s functionality and detailed interactions were explored and documented carefully. One of the most important modules was the Code Editor, pictured here in different configurations.

After we flushed out the detailed interactions, we moved on to visual design. Having done a rebrand earlier that year, we naturally experimented with matching the visuals of the learning environment to the site’s look and feel. In the end, after several explorations and gathering user feedback, it became clear that the site and the platform had very distinct design requirements because their purposes are inherently unique.

First iteration of the new Codecademy Learning Environment.

We experimented with both a light theme that resembled the look and the feel of the rest of the Codecademy website, and a dark theme, which offered a more immersive, truer-to-life experience.

The final design relies on a darker backdrop to allow for a more immersive experience: the contrasting lesson content and support module, where every lesson starts, stands out and draws the user’s attention while other elements that are less necessary exercise to exercise, such as navigation, recede into the background. The code editor and terminal, typically using light-over-dark themes, blend in with the background. This, coupled with the ability to collapse the lesson content and support module, let the user focus on the task at hand. Furthermore, by having a contrasting interface when compared to the website, we emphasize the fact that the user is now in a different “mode”: a learn mode, a do mode.

Different modalities of the learning environment in final visual design.

Iterations

Second iteration of the Codecademy Learning Environment.

The release of this new, versatile learning environment means that even while the Product and its needs will continue to evolve, we can now think of new features and solutions to these needs as iterations on the platform. As a company, we are committed to this platform and we’ve laid a solid foundation along with feedback cycles that enable us to improve the product. Since its launch, we’ve continued to incorporate user feedback in our designs and already made several adjustments: layout revisions to leverage screen real estate in a better way, additional functionality to modules (like the ability to go fullscreen or drag the edges to control their size), a better status feedback system, among other changes. Some of these can already be seen in the platform, and we’ll be adding more soon.

The file navigator module, part of the feature set for the second iteration of the learning environment.

What We Learned

As a team, we learned a lot over the past few months on what the best design and product development process is for us at Codecademy. However, there are things we can extrapolate that should apply to every design team out there, especially those working on a dedicated product. In the second part of “Redesigning Our Learning Environment”, I focus on 5 key learnings we extracted from the process described above.

This is one of the many things currently brewing at Codecademy. Want to know more about our design projects? We’re hiring! Send me an email or follow me at @andresiga.