Who needs my help today?

Renaissance’s assignment hub combined work from several learning products. Version 1 put it in one table with sorting, filtering, and completion counts. The team, me included, expected those controls to help teachers find what they needed.

A count such as “11/16” showed how many students had finished, but not who had finished or who had yet to start. Teachers had to open a report in the source product before deciding whom to help.

Assignments was the app’s most visited page and the one losing the most users to individual products. I argued that student visibility belonged in the core experience: the opportunity was to help teachers identify both the work and the students needing attention without leaving the hub.

I won support to test a different direction. Our UX research partners ran moderated sessions with five current users and five teachers new to the product suite, comparing Version 1 with two prototypes.

Teachers organized their work by urgency. I replaced the flat list with groups: new assignments, overdue, due soon, in progress, and done. Opening an assignment revealed its students, working status, and assignment-specific results, with students who had not started appearing first. Teachers’ feedback supported this direction.

Try the grouped view below: open an assignment to see its students, sort the table, or switch to Before to compare the original count-based layout.

The interface depended on more than grouping the list. The API returned completion counts, so I worked with engineering and API owners to add student IDs and support student-level detail.

I facilitated an object-modeling workshop with product and engineering to define shared assignment attributes while preserving product-specific outcomes, such as pages read or questions answered. That gave teachers one interaction across products that stored assignments differently.