Case Study — Communicating an information model for which your UI was not designed

Our re-design of MyPlan, UW’s Course Planning Tool, to accommodate FIG (First-Year Interest Group) courses.

Context

What are FIGs?

First-Year Interest Groups (FIGs) are bundles of courses that freshmen can take together, as a package, during their first quarter at UW.

FIGs ease students into their college life and help students quickly establish a small community within the huge University by having the same cohort of students take the same grouping of classes together. Also, every FIG includes a 2-Credit course called “University Community”, aimed to help students settle into UW life.

For example, every student that registers for a specific 12-credit FIG would take the same 3 course sections; English 131, Econ 200, and the 2-credit “Gen St 199: University Community” course (illustrated below).

Example of FIG possibilities — source

What is MyPlan?

MyPlan is a web application that UW students use to plan their academic schedules for future quarters.

The Problem

MyPlan doesn’t support FIGs in a meaningful way. FIGs were squeezed into MyPlan’s existing model for showing courses, which doesn’t align with the actual structure of FIGs. MyPlan’s interface makes FIGs feel like an exception, or even a hack. This is a missed opportunity for the University to encourage students to take FIGs and take advantage of their clear and meaningful benefits!

While MyPlan presents all courses as independent peers, FIGs are complex groupings of courses that don’t work independently. You either enroll in a FIG, adding all the courses, or you don’t. Re-designing how FIGs are displayed in MyPlan meant totally re-thinking how information models could be communicated. In solving this problem, we found we were creating a few rough guidelines for representing different information models.

Project Goals

Working within the constraints of the current MyPlan UI:

  1. Effectively communicate that FIGs are collections of courses taken together simultaneously.
  2. Help students find FIGs they are interested in and build these FIGs into their schedule.

We — Oorja (another student designer) and myself — had about 6 weeks to provide the MyPlan development team clear and actionable design recommendations for their next sprint. The timeline was tight because the next batch of first-year students would arrive in the fall.

Process

  1. Map current FIG registration workflow — how do students register for FIGs? What workarounds to they use when MyPlan limits them?
  2. Ideate a new workflow — how can students better explore and add FIGs to their plan?
  3. Mock up recommendations to MyPlan — How can we make this new workflow possible with changes to functionality and visual treatment within MyPlan?
  4. Usability-test with students — Do our interface changes allow students to find and register for FIGs?
  5. Re-scope recommendations to meet technical constraints — Is this solution possible? How much work will it take? is it worth it? What are workarounds?

Takeaways

We ended up with these guidelines for rethinking how to convey a new structure of information within an existing UI.

1. Revisit the Information Architecture

Retracing the structure of information behind your application helps you understand your new information model in the context of what users expect in your product. When you take time to re-examine how you’ve structured information within pages, and how those are connected to each other, you may find that adjusting this structure will allow you to accommodate a new information model while keeping a consistent structural language across your interface. Even if you don’t significantly change the structure of your product, taking this step lends clarity and intentionality to your decisions.

In our case, we thought about what students are looking for when they arrive in the current MyPlan IA with FIGs in mind, and the actions they take on the current interface to explore FIGs. With these things in mind, we outlined three levels of FIG information that should be supported in our interface.

Three levels of FIG information

  1. List of FIGs — student looks for a FIG among a list of other FIGs
  2. List of courses within a FIG — student considers courses at face value, their times, and instructors to make an educated decision
  3. Details about a particular course (within a FIG) — student evaluates whether or not a course within a FIG will be interesting or relevant to them
Mapped out levels of FIG Detail

Exploring the existing information architecture made it clear that a level of information was missing. Both levels 1 and 2 were being handled on the Gen St 199 course page (shown below), but level 3 — details about individual courses within a FIG — was not accounted for anywhere.

Gen Studies 199 Course page displaying all FIGs

Knowing this, we considered introducing a new FIG page (shown below) for each of the FIGs on the Gen St 199 Course page shown above (A, A1, A2, etc). The page would introduce the FIG and outline the courses within it. This adjustment to the architecture of MyPlan would clarify the structure of FIGs and give space for communicating course information.

IDEA — Course page, arriving from FIG A1 page (left), FIG A1 page with course information (right)

We ultimately showed this same information through a pop-up modal without creating an additional page for each FIG, but I’m glad we designed the page first, because it still helped us explore ways we could communicate the missing level of information.

