Vitae Navigation

The information architecture for Vitae (ChronicleVitae.com) was developed rapidly, along with the rest of the complex site. At the time of the site's launch, the goal was a minimal viable product that could begin to develop a user base. As the site grew, the Vitae team prioritized adding new features over revisiting the overall navigation of the site. After some time, we realized our site navigation could use some fine tuning. The Chronicle's in-house researcher and I banded together to conduct a few research efforts. Our goal was simple: to determine the best way to reorganize our site's navigation.

When I first started working at the Chronicle, my colleagues briefed me on Vitae’s history: it was designed quickly, launched, and had been largely untouched (with the exception of a few bolted-on features) for about 2 years. I’d been hired during a pressing time — the business was reevaluating the effectiveness of the professional network for job seekers in higher education. It hadn’t received a typical iterative process and was yearning for an update.

The team began prioritizing many new features customers had requested and revising previous features that needed a version two, but something that stuck out to me personally was the complex and bloated primary navigation of the site. There were no less than 9 primary navigation options (two of which were post-launch features, which really didn’t seem to be core functions of the site). I requested the manpower, time, and budget to do some research and user testing to revise this navigation and streamline the process of getting around the site. I wanted to give our users the best way to get around the site and to give some of our sleeper, hard-to-find features a real chance. I started with a quick post-it note brainstorm to see how our site navigation could be improved.
Our in-house UX researcher and I got straight to work with a card sort. With our budget, our card sort needed to be remote. We create cards with terms found throughout our site, including all of the primary and secondary navigation items. We took note of a pattern that most users lumped our secondary items into three larger primary categories: job-related features, community-focused features, and content. We also noted that a user’s personal messages, profile, and settings should be accessible from the primary navigation; otherwise, it was maddening to find them.

With the results of our card test in hand, I created a few different prototypes to test different labels with a click test. This test was the easiest, most economical way for us to test the validity of different labels for our primary navigation. The challenge with the click test was that it would only record whether a response was correct, or incorrect. We decided to create a secondary “correct” answer in order to see where people were clicking if they did not succeed on the first try. I’m so glad we chose to set this up, or some of our results would have been completely void of useful information.

Our click test helped us determine which labels work better with our user base. But now, we needed to know where the secondary labels fit best. The results of our card test were a bit inconclusive when it came to secondary navigation items, and besides — we wanted to see how our users would interact with a workable prototype.

I created an interactive prototype, keeping the results of our previous tests in mind. I used Marvel App for the prototype and we coordinated with UserTesting.com to set up a remote user test with 8 users. We noticed a few pain points repeating themselves throughout the user test recordings. People had trouble recognizing the term “dossier,” even though they were in higher education and it was assumed that most knew that term well. Our new primary categories were working extremely well. Some users associated things like “My Saved Jobs” and “My Job Email Alerts” with their personal settings, instead of with the “Jobs” category, as we’d predicted.

I adjusted the prototype accordingly and presented the results of our rigorous testing to our stakeholders: the product owner, the dev lead, the business, and the director of UX (my boss). We moved forward with development a few weeks later. I coordinated with the developers to make sure the new navigation bar, which we luckily were able to rebuild from scratch, came out working as effectively as I’d intended. In October 2016, we were able to release it to production. It was one of our quickest and most successful projects yet.
Back to Top