Banzai Grading Interface

 

The Problem

The grading interface is one of Banzai’s oldest designs and was due for a refresh; furthermore, it was not originally designed with many of the features that we foresaw it needing; in other words, it was time to help it grow.

Features we introduced:
1. Win/Loss tags for games on the class view
2. Removing students in bulk on the class view

Previously, teachers have to ping-pong between student profiles & the list-view to do both of these things. It was friction, basically.

Solution

1. Update the overall Grading interface with improved typography, spacing, buttons, & navigation.
2. Implement Win/Loss tags. These pertain to the game section only. W/L tags are not customizable. They're hard coded. For example, if the student saved for a bike or for college then they won. If not, they lost. See these tags in the mockup below.

Goals

Give teachers the ability to remove multiple students from a class at once. This can be done by selecting/deselecting all of the students by clicking the checkbox, or by selecting specific students from the class list and clicking the "remove from class" button in the dropdown. You'll also notice that any other relative actions could be added to this list as well. Teachers can also remove students from their class by removing them individually from that student’s profile. If a teacher wanted to re-add a student she removed, she would re-send him the class code. Additionally, enhance the mobile experience.

Developer Notes

Delete batches of users: On the front-end, do not dispatch a flurry of remove-student requests. Inefficient and inelegant. A back-end developer will need to introduce an endpoint that can remove a series of students from a class based on an array of student ids. Make sure there is proper security around this action. (i.e. That the teacher owns each student. See app. auth, and consider a new function like owns-each-student?, or something. Maybe there's something in there that can do it.)

Rabbit Holes (what we wanted to avoid)

Developers: Wherever possible, avoid letting the design upend the entire app. Keep changes to a minimum; avoid things that potentially create radical side effects. We shooting for mobile responsiveness, so taking on too much could have jeopardized the timeline.

The Team
Camilla Aubrey, Product designer & Pitch writer
Zac Boswell, Front-end developer

 

Previous
Previous

Banzai for Kids

Next
Next

Formula 1 Booking Flow Error States