Implementation of the Program Finder

Timeline: 1-month design/ 4-month testing • Materials: Pen, Paper, and Adobe Xd

UX Techniques: Analytics, Competitive/Comparative Analysis, Sketching, Prototyping, Mockups, Optimizely for Variant Testing

Background

Once a year we work with an outside agency to conduct research about prospective students. This 200+ page document dives deep into what makes a prospective student decide to go back to school. This document is a great resource for persona information, competitive tuition cost, and even what industry is growing so that we can market more to that demographic.

Through this research and our own evaluation and analytics we found that prospective students ask themselves three important questions:

Do you have my program?
How much does it cost?
Where is the program held?

There are 200+ programs that take place either online or on campus within a variety of fields of study. In this project we are focusing on the first question, but see my other projects for ‘How much does it cost’ and ‘Where is the program held’.

The Problem

In the old flow there was no filtering system. A user would have to find their program by navigating through school pages, then department, then program, which is a poor experience. Users do not know the intricacies of programs and the departments they fall under, let alone the school. It might make sense to faculty, which is who recommended this journey, but a prospective student lacks this background knowledge thus making the experience confusing.

The Solution

We came up with two solutions to this problem: a program finder and a search bar on the homepage. Here we will focus on the program finder but check out the search bar project for a deeper dive. To fix this problem using the program finder, we implemented three main filters: Area of Study, Degree Level, and Format (online, on campus, or mix mode). All 200+ programs have to fit within these filters. For area of study there are eight categories which users better understand than what school a program lives under. The flow now feels very natural, and does not force the user to look too hard for what they want to accomplish.

Card Sorting and Information Architecture

Our team conducted a card sorting activity in effort to develop the Information Architecture for the programs of the National University website. This method involved crawling the old site, then putting each program into a certain area of study.

It was immensely helpful to get all stakeholders in a room to take part in this method including faculty (which we refer to as our client). It was a challenge, though, to try to change the mindsets of these individuals because they were the ones that built out the old flow.

This gave us a valuable opportunity to probe and to give rationales behind the decision-making process. This helped us to uncover key quantitative insights that couldn’t be deduced otherwise. By going through this exercise, it convinced them this was a better flow and would improve the experience for potential student. Getting buy in from them early on in the process was extremely valuable and a step-in right direction.

Tasks and User Flows

Now it was time to come up with user flows. We wanted to test our flows by creating different tasks for users to accomplish and then see how easy or difficult it was for them to complete based on our proposed IA. There were several tests that we asked users to complete. One of the most important tasks we set was:

You are a prospective student who is looking to go back to school, and want to see if NU has an MBA program. Go to the NU homepage and find the MBA program page.

Hypothesis

The belief was that if prospective students could find their program faster, with less friction via the program finder, then they could find the content they were looking for faster. In turn, this would generate more leads and thus, they would be more likely to enroll in the university resulting in higher revenue.

Low-fi mobile prototype: Iteration One – Acted too much like an ecommerce website; Too heave into search

Low-fi mobile prototype: Iteration Two – Pulled out filtering options, but still too heave into search

Low-fi mobile prototype: Iteration Three – Pulled out all filtering. Made it more of an experience/journey using steps as the flow

High-Fidelity mobile prototype: Using the correct brand, UI patterns, and style guides

High-Fidelity desktop prototype: Using the correct brand, UI patterns, and style guides

Findings

After 118 days of splitting the traffic the program finder is outperforming the old navigation via ‘College of’ by 64.3% with a conversion rate of 4.7% which is up 67.8%.

Optimizely Screenshot –Showing results of the program finder vs the control/original

Overall improvement to the program finder vs the control/original

Reflections

One of my main take-aways from this project was the value of the relationship with the client and bringing them in to be part of the process (i.e. including faculty in the card sorting activity). Historically, the faculty/ clients have been slow to change, even resistant at times. Partnering with them not only gave us key insight into how to categorize the programs, but also made them more receptive to the changes.

A thing I would do differently in the future would be to implement some form of user testing before pushing it live. The way we tested was through splitting live traffic of the control and variant pages. Having some user testing would have helpful to gain useful knowledge to see if what we came up with was correct or if we needed to go back and design another iteration.

No related posts found