Rapid Prototyping: a news app for the forgetful
UXDi — Project 1
The challenge: Research, prototype, and test a news aggregator app.
In just four days.
Going into this assignment, I had some initial reservations about developing a news aggregator, being that I’m very passive about my news. (I tend to let the bigger headlines come to me via social media.) However, this served as a crucial reminder that as UX Designers, we are not the user.
With that in mind, I was excited to explore and learn just how do people digitally interact with news, and what could I do to help people do it better?
Research
To discover current behaviors with news apps, I set out to conduct some user interviews.
When developing the set of questions I would ask my users, I wanted to cast a wide net to get a better sense of context. So, I conducted interviews with 5 of my UXDi peers and asked them a series of questions such as:
- How are you typically exposed to current events?
- When do you read up on current events?
- Where are you checking out the news?
- What kinds of topics interest you?

The responses I received were all over the map. Many users relied on social media posts to stay informed (like me) while others took advantage of notifications from dedicated news apps. Some users caught up on events while commuting, others while relaxing at home. Some loved sharing content online, others preferred privacy.
When looking at this data, I noticed a few thematic behaviors.
- Users get their news from both passive and active sources.
- Users don’t like working too hard to find news/information they want.
- Users actively engage with news if it interests them.
- Users control when they engage with news.
The first setback
At this point, I saw that I had failed to identify a problem. My interview questions didn’t facilitate discussions that got users thinking about or expressing their pain points.
Yikes. How was I supposed to narrow this down?

I took a step back and, after sleeping on it, considered the vague user I had in mind:
a semi-engaged, moderately informed, very idiosyncratic user who is mostly happy with their level of engagement; they read what they want, when they want to
If an engaged user is happy, the question then becomes: what happens when their engagement is disrupted?
Finally! Something to investigate!
I re-interviewed my participants with a simple question:
What do you do with articles you want to save for later?
“I usually open tab in the mobile browser & leave it there forever. It makes me really sad because on Facebook, links opens inside the app and there’s no way to save it.”
“There’s a save button in my app for something I would leave for a later time. It’s a tab on the side. You have to go directly to it to access them.”
“I text them to myself, I don’t know how to use bookmarks very well. I always want to read it but I never get to it.”
The pain point practically jumped out at me:
Users often find their own ways of saving articles for later, but will not actually go back and actually read them.
Eureka!
The Idea
With a pain point and design goal clearly identified, I now had an app to sketch out and develop.
Design Goal: To create an app capable of sending a user their saved articles via text or email at a time more convenient to them.
In theory, if a user knows they’ll have time to catch up on the day at home, they could set a text reminder for 7pm. Or, if they’d like to catch up on missed articles during an NJ Transit ride, they could trigger the reminder email to be delivered at 8am. All links assigned to a user’s set time would be combined into single text/email.
To begin sketching out this interaction, I established a very basic user flow and submitted it for peer review via a pin-up session.

Right off the bat, my peers expressed similar concerns to my own: What do the articles look like? Where will the news be pulled from? What do the reminder texts and emails look like? How do you select for interest? Can you bookmark articles? Where can you view your saved pieces? Can you add a second reminder option?
All of this feedback was valid, and I must admit, it caused me to wrestle with the issue of scope creep. How much of this feedback could I address? How focused should I be on one feature vs. the bigger context?
The Dream App
In my mind, the user would be able to log into their social media feeds, select their preferred trusted news outlets (ex: NY Times, CNN, The Guardian, etc.), set their favorite categories, and an algorithm would populate articles based on some some sort of importance/frequency score. There would be a share function, of course, as well as additional bookmarking or exporting features.
The Reality
This project was designed to move fast. We had four days in total from start to finish. My instinct, as a recovering perfectionist, was to focus on the feedback I received on the app’s principle “save for later” feature.
Prototyping
When moving into the prototyping phase, I drafted modular paper prototypes and loaded them into the POP prototyping app. (What a fun tool!)
I was surprised by how many additional screens I had to account for to deliver a more natural flow to the user’s process.

Once I was confident the app had a smooth enough interaction, I took to user testing. When testing, I asked users to complete a series of tasks:
- Identify the article they want to save for later
- Trigger the reminder prompt (via swipe gesture)
- Successfully set the reminder
- Navigate between the saved articles list and the home screen
Being able to test this with paper/POP turned out to be a huge advantage. It didn’t take long to adjust and modify my prototype as needed. When I would notice users struggle on a task I was able to quickly go back and adjust the interaction within POP.
What Worked Well
I was pleased with the positive feedback on the reminder dialogue as well as the confirmation screens. Users expressed pleasant surprise that it was so straight forward. Users were also able to navigate well within the limited functionality of the prototype.
What Needs Work
Some iconography was unclear. There is an “X” button meant to remove an article from the feed that was misinterpreted as a cancel command. The swipe gesture was also not intuitive; users assumed they would have to tap an article to introduce the “save” feature. In retrospect, I could have added a sample article screen triggered by a tap to inform the user’s initial interactions with the app.
Next Steps
I’d love to be able to refine some of the visual aspects of this project such as the icons, as well as developing out more of the app’s native functionality; what it feels like to read an article, how to on-board user preferences, and how to cancel a reminder.
Additionally, in retrospect there are some branding issues with the app which I chose to name “Ricochet.” I intended to allude to an object reaching multiple points of contact but I realize this might have unpleasant connotations when dealing with current events (…oops).
If I were to develop this concept further I would certainly want a lighter tone to account for the branding humor I had in mind (see bonus links below).
Resources & Links
Clickable Prototype:
https://popapp.in/w/projects/57194a20d0819bd218d1e9d6/preview
Interview Transcripts:
http://samverdure.com/files/p1-interviews.pdf
Bonus Sketch:
Sample Text/Email:
http://samverdure.com/files/p1-reminder-sketches.PNG