It’s all about the pace: A case study in product design for classroom teachers
As senior UX-UI designer, I was fortunate to help steer Speak Agent to launch in spring 2017. It’s a SaaS platform for teaching English language learners (ELLs) in grades K–12.
The web app was built to be responsive down to tablets, but like most enterprise software, the interface is heavily reliant on data tables for creating and editing wordlists and lessons, making assignments, and viewing student performance across multiple classrooms and schools.
Since the launch, I’ve wondered what a mobile version of the app for teachers might look like. This article is an exploration of porting a specific feature to a mobile app. It’s based on knowledge gleaned from small-scale user research conducted prior to launch and my own discovery research after my tenure at Speak Agent, Inc. In addition, I took this opportunity to build an interactive prototype in Figma, a tool increasingly popular in the industry that I had no prior hands-on experience with, and to explore prototyping animations in Principle.
This story is meant to show my thought process, my approach to doing both UX and UI design, and what I see as the next steps if this product were to be developed.
Understanding teacher pain points
U.S. Department of Education stats indicate that a typical classroom teacher in public schools has 5–6 class periods, and about 25 students per non-special education class.
Recent surveys estimate that more than 50 percent of teachers have at least one student with limited English proficiency. ELLs can be found in public and private schools, and in urban, suburban, and even rural schools, and they are now often mainstreamed into academic classes. But fewer than 1 in 3 teachers have even a modest level of training to support ELLs.
The disconnect between training and need is vividly demonstrated by the academic achievement gap: only 63 percent of ELLs graduate from high school, compared to a national average of 82 percent (yes, that’s not great either!). In Arizona, the graduation gap is 18 percent vs 76 percent.
The importance of actionable data
After Speak Agent shifted its target customer to school districts, the educator side of the platform needed to serve the needs of a variety of roles in the school system, from teachers to IEP (Individualized Education Program) coordinators, principals, and district supervisors.
In collaboration with the engineering and marketing team, I designed and built low fidelity dashboards for each of those types of users. The emphasis was to display actionable data in easy-to-digest form. The dashboards show student progress in various facets, grouped by teacher, coordinators, classes, and school.
Decisions on what data were most relevant to different users were shaped by the knowledge of classroom teaching among several Speak Agent staff. Teachers can drill down on individual students to see their progress with vocabulary and various lessons; the district can see how well their investment in edtech is paying off.
Being able to delve into a variety of data and graphs is obviously of great value. My challenge was how to present some of that data in a useful way in a mobile app.
Focusing on classroom teachers
I focused my design work on a more limited version of the app for mobile devices: providing teachers an easy way to get a snapshot of their students’ progress.
I interviewed Katherine L., a friend with several years of classroom teaching experience, who was familiar with the beta version of Speak Agent from early user testing. My goals:
- get a sense of how teachers currently keep track of their student progress in close to real time;
- tease out what kinds of data would be of most value; and
- determine the appeal of a mobile version.
Based on this discovery, I designed a prototype that I would use for testing and refinement.
It’s all about the pace
For Katherine, a mobile app offered great appeal: she could use it while waiting in line. Her school district offered tools like Gradepro Plus, which she found too rudimentary. To check student progress from home, she had to log in through a VPN which she found clunky and inconvenient. (Note: this security requirement is likely to apply to any app displaying student progress, and will need to be taken into account in assessing feasibility).
My initial idea envisioned teachers being able to see a list of all of their students, and swipe through each one to see a snapshot of progress. What I discovered was that the bigger challenge for classroom teachers is keeping all students in a class on pace: seeing at a glance who is behind or ahead of pace, provides the information a teacher needs to know who needs additional help right now and who can handle more challenging material. Analytics tools that support this “differentiated instruction” are hot in the edtech space.
This insight was good news for the UI design: a teacher might have 100+ students, too many to comfortably and efficiently check on on a handheld device, while 5–7 class periods would provide a way for a teacher to quickly drill down to see students falling behind or working ahead of the rest of a class.
For an individual student, Katherine noted that she wants to see not only how much work has been completed, but the degree of mastery.
A nice-to-have would be to compare a student’s progress this year in this class to the same time point in the previous school year. This provides insight into potential issues at home or with a particular class so that the teacher could intervene early.
In light of this interview, I revised the user requirements:
- Must be able to quickly see the status (falling behind, on pace, ahead) of students in a class.
- Must be able to see data on completion rates and mastery for individual students.
- Nice to have: ability to jot notes on each student for future reference; ability to see year-over-year comparison of a student’s progress.
Assumptions to be validated
- Teachers prefer seeing summary stats for every class/period at once in a long scrolling screen, rather than having to swipe or tap to see each class individually.
- Teachers will want to see all students on, behind, and ahead of pace (not just those behind).
- Teachers want to see progress and mastery for each student.
- Teachers want to add notes.
Tasks for usability testing
- How would you see a list of students falling behind in Period 1?
- For Period 1 class, how would you see students on pace?
- How would you see information on an individual student?
- For a student, what would you expect to see tapping on Mastery?
- What would you expect to see for Progress?
- Do the stats displayed for a student make sense to you? If not, how would you change them? (remove, add)
The UI hits the mark on two core design principles based on psychology: Hick’s law (limiting choices to support clarity) and Miller’s law (chunking information). But it needs refinement to conform to Jakob’s law: matching users’ mental model of how an app should look and work.
Android-based Chromebooks are taking over classrooms, but teachers may be using iOS devices. I would gather analytics and refine the UI to match whichever platform the data say most teachers are using (and plan for porting the design to the other platform down the road). I would also collaborate with a front-end developer to improve the animations, as I am still at the training wheel stage.