Coding Dojo’s Learning Management System(LMS) - Rostering Feature
2021.6
Project Overview
Background
Coding Dojo has been rapidly growing. As a result, many of the company’s traditional workflows have become growing pains. Rostering is a crucial and complex process of student management. Due to the lack of a suitable internal tool, instructors have been relying on multiple external tools like spreadsheets to roster their students. The lack of consistency, standardization, and automation has brought not only confusion and frustration to users, but also business risks to the company.
Discover
What is rostering?
Rostering is the process of moving students from one learning stack to another. There are two major steps and two types of users involved:
Step 1: an instructor passes out their academically qualified students to their next stack;
Step 2: a regional lead (regional instructor manager) breaks up the cohort and matches up the students with next instructors
(Gif will automatically play. Thank you for being patient.)
Why did we need to redesign the rostering feature?
Coding Dojo’s instructors used to rely on spreadsheets + other tools (e.g. the old LMS) to roster students. This used to work when the company was a local-facing, smaller-size bootcamp service based in Seattle. With its rapid expansion in the past few years, Coding Dojo now has services to not only most of the states but also a few dozens of countries on different continents. The lack of efficiency and standardization in the traditional rostering tools has become frustrating to instructors, as they now have to manage much more students.
As a result, instructors started to explore their own alternative methods. This often ended up with more spreadsheet assets. As these band-aid solutions might have been working for a smaller group of users, they had actually caused more de-centralization and chaos. Eventually, the rostering had become a potential risk to operation, management, finance and even compliance for Coding Dojo.
Survey - discovering problems and Establishing baselines
To better understand users' current experience of rostering, we sent out a survey to over 100 of our instructors(including Regional Leads), asking about their then-current feelings about the rostering experience.
As a result, we received a 5.8 NPS score and an avg. ~52 min/program processing time.
Focus groups - understanding the “classic“ workflow
We hosted several workshops with representatives of our target users to better understand their “classic“ workflow.
Define
Persona
User pain points
Success Metrics
Design
wireframes
I designed lo-fi wireframes for early-stage demonstration and app critiques. We conducted a weekly design tag to communicate updates and validate the wireframes with major stakeholders. Based on stakeholders’ feedback, I iterated multiple versions of wireframes to better address their concerns.
Design Style Guide
I created the design style guide, standardizing color scheme, reusable design patterns and elements, and other components, which later contributed to the Coding Dojo LMS Design system.
Prototype(gifs play automatically,please allow time for loading)
Step1: Instructor fetching students
Step2: Instructor assigning qualified students to next stack - Job done for instructor!
Step3: Regional lead fetching students
Step4(option A): Regional lead drag and drop single/multiple students to available instructors to match them up
Step4(option B): Regional lead select multiple/all students, and use the Smart Match feature(system to evenly break students up into diverse cohorts based on their demographic information) to auto-match students with their next instructor - Job done for regional lead, hooray!
Deliver
Results
Reflection (key learnings & Contributions)
1. Good documentation is important.
I worked with my PM to start building a document shared with our devs, where we include our conditions and logic, design updates, design specs, notes regarding edge cases, QA results, and launch schedule. I talked to our dev team to learn what they liked and didn’t liked about how we handled this project. And they suggested the early access to this one single source of truth was fairly helpful to move things forward.
Demonstrating an early version prototype to stakeholders for app critique
2. Transparent communication is the key to solve complex problems that involve multiple stakeholders.
We established an open and transparent environment of communication by hosting weekly design tags with our stakeholders. It was not only a process of Q&A, but more of a method to build trust between us and our target users and stakeholders. You can’t build a successful product without having trust from your users.