Feedly, released in 2008, is an RSS reader that was among those highlighted on the blog Lifehacker when Google shut down its own popular reader in 2013. It allows users to aggregate blogs’ and other websites’ RSS feeds so they can browse and save what they read in one central location. Since I’m an avid user of their desktop webapp, I wanted to take a look at the browsing experience on Android.
I conducted guerrilla usability tests in San Francisco. To test the app, I looked for users who had read blogs and other content that updates daily/weekly on their phones.
With spoken consent, I captured screen recordings and took notes on how clear it was to complete the following common RSS reader tasks:
- Add a feed
"So, what website did you visit last week that had a really interesting article or post? How would you remember a website like that so you can read it again next time you open the app instead of your browser?"
- Mark a story as read or unread
"So each page has a lot of articles, and you’ve read some of them, but not all of them. How would you keep track of what you’ve seen and what you haven’t?"
- Save a story for later
"Let’s say you really like a story and you want to come back and see it later. What would you do?"
- Share a story
"You read a story and you think a friend would really like it. How would you get them to read it?"
- Make a collection of stories
"What’s a topic you’re really interested in? If there are a lot of things you want to see on that subject, how would you make it easier to read them all at once?"
After the first few usability assessments, I rephrased the discussion guide and tasks to make them more open-ended. I tested on my Nexus 5, and tried to make screen recordings using a few different programs, eventually finding Rec. (paid), which allowed me to track finger movement and external sounds for up to 20 minutes.
Synthesis: 2x2 Matrix
After the usability sessions, I reviewed my videos and notes and used post-its to visually represent my findings
And mapped out major pain points.
And arranged the 4 pain points based on ease of implementation and confusion to the participants.
Four usability issues emerged:
- Participants had trouble adding feeds the first time
- Participants did not understand when they had completed an action
- Participants had trouble making collections/folders
- Participants were frustrated by menu navigation
Problem 1: Participants had trouble adding feeds
One thing a couple of participants mentioned was that they didn't want to use the magnifying glass icon because to them it suggested a search for content they'd already added.
"The magnifying glass is something I'd use to search content. This is like discovery hidden behind search" — User
Once they tried it, they saw that it offered several categories, and then blogs within categories. A couple of the more technical participants noticed the "+" symbol, but some of the others did not. Also, when accessing the same categories from the "Add website" option inside the hamburger menu, users assumed that tapping on the row of the blog name instead of just the "+" would add the blog to their feed. This led to confusion later when they couldn't find the blogs they added.
"Okay, so I have to press the "+" or something?"— User
Most of the users didn't notice whether or not they successfully subscribed to something, which is tied to problem number 2 below.
Since the "Add website" button sends users to the search menu already, the users thought tapping the whole row would add the website instead of just the "+" symbol.
Another option would be an "Add/Added" or "Subscribe/Subscribed" button instead of the "+". However, since most users explained that they expected tapping the row to add, perhaps a confirmation (like the lit-up + symbol) before sending them out of the menu would be better than adding a button. That desire for confirmation leads us to the second usability issue found.
Problem 2: Participants did not understand when they had completed an action
The problem with adding feeds is linked to the larger issue of feedback. Participants didn't always know when they'd completed an action since they didn't often receive feedback from the app. The two most salient pieces of feedback were for the long press save when not inside the article, or when tapping the bookmark icon when inside an article. Outside of these, the difference between states was not easy to see for many participants.
"I see that I bookmarked it, but I can't tell the difference between read and unread."— User
The pop-up notification is used for Saved/Unsaved and keeping things unread. It is locked to the middle of the screen, but could be more effective if moved closer to what's being modified. It could also be used in the the previous problem of adding feeds to let users know when they've successfully added a feed.
Also, while reading, the difference in read and unread could be made more salient by darkening the images to accompany the darkened headline text of the read articles. The bookmark icon could also be brighter to allow users to skim more efficiently.
Problem 3: Participants had trouble adding collections/folders
Users thought that everything from tags to filters to "edit content" would allow them some of the functionality of grouping. On the desktop, you can add new collections by clicking on Organize under the existing collections. The app, however, does not offer this feature.
"I mean how much frustration is a person supposed to put up with? ... I mean, I can keep looking. I just wasn't sure if there was like a certain amount of frustration you're like 'Oh, that's too much frustration... Nobody should have to deal with that kind of...'"— User
Users looked around the menus in circles for a way to make new collections and either gave up or added new blogs. They thought the answer might be in the hamburger menu, but:
"The hamburger button is not the answer. There's nothing good in there." — User
Allow users to organize their collections in the app from the hamburger menu. Also, since tags appear separately in this menu, putting tags inside their own accordion menu would reduce visual clutter.
Problem 4: Participants were frustrated by menu navigation
Some users intuitively looked into the menus when lost. As mentioned before, they didn't trust the magnifying glass icon, but instinctively looked under the ellipsis menu and the hamburger menu. A couple of users said that they expected some long-press contextual menus, but that using the long-press for saving/bookmarking was intuitive. The final participant wanted to be able to swipe out the left and right menus since in most views the left and right swipe gestures didn't seem to do anything. A couple of users weren't sure what each menu did, however, and just kept tapping on the menus in a loop.
Feedly offers many options and many views for reading blogs. To provide so many features and be as uncluttered as it is, it requires a lot of menus. Menu navigation is an area with many different and often competing conventions, however.
One easy solution would be to change the magnifying glass icon, which many participants found misleading. Aside from that, however, other solutions are outside of scope of this test.
Since Android is a very diverse ecosystem of devices with different UIs, and since a lot of people in the groups I was targeting in San Francisco use iOS devices, there is certainly room to recruit separate groups to test. I would love to test my hypotheses with more devices and more users. Think, build, check!
I would also like to spend time comparing feed reader behavior with email and social media because most participants mentioned that they have become accustomed to the gestures of other apps like Gmail and Facebook (e.g., swiping left and right), and many mentioned that they usually get their news through social media these days.
I am not affiliated with Feedly. This review is put forth unsolicited; it was an exploratory learning opportunity done to develop my UX design skills.