Funny or Die had not updated their iOS app for many years. User engagement in the apps was very low, and the bounce rate was high. I was brought in to create a new user experience for the app, leveraging existing content and allowing for new types of content.
My primary role for this project was UX/UI Designer, working with the Product Manager who provided the user research and relevant data.
Increase app installs was the first challenge, but the real goal was to increase user engagement and interaction.
Fans visiting FOD on their mobile devices chose to go the website instead of the app. The current apps were very outdated and not fun to use, and while the FOD website was optimized for mobile viewing, it still was not an engaging experience on mobile devices.
The big question was, “How do we leverage native features of mobile devices to keep users engaged and interacting with the content for a long as possible?”
FOD had a clear idea of their users, and how they consumed FOD content. There were some clear distinctions between the types of users and the types of content they consumed. They had a persona who engaged with written content the most, one who primarily watched videos, and others who just liked to browse photos. While there were also the contributors of original content, we decided early on that this mobile app wasn’t to be used as a tool for them to submit and manage their content.
Regardless of these distinct personas, the business goal was still the same across the board. We knew from personal experience as content consumers and users of rich media apps some of the tricks a techniques for increased engagement. The first trick is to provide great content, and FOD had no shortage of great content.
Another trick was to provide that content endlessly, a la Instagram, Twitter, *Tinder, etc. The last trick was making access to the content as easy as possible through smart architecture and navigation.
FOD has tons of great content, and a mostly unstructured taxonomy, which could lead to some architectural challenges. I instinctively knew that the architecture needed to be as simple as possible if users were going to able to navigate the app easily.
Working with the PM at the whiteboard, we worked out the idea of limiting the content categories to a few high-level verticals. Deciding on those verticals could be done through A/B testing, and/or looking at existing data on the most popular content streams in the current site.
Limiting the content to a few verticals had another advantage, it would make navigating easy. Each vertical could have endless content (and infinite scrolling), and the next vertical could be accessed by swiping left or right. We could also add in some UI mechanism for jumping quickly to a vertical. Of course, we would have a search tool for users trying to find something in particular.
To keep users continuously engaged with content required removing as many barriers to accessing content, such as limiting the number of taps it took to get to the content. An idea I came up with was to keep the users in the vertical until they chose to leave it. So if a user was to tap on an item of content to view it, the item would expand in place. If it was an article, at the end of the article, the user would see the items that were originally below that article before they tapped on it. It would be as though they never left the vertical. This would negate the need for the user to have to ever go “back” and instead always go forward.
Navigating the verticals would be as easy as swiping left or right. Or, users could jump to a vertical by opening the menu. The first concept for this was to make the header at the top the menu. We discovered through user testing that this concept wasn’t immediately obvious to users, and in the end, a more straightforward solution was employed (see last wireframe).
To validate our assumptions and observations from user testing, tracking was added to key components of the app. Some elements were re-tooled, but only minimally. One of the biggest changes was to the concept of items opening (expanding) in place. For the sake of speeding up development, the decision was made to use native device flows when transitioning to content. But the idea of showing additional infinite content below the item selected was preserved.