A Deep Dive into NU’s Program Search Bar – A UX Case Study

Part I

Background

With over 200+ programs at National University, finding the right program for a potential student can be daunting. Therefore, the process of finding the right program must function flawlessly. This was not the case before this design project. For users to access information about a desired program, they would need to either click on the program’s link in the navigation or click on a button in the header. This would take the user to an academic program page where it lists out the six schools that all programs live under.

This was a clunky experience and therefore, we wanted to introduce the idea of a search bar. A search must be clear and concise and have artificial learning to bring up search results that users are expecting. I have documented the process, my thoughts, methods, wireframes, prototypes, results, and finally the live page. The design process I followed progresses through five stages of user centered design: Empathize, Define, Ideate, Prototype, and Test.

 

Research

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 from persona information, competitive tuition cost, and even what industry is growing so that we can market more to that demographic.

 

Diving into the Patterns of Search and Navigating

As a known UI pattern for several years, search has a couple of key features:

  • Users who use search know specifically what they are looking for — often as specific as an actual product name.
  • Search lets users control their own actions and find things they are looking for.
  • More users utilize search on a mobile device. Complex navigation seldom works well on mobile devices, so users don’t typically use it. Instead they prefer to quickly insert the search word and go directly to the result page.
  • Search is the user’s escape when they are stuck in navigation – when they can’t find a reasonable place to go next, they often turn to the search function.

Analyzing the above, the following conclusion can be made: each site should consider there are different types of users and a good user experience should appeal to all of them. Bad UX is when both search and navigation are too narrow or try to target only one group of users. Good UX would include functionality that has equal weight for both search and navigation. The image below presents this concept.

Ideation for Search Bar Flow

The original design for the hero section had a headline, a subheadline, and button that would go to the ‘College of …” page. From there, a user would have to find their program by navigating through each college page, 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.

Old user flow for finding a program

In the new flow, a user that lands on the homepage can simply start to type the program they desire, and the results will auto-populate in a box below the search bar. This search bar is a smart search, which works like people work. For example, if a user was looking for an MBA, they wouldn’t have to actually type “Master of Business Administration”; rather, they simply could type MBA, and the search would know what they meant and serve up the correct results.

New user flow for finding a program

Hypothesis

We wanted to test our design and see if it yielded the results we wanted. We set up a test through the testing platform, Optimizely. The idea for this project was to create several different designs for the homepage hero section and see which one preformed the best. The test was setup with the one control/original and five variances:

  • Button Centered
  • Search Only – Left
  • Search Only – Centered
  • Search & Browse – Left
  • Search & Browse – Centered

Low-Fi mobile wireframe with three ideas for different layouts

High-Fidelity desktop mockups with all six layouts

Results

The winning variation was ‘Search Only – Centered.’ This variation had the highest increase of traffic to program pages (click through rate) with a 46.43% increase without affecting conversion rates (RFI conversions).

An increase in traffic to program pages did not yield an increase to the conversion rate; therefore, the next step was to run tests to improve program page performance, which we did. Tests were completed on the top five program pages. All of these pages saw an increase ranging from 5% – 97%.

Part II

Background

Although this project was ‘completed,’ as designers, we know that is never really the case. We continue to iterate and improve the performance of the page. In the first iteration of this project, we had a strong understanding of the correct UI pattern, but there was still some challenges with search results on a mobile device. The results, which auto-populate, were getting cut off by the keyboard. Users were only able to see the first few programs which would force them to scroll. However, scrolling was also somewhat of an issue because the list was not full width, leaving some of the site page surrounding the drop down. Because of that, there was the potential to mistakenly scroll on the site instead of the list itself. Another issue was the length of the program names. The name would include the degree level, the type of degree, as well as the program name itself.

Problem with iOS keyboard cutting off search results

Research

The scrolling issue led us to do some research regarding complications on mobile. We discovered that, although smartphones continue to get larger, our hands don’t, thus making one-hand-operation of phones more and more difficult. An example of this is a hamburger menu, traditionally placed at the top left/right corners. Because of larger screens, this can be difficult to reach. Thoughtful design can rectify this issue making mobile sites easier to navigate.

In the analysis of 1000’s of smartphone users, Steven Hoober found about 75% of people rely on their thumb and 49% rely on a one-handed grip to get things done on their phones. On large screens (over four inches) those kinds of behaviors can stretch people’s thumbs well past their comfort zone as they try to reach controls positioned at the top of their device.

Ideation for Search Drop-down

There were two UI goals:

  1. Fix scrolling issue by making the search bar and results list full width
    When a user taps on the search bar, the site will display an overlay having the keyboard and search bar as the focus — ready to take the search string from the user. Once the user starts typing their desired program, a list will auto-populate dependent on user input. The search bar and the results will be full width with the intent to solve the scrolling issue found in the first iteration.

 

  1. Fix long program length names by separating degree and program information
    Instead of the search outputting “Master of Science in Higher Education Administration” the new output would be “Higher Education Administration – MS”. The rationale behind doing this is to shorten the name of the results and split them into two different fields in order to give clarity to the user regarding what program they are looking at.

Hypothesis

The big idea here is for users to find their program on a mobile device with ease by improving the mobile experience. The new layout fixes this problem by putting the search box at the top within the header. When users type, results still auto populate, however, a full screen box appears and users are able to see more programs.

Low fidelity prototype for a mobile device

High fidelity prototype for a mobile device

Results

Having the search results become full-width with the splitting of the program name and degree level was the obvious winner. This variation had the highest increased conversion rate on the program pages. It was a 91.23% increase from the original design.

Results

One of my main take-aways from this project was the value of the relationship with development and having communication in both directions.  Historically at NUS, there has been push and pull between design and development. But both departments bring value to the table that is vital– development with knowledge of functionality and building projects out and design with user experience. Everyone has a role to play and recognizing that role and partnering with each other creates a better end product.

A thing I would do differently in the future would be to advocate for more time for research and discovery. This would allow for more consideration of the user and more empathy. With any project, there is a timeline and with this project in particular, the timeline felt rushed. We may have met the deadline; however, we had to go back and complete a second phase; second phases run the risk of never being implemented. It is important to spend the time up front in order to get the project as close to ‘right’ as possible the first time around.

Based in sunny San Diego, California

+1 (619) 997-2058

jdgase@gmail.com