Twitter Concept: Flutter through Timelines
I use Twitter. A lot. But that didn’t use to be the case, for it was only recently that I grew to love the app and actually enjoy using it. My friends have gone through the same thing, they didn’t like it at first, but then at some point, they just grew to use it every day.
So why do people either use Twitter all the time or never at all?
To answer this question I launched a full federal investigation into why and how people use Twitter.
I started as one does with user interviews. From my very thorough interviews, I came out with these main takeaways.
The biggest issue is hesitancy. Users really only follow their friends and not many others outside of their known circles. There are many reasons for this — familiarity, a want for a good “ratio” of follower to following, a lack of desire to explore outside sources for content.
The biggest issue is that users still get bored and don’t want to actually go look for new content, they’d much rather log off for the day. With my handy dandy research, I came up with my people problem.
The Problem
Twitter provides interesting content based on the user’s following data, however, the experience of daily use is often stilted and the user’s cannot explore other, similar content they may enjoy because the timeline is:
1. dependent on who you follow
2. difficult to follow accounts without a background sense of familiarity
The area of interest became the timeline itself. Users showed me that they go on Twitter, scroll through the timeline for the day, and then log off. I had to find a way to keep users on the timeline and have any new content within reach of the timeline itself.
So the next step was to create . . .
Low Fidelity Sketches !
The low-fidelity sketches allowed me to map out what area of the app I wanted to target, but it did not allow me to fully understand how users would interact with it. So onto the next area: user testing from more exploratory prototypes.
These tests provided me with the information I needed, and then it was time to make high-fidelity prototypes. With the help of my UI Kit, I created medium-fidelity prototypes that attempted at a design that felt native to Twitter.
The beauty of a medium-fidelity design is that you can immediately discard it if it doesn’t fit. I did this with many of my other flows, because they’re exploratory, they’re meant to be reconfigured and redesigned.
My medium-fidelity iterations needed work, so I went back and reworked them until they felt genuine and appeared as a feature that I’d actually want to use.
Below is the final prototype I made. It shows the interactions that I created based on user feedback and after iterating through many ideas. The main takeaway I want users is that the timeline is dependent on them, but not taxing.
I wanted to give users agency over their timeline in a way that felt refreshing and allowed them to input as much as they wanted. Twitter is a place to find information quickly and concisely, so our timelines should give us this info in the same manner as the Tweets themselves.
Reflections
I definitely know a lot more about Twitter than I ever thought I could.
I realized how many features are in a single app that users just don’t know about. The course provided me with the procedures but most importantly with a design mindset. Ideas come and go and the iterative process allows you to grow and create the best designs you possibly can. It was because of the rapid ideation period that I could take in new user feedback and create a final design that felt catered towards my intended recipients.
Thank you to the App Dev team, especially my TAs Gracie and Angela, my crit group and all of my user studies!
This case study was part of Intro to Digital Product Design at Cornell University. I am not affiliated with Twitter in any way.
