Case Study: Onboarding Flows

At Droptalk, I enjoyed working through the complex challenges that come with a tightly controlled user base. Intuition and planning are key when you can’t rely on the results of A/B testing; 100 is too small a sample size to be effective.

However, because early users are friends and family—very close friends and family, any data that suggests hesitation represents a glaring red flag. After all, our users had above average patience because they wanted to like the product. (Not to mention that half the time one of us was sitting there, physically walking them through the sign up flow, interface, and features). 

Mixpanel funnels showed us where users were dropping off. 


As you can see, fewer than 10% of users who downloaded the app (either from the Chrome Web Store or iOS App Store, Android is excluded from this analysis) proceeded to the next step, which was filling out new user text fields and clicking the sign up button or connecting through Facebook. (And we thought they were our friends!) 

8/8 users who overcame that massive hurdle were authenticated, indicating they’d entered valid email addresses.

We took a look at the screen users look at during the event labeled “LANDINGVIEW” in the bar graph above.


We tried to map out any and all issues they might have had on this screen that prevented them from proceeding.

1. Couldn’t find call to action button

2. Unwillingness to grant third-party apps access to FB. 

3. Because they don’t want to do FB signup, signing up with email and password is a bad experience. It takes a long time to type email addresses from mobile keyboards and is just annoying in general.

4. We decided to exclude the “repeat password” command many new user fields have to minimize friction. However now it doesn’t look like a new-user screen at all, as this sacrificed clarity.  

5. Users were not delighted by the app’s appearance; left out of sheer disgust.

Now for the solutions.

1. The call to action button should ideally say, in text, “Go” or “Sign up.”

2. Present the user with a clear introduction to the product so he may assess the legitimacy and value, to him. Once he has a willingness to sign up, Facebook will be the quickest option (single tap versus several text fields and confirmation). Most power users, our initial target market segment, are aware of this.

3. Try hierarchical discouragement of email sign up. Make it small, make it a different screen, something. Push them to use FB.

4. Improve clarity between Sign up and Log in.

5. Iterate, iterate. 

After releasing several versions, with steady incremental improvements on Mixpanel, we ended up with this one:


This new sign up screen is the second screen shown to any user. Initially, they will be presented with a 3-part illustrated slider that introduces the product. At any time, the user can choose to log in, or sign up via buttons along a bottom nav. Facebook options present themselves on the second screen. 

This redesign, coupled with overall polish improvements to the iOS product, improved our Mixpanel funnel success ratio—-numbers went from 8/82 to 70/151 in the coming weeks. 

We are still short of achieving the optimal, seamless onboarding experience of our dreams, but we will continue to iterate and experiment to get closer. We are lucky that our user base is small enough that we don’t have to worry about disrupting their experiences.

Architecting an onboarding experience, which was far more complicated than I’ve illustrated here and involved several intermediary steps, marked my transition from a visual designer into an experience designer. As I’ve since learned, the combined forces of data and design can be truly unstoppable :)


Design Process: Desktop Messaging

Problem: Communication is a hassle.

1. Text messaging is more convenient than email, but mobile devices are conducive only to short replies. So they are limited to solving just half the problem.

2. Email has been largely unchanged for the last 20 years. It continues to be disorganized, as mail is organized by time instead of priority. Gmail’s new priority inbox and subject-based inbox features touched upon that problem but did not execute a solution well. Nothing is a bigger drag, stressor, or time suck than email. Nobody looks forward to checking email, so it is most often associated with work, making it a bad choice for casual communication. 

3. Rich media:

  • Photo sharing from mobile is alright, as long as you’ve taken the photos from that device itself. If you have them stored on a repository like Dropbox, you will have to download them to your device first.
  • Video files, because of their size, are a huge issue. iOS prompts users who try to share large videos through messaging to instead post them on YouTube, effectively breaching the separation of public and private domains. You should be able to choose between public and private sharing on your own, not because there’s no logistical solution.
  • Private link sharing: If you don’t want to broadcast on Facebook, or if you want to make sure specific people and only them see something, you could technically use direct messaging. However, only 12% of Facebook users regularly check their inboxes because of a massive flux of event notifications and group activity. Emailing a link takes so much effort (highlighting the link in the address bar, copying, finding your email tab, composing a new message, adding a recipient, pasting the link, typing a subject line or being prompted to agree to not type a subject, sending the link—-and that’s if you’re already logged in and have the recipient’s contact information) that most people don’t even bother with it. Even copying links and sending them through existing messengers removes the user from a workflow.

