Long and Short
A retrospective of Project One, UXDI
In my first project of the UX Design Immersive, I was tasked with the creation of a news aggregator app. Through research and testing, I discovered that people have difficulty finding relevant news that fits their schedule. The following is a detailed review of the process I followed to arrive at Long and Short, a news app that separates curated news into separate feeds based on read time.
With little personal experience using aggregators, I was uniquely poised to address research and ideation with an open mind, and imagine a solution that doesn’t already fit the mold. I interview six people, some users of aggregators, some not.
Asking a series of five questions, I attempted to identify common points of frustration, but was struck instead by the surprising variety of ways in which people engage with the news.
“It’s important I get it done quickly so I can keep moving”
“I wouldn’t mind taking longer to read, because my commute is really long.”
“In one sitting I read for two to five minutes. Sometimes less than one minute. Sometimes more than fifteeen.”
Differences in news consumption didn’t just vary in time spent, but also times of day, locations, preferred medium, preferred content, and perhaps most telling, what the news meant to people. It started to become clear that, above all, news consumption is a very personal activity.
One issue that arose during the research phase had its basis in this variety. Though my questions began as open-ended probes, once I identified a few pain points from users, my inclination with subsequent users was to attempt to confirm that they had similar problems. This may have lead me to inject a bias into my questions, though I tried my best to remain as objective as possible.
There’s an interesting balance between allowing a participant’s answers to stand for themselves, and offering suggestions that can help unlock further insights. For example, when asking people to describe their current news consumption experience, I might get a response like, “I’ll check my feed throughout the day, and if something seems interesting to me I might read it.” If I go a step further and ask them to describe any frustrations they have, a slightly more closed ended questions, they’ll open up much more about the things that annoy them.
“I hate searching for content I think should be in my feed.”
“I don’t like seeing articles of sources I don’t normally gravitate towards.”
“Whatever coding [my app] uses to pull sources, it’s just wrong.”
Sometimes, a little suggestion gets people talking more. Moving forward, I’d like to find ways to remain objective while still getting people to talk. I’m sure this can be done with non-leading questions, but it’s something I need to work on.
After conducting the research, I employed methods like affinity mapping and topic grouping to discover commonalities and differences between users. One of the most effective methods of identifying these threads was to listen to the recorded interviews back to back. Hearing participants express similar problems in different ways unlocked crucial findings, which ultimately lead to my first problem statement and goal for my app.
From identifying and grouping users’ pains, pleasures, and behaviors in context, I noticed something that at first presented an obstacle to me, but soon became the key finding of my research. People’s behavior varied widely around the issue of how much time they had to read the news. Rather than choose one persona and tailor an app to their needs, I saw this as an opportunity to make an inclusive app: one that engaged both short and long article readers.
A full list of key findings.
- Want news that’s tailored to their specific interests
- Make time for short intakes of news, and longer ones depending on time of day
- Often avoid news aggregators for longer content
- Use aggregators for breaking news on the go
- Go to native sources for their favorite publications
- Consume news in various formats: print, video, and audio
With these findings, my first idea was to create an app that solved every problem. I wanted to create an app that would allow users to select their sources, topics of interest, preferred format, and the option to download content for offline consumption. This would of course lead to a severe case of Featuritis, so I decided to simplify.
The core goal of my app became to address the problems of poorly curated content, and unpredictable reading times. To do this, my app would:
- Separate articles into two folders — one for short articles, one for long
- Show reading length data up front
- Allow users to easily tweak content preferences manually and automatically, so they’d know their feed would fit them perfectly.
With these goal in mind, I created a rapid pen and paper prototype of my app. The prototype was meant to highlight the interactions of quickly selecting starting preferences, adjusting article length options, choosing an article, interacting with automatic AI adjustments, and manually inputing content preferences.
Using the paper protoype uploaded in POP app, I conducted usability tests with five participants. Following a set script, I gave users the scenario that they were busy urban entrepreneurs, who on a hectic morning want to find a couple good stories they can read while they wait for a train. I employed the hug method using my laptop, and filmed their interactions, recording notes on their comments and difficulties with the interface.
The usability tests revealed much to me about the effectiveness of the app’s concept and layout. Users understood and generally liked the concept of the app, stating on several occasions that it’s an app they would use. The flow of the app was also successful. Users felt like they knew what to do at each juncture, with a couple of notable exceptions.
- Users experienced confusion around how to adjust their content preferences. They wanted to select more preferences up front, and had trouble understanding how the app learned their interests over time.
- They wanted the option to undo/go back on every screen
- They wanted to click on images as if they were icons, because in other places similar images were clickable
Users also suggested that articles be listed in order based on length, and requested a neutral home screen. User feedback enabled me to make a few changes to the prototype before testing one final user.
I eliminated extraneous instances of icon-like images, and changed a bucked icon to a hashtag to avoid confusion with it being a trash bin. I also added a home screen, and rearranged articles based on read time.
Certain limitations of the protoype caused some functionality constraints, but for the most part the app got its message across.
Did I meet my goals?
I believe this initial prototype solved one of the two key problems I identified from my user research. It gave users the ability to quickly choose a grouping of long stories or short ones based on how much time they had.
Where it could be improved is in simplifying the interaction of adjusting content preferences. My attempt to limit time spent choosing content preferences in the initial setup of the app lead to users being uncertain if the app would choose articles appropriate to their needs.
Since one of the main purposes of the app is to ensure users that the app is truly learning their preferences (as opposed to making erroneous guesses based on metadata), the next prototype should somehow make this interaction clear. I think this could be done in the “getting started” screens, but I want to avoid including a lot of written instruction. It should somehow feel more intuitive. A higher fidelity mockup might be enough to clarify this sticking point.
From start to finish, the process of creating an app based on the user’s needs revealed much to me about users, and even more about myself. Moving forward I hope to find ways to remain unbiased in my research and testing, be freer in my sythesis and ideation, and prototype faster and with more abandon.