Enhancing Student Login in CommonLit
Company: CommonLit is a literacy program used by thousands of teachers around the country
Overview
I spent six years as an educator before I became a UX designer (go Wesbury Eagles!!!) and during that time my students and I got to be guinea pigs for a revolving door of educational apps and learning tools that the school district fancied as being the next great revolution in education...at least until the next thing came along.
During that time, there was one platform that did stand out as being clearly in a class by itself for its depth and usefulness in helping students in reading comprehension, and that is CommonLit.
Over the years, I used CommonLit with every class I had and it clearly helped improve the students’ reading ability, but my students and I encountered a few problems while using their platform. So I decided to do that thing UX designers do and see if I was the only one agonizing over these problems and what solutions I could bring to the app.
THE DESIGN PROCESS
I followed IDEO's design methodology and lean UX.
Although I was approaching the project with built in assumptions I had made having previously used the platform, I wanted to make sure that my design decisions were supported by user research and validation.
PERSONAS
I created a set of provisional personas based on online research and my own experience with users.
To start with, I made two personas for potential users. One persona was for a student, the other for a teacher. Although I understood these personas would have latent assumptions and biases inherently baked into them since they weren't fully researched, they were crucial in serving as a guide to inform my design decisions and priorities.
JOBS TO BE DONE
Using the JTBD framework, I explored the various motivations and desired outcomes for my personas.
I created the following job stories based on six interviews I conducted:
USABILITY TESTING
With the job stories as a guide, I developed a few scenairos with a set of tasks for participants to perform.
With my questions in hand, I went to Westbury High School and sat quietly until the English teacher had come to a stopping point with her students, and was kind enough to let me interrupt. In the end, I tested the tasks on five students and five teachers. Here’s a breakdown of their familiarity with using CommonLit.
FINDING AND PRIORITISING PAIN POINTS
After reviewing my notes, I grouped user pain points into similar categories using affinity mapping.
I then used affinity mapping to group the pain points into similar categories so I could get a better visualization of what the problem areas were.
Then I prioritised each pain point based on its importance to the user as well as to CommonLit. I used my conversations with the existing and potential users as a basis of forming assumptions of the importance to users. Based upon what I had learned about CommonLit from their website, I listed my assumptions about the importance to them as well. Logging in, using a join code for a class, and having the ability to track student growth across semesters were core features that allowed CommonLit to stand out as an eLearning tool.
UNDERSTANDING THE DILEMMAS
It was at this point that I realized that the primary usability issue users were having dealt with logging in.
All the evidence I was collecting pointed to the log in process as the major usability issue users were encountering. To try to fully understand the issue, I broke it down to its component parts. Since there are two sets of users: students and teachers, I needed to understand how they fit together in this puzzle.
Pain Point One: The only way for students to join a class is by using the class code.
Giving a class code to students is useful in having a teacher group all his students by class, for shared assignments and lessons.
The first thing a student sees when they land on the CommonLit student's view is a prompt to enter this class code. The issue arises within this flow because it inadvertently groups all students together - those who are new to using CommonLit and those who have used CommonLit in the past and already have an account.
Pain Point Two: Students who have lost their log in information are instructed to ask the teacher for help.
This might seem at first glance to be a good solution. However, the only instructions that teacher has to help the student are to either send them back to enroll or enter the class code. Since the student is having issues enrolling in the first place, all this does is leave them looping back through the same options.
The next page in the flow brings up the sign up page. This works well for new students. However, if you are a returning student and don't remember your password, this flow places you into a loop that you can't break out of.
Pain Point Three: Due to a set of unique constraints, a password reset is especially difficult.
My initial thought on the solution to this problem was to just have students click on a password reset and get emailed a link to change their password.
However things aren't so simple. CommonLit is used in school districts all around the world. However, many school districts have a closed email system that strives to ensure the safety and privacy of the minors in their schools comes first and foremost. Since CommonLit is considered a third-party app it, like all other third-party apps, are not allowed to send emails to the students.
In addition, most teenagers only have their school-issued email addresses, which they are encouraged to use when on campus. Therefore, although CommonLit asks the student to register using their email address, they have no way to actually use that email address on file to send the student a link to reset their password.
Pain Point Four: Students who get stumped by the issue simply don't enter an email, and just create a duplicate account.
For CommonLit, having students create brand new accounts to circumvent the issue of not being able to retrieve their log in information is not something they want to happen. One of the best things about CommonLit is that it is data-driven and tracks a student's lexile growth across semesters, and even years. If a student dupes their account, that messes up CommonLit's data.
FLOWS
It was while mapping out the flow of the current page that it occurred to me that a potential solution would need to involve the teacher more.
I diagrammed CommonLit's current flow system to get a better view of the points were the task flows were breaking down. This would allow to where usability improvements could be implemented. The red warning icons represent the pain points I would be tackling in my design solutions.
As I was working, I was struck by how powerless the teacher was in this use case. Due to the unusual constraints on the platform, having the teacher serve as the defacto admin would serve as the optimal solution to the problem.
IDEATING A SOLUTION
I considered several solutions, most of which I had to reject because of the stakeholders' unique constraints.
When it came time to start sketching, I came up with various potential solutions. One of the most promising solutions was to have a temporary password sent to the student's phone.
Based on validation that I received from that first solution, I stumbled upon an unancipated issue. The problem with this as a solution was that it worked under the false assumption that all students would have access to a cell phone, which is simply not the case. Many students, especially in lower income neighborhoods, can't afford the cost of a monthly phone bill.
WIREFRAMING THE SOLUTION
Although the solution I arrived at would require some heavy lifting on the engineering team, it would circumvent all the various usability issues and constraints on this project.
Although this solution would require some heavy lifing on the engineering end, it would circumvent all the various constraints placed on this project.
The solution would involve giving the teacher access to a password key that could be used to reset the student's log in, allowing for instanteous access into the student's account.
With the direction of my solution decided on, I finished out my sketches and turned to wireframing.
PROTOTYPING AND VALIDATION
After creating my Hi-Fi mockups, I tested it with 5 new individuals, and used insights from the validation testing to reiterate on the screens.
Working in Figma, I made mockups for my proposed solution. I made two separate user views - one for the teacher side and the other for the student view. My solution involved changes to both vieew,s and both sets of useer would have to work in concert to fix the usability issue.
Insights from the validation testing allowed me to refine my solution. Below are the Hi-Fi mockups of my final solution including the results of the user testing before and after implementing my design solutions.
Pain Point One: The only way for students to join a class is by using the class code.
DESIGN SOLUTION: Starting the student off by first determining if they are a new or returning student would remove the assumption that all students are grouped under one bucket, creating awareness that the distinction matters.
Pain Point Two: Students who have lost their log in information are instructed to ask the teacher for help.
DESIGN SOLUTION: Instead of asking the teacher for help with figuring out how to log in, the student can now ask the teacher for one specific piece of information - the class key. Once they enter this key, they are allowed temporary access back into their account, and can now change their password.
Pain Point Three: Due to a set of unique constraints, a password reset is especially difficult.
DESIGN SOLUTION: These constraints are important to schools seeking to protect their wards. In order to create a solution that preserves these boundaries, giving the teacher access to a class key on their end allows them to serve as admins, eliminating the need of reaching out to the help desk everytime a student gets stuck.
Pain Point Four: Students who get stumped by the issue simply don't enter an email, and just create a duplicate account.
DESIGN SOLUTION: With students now able to easily gain access back into their accounts, they won't feel forced to have to create a brand new account out of frustration. This will benefit the stakeholder since it preserves their ability to have true growth data.
Here's an overview of the results of my design changes.
You can also check out my prototype of the student view here.
MY TAKEAWAYS & REFLECTIONS
Juggling multiple users and stakeholders can be tricky
This project involved a lot of moving parts due to the different stakes that were at play. For the student, it was to get into the class even if it meant taking a shortcut. For the teacher, it was about making sure everyone was logged in and doing the work. For CommonLit, it was to provide a good user experience but at the same time be able to have true metrics to draw from.
In order to arrive at my solution, I had to sift through the various assumptions users were making right off the bat. Although my first few attempts at a solution failed, I was ultimately able to find one that worked once I realized that being able to clarify those misconceptions the users were coming in with was the key. So being able to have clear language that communicates directly to the user can sometimes be the biggest help a user experience can provide.
Hello, I'm Qasim Brown
I'M A VERSATILE UX AND PRODUCT DESIGNER WITH 6 YEARS OF EXPERIENCE SPANNING LEARNING TECH, ENTERPRISE SAAS, HR TECH, AND PRINT DESIGN.
My expertise lies in design strategy and translating complex backend data structures into intuitive, easy-to-use design solutions that allow users to accomplish their jobs-to-be-done in a simple and visually appealing interface.
I am currently looking for a full-time remote role as a Product Designer on a team that aligns with my passion for innovative solutions and driving impact.
My email: qsbrown3@gmail.com | LinkedIn: www.linkedin.com/in/qbrown452