Course Pacing Redesign

Problem

It could only pace a whole course. Instructors called that unusable, and usage was about 1%, even counting anyone who only opened it.

Solution

Sections and Students tabs, a full-screen view for each pace, blackout dates and pending changes.

Result

Released to beta in the middle of a term. Courses using pacing went from under 1% to 1.05% in the first 14 days, too early to tell whether instructors would adopt it.

In a rolling-enrollment course, students start on different dates, so every due date differs by student. Instructors entered them by hand, and again for every extension.

A few major US universities run courses this way, some with more than 50,000 students. They are large accounts for Instructure.

Course Pacing calculates the dates from a pace. Its first version set one pace for the whole course.

The feature is essentially useless to me unless I can set paces for my students individually.

Three things made it hard.

• Scale. The dropdown for switching between sections and students stops working past about 25 students.
• Three levels. A course, a section and a student can each have a pace.
• No documentation. The first version's decisions weren't written down, so the engineers who built it were the best source.

Tabs in place of a dropdown

The main alternative I explored kept the dropdown and added drill-downs for choosing a student. It couldn't work in a course with thousands of students. Sections and Students each get a tab instead, so a large course becomes a list to scan.

A full-screen view for each pace

Selecting a section or student opens its pace full screen.

A page that says where you are

A title, a one-line description, and more prominent stats and default pace. The original had no title.

Added in the same release

Both came from faculty feedback that the product manager gathered on customer calls.

• Blackout dates, so nothing falls due inside a set date range.
• A way to view and reset pending changes.

Open the Course Pacing prototype in Figma

• Testing. Three moderated sessions with administrators and instructors at US universities, plus surveys. The product manager set the goals and I ran the sessions, asking each person to do real tasks in the prototype, such as creating a pace and setting durations for their students. All three were positive. I didn't read that as a prediction of usage.
• Accessibility. Reviewed with our accessibility engineers for screen reader and keyboard focus issues.
• Build. Several sprints. I answered usability and accessibility questions and proposed alternatives when something couldn't be built as designed.

• The redesign went to beta in the middle of a term, together with the new features, so their effects can't be separated.
• In the first 14 days, courses with pacing turned on went from under 1% to 1.05%, from the product manager's numbers.
• That window couldn't show much. Instructors set up a course's structure before a term starts and rarely change it once it is running. Nobody checked again when the next term began.
• We never set a measure of success before launch.

• I would agree on the success measure before launch, count section and student paces separately from course paces, and read the result at the start of the next term, when instructors actually set up their courses.
• Adjusting the duration of individual items is still inefficient. I wanted to redesign it. The engineers resisted, because untangling the existing code would have taken too long.
• That argument is weaker now that AI tools can read an unfamiliar codebase quickly. Today I would start from the design, not from what the old code allows.