Redesigning Onboarding

Overhauling DigitalOcean's onboarding and verification.

For more context, read a bit about my time at DigitalOcean.

When I joined DigitalOcean, our user onboarding flow looked like this:

Stone-age Onboarding
  1. Sign up
  2. Land on a screen with 3 steps, which blocks your access to other pages.
  3. Receive an email, open it, and confirm your address.
  4. Land on the credit card form with no context, which blocks your access to other pages.
  5. Land back on the 3 step screen, your next step is to create your first Droplet.

Our funnel numbers actually weren’t bad considering the designs above.

  1. 10% of people who saw our marketing site signed up (say, 20,000 customers)
  2. 80% of those left confirmed email (16,000 customers)
  3. 50% of those left added a payment method (8,000 customers)
  4. 75% of those left were subsequently billed (6,000 customers)

Now, if you were especially lucky, you’d also get this beauty. Our friendly fraud and abuse system might have flagged you for suspicious behavior and locked your account. If indeed you were flagged, you’d be dropped on this page right after adding your credit card.

Stone-age Verification

It wasn’t a pretty sight and—considering our high false-positive rate at the time—it wasn’t a rare one either. The only way out was filling out the form in the middle (aka the only step that’s actually a step).

Before we finally tweaked our algorithm, we diverted far too many good actors into this flow. It resulted in an awful experience that they wouldn’t soon forget. In fact, we later found that users that were flagged—even if it was just once a whole year ago—were far more likely to be detractors in our Net Promoter Score surveys. This means that a bad flow here could negatively affect our brand for years to come.

A later version of this flow was designed with additional OAuth features that could help verification. While it was more pleasing aesthetically, it resulted in more confusion.

Connecting your social accounts had about a 10% chance of automatically unlocking your account. If (when) that didn’t work, your only recourse was to click a seemingly unimportant link to open a support ticket. Even if you actually read the copy, it didn’t make it clear that this form would likely be required.

Bronze-age Verification
Calling a process “simple” doesn’t make it so.

This experience led to people giving us lower ratings literally forever. It needed fixing. Reducing the friction and “bad feels” around the verification flow was the goal of this project, but we decided to take the opportunity to tackle the onboarding flow as well.

Our goals, in order of priority, were:

  1. Reframe verification to feel less negative. Possibly spin it as a good thing.
  2. Make it obvious that you need to submit a ticket in order to get verified.
  3. Increase % of users who add a payment method.
  4. Increase % of users who confirm their emails.
  5. Add delight ✨

Flow Mapping

The first step was to get a feel for the onboarding flow, from start to finish. Which parts could we cut? Which parts were more complex than we initially thought? Did we miss any edge cases? Were there any opportunities we hadn’t noticed? Seeing the beast often helps.

Mapping the onboarding flow
The Perspective Crop Tool will never not feel magical.

This helped us recognize some pragmatic areas for improvement. We’d explore these both holistically—in the context of the larger flow—and in terms of page-specific improvements. I’ll go through some of these areas, in the order that a user would see them.

The Login & Registration Screen

Style, Layout & Microinteractions

The most obvious change I made to this step was visual. I felt the previous design’s starkness failed at guiding the user’s eye to the registration box. A higher background-foreground contrast could speed up registration and reduce cognitive load.

First Login page iteration

Before the redesign, people frequently got our Log In and Sign Up pages mixed up, usually due to the Sign Up CTA on the public site. When they tried to log in, they’d get a message that their email was already taken. Even though we placed a log-in link under the form, this was understandably frustrating.

I suggested we log in existing email/password combinations, regardless of which page users were on. There were no engineering resources to implement this at the time, so I opted for a temporary fix.

Second Login page iteration

This option seemed like it might be overwhelming for users. The point of the visual overhaul was to increase focus, and this did the opposite. I continued to explore options.

Third Login page iteration
Fourth Login page iteration

Once I landed on a solid direction, I wanted to see where I could add some delight. DigitalOcean’s brand is friendly and casual. Until this point, though, it had never shone through in the UI.

I explored some whimsical animations, which I felt were a good mix of form and function. They were fun to watch and helped clarify the context of each part of the flow.

Login micro-interactions

When combined with a second card for signing up, these animations illustrated that each card represented a separate flow.

Optimizing the flow

One of the main changes we wanted to test was shifting the email confirmation blocker to earlier in the process. In the existing flow, when a user signs up, the first thing they see is this blocker:

Old email confirmations

Even with the updated aesthetic, the page felt like a lot of work.

By sending users straight to the control panel, we were giving them a momentary impression that they were in—only to renege the offer and give them additional tasks.

Users could see the navigation, but couldn’t follow it until they completed onboarding.

New email confirm flow

The flow we had in place forced users to leave this page and manually open their emails. They had to find the right one and click on the button. It would drop them back on the same page, with the email confirmation box disabled and the next box (set up payment method) available.

Shifting the email confirmation step would allow us to remove the first box from this page. Also, if we’re being honest, the last box was only there for visual balance (boo).

