2
16 Comments

Registration Workflow

I'm currently trying to put together the registration workflow to my new product onetomany. Right now I'm going with just providing an email and name, and then we send out info for you to use the product.

Activation Link

The workflow for this would be registering with a name and email, then receiving an activation link as seen below. My concern with this is around the unique activation link being stripped. If that happens then I the workflow becomes a lot more tedious....

Activation Link

Temporary Password

The workflow for this would be the same as above, but the difference here is you're offered an actual sign-in to use on the app, should the link be stripped.

Temporary Password

At the end of the day, it's not a huge deal but I would like to provide as little barrier to entry as possible.

Thanks a lot, everyone!

Which method do you prefer?
  1. Activation Link
  2. Temporary Password
Vote
  1. 2

    Think about user friction. We don't validate, for this reason.

    1. 1

      By validate, you mean email?
      And do you NEVER validate? Or only after they want certain features?

      1. 2

        Limiting user friction is more important.

        1. 1

          wow... what product is this for? Don't you get heaps of spammy users this way?
          Thanks

  2. 2

    I think it will help you if you allow users to demo/trial it without asking for too much up front. Whatever workflow best facilitates that is probably the one you should go with.

    1. 1

      I think that's the general consensus
      Thanks a bunch for jumping in though! One more +1 to the idea carries weight haha

  3. 2

    I implemented pretty much the same workflow for rotor.app as outlined in Chris's response below. Send the user a confirmation email but do not gate the trial account behind the activation. What I do is informing the user that some features/functionality will be unavailable until the email address has been confirmed.

    1. 1

      What did you end up restricting?

      1. 1

        Basically anything that's related to paid features. A user simply cannot transition from trial to a paid subscription until the email is confirmed. If the email is left unconfirmed, the trial ends and the user completely loses access.

  4. 2

    Personally, I've gone with an even more aggressively simplified registration workflow. All I ask for is an email address, once you enter that I drop you right into a free trial account. You don't need to go off somewhere else and then come back to the app, you can just immediately start exploring.

    I do send out an email verification link but it's not a gate to start using the app. Users can set a password from within the app, but again it wasn't a gate to the registration process.

    I believe there's a ticking clock on getting users hooked on your app to decide if they're going to pay for it. I want to eliminate as much friction as possible to make sure I maximize that time. Making someone leave your site to go wait for an email just gives them an opportunity to leave an never come back.

    Early on I had been asking for a lot more information upfront and making users jump through multiple steps. I realized that ultimately I don't need any of that information to have people try my app however. If a user isn't ultimately going to convert to a paid plan none of that information matters anyways, so I might as well instead focus exclusively on trying to make it as easy as possible to get them hooked and converted to a paid plan. Eliminating friction is just one part of that process. That's been my approach to onboarding though.

    1. 1

      This is super valuable thank you SO MUCH for the input!
      I really want to prevent a user from navigating away. The idea being, create a number, use the number, problem solved.

      I've got a weird follow up if you have time;
      Since when you create an account you can also create a mobile number to be used, I need to validate the email before I do that so people can't create spammy numbers...

      Do you have any ideas on this?

      Thanks a lot @csotherden

      1. 2

        If it's easy for you to enable/disable/re-enable the number you could possibly consider time bounding the use of the number until a user has validated their email address? Say, allow the number to be used for 20 minutes after account creation and then disable it with a toast type notification in the app that they need to confirm their email address to continue?

        That should be plenty long enough for someone to see "create a number, use the number, problem solved." in action.

  5. 1

    Thank you to everyone that offered their valuable feedback! We've just gotten the activation link working in the email and are very excited to start working on the dashboard and putting the API live, now that all the external fluff is sorted and looking pretty! Watch this space 🎉

  6. 1

    I'm unaware of how much time this will cost and how much time you have, but is it an idea to AB test it to build an understanding of what your registration to login ratio looks like? That way the data will tell you which solution is best.

    1. 1

      That's definitely an option! But yeah, time versus pay-off, I'm not sure yet.
      I want to avoid putting too much effort into a problem I don't currently have. However, it's a problem I HAVE had, hence why I'm posting it here

      Thanks a lot for the engagement though! I hadn't thought of AB testing 🤦‍♀️

Trending on Indie Hackers
How I grew a side project to 100k Unique Visitors in 7 days with 0 audience 47 comments Competing with Product Hunt: a month later 33 comments Why do you hate marketing? 27 comments $15k revenues in <4 months as a solopreneur 14 comments Use Your Product 13 comments How I Launched FrontendEase 13 comments