Optimizing content discoverability for intellectual readers

Overview

How can we best help readers find useful and interesting content on JSTOR Daily?

JSTOR Daily is a free online publication from the digital library JSTOR, bringing insights from academic research to scholarly and general audiences alike.

JSTOR Daily's original homepage.

The writing was there. Getting to it was the problem: a sprawling site structure and an inefficient search stood between readers and the articles they came for.

Educators struggled to find articles they could teach with, and casual readers were overwhelmed by the size of the catalog—leaving good writing unread, and readers with little reason to return.

Project objectives and goals

Working with the JSTOR Daily team, we had the following goals for improving the publication website:

We created a timeline to convey to the JSTOR Daily team when we would provide certain deliverables, and to keep ourselves accountable throughout the project as well.

Six research methods to evaluate user experiences and functionality

To get a full picture of the current situation with JSTOR Daily, we engaged with a diverse set of six methods.

• Surveys: Gauging at scale what readers want more of
• Interviews: Understanding readers' desires and pain points in depth
• Accessibility Audit: Making sure the site is accessible to all kinds of readers
• Google Analytics: Seeing what content attracts the most clicks and screentime
• Competitive Analysis: Seeing how other digital publication sites approach navigation, layout, etc.
• Usability Tests: Testing the original website to pinpoint specific opportunities for improvement, and testing the prototype as we develop it to refine it

Research findings

I'll cover a few of the methods here; the full set of results lives in our final report, linked at the bottom of this page.

Surveys: What people desire and what we can emphasize

We sent out our survey to the JSTOR Daily newsletter, and used affinity mapping to analyze 243 survey responses from both readers and non-readers. We gauged what people desired more from the JSTOR Daily website, and what they liked about the website that we could place more weight on.

Competitive analysis: Drawing inspiration from competitors

We observed and noted how successful competitors, some of which were mentioned by research participants, organized their content and layout.

For example, we analyzed what worked about Aeon's navigation menu:

• ⭐ Large titles for categories
• ⭐ No more than 7 categories (5 plus or minus 2 is the best for cognitive load)
• ⭐ Differentiate between larger categories with color, location, and font size

Analyzing what worked about competitors' choices would help inform our own design, drawing inspiration from best practices.

User journey: Seeing through users' POVs

Across 10 interview participants, we noticed two common groups of users that we could target in our improvements: educators and casual readers.

In addition to personas, we created a user journey map to walk through a specific scenario for each user group from their perspective. This helped us pinpoint specific opportunities for improvement.

Usability tests: Uncovering usability issues

We provided tasks to familiar and non-familiar users testing the following:

• 🎯 Navigation
• 🎯 Search function
• 🎯 Relevance of content categories
• 🎯 Newsletter subscription (evaluating specific retention methods)

This revealed the following specific usability issues:

Turning user insights into ideas

Design requirements: From research to tangible features

With the sheer amount of information we gained from our many research methods, we had to hone in on what would be most important and impactful to users.

We created a table of features informed by research insights to evaluate and compare the features in how much they would improve user experience. We used this table to decide what to focus on in our prototype, while leaving the rest as a future reference for the JSTOR Daily team.

Our rapid ideation session—what features would be most helpful to users based on our research insights?

Low fidelity wireframes: Developing and testing functionality

We focused on redesigning three main components:

• ⭐ Homepage
• ⭐ Navigation bar
• ⭐ Article page

We started out with low-fidelity wireframes to firstly focus on functionality and layout. This initial draft proved useful as we were able to obtain user testing feedback on these early stage ideas, easily adjusting and iterating as we continued to design.

For example, the mobile article menu was adjusted based on the following feedback:

• Feasibility: JSTOR Daily could not implement an account system to allow users to save articles.
• Accessibility: The menu was moved to the bottom of the screen for more convenient access.

Key design elements

Our final design was informed by both user feedback and needs, as well as JSTOR Daily's business goals. After multiple cycles of feedback with the JSTOR Daily development and editing team, and various types of users, we developed the final redesign with the following themes:

We saw significant improvements in task completion time (i.e. sharing articles, finding topic-specific content) on our prototype compared to the original website. Four out of five tasks had at least an 80% increase in task efficiency.

Below is a more detailed explanation of what we changed and why in the three main components: the home page, navigation bar, and article page.

Home page

Navigation bar

Article page

Handing it off

To allow the JSTOR Daily team to easily reference our recommendations and findings after the end of this project, we created handoff documents so they could more easily implement our design as we intended.

User flow

Maps out each interaction and the paths a user can take within the redesign.

UX Specification

Clearly defines layout, interactions, and behaviors of the redesigned user interface for developers.

Reflections and next steps

This project could only be so fulfilling because of the people I worked with—my teammates with their collaborative, dedicated, and creative spirit, and the JSTOR Daily team for their helpful feedback, support, and direction. I will not forget the late night work sessions with the team and Google Meet calls where JR's cat would say hello!

I learned a lot from the nature of the project—since it was client-based, consistent communication, emphasis on business goals, and evaluation of feasibility was necessary for the project's success. The sheer amount of user feedback and engagement during the project was amazing. I met all kinds of readers, and was inspired by their dedication to knowledge. It was fulfilling to hear the many different ways of what JSTOR Daily meant to them.

Moving forward, I would like to improve on one aspect:

• Design systems: Although we created a dedicated asset system used throughout the redesign, I would like to further explore creating a more structured and granular design system to allow for streamlined designing.

Thanks to my teammates—Olive, Liam, Mida, and Connor—and the JSTOR Daily team—JR, Johnathan, and Anjanette—for making this such an amazing experience!

Final prototype

Try out our interactive prototype of the JSTOR Daily redesign! Scroll and click around the preview below, or open it in its own tab.

open interactive prototype ↗