Removing the boxes made both the first and second steps feel a lot less like steps. Email confirmation became something you did as part of the registration—before you even see the app.

The changed flow didn’t actually result in less work for the user. What it did was lower the perceived friction. Here, once the user lands on the control panel, they only have one thing to do: set up billing.

What once felt like 3 steps now doesn’t feel like a process at all—it’s just the obvious next step.

As a result, the entire onboarding flow felt much more streamlined.

New email confirm flow

You may have noticed that in the first flow there were two levels, whereas the second flow has only one. The old flow’s email confirmation screen was a dead end. All you could do was resend the confirmation email. If you wanted to continue the process, you’d have to manually open your email and continue from there.

With flows like this, people often end up with two tabs, one of which remains useless until you remember to close it.

One of our small improvements was to make it more obvious that the tab was now useless, and you could close it. It was a bit better but still resulted in a dead tab.

Confirm email dead end

For some email addresses, though, I had an idea that could alleviate this entirely. Instead of a dead-end, we could link off to their email provider logins.

If you used Gmail, for instance, you’d get a button that could lead you straight to your Gmail inbox. This would happen in the same tab, and feel like part of the same flow. We could make the same work for Outlook, iCloud, Yahoo Mail, and any other email provider. I talked to one of our engineers, and he figured out how to ping emails on the fly to check whether addresses were part of Google Apps accounts.

