Background
My team (Greyson Gerhard-Young, Nick Diaz) and I were tasked with creating an interface for an existing startup without actually looking at their existing. It allowed us to really think about the company’s who, what, and why.
The startup we chose, Listle, aims to make articles easily available in an audio format. They consolidate a wide array of stories and then convert them into podcasts.
before starting—who are we designing for?
We believe news companies will be directly impacted by Listle, since we are providing a platform for their content. This will increase the reach of their stories, but might also negatively impact their platform’s usage. Writers will also be directly impacted, as Listle provides a new medium for the public to consume their content.
Podcast creators would be indirectly impacted since Listle represents competition in the market for audio content. If Listle became successful, it’s likely the value of similar podcasting work would decrease.
In order to ethically address these issues, we would love to incorporate podcasts onto our platform (either in their own section or alongside articles pertaining to similar topics). Additionally, we want to partner with news companies to ensure that their content is being diffused in a manner they find acceptable.
prototyping
When starting to brainstorm for our initial sketches, we knew that we wanted to combine an audio-streaming interface with a news interface. So, in our four sets of sketches, we tried to think about Listle in the context of Spotify, NPR, and CNN. In our third set, we implemented our own feature, Debrief, that would allow listeners to be filled in on one specific topic from start to end. This feature combined both the audio and news aspects of Listle’s to create a beneficial product for users.
For our hi-fidelity prototype that we presented to the class, we decided to keep the Debrief feature and synthesize elements of Spotify, CNN, and NPR into our prototype. A lot of the feedback we got back from the critique session was centered on what exactly the Debrief section meant, more uniformity and clarity in the Navigation bar, and wording. In our final prototype, we ameliorated these concerns by bringing back the description of the Debrief section we had in our initial sketches and making that screen even more clearer, highlighting the nav bar according to what page you are on, and changing out ambiguous wording. We also added more individual controls to each page to more efficiently model the flows according to each different stage of interacting with the prototype.
I’ve linked our final prototype and included screenshots below.
The homepage
Our added Debrief Feature
Play mode
user testing—hypothesizing
To analyze the learnability, usability, and memorability of our interface, we put it to the test on User Testing.
We gave users the task of choosing a trending story, playing it, and then adding it to their saved articles. We then want them to explore debrief and add another story to their saved articles.
We predicted that the average time for a user to add a second article would be significantly less than for their first article since they’d be more acclimated to the process. We also hypothesized that the error count during the stage of transition between the first saved article and the navigation to explore would be higher than any other stage of the task.
results
We weren’t correct that users were significantly faster at adding a saved story the second time, but this was mainly due to how easy the process was in the first place. There were no errors for either subtask, and the time difference is essentially due to user error.
Our second hypothesis was correct, the transition between the initial saved story and the debrief section had by far the largest error count. A large portion of these errors were a technical bug (inability to click on a debrief heading), but plenty of others occurred: inability to scroll, essentially clicking on icons at random until arriving on the proper page.
Users were generally satisfied with the experience and understood the purpose of the application. They enjoyed how easy it was to add stories to their library, and were eager to explore new features.
converging
One of the biggest issues throughout user testing was the transition between saving a song and navigating to other sections of the application. We believe this is an important efficiency issue, and one that could be addressed with a simple solution: adding additional hyperlinks on that stories page. Users also continuously struggled to figure out which icon linked to the debrief section. A subsequent prototype would confront this problem by providing a more clear link between the symbol that represents that section and a user’s mental model of a news feed.
It was hard to strike a balance both providing users with explicit instructions/relevant information and also simulating an authentic experience where they wouldn’t have a ton of information. There were also some difficulties in collecting exact time values on each task since users would often incorrectly click through sections and then stop to discuss their rationales.
One convenient aspect of the process was the detailed video recordings, which allowed us to actually understand decision context. For example, users were able to explain that they found the process of saving a story convenient since they had an internal mental model that mapped that icon to favorites.
For future iterations, we learned that it’s important to thoroughly ensure functionality before deploying a prototype to be tested. While it’s helpful that users dislike an unclickable button, it would have been preferable to observe them in a more natural navigation process (since many people seem to have a tendency to get overly focused on a single issue).