Civitas Learning creates software for the higher education industry, which enables institutions to use machine learning with their existing data to identify the best ways in which to improve student outcomes such as retention and graduation rates.
The Degree Map product is intended for use by advisors, student success coaches, and students to help students explore and select majors and career goals, and form their degree plan based on those goals. The purpose is to keep students on track for graduation without taking too many extra courses that don’t count toward their goals.
The “Explore Degrees” section of our product had been problematic for quite some time. We had progress indicators that showed the students’ estimated percentage of completion toward a potential degree. These were designed as cards which could be clicked on to proceed to a full comparison of current progress toward that degree. However, because the percentages were only an estimate, it was confusing to our users when they would get to the next screen and see that the percentage didn’t match.
I was tasked with coming up with a solution to make the progress indicators less specific so that the percentage numbers were only shown on the page with the full comparison, while also not deviating too much from the existing design. At the time of this project, we were a design team of four, with two of us on this product. I produced all the mockups in Sketch, and shared my work with the team at the end of each stage to get feedback, refine, and select the best options to present to the product manager.
During the design process, there was a lot of back and forth between myself and the other UX designers via Slack, as well as the scrum team at our weekly playbacks.
Some of the initial ideas I had were centered around keeping it as simple as possible, with a simple “thumbs up” or star to indicate the degrees with the highest percentage of completion. We eliminated this concept because it seemed too much like adding a “favorite” which wasn’t a feature the app could support. Also, it seemed logical to me that we were “matching” students to degrees with the highest completion, but I was told that our partner institutions did not want students to think these were the only degrees they could choose from. They didn’t want the responsibility of a student making a poor choice based on this product’s recommendation, and we kept this in mind.
I also had a version which implemented the same bars we used in the new design of the Degree Planning section, but the product manager felt it was too heavy on text, and might not resonate well with partners. In the end, we had many solutions that were better, so these were never tested.
Another concept we backed away from was showing an indicator for majors with no measurable progress. We felt this would be discouraging to students, especially those at the beginning of their academic careers who would have few courses to apply to the degrees.
I narrowed down my early concepts with the help of another designer on my team to what we felt were the three strongest options, and provided these to the product manager to present to our partner/user.
After the first round of designs were presented and discussed, the product manager came back with feedback that they were close, but not quite there. She then requested three specific types of iconography to show the degree progress in gauges. These were a funnel, a circle, and square or rectangular segments. I presented these to the other members of the UX team, and we agreed that some of the gauges looked too much like volume indicators, and there was difficulty identifying the pattern of progress I'd created with the circles and squares.
After some refinement, we presented these 2nd round concepts to one of our "power users". I sat in on the partner call to discuss these designs, and some of the feedback was that the icons that were segmented into four sections were assumed to be grouped into years of study (i.e. freshman, sophomore, junior, senior). For this reason, we concluded that three levels of visualization would be ideal.
More refinement was necessary at this point, and I played with the rectanglular bars to make them look less like volume indicators. This resulted in squares, rather than bars, which were well-received by both the design team and the product manager. This third round of designs is what was presented to the product manager for approval.
Once these had been fine-tuned and mocked up for presentation, the users reacted most favorably to and ultimately approved the grouping of three squares in a horizontal row. In this submission, we also needed to provide verbal descriptors for the levels of progress that would resonate with our users. We chose to keep the language positive to provide encouragement to students who might not be far into their degree plans, which ruled out terms like "zero" and "no". This was a joint effort between myself and a couple of the developers on my team.
After implementing the approved icons into the design, I discovered that the card layout we’d been using wasn’t ideal for presenting this information. After doing some research, I confirmed that this data would best be presented in a list. This worked better for the icons we’d chosen, as well. Making this change created a domino effect, which led to a new layout for the screen, and a toggle to switch back to the original card format, which was requested by our users. For the toggle, we ultimately based them on the Material Design style guidelines.
The designs approved by our Product Manager and partners are shown below. The table allows for sorting via the column headings, whereas the grid view required an additional dropdown to sort. We again used Material Design to guide the look of the dropdown, which is used throughout the application. These designs were implemented in the following sprint, and are now available in the product with the default view being the new table layout. (click to enlarge)