Twitter’s design team is famously open about their process and thinking. It’s fascinating to observe as they work through updating and improving their applications to make them more appealing to a large and diverse group of people engaging on different platforms contexts. The degree to which they’ve succeeded is impressive, but that’s not to say that every decision makes sense to an end user. Particularly, without the benefit of having been a part of the research, observation, and iteration that led to it.Based on my understanding of the vision driving Twitter, the ability of a user to follow and be followed by other users is second in importance only to the user’s ability to send tweets. Without the concept of following, Twitter devolves into a mob of people shouting at each other.That’s why I was surprised by the design team’s decision to hide the Follow button while scrolling through another user’s timeline on Android and iOS devices (web maintains the button’s visibility). Depending on the height of the user’s device and the length of the most recent tweets, a mobile user will typically be able to read around three (but as few as one) tweets before scrolling the Follow button off the top of the screen.
Current review and follow interaction with disappearing Follow button
Experience Failure?
Do one to three tweets provide enough information to make a decision on whether to follow another user? In some cases, yes. Personally, and for a handful of other users I asked during an informal research session (details below), the answer is no. During that research session, three general follow scenarios emerged:
- “A friend recommended that I follow a particular user, so I am going to follow him or her. This includes public figures, friends of friends, etc.”
- “An unfollowed user has come to my attention via a single retweet or contribution to a trending hashtag.”
- “An unfollowed user has come to my attention via repeated retweets or contributions to trending hashtags over time.”
In scenario 1, the user is not affected by the disappearing Follow button, as the decision to follow has already been made.In scenario 2, given the limited insight into the unfollowed user’s tweeting habits, the potential follower is interested in discovering both quality of tweets and approximate volume of tweeting.In scenario 3, a perception of consistent quality already exists, so the potential follower is nearly committed to following (similar to scenario 1) but still may have questions about quality and volume. This desire to learn more coupled with limited viewable tweets on a mobile screen means that scrolling through the timeline is likely before a decision to follow is made. If the potential follower scrolls 10, 20, 50 tweets down before deciding to follow, he or she must subsequently remember that the follow button exists, remember where it is (after potentially trying to discover it somewhere on-screen), and then scroll back to the top of the profile before again locating and tapping the Follow button. That’s significant thinking and interaction between decision and action, and ample opportunity for an experience failure.
Reaching out
Given the insights gained from my personal use patterns and informal research, I assume the decision to scroll the Follow button away was explicit and arrived at after extensive research, observation, and testing, which serves only to further pique my interest. Curious, I tweeted @design, Twitter’s in-house design team’s account.
Yo @design - Curious as to the thinking behind not keeping the Follow button visible when the user scrolls down the mobile timeline— Dante Passera (@dantepassera) June 8, 2015
In spite of the one whole favorite that tweet earned, I never heard back from Twitter. I’m almost glad I didn’t though, because it’s given me an opportunity to conduct informal and rapid testing on potential improvements to a discrete piece of UI functionality in an existing project.To reiterate, this is not a takedown. As a creative professional, I understand the competing interests that lead to the ultimate implementation of a design. There is a reason that the Follow button scrolls off the screen. Since I wasn’t a part of that initial design process, however, I can’t speculate on what it might be. Instead, I’ll present three options for making sure the Follow button is immediately accessible at the moment of decision to follow, while disrupting the current UI as little as possible.
Validating Potential Need For Improvement
Now that I was about to embark upon a course of prototyping and testing, I wanted to verify my assumptions about the difficulty in executing a follow action. To that end, I created a Pixate prototype based on the current Twitter Android app, presented it to a group of eight web-only Twitter users, and had them execute the following task:
“Decide to follow and then follow this profile”
Six of eight users scrolled before attempting to follow. Of those,
- Three scrolled back to the top and tapped Follow
- Two scrolled down, tapped the overflow menu, closed the overflow menus, scrolled back to the top and tapped Follow
- One scrolled down, tapped the user name and exited the profile, returned to the profile, and tapped Follow
User exhibits desired behavior
User searches in overflow for follow button
User guesses incorrectly at functionality
While each user was able to discover how to follow, there was substantial pausing to review and consider options, as seen in the test videos, as well as one instance of a “catastrophic” action - exiting the profile.
Creating and Testing Potential Solutions
Based on these observations and my own instincts, I created the three following Pixate prototypes, each with the benefit of not requiring a scroll reset to follow, and each with unique perceived pros and cons:
Option 1: Display Follow/Unfollow in action bar on scroll
Pro: Persistent display of Follow button and status; Spatial connection with original follow button; Highly visible; Consistent with action bar and follow button styling
Con: Adds visual complication to action bar; Displays screen-level action adjacent to and in same style of app-level action (Twitter search)
Option 2: Replace action bar tweet count with Follow/Unfollow on scroll
Pro: Persistent display of Follow button and status; Clear spatial association between name and follow status; Removes confusing history back action from name interaction
Con: Spatially disconnected from original follow button; Visually distinct from original follow button; Requires discovery of purpose
Option 3: Display Follow/Unfollow in overflow menu
Con: Further complicates overflow menu; Requires discovery of existence
These prototypes, along with the original stock prototype, were tested with six of the eight original web-only users and 11 mobile-primary users. Because of the limited time available and informal nature of this test session, I again presented the users with a single, simple task to be executed on each of the four prototypes:
“Read enough tweets to decide to follow and then follow this profile”
Each user was then asked which version allowed them to most easily complete the above task, and only two indicated the current approach (scrolling up to Follow). Of the rest,
- 12 stated a preference for option 1 (Follow button in actionbar)
- 3 preferred option 2 (Action bar tweet count replaced by Follow button)
- 0 preferred option 3 (Follow button in overflow)
What’s more, no confusion was observed when engaging with option 1, as Follow actions immediately following cessation of scrolling. With option 2, some users still scrolled back to the original Follow button, and only one user found the overflow Follow button in option 3 before scrolling back to the original Follow button.
Recommendation
Based on the feedback gathered from observation, conversation, and my own experience and instincts, adding a Follow button to the action bar on scroll is the clearly preferred method of handling non-immediate following. This also appears to be the option least disruptive to the UI, especially given my lack of direct knowledge of the research, business goals, etc. that helped to determine the current design, and the easiest for the development team to implement.I personally like some aspects of option 2 as I find the tweet count by itself lacking in useful or actionable information. Also, breaking up that history back button would reduce the number of unexpected returns to the main timeline. That option, however, has its own issues related to visibility and button consistency. Option 3 is the quickest of quick fixes and should be used only as a stop-gap measure, if at all.
Hunting For Deeper Meaning
I’m confident in the above recommendation as a solution to the discrete issue of the disappearing Follow button but, again, am intensely curious as to the thinking and requirements that led to the UI’s current behavior. Looked at in a vacuum, just about any design decision can be second guessed, and the maturity of a designer or design team can be measured by its ability to accept a superficial design flaw in service to a deeper design or business goal.If @design or anyone else has additional insight into this aspect of the UI or would like to point out something blatantly obvious that I missed, I’d love to continue the conversation on Twitter or in the comments below.Cover photo by mkhmarketing.
