March 11, 2017
This is a continuation of designing a new podcast application. You can read Part 1 here and Part 2 here, Part 3 here and Part 4 here. This post goes over the theoretical exercise of designing and developing a set of A/B tests in order to improve the interface.
The Play Button
The image on the left displays the current home screen. During a user testing session (here) I received feedback from a few users regarding the play buttons next to the episodes being redundant. In order to better understand whether its important or not, I propose running an A/B test once a functional prototype is available. This can be done by providing a subset of user the left screen in the application and the other subset the right screen. The aim of the test would be to track how often a user clicks on the episode tile and where exactly on the cell does the user tap. This would be recorded for both versions. According to my expectations, if the play button does indeed add a useful trigger for users, we would see more people clicking the cell either on the play button or close to it. On the opposite I would assume that without the play button we would see more diverse locations where the users tap. If on the other hand the play button is indeed redundant, we should not see distinction is patterns between the two designs.
Home Screen (Episodes vs Podcasts)
Another important experiment to run would be to figure whether to display podcasts, episodes or both on the home page. Some of the feedback I received from potential users stated that the current home screen (left) looks too crowded. In order to fix it, I could potentially add more white space between the podcasts covers. I think that its more important to understand if we even need two separate ways to display the podcasts. Maybe majority of the users would rather just have podcasts on the main screen and further drill down to its episodes. That being said, I am not entirely sure what the results for such a test would be and thus this is an important experiment. This can be done even before implementation but I would still potentially like to run this test in a functional prototype to see the use cases we get.
Feedback/Reviews
Most application developers face the issue on how to receive feedback or reviews for their applications. Some developers hide the option in settings while some to keep popping up an alert view in order to get feedback. Each implementation has some positive and negative benefits. Using multiple alert views could get more people to send feedback or leave a review but it could also have a negative impact on other users. What I propose is having the option to send feedback in the settings screen but using a small proportion of the user base in order to test different times to display a single alert view asking for feedback. The aim would to be figure out when the best time would be to pop up an alert view to get the highest amount of participation from users but with the condition that the alert view is only shown once during the applications lifetime.
February 23, 2017