PROCESS

Feature Development

At Instructure, we have 3 stages to our Design Process:

1. Discovery
   The time to understand and build empathy on the problem space by speaking to customers, CSMs, related stakeholders or running value-test user researches. My Product Manager and I would reach consensus on the area of focus which would drive the growth flywheel. Usually on features that’ll lure new customers in, maintain competitive edge, or solving existing pain points.
2. Definition
   Onwards to building design artifacts such as user journey maps, high-level screen flows, lo-fi mockups in web / mobile, accessibility study and prototypes and running usability researches.
3. Delivery
   Designs should be buttoned up for all use-cases, all states with a11y notes and interaction callouts for engineers to be implemented. This stage involves being proactive partner with the engineers and run regular design reviews to catch the unexpected before the release.

DISCOVERY

Feature: Course Pacing

Instructors need a “maintenance” free way to support a rolling enrollment course. Before “Course Pacing” was developed, teachers have to manually input due dates for assignments for every single students. This is a terribly inefficient way of maintaining a course. Imagine the amount of clicks required to set customized due dates for a course with over 100+ students. Instructors just do not have the time to meticulously clicking away in Canvas. The problem is even worse when students need due date extensions due to various circumstances.

DEFINITION

MOCKUPS

There was a solution that was developed in the past prior to me joining the team. So the usual high level flow and user journey flow was skipped. With the Course Pacing solution, instructors can quickly quantify and set the “duration” of the assignments rather than setting the due dates for each individual students. Every students will have the respective due dates calculated relative to when they’re assigned to the assignment.

DEFINITION

However, there was one glaring oversight with the existing design. It doesn’t scale to work well with courses with large amount of students.

The design uses a dropdown menu to navigate between sections and students. It works fine when the course has only a few students. But when the course reaches to 25+ students, the dropdown selector is not usable.

So I have to come up with a separate design so courses with large number of students is usable.

Various options were considered but ultimately one was decided upon due to time and technical constrains. Other than the scalability issue we were off to solve initially, this design also addressed a few other things.

Improvements:

1. Using a H1 header to orient the user, the previous design did not have a clear indication of what this page is.
2. Included a short description underneath the header to remind users what this page is for.
3. A larger callout to the “stats” and the “Default Pace” by framing the components.
4. Included sections and students tab to address the large courses navigation issue.
5. Clicking into any section or student item will open a fullscreen modal for instructors to set paces for the chosen section or student.

We conducted a few moderated user tests and surveys and validated our approach.

I’ve also reviewed the design with our in-house accessibility engineers to sort out a few screen reader, keyboard highlights issues.

The engineer team then took the design and broke down the work spanned across multiple sprints.

I was actively engaged throughout development, answering to all usability questions, accessibility concerns, and offering alternative solutions whenever there are issues arises.

DISCOVERY

Feature: Selective Modules Release

Essentially instructors have long asked for a way to give their students the content they want to see, tailored specifically to their needs. For example, an advanced student could be assigned additional challenges as compared to other students.

Currently, there is no quick and easy way to achieve this. An instructor would have to go through all the materials and assign them individually to the advanced student, which is extremely tedious. In addition, these additional materials would be accessible and be seen by other regular students as well, which could lead to confusion. There are many use-cases where instructors would want to hide these additional content as they may carry a stigmatism towards a certain group. (ie. slow-tracked students who need additional work to catch-up) Or the instructor just want to divvy up the class in a certain way so that the content is unique to each group.

In short, instructors simply want the ability to show course content to the right group of student exclusively.

DISCOVERY

Brainstorm Workshop

Along with my Product Manager, we have aligned on the issue we want to tackle. We have heard from over 25+ customer calls and 100+ posts on the community board that Selective Modules Release is an issue large enough to make a huge impact for Canvas’s competitive edge. My PM had done the work to convince the business opportunities and eventually the VPs have greenlit the initiative.

To tackle this issue, where should we start?

We’ve chose to outsource the thinking to my team. So I’ve ran a design brainstorming workshop to capture everyone’s thought on the issue. The result of the brainstorming session produced a number of options in which my PM can explore what solution has the most potential.

DISCOVERY

User Value Validation

With some high level form of solutions in mind, we need to make sure we’re headed in the right direction. So I’ve put together a Maze survey with mockups just enough to illustrate our solutions and posted into the community.

The feedback received were on-point and it also opened up more insights and use-cases to be considered when actually designing the solution.

DEFINITION

High Level Flows and Mockups

Now with more understanding on our instructors and their use-cases, I started to map out their user journey to dive deeper into their time of usage, motivations and goals.

I used Figjam’s template to map out a typical instructor’s workflow throughout the year.

I then began mocking up the screens we’d need to complete the user journey. Carefully thinking through each screen’s interaction. Because we were committed in delivering value in a tight timeline, we want to make minimal changes to the existing codebase (which means minimal changes to the existing UI).

A click prototype is then created for both internally and externally (usability tests).

MINOR FEATURE

Feature: Bulk Publish

Through aggregating all the feature request community posts, our team had some capacity to tackle a few low hanging fruits that’ll really delight the instructors.

One of the most asked for feature is the ability to bulk publish/unpublish module items.

Instructors had to click one by one in order to publish / unpublish items. This is again very tedious and aggravating. Especially when starting a new semester, instructors often copy an existing course (with all contents already published) to a new course. Then the instructor would have to unpublish all items to start fresh.

So along with another engineer, we took it upon ourselves to add the function to bulk publish at the Modules page.

It may seem like a simple addition, but there’s alot going on behind the scene.

For example, there are many edge cases and error handling states that needed to be addressed and communicated.

And with bulk jobs, there will be an inevitable wait time/progress that needed to be displayed so users still know the page didn’t just froze on them.

Also along the way, there were many technical hurdles (the codebase was more than 10 years old), so our engineer needed to unpack the code thoroughly without breaking things.

MINOR FEATURE

Feature: Account Calendars

Account Calendars was one of the first projects I was assigned to complete. It was previously determined that administrators had been requesting an “Account Level” calendar to put events such as first day of school, last day of school, exam start/end periods, school wide closures / vacations.. etc. And that every student in the school would have access to it automatically.

The workarounds administrators have been using were asking every course instructor to put down the same dates. Which means students who are enrolled in multiple courses will see the same events on their calendars – which ultimately resulted in a very convoluted student calendar.

The ask is very clear:

1. Admins want to setup a “global” calendar for students / faculty members to display institution wide events.
2. Students and faculty members need a way to access these calendars.

To tackle the first ask, our engineers have already figured out the best and easiest way is to expose additional calendars for each “Account”.

Meaning anyone who falls under an account will have access right to the “root” calendar. The question then becomes how does one see and interact with this root calendar?

Drawing inspiration from Google Calendar’s Other Calendars’s, we determined that it would be the simplest to enable students and faculty members to “subscribe” to a root calendar.

To account for institutions that could have literally thousands of accounts, we added a search bar and pagination load to help users narrow down the results.

Since this a rather subtle and new feature. I opted to use a “NEW” tag to bring slight attention to the feature without disrupting users’ usual workflow.

We’d also have to account for the administrators so they have the ability to turn on/off the visibility of the root calendars. (Because an institution could have 100s of accounts and they really only need a few to be enabled.)

We later also added the ability for administrators to set whether the root accounts should be auto-subscribed or manually subscribed. For schools that have young children, this option makes it the younger folks do not need to manipulate a few rather cumbersome steps.