Content Editor Top-to-Bottom Redesign

Summary

The case study covers a top-to-bottom redesign of a content editor for ASSISTments. I discuss the complexities of designing for multiple user personas with different use cases. I describe both the importance of the navigation nodes in the design of the information architecture and how the design supports the organization goal for developing new item types.

Introduction

ASSISTments’ content editor helps internal authors, teachers, and researchers create custom content which can be assigned in the ASSISTments platform. The original editor was built around 2008 and grew organically as the needs of the organization changed. Using this builder was cumbersome and unintuitive, which led to the need to have in-depth trainings to help users navigate the editor. The goals of this redesign were to:

  1. Support the creation of new item types not currently available in the platform.

  2. Improve the navigation of the content editor for a range of diverse users.

  3. Complement and align with the teacher and student platforms.

Discovery

Comparative Analysis

I conducted a comparative analysis of a range of products across different industries to:

  1. Collect design patterns to inspire my designs

  2. Learn how other industries handled similar challenges with content authoring

  3. Understand how other content editing tools structured their information architecture

Stakeholder Interviews

The content editor’s biggest challenge was meeting different users needs—internal authors, teachers, and researchers—all of whom use the product differently. I interviewed the head of content multiple times to understand her pain points, goals, and workflow. Since researchers and teachers weren’t available, I consulted with those who help them author content. I also had multiple discussions with back-end and front-end engineers to learn the current system’s complexity so I could present key information to users without overwhelming them. I regularly followed-up with key stakeholders to make sure I accurately captured their needs in my wireframes.

Lessons from Early Wireframes

When redesigning the experience, I faced resistance over certain design choices, like hiding the right-hand navigation panel to increase content space. Despite the old builder’s user experience challenges, users still needed complex building capabilities. Based on a continuous feedback from internal builders and engineers, I identified three key needs:

1. Navigating and viewing all problems in a set, regardless of the one being edited.

2. Editing problems, answers, and supports on one screen.

3. Switching between different views to edit, view, and test the student experience.

Information Architecture-Navigation

Multiple ways to view content

I learned how important it was for authors to view their content as their students would see it. It was also important for them to be able to see the entire structure of a problem set—which included correct answers and supports they had authored for the each problem. Because of these and the need for authors to quickly toggle between different problems they were writing, I decided to:

  • set the right hand navigation default to be fixed (with an option to hide it)

  • Add a toggle on the root problem set, which let users switch from editing to viewing to testing their problems.

Navigating with Nodes

One of the most complex challenges I needed to solve was how researchers could easily navigate sets of problems they created. They needed to be able to author content and build complex problem set structures to support their experimental designs. The design had to be robust and flexible because researcher could have up to 20 variables in a single root problem set. Since I could not interview researchers directly, I relied on countless conversations with engineers to understand the complexity of problem sets researchers had previously built. I learned the navigation needed to be able to help researchers:

  1. See all of the problems they designed in a single list (image 1)

  2. Navigate the structure of embedded sets of problems while editing those problems (image 2)

  3. Edit embedded problem sets’ structures and settings (image 3)

Support for New Item Types

Problem Body Answers

The current system only supported one answer input per problem—a huge pain point for students, teachers, and authors. Our new item types needed to:

  1. Support problems with more than one kind of response

  2. Allow builders to place responses anywhere in a problem body

  3. Support settings to communicate feedback effectively to students

I found other platforms used the slash </> key to trigger a list users could select from, I used this idea in my design because it was a familiar pattern to users and gave the platform flexibility to develop more items to add to problems in the future.

Effective Student Feedback Settings

Content authors wanted flexibility in the way they communicated correctness to students—because context was so important for each problem—for example, if a problem had 2 answers and they were not related to one another, builders wanted to let students know one of their answers were correct.

Teacher and Student Product Integration

Component Reuse

As much as was possible, I tried to reuse already existing components to both minimize development time and give users a consistent experience across the product. One example of this was reusing the navigation experience for both find and assign for teachers and the problem set view for builders (example 1). A second example reused response labels in both problem set view and student experience (example 2).

Example 1

Example 2

Conclusion

The project launched on July 23, 2024 in full to our internal content builders and an alpha set of teacher users. Alpha users reported high satisfaction with the new item types and navigation experience of the new content editor. The roll out for all teacher users should happen in 2025.