Analysis: Usability and feedback in Feedly Reader

Feedly is an RSS reader that became popular when Google shut down its similar service. Although many people get their content from social media, there are still many users of RSS readers, as well as people who've never heard of them.

Context

The Feedly Android app works well for general browsing and discovery, but confuses users when they try to save articles and blogs and come back to them later. 

Role

I was the sole designer for this usability test. I conducted the test with 7 participants and synthesized the research for design recommendations over a two-week sprint.

The Usability Test

I selected people who read blogs and other content that updates daily to weekly on their phones since they would be potential users of an RSS reader. If I were working in a longer-term capacity, I'd prefer to recruit new users and current users separately, as well as users of competitors' RSS readers.

Usability tasks

  1. How would you remember a website you like so you can read it again the next time you open the app?

  2. How would you keep track of what you’ve seen and what you haven’t?

  3. Let’s say you really like a story and you want to come back and see it later. What would you do?

  4. You think a friend would really like a story. How would you get them to read it?

  5. What’s a topic you’re really interested in? If there are a lot of things you want to see, how would you make it easier to read them all at once?

Problem Synthesis & Potential Solutions

During the tests, four usability issues emerged:

  1. Participants had trouble adding feeds the first time

  2. Participants did not understand when they had completed an action

  3. Participants had trouble making collections/folders

  4. Participants were frustrated by menu navigation

Problem 1: Participants had trouble adding feeds

"Okay, so I have to press the "+" or something?"

One of the confusions users had was that when they tried to subscribe to a feed, in Feedly's case "Add," they usually tapped the row, which sent them to view the feed. They either ignored or missed the "+" symbol, and they weren't always sure that they had added a feed successfully. The solution is to make the "+" button more salient, for example by adding a border.

Adding3.gif

The second problem about not recognizing if they had successfully added a feed is part of a larger issue, though:

Problem 2: Participants did not understand when they had completed an action

"I see that I bookmarked it, but I can't tell the difference between read and unread."

Participants often missed the feedback in the current UX for adding, bookmarking, and viewing read/unread articles. Like solution 1, the recommendation is to make the feedback more salient by making the icons brighter, as well as increasing the contrast between read and unread articles.

Feedback4.png

Problem 3: Participants had trouble adding collections/folders

"The hamburger button is not the answer. There's nothing good in there." 

Making a collection in the Android app is only possible when subscribing to a feed for the first time. This led to the most frustration for users, 3 of whom defaulted to using tags, which only work for individual articles. Also, when tags are created, they automatically take up a whole row, which pushes the navigation even lower on the screen.

Collections4.png

The app could borrow the ability to organize with drag-and-drop that currently exists on desktop. This could be accessible through the same left-hand menu as the rest of the navigation. This would also be consistent with the layout on desktop. 

The tags being listed individually may capture certain user behavior. Insight into that and menu navigation would be a great topic for a follow-up usability test.

Benefits

  1. The first two solutions make the results of user actions and the changes of state (read/unread; bookmarked/not bookmarked) more recognizable, so users will be less confused because they understand if something has happened. More on the border around the add button below.

  2. The last solution provides a more organized menu, and it allows users to perform the organizing action in the menu they expect it to be in.

Next Steps:

  1. If I were at Feedly, I would check analytics to see how severe of an issue each of these tasks might be having on the behavior we want to encourage. I would then A/B test each solution against the current design. I'd be curious to see whether the border around the add button would increase conversions the way it does for other buttons. It's not the prettiest solution, but that's a struggle that a lot of contemporary UI faces with making button affordances clear so users don't think they're labels.

  2. I'd love to take a look at Feedly's user segmentation to see what kinds of users they have and how their behavior is different. I wonder what usability issues could be fixed for everyone but edge cases, and what product decisions could be made based on users' social media use. A lot of the usability test participants said that they love the idea of an RSS reader, but get blog content through what their network posts on Facebook or Twitter. Also, a couple of them tried other RSS readers and settled on different ones in the past, but said that they liked the visual design of Feedly better. There are a lot of product and growth opportunities.