End of Scroll Design

When:

Summer 2019 for Western Digital Internship

My Role:

Lead UX Design/Research

Skills Used:

User research/interviews

Interactive Prototyping

Competitive Analysis

Ideation/Wireframing

Use cases

Tools Used:

Figma

InVision

Usertesting.com

Background

ibi is a product that allows consumers to collaboratively store photos on a physical hard drive and access their photos remotely via the internet through the ibi app. In other words, it's like a little personal cloud that a close group of friends or family share.

In an era of privacy concerns regarding data harvesting from cloud platforms, I was excited to work on ibi because it was a refreshing take on data ownership and intriguing because having a hardware component that a user could 'own' made the ecosystem feel more secure. This summer I interned at Western Digital to design part of the app.

The existing ibi app is predominately separated into three main tabs and each tab is a vertical scrolling list, as shown below:

Tab 1: Inner Circle

Newsfeed

Tab 2: List of All Photos Stored

Tab 3: List of All Photo Albums

The Challenge

The main interactivity of each tab is scrolling. What happens at the end of each tab? I was asked to propose a design for the end of each scrolling list which initially seemed like a simple task but, upon lots of user research and usability testing, became a design opportunity to assist users in understanding the ibi ecosystem.

Vertical Scrolling is an Integral Interaction to the ibi App Experience

Background Research

Existing User Research Says The ibi Ecosystem is a Very Confusing FTUE

An ecosystem like ibi is fairly unique in the marketplace because it combines social media (users on the device could post photos to the 'inner circle' newsfeed) with storage (everyone on the device shares storage space) with a physical hard drive. We knew from previous research that that the FTUE of ibi for new users was extremely confusing. People didn't understand the app until quite some time exploring it, and our quantitative data showed that only a fraction of the features were being used. To make things even more complicated, we were partially targeting a group of users we called 'non-techies' who are less familiar with technology. This confusion about ibi was actually quite a large problem.

Target Users

Designing for a Population of Non-Techies

I sat down and did a couple of expert interviews with the Lead Product Manager and Head Designer to figure out who the target users for the product were from a business perspective. By and large, the imagined target consumer for ibi was a parent in a household who wished to collaboratively store photos with their family members but was considered a 'non-techie' who doesn't really care to know what the cloud is and prefers something tangible. Once the item was purchased by the target consumer, the users could be anyone in the family, but from the quantitative data the product team informed me that usually only one person was on the device (presumably the person who purchased it). Based on user interviews conducted for another part of the app, I filled in the persona, but also later recommended that more personas should be created for other family members:

Description: Parent of a family who wants to treasure family moments together. She uses technology casually but doesn't care to understand how it all works. Children might be either teenagers or already in college and this parent wishes to keep in contact with their family across distance.

Age: 45+

Location: Suburb of a large city

Frustrations: 

-Doesn't want to deal with complicated apps

-Is not familiar with and does not want to deal with the cloud

-Feeling out of touch with her family and lacking personal connections

Goals:

-Feel closer to family, in-the-know about their lives

-Separate space to share with family outside of social media

-Keep memories in a safe and secure location

Tasks:

-Keep in contact with family either through messages or photos/videos

-Wants to see micro-interactions between family members

UX Competitive Analysis

The End-of-Scroll Design for a Short List Might Be Different Than for a Long List

Because I've never thought about the end of a list feature before, I decided to start out with some UX competitive analysis of the existing market because, hey, there are a lot of talented senior UX designers who have dealt with this problem before and I needed some inspiration! That being said, I used this method with caution because I wasn't looking to 'copy' a design just because someone more senior had done it for a different app.

I compared many different apps and mobile experiences that contained vertical lists and analyzed why they might have decided on that type of design. I grouped the approaches into 7 'buckets' ranging from simply ending the list to providing some kind of animation upon reaching the end. I then further culled out the examples whose app had a similar function to ibi. Two approaches made the most sense for ibi:

01  "Simple Stop"

As the name might apply, this design simply stops the user from being able to scroll beyond the end of the list. This design was mostly found in cloud storage apps like Google Drive. This makes sense - reaching the end of the list clearly signals to the user that there are no more files.

02  "Add More Content!"

Other the other hand, social media apps took advantage of a design opportunity for when the content feed (lists) were short; when a new user did not add enough 'friends' to produce a long newsfeed and reached the bottom, all social media apps found some way to encourage the user to add more 'friends' to secure more content. Of course, this behavior disappeared or was unreachable when sufficient content was added and the list became too long.

Design Opportunity! The only time a user would encounter the end of a list is when there isn't much content yet to fill the list - in other words, there's a high chance they might be a new user and we previously established that new users generally experience confusion about ibi

At this point I've decided to narrow the scope to the experience for short lists, because it doesn't really matter when the list gets really long (user uploads 5000 photos) because users will never reasonably reach the end of the list. And I'm excited because I think there's an opportunity here to use the end of the list to help explain the ibi ecosystem - but first I need to observe how people interact with the app if they are confused.

User Interviews and Usability Testing

