Seen's onboarding flow at the time


In our calls with users, we looked for reasons behind lower retention rates after day seven. We found that a primary issue were with users who were invited to the app rather than users who had been onboarded in a meeting with me and Faheem (a cofounder of Seen).

Our app's onboarding process involves one screen where users accept all permissions. We found that users felt suprised that their reactions were recorded when joining the app. Likely, when they were accepting the permissions for the app, they did not register the implication or purpose of the app.


☹︎ Users feel too much pressure sending a video message

☹︎ Users who have not been on boarded do not understand how to use the app or what the use case is

☹︎ Users do not know who to invite to the app

☹︎ Users feel like they should not send another message when they have sent the last message

Research & Steps

Retro's onboarding flow
Looking through the onboarding flows of the most notable social apps (Snapchat, Instagram, and Titkok), I noticed a straightforward method of "giving the user a use case/instruction" while onboarding.

But looking at more emerging social media apps (Retro and Bereal, for example) there is a more intentional onboarding flow--one that convinces you to use the app in a more psychological, anti-social media way. As Seen is more aligned with these ideas and battling in a smaller fish pond, I opted in for a more immersive experience while onboarding. As we had trouble with our users actually reading through permissions, I design screens to set Seen as an app with 'new social norms' which are read while you enter the app.

The process for these designs involved the following brainstorming slidedeck.
BeReals from my friends which fit the "vibe" Seen was going for

Brainstorm & Prototype

Design Breakdown

The goal of this onboarding flow was to introduce the app's use case and a unique "vibe." General goals included decreasing the pressure of sending a message (especially, sending a second video message after you have not received a response) and introducing the social use case for the app: something for you and your close friends. 

The app opens up to a casual seen in the background along with reactions which bounce on the screen when you shake the app. Both the bouncing reactions and the button which says "let's play" build on the app's playfulness. The background video is meant to show a user what type of content they should see on the app (low effort and frequent). Rather than an drawn icon, I felt it was most important to have real people, as that is the main purpose of the app, seeing your friends.

I chose to replace the permissions section for the app into rules which used visuals and interactive features to get users prepared to enter the app. The first rule is to "get comfortable," which is paired with the camera permission. Since users often felt surprised by the camera when entering the app, I felt it would be best to have users to register a front-facing camera in a low-commitment setting.
Often, we'd hear worries from invited users about who is on the receiving end of the message they're recording (ie. "is it like a public post? or is it something that is send to all your contacts in your app?") To clarify this, I added the rule "Close friends, only" as users allowed access to their contacts.

When you compare this screen to the previous "1. Get Comfortable," you will notice that the action buttons are on different areas of the screen. This is so that it becomes more difficult for a user to skip through reading the instructions by spamming the buttons.

Also, the idea of "close friends, only" draws from BeReal's initial marketing. As a general trend we found users who stopped using Instagram and BeReal left because too many people they followed were people they didn't actually care about (ie. acquaintances and content creators). This is especially important for our branding as it decreases the pressure of filming a video as you no longer need to worry about the way you look when sending a video to a close friend.
The final rule before users create a username and profile is "3. Send a message to see your friends." This introduces a "why" for sending a message as well as why for enabling notifications. As users felt like they shouldn't send a message unless they received one, I wanted to reframe it as a way to see your friend regardless of whether they respond (since, their reaction is sent when they open your message).

Especially since this permission requested users to enable notifications, I wanted them to draw a direct connection between enabling notifications and seeing their friends. In both this screen and the previous, we'd get the photos of friends from their contact photos.