Redesigning Our Learning Environment: What We Learned
Introduction
In a previous post, the first part of “Redesigning our Learning Environment”, I went over the various stages of our design process. During this stage, we learned a few things that many design teams can apply to their own process, especially when working on a dedicated product. In this post, part two, I will go over 5 key learnings: (1) Embrace Product-Principles, (2) Design for a System, (3) Leverage Modularity, (4) Contextualize the UI, and finally (5) Minimize Cognitive Overload.
1. Embrace Product Principles
Product principles are fundamental values that help companies make decisions about a product. For a design team, they provide a high-level style guide that helps steer all design decisions — from user interactions to visual designs.
While these are usually quite general, it’s the design team’s job to interpret and translate our product principles in order to inform even the most detailed design decisions. Let’s take two of Codecademy’s product principles as an example:
- Codecademy believes in learning by doing.
- Codecademy is accessible and approachable.
The first principle has helped us guide big product decisions that define the user experience: where others use videos or images, we use interactive learning. While designing our new environment, we also knew we had to support the interactions that users find in real development tools, since we’re not just teaching content, but the full coding experience. Therefore, it’s not enough to show users an image of the file structure for the application they are building — they should be able to explore and interact with files. As a consequence of this principle, we ended up designing a file navigator that allowed users to interact with files and directories very close to how they would in real life.
The second principle, relating to accessibility and approachability, has helped guide our decision to not only incorporate more animations/transitions in the learning environment, but also the feel and timing of these.
2. Design for a System
Think like a developer. Reuse your work when possible, and design solutions that can be used over and over. This means one-offs should be minimized: you’ll thank yourself for it, the Engineering team will thank you for it, and users will thank you for it. Here’s why: implementation of solutions based on design patterns is faster and easier to maintain, and for the user, it means that they don’t have to learn new behaviors, and that they know what to expect.
In our learning environment, module behavior in the grid was designed with this in mind. While there are very specific exceptions that are justified by the idea of providing a better learning experience, we designed all modules to have shared functionality, such as collapsing and the ability to go fullscreen, as well as shared layout logic — any module can be at any place in the grid at any time.
3. Leverage Modularity
A product is not only a system of rules, but also a system of parts. Being able to discern and define these parts clearly is a key first step to providing a focused and friendly user experience, for it facilitates the implementation of lessons 4 and 5.
Here’s a general example of how we leveraged modularity. Our previous approach to a coding environment assumed that the lesson content, the code editor and the preview/output console were a unit. Acknowledging that these were individual parts that could be removed or surfaced in each exercise allowed us to come up with a modular playground for the Content team to try new teaching approaches and exercise types, resulting in an improved and more engaging user experience.
4. Contextualize the UI
UI elements and functionality should only appear when they are relevant to the user. This is working with the same logic as contextual menus: offer users actions that matter depending on their task at the moment, or the part of the interface they are interacting with. This can be at the general interface level or at a modular level. At an interface level, elements that situate the user and provide important general context should be kept visible at all times.
For us, this meant separating the elements users might need at any time, like navigation and progress, and making them easily accessible in the Shell, which doesn’t change exercise to exercise. At a modular level, options like the ability to reset the state of the users’ files or applications only appear on exercises that handle files.
5. Minimize Cognitive Load
By having a modular system that contextualizes functionality, you can provide a clear, focused experience for users. Often times, interfaces may contain elements that are unnecessary or distracting — resulting in cognitive overload for users. The best way to prevent this is by using progressive disclosure, surfacing UI elements as they are required by the user.
In our Learning Environment, we do this by surfacing the different modules users require in each exercise, and hiding the ones that they don’t. The modalities below represent the distinct layouts that are possible within this framework. Furthermore, we take this a step further by removing extraneous UI elements or functionality at a modular level when they’re not needed. The code editor, for example, has the following parts: (1) file navigator button, (2) file tabs, (3) file body / editor, and (4) file path, and (5) Run button. If a user is not dealing with multiple files in an exercise, then we remove the file navigator button, tabs, and the file path. On the other hand, if a user is working within a complex application and modifying multiples files at once, then we present the code editor with all its parts. This helps reduce users focus on what’s important and relevant to the exercise.
Conclusion
We hope that sharing the process and lessons of redesigning our Learning Environment, you can find some inspiration and tips to improve your own team’s process. For us, it’s very helpful to look back at what we’ve done and reflect on it. We’re excited about the new Learning Environment, and we’ve seen great reactions from our users. At the same time, we continue to receive feedback and, keeping the five lessons outlined above in mind, we’re excited to keep iterating on our new platform.
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.
