Overview
Redesigning Harvard Business Review’s bi-monthly series to encourage reader engagement with multiple content items and improve awareness of the value of the series.
Overview
Redesigning Harvard Business Review’s bi-monthly series to encourage reader engagement with multiple content items and improve awareness of the value of the series.
Company
Harvard Business Review
Role
Lead product designer — interaction design, UI design
Team
Agile team consisting of a Product Manager, Project Manager, UX Researcher, and team of Developers.
Duration
February — August 2018
The Big Idea is a suite of content that is published bi-monthly. The content centers around a single idea and is held together by the first article in the series. The goal of the Big Idea is to engage readers over time by publishing new content in the series each day after go-live, for a total of one to two weeks. To provide the most value to readers, it is important that they know what content is included in the package, and when it will be available, as well as how to navigate quickly from one piece of content to the other.
Unfortunately, despite our interest in engaging readers in multiple content items, a year after the first Big Idea was launched, metrics showed that users were not navigating to other content within a series. They tended to remain on the content they had initially landed on and were missing out on the additional related content.
The navigation overlay — The main artery of navigation for The Big Idea series. A button on the first article in the series opened this overlay with links to the rest of the content. This experience isolated content in the series and wasn't intuitive as a navigational tool for users, among other issues.
Sticky top navigation — This simpler, persisistent navigation appears on all content that is part of the series, connecting them and letting the user know where they are.
During this navigation redesign, I was lead designer on an outcomes-based product team where I collaborated with user experience (UX), software engineering, and our Product Owner throughout the design process. Together we pinpointed the main issues with The Big Idea and conducted usability tests with mid-fidelity prototypes that I created to test our assumptions.
At different points in the process, I was responsible for presenting our approaches to stakeholders within marketing, editorial, and product to ensure buy-in. As a result of this process of interacting with our readers, our stakeholders, and the team, I successfully developed and designed a new navigational solution. Finally, I worked with our engineers to have the final design go live on schedule without sacrificing planned interactivity or visual design.
In order to understand from our stakeholders their assumptions and perceptions around why users were not navigating through the Big Idea series, we conducted a few stakeholder interviews. Our goal was to learn from our subject matter experts and to understand what their measures of success would be for a new Big Idea navigation.
It wasn’t disinterest in the editorial content itself, but three key problems that were blocking users from engaging with the rest of the series.
Because there was no mention in any of the content of The Big Idea that it was a series, users wouldn’t know to look for navigation to go to another piece of content within the series.
Using the language of “The Lineup” to refer to the suite of articles and the overlay that contained the navigation confused our users.
The name given to the navigation didn’t explain its function.
Using the language of “The Lineup” to refer to the suite of articles and the overlay that contained the navigation confused our users.
The overlay took users out of the context of the main article, interrupting the reading experience. It also wasn’t recognizable before opening it as a navigational element that was meant to guide users through the series.
When a reader selected a piece of content within the series, they would not be able to go to another article unless they went into the overlay or, if in a subarticle, a back button in the overlay. This meant that there was no way for users to organically flow from one piece of content to the other.
Once we understood stakeholder interests and concerns, it was time to start cranking out ideas to test with users. Design, engineering, and UX invited stakeholders from editorial, production and data analytics to brainstorm together in a workshop.
Eventually some ideas that proved promising bubbled up to the top, such as sticky navigation and the ability to swipe between articles. Also helpful was that we gained insight into what assumptions we wanted to test against each other.
With the ideas from the brainstorming, I began wireframing potential solutions that we could test with feedback and approval from the design director for UX and Product. All options had to:
An option with repeated navigational components throughout the article. Each navigation has a different amount of information about the series that’s appropriate to where it’s placed in the article.
An unintrusive persistent/sticky navigation. It takes up the space of the left rail when opened.
A second option for a persistent navigation that is at the the top of the page. An often-used and familiar pattern of navigation for our users.
The goal of this option was to have the navigation repeated throughout an article. The modules were adjustable based upon their location in the article and the editor’s discretion.
The idea behind this concept was that context was everything. We hypothesized that a reader would be okay with having very condensed navigation at the beginning of an article because they just want to get into the content. However, inserting expanded navigation to the full series in the next few paragraphs was the right way to encourage readers who had already lost interest by that point to try something else.
A small placement to make the user aware that the article is part of a series and if something was just published or coming up.
A small placement to make the user aware that the article is part of a series and if something was just published or coming up.
Shows the user the full series offering. This takes up almost the full-page width and is meant to increase curiosity and engage those whose interest in the current article is either waning, or if they want to go deeper.
Another small tout focusing on the next article and giving the user the ability to navigate through the rest of the content.
The goal here is to get users to the next piece in the series or pique their interest in another The Big Idea.
This solution was very similar to a typical persistent tray of links that’s pinned to the top of a page. A key difference is that it took up the left-hand rail of the article without impeding on the reading experience. The nav could accommodate a large list of content easily because a user can scroll up and down to see all content.
This option was another pinned navigation with the main interaction being a tray of links always present at the top of the screen except on scroll-down. This allowed the user to see the content without disrupting the reading experience. Ultimately this was the option chosen to be developed and shipped.
Throughout the design process we refined the way the information in the navigation was shown to optimize for clarity and conciseness based on feedback from users and stakeholders. Anything that wasn’t necessary to guide a user to the next content item or provide an understanding of the concept of The Big Idea series was thrown out. Below are a few of the stages the design went through as the idea was developed in this way.
Our UX researchers and I created a series of questions to accommodate our prototypes that were used to conduct guerrilla testing in our office cafeteria. We placed the three prototypes in front of our volunteers, and observed how they interacted with them.
Our goal was to learn from people who were not necessarily familiar with HBR and definitely not familiar with The Big Idea so that we could make sure that any user coming into a Big Idea could understand what it is and how to navigate it. In addition to the guerrilla testing, we also set up an unmoderated test on usertesting.com. The questions we wanted answered were:
Users preferred navigation that was persistent. While we thought in-context modules would do the best because of the multiple opportunities to catch readers’ attention, some of the modules were completely missed by users as they scrolled.
The navigation is not intrusive because it disappears as a user is scrolling down the page. On scroll-up it appears again to let the reader know that they are on a series of connected articles, what has been published, and what will be available later.
It has the benefit of being on every piece of content, so the user is habituated into knowing where to go for more content.
Navigation always being available at the top of a page is a familiar pattern, so this option was more intuitive for them to use.
It was at this stage that we felt that we had enough information to develop the persistent top navigation for go-live. We kept option one (the in-context navigational modules) in our back pocket for phase two of the navigation.
Since the desktop design was already so high fidelity while testing with users, all that was left to do was polish off the styling and finalize the mobile design.
Since the desktop design was already so high fidelity while testing with users, all that was left to do was polish off the styling and finalize the mobile design.
The updated main article for the series with final persistent navigation.
The rest of the articles/subarticles in the series. Now that the navigation wasn’t housed in an overlay, all of the content, including the subarticles, were unified.
On mobile, it was important to design a navigation that is as unintrusive as possible. I designed the behavior and interaction to take up as little space as possible but still be easy to find and navigate through on a mobile device.
The mobile device view with MVP animation.
It helps to double-check your bias towards a solution. Every designer will have a favorite solution that they’re rooting for. While I favored the option with in-context nav as MVP, it was apparent that users were responding best to another option. I learned to let go of my bias and support the version that provided the best experience for our testers.
If it’s well-designed, users will figure out how it works. We went through a lot of options that were less traditional forms of navigation and required a certain amount of learning for the user. The team had many discussions throughout the process in order to ensure a balance between an experience that requires some learning and engagement on the part of the user, and one that is just too unintuitive to use.