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.
This research and design project stemmed from a new technological capability that our development team had been working on for a few months. Previously, our products that contained a high quantity of data analytics could send that data to only one source at a time, which was time-consuming and inefficient. Now, we were able to send the data one time, and have it surface in multiple places at once. This process was called "bulk extract". I was tasked with finding the best uses of this capability within our product suite, which was centered around increasing persistence and graduation rates for higher education students.
I had prior knowledge of our degree planning and scheduling products, having created an in-depth demo of the two products working together. However, I had little experience with our Courses product, which is the one we wanted to extract the data from and have it surface in the others.
I spent quite a bit of time exploring the product in this early stage to familiarize myself with it. Because it's so complex, though, I needed help from our in-house subject matter experts to gain a thorough understanding of each of our products and how they worked together - or could work together in the future. My colleagues consisted of 2 product managers, the VP of Product and Strategy, 2 software engineers, the Sr. Director of Strategic Planning, and the UX designer for the degree planning product. Since the primary users of this product would be academic advisors and their assigned students, I also interviewed 2 of our product training & enablement consultants who had prior experience as college advisors.
As I gained a more thorough understanding of what type of data Courses contained, and how it impacted student success, I was able to develop a concept (shown below) of a flow of data-driven course signals throughout our product suite.
I presented my initial round of mockups to our VP of Product and Strategy for review. She was a co-founder of the company, and had in-depth knowledge of the history of each of the products I was working within. She made suggestions for fine-tuning the text descriptions I used in the course signal messaging so they would be more consistent with what the product actually does.
She also directed me toward two of our product educators/consultants (Lori and Chuck), who both had previous experience as academic advisors, since advisors would be one of the primary users of this information.
My interview with Lori and Chuck largely focused on what their experience had been as advisors and how they would see themselves using these features. My biggest takeaways had mostly to do with the data itself - what information was most important to gather, and how that would best be calculated. They also let me know the types of information advisors trust vs. distrust, and how sensitive students are to negative messaging. They cautioned against giving students too much information regarding difficulty of courses they were taking because they might just get scared and not even try. If I were to revisit this work, I would do more user research to include student feedback, as well as that of advisors currently in the field.
I presented a slide deck with my insights and a prototype of my solutions to Angela, the product manager for Degree Map, with assistance from Carl, the product manager for Courses, who provided additional explanation of the technical aspects of the product. Angela suggested that in the context of Degree Map, keeping course signals private to advisors would be ideal. There was concern that students would not understand how to interpret the course signals, and might self-advise themselves out of courses that they need.