imageArcane technologies remain the most effective way to send large files. 
Try explaining this to your grandmother. 

The interesting part is the way friction changes a user’s behavior. Once your subconscious is aware that it’s a hassle to send things, the bar for your content is set pretty high. The sender must perceive it to be really funny, really useful, or really relevant to the recipient. That puts some amount of social pressure on the sender, which just adds to the problem. You don’t filter yourself nearly that much when you talk to your friends in person.

Imagine how much information goes unshared, or undiscovered because of this. There’s a treasure trove of knowledge out there that we leave untapped simply because it’s inconvenient to access. 

Improving these could noticeably improve the way people communicate, the basis for all human (read: user) interaction. 


We planned a three-pronged blitzkrieg against “annoying communication.” Really, it was a three-platformed, more effective messaging service. This post is about the desktop version.

Chat hasn’t seen much innovation or evolution since Yahoo Messenger launched in 1998.


The extent of evolution following a decade’s worth of messaging. 

It spread to other platforms, optimized for speed, underwent several design overhauls, but the core functionality and features remain largely the same: send text, photos, emoji, and view online status.   

Existing desktop messengers are either separate applications (e.g. Messages, Google Talk, for OSX) or hosted on specific web pages (Meebo, aim.com, Google Hangouts). Responding to a message requires you to stop what you’re doing and switch apps or switch tabs.

It sounds like it’s just a click’s effort, but the switch from one screen to another takes a huge cognitive toll on your brain. The colors change, you have to move your eyes to a different position and refocus. Ocular disruption, cognitive disruption. If you’re just replying to “hi,” it could be chill, but if you had something to say chances are you’ve forgotten at least part of it. And If you had some external content to share, you are subconsciously aware it’s not worth it.

Since we are building a product around content sharing, this was of particular interest to us. But we believe that as long as people in close proximity can hold a conversation about what they’re looking at, what’s going on in their lives, or what they’re thinking about, it should be possible to do the same from different machines and different locations. We’re already connected. The only thing we need to be working out is ease. With appropriate integration, we could make online communication seamless, and transform the scope of interaction in messaging.

It occurred to us that building a in-browser app, with access to all running tabs (several months before Google Hangouts became a Chrome extension, actually!) would take several steps out of the long sharing process.   

As an extension, it runs in the background of each tab. This ensures two critical points of access:

1. Access for you. It’s convenient, ever present, but tucked away when you don’t need it so it isn’t distracting. It integrates into your workflow, instead of complicating or distracting from it.  

2. Access for the app. With a single click, you can share a web page as you browse. It can access your current web page because it is running on top of it. With a drag and drop, you’ve just sent a photo.


My personal takeaway from this process was learning how to deal with conflicting priorities. Designers must try to achieve a compromise between expedience and intrusiveness, to make the product most convenient for the user. Friction was the problem we’d sought to solve, but if we were too good at guessing what the user wanted to do, it would scare them away. 

For example, having an app that was constantly open may engage users, but it would take up important real estate and intrude. Several other apps introduced sidebars into the browser, and compressed everything else into a smaller part of the screen, but it looked elementally heavy and we wanted to avoid this. 

Plus, if we were always open, we would have to worry more about optimizing for size and keeping it compact at the expense of vital information that should be shown at all times. We wanted to show a list of conversations (similar to a “Buddy list”) as well as the currently open conversation. This would save the hassle we face in mobile messaging, where size is an issue.

We decided that an app that minimized itself and pushed reliable notifications would be only a little less engaging, and a lot more convenient. 

Our initial extension looked like this:


