Common Lit
A project in which root cause analysis is used to solve a design problem for an EdTech startup, leading to an improved and simplified user experience
#Information Architecture#Interaction Design
A project in which root cause analysis is used to solve a design problem for an EdTech startup, leading to an improved and simplified user experience
#Information Architecture#Interaction DesignCommonLit is a nonprofit Edtech organization with a mission to ensure all students, especially those from disadvantaged areas, are academically prepared for success after graduation. I was tasked with helping them improve their processes for student account access and adding students to classes.
Some students are unable to easily log into their existing account and thus end up creating a duplicate account in order to join a teacher’s class or are left unable to create a new account.
(1) If we eliminate the option for students to use emails for sign up and instead use simple and memorable identifying data (such as birthdates) to allow students to log into their accounts, all students will be able to log in the same way and will not have trouble remembering their log-in details.
(2) If we allow teachers the ability of adding students to a class from their end, they won’t be powerless in troubleshooting student login issues.
The teacher has no ability to add students. Upon clicking the button labeled “Add Students,” teachers experience a pain point when they find out they can’t actually add students. The teacher only has access to instructions to guide students in adding themselves.
Teachers are provided with a form to distribute to students to guide them through account set up. This form, intended for use among kids of various reading abilities from 3rd grade and up, may present accessibility issues.
Users creating a new account are prompted to enter a class code before signing up. Existing users will also need to enter the class code at some point to join a new class. This step can be streamlined and made consistent for all users if they are required to log in/sign up first.
CommonLit states that there are privacy and equity concerns in giving email addresses to young students, as well as other issues stemming from using an email to sign up; therefore, it is not an ideal means to sign up for an account. If using an email address for sign-in is not accessible for all students, it’s best to remove the option so the process is consistent for all students.
I clarified the problem statement and began the convergent thinking process.
The root cause of the problem existed in a disorganized system that relied on students to memorize their login passwords for as long as they needed to use the product. From here, I formed my hypotheses:
The teacher now has the ability to add the student to a class, using simple data about the student.
The login process uses unique information that identifies each student accurately. The student login screen requires 4 fields to log in, which is not an ideal experience, but because login information can’t be retrieved, information that students ages k-12 would likely know about themselves must be used to verify identity. As Tesler’s Law states, there is a certain degree of complexity that can’t be removed from the system. The majority of complexity is either put on the system or on the user.
After successfully logging in, students are prompted to enter the class code to be added to a new class.
Tolerance for Error: This screen allows students to confirm they have entered the code correctly before being added to the class.
With more time, I would consider more edge cases and test the design for usability. I would like to ideate solutions to further simplify the sign in and sign up processes and conduct comparative analyses to standardize the process with other similar commonly used products.
