Growth & Marketing
October 25, 2020
February 18, 2021
Growth & Marketing
October 25, 2020
February 18, 2021
Dogfooding — or eating your own dog food — is a common practice in some software companies that decide to use its own product. It is a really good way to test their quality and that is why we have decided to carry it out. Do you want to know the result?
After a few months of hard work in our editor, we decided to build our user onboarding process, its forms, flows and automations with our own tool, how could it be otherwise. Today we tell you how and why our user onboarding flow is the way it is... and the time it took us to build it with our own tool.
Why hadn't we done it before? Well, there's not a single reason why we wouldn't have done it sooner, but a set of them.
Actually we started a company focused on forms and automations, not exactly registration forms, and we have been working on creating a product and less on scaling it, but now we have the need to reuse flows in several places (on the platform, landing pages, etc.). So, in short, the growth of our own product and company led us here.
We also wanted to add some of the features of our product to its user onboarding flow, such us spam filtering, 2-factor authentication and passwordless forms in order to reduce friction without giving up on security, and do you know the result?
We have saved more than 1100 lines of code on the login and registration functions, field validations and CSS styles. And we should also keep in mind that the login and registration that we had before was much simpler, without 2FA, OTP for email verification nor passwordless options.
At the same time, the whole onboarding process was fully coupled to the platform web page, so we could not reuse it. Now, we can embed it anywhere with a line of code.
The first key point in our user onboarding process, as in all of them, is the sign-up or registration form, where we aim to balance our needs with the best UX practices without sacrificing security.
It may look like a simple form at first glance but there are a whole series of reasons behind why it is this way. It offers minimal friction for new users and it also collects the data that our team needs to qualify them, with completely custom server-side logic.
It includes three registration options among which the user can choose how to register:
The logic behind this form can be quickly and easily set up thanks to the visual flow editor, that allows us to configure everything by dragging and dropping native actions, and copying and pasting a few data and keys from external applications.
This form has been created from scratch in a few minutes with our own form editor, but you can save even more time with a set of fully editable templates. They are compatible with any tech stack and the flows and server-side logic will be automatically created too.
Why have we chosen this setup? To balance security and UX as much as possible:
To make all the registration options work properly, we need to create and set up a flow for each registration option and one more to verify the one-time password, in case the user has chosen that option to register.
As you can see above, each flow is linked to a step of the form. Although the actions of each one are different, they all start by creating a JSON object to manage the authentication settings and then make the pertinent queries and launch custom actions.
The next flow actions are different for each case, and range from checking if the user is already registered.
As you can see above, the social signup flow gets the email from the user’s Google account, registering it automatically and in one click or displaying the proper error message, in case one occurs.
The email + password flow checks if the email is already registered. If it is, generates and sends also an OTP by email that the user must include in the next form step, proving to have access to that email account.
The email + OTP option simply checks if the email is already registered and, if it is, generates and sends the one-time password by email that the user must include in the next form step, as in the previous case.
The two access options with OTP redirect the user to a second step of the form that has an associated flow that verifies that the OTP is correct and proceeds to submit it.
If all validations are correct, the new user will be able to submit the form and the after submission flow will be executed for all cases.
Once the form is submitted, the flow you can see in the picture is launched, which is intended to do some checks on the email, qualify the new user and notify both the team and the user that the registration has been executed successfully.
This flow has been entirely created with our visual editor and a flexible set of native actions, which allow us to connect it with any external service with an API. Let’s take a look at the actions we have used in this use case.
In the first place, we have used a HTTP Request action to connect with the IP Geolocation API to obtain some extra information and qualify the user a little bit more, and then another one to connect it with IPQS and automatically score the user's risk level, helping us to detect users who are possibly going to use Arengu fraudulently.
After the IP data enrichment, a custom notification is automatically sent to one of our Slack channels to keep our team properly informed.
It includes both the data that the user has directly input in the registration form and the data enriched with third-party services. Fields can be easily set up on the native action.
After a short delay, the following group of actions send a welcome email to the user, in addition to subscribing them to the newsletter, adding the contact to our list in Mailjet.
As you can see in the picture below, the first action of this flow performs several checks on the email with which the user has registered, including whether or not it is a corporate email, in order to better qualify the new user and launch specific automations.
Once the email is verified, we create two different paths depending on whether or not it is a corporate email. As you can see in the picture, we just needed to include a conditional logic action to create two different branches to manage both cases.
To qualify the user even more, we use Clearbit to get some extra information about the company, simply by using the available native action.
Once the contact details have been enriched, the company, the person and a deal will automatically be created in Pipedrive for our sales team to contact them, and personally show and explain the product and discuss any possible needs they may have.
Finally, a custom notification is sent to the sales team with the most relevant enriched data of the new contact, so they can evaluate the leads in real time and contact them.
If we are already registered, the login form offers us the same frictionless access options as the registration form: log in with Google, with email and password or a magic link, and it also requires a flow connected to each of the form steps to make them work properly.
As you can see, the login and registration flows are quite similar. The biggest advantage when it comes to building them with our editor is to easily set up 2FA to the users who want to add a second authentication factor, without the need for any new development.
In addition to the login and registration flows, we have also implemented a complementary set of forms aimed at promoting communication with our users and managing their feedback. You can find them in different sections of our website, offering a direct contact channel for suggestions, feature and integration requests and any type of input.
For example, demo and request startup plan flows include data enrichment and their data is sent directly to Pipedrive and a Slack channel to notify our sales team.
The data from the contact and feedback forms, which are also used on different pages, is automatically sent to our product team too, using the Slack message native action. And the newsletter subscription form... Well, it just subscribes the user to our newsletter, as it would be expected!
Why have we chosen this setup? Basically, to save our teams time and facilitate their work by helping them to easily manage the qualitative information that we receive.
Creating and configuring all these forms and flows with our own editor, including third-party and own integrations and automations, has taken us about 3 working days in total.
During these 3 days, the product team worked on developing and configuring the forms and flows and, simultaneously, the development team setting up the frontend and the new backend web services to allow the use of passwordless flows.
In addition to the more than 1100 lines of code that we have saved, we have also achieved:
Have you already found the onboarding process that best suits the needs of your product? As you may know, finding a flow that balances UX and the needs of your sales team can be a bit more labor-intensive than you initially thought.
Arengu allows you to save time, effort and money when implementing these forms, flows and automations, and iterating them until you find the best one for your project.