A small tablike button persistently overlaid every web page, in every tab. After much research, we chose a good spot for it: it was unlikely to block anything important here, because nearly every web page had a sidebar. Top nav functions like search or notification bars were generally placed on the upper right.

The beauty of this design was that the extension opened up on hover. You could select a conversation from the left sidebar (grey shaded area) or continue typing into the current message thread. A button just below the text field allowed file upload and single-click link sharing. Whatever page you were on could be shared by a single click, no confirmation required.

Power browsing users could click through a Wikipedia blackhole and be able to, with literal seamlessness, take a friend through that entire pattern of clicks in real time. A single click. You didn’t even need to click to open the chat interface because it opened up on mouseover.

Dragging a photo in the general direction of the blue tab button would also open up the extension. From there you could hover (with the dragged photo) over any conversation and drop it in, or into the current conversation’s text field. And instantly it would send, without the need to “enter” confirmation.

Of course, it wasn’t perfect. Overtime we discovered a few problems: 

1. Hovering at the top and then bringing the mouse back down to the share or upload buttons is a hassle. Could be solved by moving the tab button to the bottom of the extension instead, but then it would have a higher probability of obscuring something behind it on the web page.

2. Even as it stood, it was obscuring some search bars.

3. The drag and drop was too sensitive. Trying to drag something from inside the browser to another app was nearly impossible (Moving photos from Google Images to Photoshop was particularly tough, as Google has it’s own search by image drag/drop function). 

4. For some reason having the tab on the page made several other page elements laggy and slow to load. I noticed this particularly with links that were in the same horizontal line as the tab button, on Google’s home page.  

5. Color was too bright. Distracted from everything else on the page and was an eyesore for a utility app that a user would be using often.

After several months of using the extension as it was, we decided to give up on the “single click” and join the other Chrome extensions in the top bar. Users would have to click to open and click to close, but at least it wouldn’t annoy them enough to disable it. (We noticed in Mixpanel that many users were disabling the extension, perhaps for browsing some specific pages in which the tab was getting in the way, but wouldn’t remember to turn it back on. This really hurt our usage, enough to change it). 

And wah lah, we joined the extension bar and jumped to the right side:


That’s our open and close icon, right next to the location bar! We did a color redesign as well to solve the blaring color problem. 

Here you can see the user has shared a map search. Yes, it took at least two clicks, depending on the open conversation, but at least it’s tucked away safely when you don’t need it. 

The link share preview was a game changer, discovery wise. It took away a lot of the social pressure of worrying about whether something you found interesting will also be interesting to your friend. If the recipient is not engaged after the preview description and headline, it just becomes another message. And when that friend does enjoy an article you sent, it’s extremely convenient and productive to continue to discuss it within the same conversation. 

Drag and drop still worked:


Same OSX drag functionality, and the auto-open feature is still there (so no extra clicks required there!). In addition, we improved the sensitivity so only dragging towards the button would trigger the interface to open. 


Sent. :)

I examined the impact Droptalk had on user behavior by mapping out the average number of rich content messages sent by each user over time. We weren’t monitoring analytics til the beginning of November, but observe the steep climb from sending two types of rich content (links, video, photos, or files) a week to a peak of 68. 


Aside from the Thanksgiving drop, this consistent climb was astounding. It wasn’t just that people were sharing more. People were consuming more, which meant they were learning more, from the friends who could now so easily send them anything that might be of interest. This in turn could be forwarded to the next guy, because once you have the article open and you’re reading it, sharing is just a couple clicks away.

Even if the bar for content you can “permissibly” send has lowered, the filter of a friend still beats seeing a disarray of information overload on a standard news site or even social news feed. And with the link preview, you can quickly decide whether or not it is worth your time. You can also easily return to the link unit because the UI treatment helps it stand out during rapid scrolling.

And, the content you really really love (whether it’s the funniest photo, sweetest text message, worst joke, or most infuriating news article) can be stashed and essentially pinned into a permanent conversation with yourself. 

The most interesting feedback I received from a user was that the product had made him “more curious.” That sharp divide between the web’s content creators (1%) and content consumers (99%) could very well even out with the simplicity of sharing and restoration of a social contract.