2. Set new expectations for your users

Users learn how information is displayed and manipulated on your interface. There are several ways to reset their expectations so they can understand new types of information.

2.1 Through labeling of unique information

Use visual treatment and text labels to make unique information easy to recognize. This signals to users that they might need to think about those instances a bit differently. When a student adds a FIG to their plan, we show all the courses in Schedule Builder and visually label FIG blocks with badges.

Before
Solution — Label FIGs in schedule builder with light tags

We carried this strategy into students’ Autumn quarter academic plan.continue to label FIGs throughout the interface. “FIG A1” Labels indicate that the first three courses are in a FIG. This lets us represent FIG courses as individual courses (which they are) while still showing that they are part of the same FIG.

Without labeling (left), Solution — With labeling (right)

Since courses often have some quiz sections that are just for FIGs, and more that aren’t, we also played with labeling a normal course page to show which sections were associated with FIGs. Students drilling down to the course within a FIG would be able to focus only on sections they’d be able to take in the FIG.

IDEA — label FIG sections within courses

Labeling FIGs assures students of their validity in MyPlan, so students can feel confident that their schedule will be valid when it’s time to register.

2.2 Through narrative at point of action

When information deviates from the existing model in your UI, it often becomes a problem when users perform an action. The system’s response doesn’t match what they have come to expect because the information needs to behave differently to accurately represent itself. You can guide users around the new information model, and interrupt potential mistakes during these moments, by providing context about the consequences of their actions (kind of like being an annoying parent).

Because FIG courses don’t behave like normal courses when you try to manipulate them (they move as a group), users may be surprised by how they behave. For example, when a student deletes a course from a FIG, they may not realize that this will destroy the FIG (you can’t take part in part of a FIG).

We brainstormed ways of telling users what would happen when they deleted courses within FIGs, and preventing them from performing actions that would be confusing to them. In an ideal system, we would have given students the option to add or delete a whole FIG when they try to delete a course within it, but — given the technical constraints of MyPlan — telling them how to interact with the current system was the next best thing.

BRAINSTORM — ‘Delete from plan’ messaging

We also included a popup on the Gen St 199 Page so students adding a FIG to their plan would understand the behavior of adding a FIG and see details about the courses in the FIG before officially “adding” it to their plan.

Solution — Popup on Gen St 199

Providing guidance at these points of potential frustration helps students navigate the new information structure that we have introduced and reinforces that we’re fully supporting FIGs within MyPlan, which encourages students to consider them as an option.

3. Surface critical information

Bringing information that’s buried in your UI to the top layers can cue people in to a new information model. You want to strike a balance between cluttering your UI unnecessarily and providing information that makes the unique model more transparent.

Students typically start their journey on the FIG website, where they can see courses associated with each FIG. When they get to MyPlan, this information is gone.

Within the visual structure already in place, we brought course information to the “course list” layer.

Before — No info on courses within FIG
Solution — Courses within FIG shown

Now, when students arrive on the FIG page, they can see courses included in FIGs. With this information brought to the surface rather than buried, students will immediately understand that FIGs are collections of courses, and have more information in front of them to decide between FIGs. This information also provides a consistent narrative around FIGs as students move between MyPlan and other UW sites.

In Summary…

As designers, we have a range of strategies we can deploy to adjust interfaces so they can accommodate unique information models. We didn’t have to tear down MyPlan to make it work for FIGs. We could retain the structure that worked for single courses while still accommodating for something different. We used these strategies to creatively address points of confusion:

  1. Revisit the information architecture
  2. Set new expectations for your users
  3. Surface critical information

By supporting FIGs in MyPlan’s UI, we’re showing students that their choice to take a FIG isn’t a hack or a workaround; it’s an option that UW encourages.

Reflections on designing for MyPlan

The real challenge of this process wasn’t designing a perfect solution for students — it was designing a solution that was better for students and possible within the current MyPlan web framework. Some functionality that we wanted was, frustratingly, not possible. For me as a student designer, it was useful to have the experience of proposing design changes, hearing that they weren’t possible, and finding other ways of accomplishing a similar goal. When we did adjust our solutions, we had to ask ourselves honestly: “Will this still add value to students?” For some ideas, usability tests confirmed that the answer was “no”. But others, however small, still made registering for FIGs less confusing.