Delight, at its core, is a positive surprise. The experience of entering an arbitrary email (say and getting a direct link to your inbox had the potential to feel magical.

Finally, I put together some screens to account for edge cases. If users tried to log in again before confirming, they’d see an “Account Pending” box with an option to resend the link. This button would then turn into a link to your email inbox. If you logged in after the email link had expired, we’d automatically send you another email and give you that same button.

Confirmation edge cases
Mid-fidelity mocks. Don’t judge.

And that’s the login page. The email would send you to the app, where you could set up your payment method. We’ll explore that next.

Maybe you’d like to play with the prototype?

Password: test12.
Two-factor: 121212.
Try registering with a Gmail/Yahoo/Outlook email.
Social sign up is just for show.

Payment Method

Focused Flow

Clicking “Update Billing” in the original flow dropped you on the default Billing page in your settings. We felt this flow should take a more guided approach.

The billing page
You couldn’t click any of these navigation or sub-navigation items. They were just a distraction.

Credit to Earl Carlson, who partnered with me on this flow.

In the first iteration of the redesign, we dropped users in a contained flow, rather than the default page. Once they clicked through their email, we’d ask them how they preferred to pay. The options were One-Time Credit (prepaid credits), or Recurring (paying at the start of every month).

The goal of the guided flow was to make every click obvious. We didn’t care if it would take more clicks to complete, as long as users didn’t have to think about any of the steps.

The app's landing page asks which billing type you want

Clicking on one of these options would lead you to the next set of new options. You could load your account with money via Credit Card, Bank (ACH), or PayPal. For recurring payments, you could still set up a card or an ACH transfer, but not a PayPal account.

One-Time billing options

To put users at ease in times of uncertainty, we added a pattern for helper text at the bottom of each modal,

We started working on each payment form. The recurring credit card form was relatively straightforward. The prepaid PayPal form afforded more opportunity for improvement.

Paying an arbitrary amount of money without knowing its value on the system—without having seen the system yet—seemed like it could be stressful. I introduced a component that showed what each dollar amount could buy you.

The PayPal page

The bank transfer form switched focus between numbers on the check as you moved between their respective input fields.

The bank transfer page

High-level, the guided step flow looked like this:

The first billing flow

It later turned out that bank transfers weren’t as relevant and we originally thought. This helped to further simplify the flow.

Droplet-First Payment Flow

Next, I wanted to experiment with dropping users in a fully functional app. We’d only prompt them for payment information once they’d try to spin up a paid resource.

Post-Droplet billing prompt

The hypothesis was that users would be more likely to pay once they configured their servers. As with shopping carts, they’d see value before pulling out their cards.

We wanted to ship a version of this and test the scenario, but the engineering effort was deemed too high.

Empty States & Freedom

At this point, we were still showing users the navigation, but not letting them explore the links. The other pages acted as a sort of tease. The only way to satiate your curiosity was adding your credit card or transferring funds from PayPal.

Some of these new customers had heard of us or read up on marketing material. But a good amount had never heard of us before, and we weren’t doing anything to gain their trust. Without trust, why would they give us their details?

Now, 50% conversion for adding payment details isn’t bad. But I believed that if we let users explore and see what they’d be getting for their money, we could increase this.

Instead of dropping the user on that 3-step view or a locked billing flow, I designed an empty state for each page.

The droplet page with an empty state leading to billing
The Droplet page empty state before entering billing information.

The empty states would be permanent, but their CTA would be dynamic. Until you added a payment method, they would lead you to the billing flow. After that, they’d prompt you to create resources.

I put together similar pages for Images and DNS records. Each page had basic information about the resource, with an option to learn more. This let users browse through the platform and get a feel for what was possible before committing to share their private information.

Finally, I then made some optimizations to the billing modal flow.

I tied the modals more closely to the pages users would have come from. If you had converted on the Droplet page, the form’s title would be “Create a New Droplet.” This framed it as the first step to getting what you want, rather than a way to add something we wanted.

I also ripped out the many billing options that we presented earlier. The most common method was a recurring credit card payment, so I defaulted to that. As a business, it was also our preferred method of payment.

Credit Card modal

If users wanted to, they could switch to One-Time Credit (via PayPal). We framed this as a secondary option, but it’s obvious and easy to get to.

It was also possible to prepay with a credit card, but we chose to nix it. Based on data, the added constraints wouldn’t affect almost any of our users, and they would result in a much simpler flow. This way we could include two possible modals instead of the original 8 or so. I met with the PMs and got buy-in.

The payment flow we came up with gave users the freedom to move around and see what’s possible. Then it made it easy to add a payment method once users chose to give us a chance.

New Verification Screen

The final piece of the flow was the verification screen. Remember that? There’s a wall of text between us and the last time we discussed it at the top of the page. Let’s recap:

Too many new users were incorrectly flagged for fraud or abuse after submitting their payment information. They would land on a page that said: “Account Locked.” We asked them to connect their social accounts, add their physical address, and other information.

All this was just to get into our app. Keep in mind, this is before they’d actually seen the app for the first time.

Bronze-age Verification
This is the page you use to make people unhappy.

The page itself was confusing. We never explained why your account was locked in the first place, or why you now needed to verify your identity. We didn’t even explain how adding social accounts would help with that.

We put the user in a frustrating, uncalled-for situation. To top it off, we weren’t showing them any empathy. Not in the layout, not in the copy, and not in the tone. With such a lousy first impression, it’s not a huge surprise that this hurt conversion and hurt the brand.

Something needed to be done.

Reframing the messaging

The way I saw it, the verification flow had two main issues. The first of these was the abysmal messaging.

“Account Locked” does several things poorly:

The thing is, fraud and abuse protection isn’t inherently bad. It exists to protect the world from sites supporting ISIS or child pornography. It helps to combat spam, and to stop bad actors from committing fraud and stealing other people’s money. And it’s crucial when it comes to providing consistent performance and reliability to all of our customers.

It’s beginning to sound like kind of a good thing, right? It’s absurd that with this many pros to verification, we decided to go with “Account Locked.” We could do better.

New copy

Reframing the flow

The second issue had to do with a confusing flow and weak expectation-setting.

The main CTAs on the page prompted users to connect their social accounts. The problem was that these accounts only had a 10% chance of verifying someone. This meant that 9 times out of 10 users would have to open a support ticket anyway.

If you scroll up you’ll see a tiny link to that end.

I repeat, a whole 90% of flagged users had to click that tiny link and fill out a support ticket. And we framed the entire flow around a method that would do nothing but waste their time, patience, and good will.

I decided to redesign the page and frame it around opening a support ticket. I renamed the ticket to “Verification Request.”

I integrated the social OAuth functionality into the ticket, but with lowered expectations. Forms are asynchronous, so connecting your GitHub or Twitter can feel more like adding an attachment. This way, there was no unmet expectations for immediate resolution.

Instead, 10% of the time, users would be magically verified and pulled out of the process. What once caused frustrated could now cause delight.

New OAuth flow

Finally, I added the ability to include dynamic survey questions. A big percentage of users get flagged due to having multiple accounts. This was an obvious opportunity to save our Support team time and canned responses.

Users flagged for this reason would receive and answer the question before our Support staff had to ask it. Users flagged for other reasons would never need to see it. This sped up verification ticket resolution substantially.

Multiple accounts

Additionally, I placed the page within the regular flow, rather than locking users out. If they were locked, empty states would prompt them to verify their account. I even gave them positive reinforcement for signing up. Here’s the final page.

The final verification page

My goal was to stop this page from feeling disruptive. Ideally, flagged users would feel like it was part of the regular flow, something they were always meant to see. And hey, for the most part, it worked.


The new verification flow shipped right away. It resulted in much less confusion and frustration from flagged users.

It was one of those instances in which design can be a powerful bandaid, but not the real solution. By making the experience better for false-positive, we were alleviating a symptom, whereas reducing false-positives by improving our fraud detection algorithm solved the actual problem. It also boosted conversion significantly.

Today, very few people see the verification page, and when they do, it doesn’t feel as negative as it once did. This has resulted in a higher and ever-increasing NPS and more love (plus, in this instance, much less hate) for the DigitalOcean brand.

The rest of the onboarding flow took a while longer to implement. As with Team Account Management, resources at DigitalOcean were scarce around this time. Only two more aspects of this project were shipped right away:

Also in line with the Teams project, most of the elements designed for this flow were subsequently implemented over the next year:

The new onboarding flow, once completed and released, resulted in a full 5% bump in overall conversions, and so I added high-fiving to my LinkedIn profile.