Finding: First Time Users Scroll to the Bottom to Gain Understanding of Each Tab

Before I started designing ANYTHING, I wanted to understand the points of confusion people had when opening ibi for the first time. I built a prototype of the existing app, developed an interview proposal and protocol, and ran it through some live remote testing on UserTesting.com. The format was generally a semi-structured interview followed by an unstructured think-aloud process as the users explored the prototype. In the prototype, I also included the on-boarding steps and included a link to the website so that they would see most of the promotional content that might help explain what ibi is.

4

remote live

interviews

Most significant finding:

Every single participant scrolled down as far as possible on all three tabs when trying to understand the app, indicating that the end of the list might be a good place to provide some additional insight

Findings related to Inner Circle Tab:

1) Participants thought that anyone could invite people to the ibi inner circle (the people who share ibi device) when in reality, only the owner can

2) It wasn't clear what the relationship of this tab was to the My Photos tab

Findings related to 'My Photos' Tab:

1) The fact that ibi photos they upload were being stored on the physical ibi hard drive was forgotten or not understood, even though I had shown them pictures of the device beforehand. This effect was also observed during live in-person testing before I joined the team. This is important because the physicality of the storage device was an important security feature to some users.

2) It was not clear to users who could see photos that they uploaded to ibi and that their uploaded photos were private. Many assumed that if they were invited to the ibi that was purchased by someone else, the ibi owner could see their data.

3) It was not clear that the ibi storage space was a shared space

Findings related to 'My Albums' Tab:

1) What 'shared' album meant was confusing to users - shared with who? 

Journey Mapping of Existing Design

End of List is a Design Opportunity to Clarify Confusion

The Solution

Goal: Reduce Confusion About ibi by Providing Guidance if Desired

I wanted to take advantage of people's natural tendency to scroll to the bottom of a list when trying to understand an app. So I approach this in two ways. 

01

First, I design UX copy at the end of the list (indicated in red below) that might address some common points of confusion. The text is clickable and clicking on it will take you to an overlay with an in-context coach mark.

This was an exercise in UX writing! At this point, I'm not too worried about visual design beyond trying to find something that is enticing for the user to click on. I tried using approach language such as "Hey, what's an inner circle?" instead of your classic FAQ style terminology. Plus, I figured I had a shot at mirroring the kind of questions the user was asking themselves in their heads. I tried several iterations including profile photos of the people on the ibi, iconography, and plain text. I've included some below...

I also tried several iterations of the coach mark style. This was again both UX design and writing exercise - keeping the amount of text succinct while conveying the most useful information was a challenge. 

02

The second part of my design... I note that the existing app has a floating action button that collapses when you scroll down. In my proposal, I recommend to re-expand the FAB upon reaching the bottom of the list to create an elegant way of signaling the end by 'capping' the experience and also to help re-enforce one of the primary features (floating action button) of the tab.

Scroll start

Scroll mid

Scroll end

A quick prototype - please ignore the fact that the collapsing/expanding animation is not smooth! :)

User Flow

Usability Testing - Testing the Design

Finding: It works! But only if the UX writing is perfect.

I built a second prototype with the new design. I then ran additional user testing/interviews and had participants think aloud when using the new prototype. 

3

remote live

interviews

Most significant finding:

The design largely reduced common points of confusion observed in the first round of testing. People clicked on the helper text mostly when the text exactly mirrored a point of confusion they were thinking already - so it is important to really nail the UX writing.

"Okay I'm looking through the photos here and I'm wondering if these are photos I own... oh actually, why don't we just click this button that says 'Who can see these photos? *reads text* Well there you go, these are my private photos."

Additional Findings:

1) If the helper text is something that seems REALLY perfunctory, like "how do I share a photo," that loses the interest of the user very quickly. It's the conceptual, meatier questions that engage users... so long as they're bite sized.

2) All participants said that the amount of wording present on the coach marks was fine especially since they actively sought out the help rather than the app forcing unwanted help on them

3) People were more likely to click on a second helper text immediately if they found the first one useful

4) There were still some lingering confusions regarding data storage, so I set out to address them more clearly in the final version.

Final Design and Specifications

Cross Collaboration with Engineering

I made some final tweaks like bolding key words in the coach mark texts. When I re-ran the prototype testing informally, the bolded words seemed to help users quickly identify the gist of the message. Once I made these edits I made a graphical specification guide for engineering and a final prototype for clarity:

Lessons Learned

1. For certain interviewing situations, it's best to get real users who have bought and owned the device. I had to ask for a lot of imagination from the interview participants and I'm not sure if it skewed the data. I should also use a tighter screener for participants.

2. I should rely more on the people who have been designing this product for a long time, and ask questions about their understanding of the users.

3. I can't address everything at once. The amount confusion people had is probably a symptom of a larger problem unrelated to the scrolling feature (maybe marketing), but I did what I could to address it in a location that made sense.

4. ALWAYS CONSIDER CROSS-DEVICE DESIGNS. I completely forgot about the tablet version and did not include in the original specifications for the engineers.

Copyright © 2019, Julia Park

julia.park@berkeley.edu