To have a great sign up funnel is important to acquire new users. It relies on many things like the marketing approach used to engage with the visitors, the marketing tools and web pages design, the sign up flow and to set up engaging UI and UX that fit the audience. Nonetheless, if all of this is gathered but technical issues are occurring when a visitor tries to register, it is just a waste of work and money, and a loss of a potential customer.
To acquire users seems easy to do. One buys traffic from a website, redirects it to a sign up funnel, and then if the traffic matches the targeted user profiles one wants, one should get new users for his product. Straight, simple.
But reality never waits to remind us about her. Technical performances of the sign up funnel are likely more important than any other things to turn visitors into users. Is the marketing tool always displayed correctly on any device or browser? Is it loading fast enough? Is the sign up process responding? Is there a fallback when it doesn’t? All of this can have a good or a bad tremendous impact on how campaigns can perform and on product’s image.
Welcome To The Jungle
When I took over the creative team in one of the companies I worked for, composed of designers and front-ends, we had to acquire traffic for different categories of products. Historically, one of these categories was splitted between two product teams. Each team was managing a different version of this digital service. There was a different product manager for each version, a different technical team, no coordination or sync in between them. After many years, each version has followed its own path. Technically, they became two different products, each one having its own sign up mechanics, using different technologies and processes. Each team was working in its own silo.
As part of the marketing department, my team had to work with the two product teams. We were dependent on their technical choices and their reliability. But as these teams were not communicating together, they didn’t communicate with my team either
When I started to have a look at the sign up processes we had to implement on our marketing tools, it looked like a jungle.
For one product version, there was 3 different sign up mechanics:
- One inherited from many years ago, using an iframe form managed by the product team.
- One for desktop traffic with specific inputs and formats to send.
- One for mobile traffic with different input formats than the desktop one and a different endpoint.
For the version managed by the other product team, it was even messier:
- The iframe form was also part of it.
- A desktop sign up mechanic, with inputs and input formats different than the other product/version.
- A mobile sign up mechanic, using a web API, with different inputs and formats than their desktop mechanic.
The use of HTTP status codes were not unified between the two products or even between the desktop and mobile mechanics owned by the very same team.
Removing the iframe form from the equation, as I wanted to get rid of it to gain a better control over what we could do in the marketing tools, my team had to implement 4 different sign up mechanics. It was not the best context to easily implement, to maintain and to optimize sign up processes.
On creative team side, it was not better. For years, this team worked with a sense of urgency, copying/pasting code in different files, using no component, no shared code, no documentation, just trying to get the job done in time. Pages were also copied to produce different versions for new content or for different kind of devices. Needless to say that maintining or fixing marketing tools could quickly turn into a real nightmare.
As mentioned above, teams were not communicating together. In the first weeks I took over the creative team management, sign up processes were often broken due to this lack of communication. For instance, a product team was putting in production a change on their side related to the sign up mechanics without telling us. We were aware of the change once our marketing tools were not working anymore. Then, we needed to fix our tools as fast as possible to minimize the impact.
As bad practices had happened for years on our side too, it took several days to get the fixes implemented and deployed.
All this had to change. We needed better communication and a unified and more flexible sign up process on the marketing tools.
All the teams agreed that communication was lacking in between them and was essential to avoid issues. With the team leads and product managers agreement, we set up a monthly meeting, inspired by stand-up format, where each team member was explaining what he was planning to do. The other teams could evaluate if they would be impacted. If we would identify any impact, specific team members could then set up a meeting to clarify the ins and outs, to plan implementations and deploys across the different teams.
As part of this issue, the lack of documentation related to the different sign up processes was also a burden to any developer who had to implement them. Even the product teams were not 100% sure of how the sign up mechanics were working as people join and leave the teams through time.
As my team was the one relying on both product teams to get the sign up mechanics fine on marketing tools, I spent few days with developers of each team to write down documentation for each sign up process. It helped to have a better view on what was the situation and how we could make everything better.
The New Plan
Once this situation assessment was done, I started to elaborate the new plan we would set up to fix the issues we encountered for some weeks.
With the back-end team from the marketing department, we decided to set up a server-side web API to be able to standardize the communication between our marketing tools and the products. No matter what product we would contact to perform a registration, we would send the very same inputs, with the very same formats, we would contact the very same end-point to submit our data, and we would get the very same HTTP status code responses. Then, our API server would contact the right product to submit the request and would send back the response from the product, in a RESTful way, to our marketing tools.
More simply, our marketing tools would not contact products anymore, our API would take care of this.
The benefits on our side would be:
- Easier maintenance and development. With standardized shared files to build our form and to set up mechanics, no need to wonder about what is the right mechanic for a specific product, what are the mandatory inputs we should send, what are the good input formats. No more copy/paste of code generating mistakes.
- No more errors from a marketing tool submitting the registration to the wrong URI, using a unique URI to submit the registrations with standardized input formats, no matter the product.
- No more questions about what the HTTP status codes meaning is. It would allow us to be sure if our submission was successful or not, what the response means to the marketing tool and what behavior it must display following the response.
- No more fixes to apply on marketing tools. If product teams would change something to their sign up mechanics, we would just need to apply the change on our server-side web API, on the API to products communication level. Only real important modifications, as a new input field requested by products, would impact the marketing tools. Even in this case, we would just add it to our common shared file managing the form and would rework our HTML/CSS to add it to the impacted tools.
With this plan set up on our side, we came back to the product teams to expose it and to keep on discussing as one main issue couldn’t be fixed this way. If teams communication doesn’t work and a change is done on product side without warning our back-end team ahead of it, everything related to this product could be broken.
We also mentioned that having different mandatory inputs to perform a registration was not handy to allow our marketing department to do tests on sign up flows. Some different registration flows were existing, but there was again no documentation, they were not the same for each product and each time we needed to test a new flow, it should be first implemented by product teams before we could use it
The Product’s Solution
Exposing our plan to product teams, we stressed the risk that lack of communication could still impact everything. Also, we reminded them that even with changes on our side, it wouldn’t remove the differences between the different products. We would still have to manage it, even if we would mitigate its impact on our work.
We also mentioned that having different mandatory inputs to perform a registration was not handy to allow our marketing department to do tests on sign up flows. Some different registration flows were existing, but there was again no documentation, they were not the same for each product and each time we needed to test a new flow, it should be first implemented by product teams before we could use it.
As I was asked what they could do to help us, I exposed what we wanted:
- A single mandatory field to create the user in the product database, likely the email address. The rest of the fields would be optional, which didn’t mean we wouldn’t never send their values.
- Because of this single mandatory field, we could handle the flows ourselves. So, I asked that it becomes the case. We would create flows, all of them with at least the mandatory field. This way, products could accept all of them.
- A solution that they would implement to avoid wild changes to their registration mechanics and to homogenize their sign up processes. We needed something different than relying on teams’ communication, something that would guarantee that if product teams do changes on their side related to the product registration, the sign up mechanics on marketing tools are not broken.
One of the product teams became immediately reluctant to these requests. They saw them as extra work to do and they didn’t want to give us control on the sign up flows. On the contrary, the other team was enthusiastic, ready to work on all of this, proposing to build a new versioned registration API, compliant with our team’s needs, that would allow our mechanics to keep working even if they do a change as we would use the previous version of the API and they would do changes on the next one, keeping both running until our team is ready to move to the new version.
After discussing these requests and the versioned API solution, product and marketing managers approved it and we started to build this registration API, with a single mandatory field and our team would own the creation of sign up flows instead of the product teams.
To Homogenize Forms
While product teams started to work on their versioned registration API and marketing department back-end team on the web API acting like a proxy with the product API, our team started to clean up forms on marketing tools. After many years, there was no consistency about how forms were displayed, managed and functioning.
For designers, we created a form design guideline for desktop and touch devices, to have a common language and principles when a designer needs to create a new form design. It covered many aspects of a form like what kind of labels to use, what kind of placeholders, what minimum height and width to use, what input field states to design, what kind of visual clues to include, animations when marketing tool is waiting for API response, error states with clear and precise messages.
For front-end developers, we started to rework all client-side form mechanics and code, covering form’s fields and user interaction behaviors, setting up all the different cases based on the type of form used (a complete form or a multi-step one – see here for a case study of a multi-step form) and the different type of sign up flows we will have to manage from now. Page would be populated with the right form using PHP functions in our tools, all the mechanics being externalized from the tools.
In the end, we set up a system giving us a great flexibility on what the sign up form is made of, based on traffic origin or marketing department requests, easy to maintain and to upgrade. Users would get a feedback for each action they perfom which was not the case before.
Because of all these paradigm switches in the way we would handle sign up processes from marketing tools to products, we could introduce a bit of optimistic UI in our designs.
One of the main concerns I had with the old sign up mechanics was that we were sending form inputs all at once to the product, waiting to get a response, hoping we could understand what it meant if something was wrong. For instance, there were cases when the product was returning a common HTTP status code for several different errors but with no specific message to define the error or even wrong message. Also, as some checks had to be done product side on the input values we were sending, the response time delay before knowing if we could redirect a user to the product could be up to 10 seconds on a good internet connection.
As the only mandatory field to proceed a registration was now the email address, we were able to implement some optimistic UI practices for the other inputs. On a complete form where all fields are displayed at once, we could keep displaying the normal error messages per input if needed. But for our most used type of form, the multi-step one, and even for complete forms if we wanted to, we could move on once the user account was created using the email address even if the other inputs were not accepted product side or if the product was down.
So, we decided that for multi-step forms, the first step would always be the email address and that for a complete form, the other inputs would be submitted by our API only once user account was created. Once getting a success from our API, the user account would have been created in product database, meaning that all other inputs would be just an update to the newly created account. We wouldn’t have to display errors for nickname or password (product would generate one on the fly if we didn’t send one). Unless if the traffic needed to be really qualified, we could simply use optimistic UI principles to move the user further in the sign up process and redirect him to the product. Once logged to the product, user could be informed that he could change his nickname or password or any other input. It would also be a fallback in case of wild change on the product API not respecting the API versioning.
500 Error Fallbacks
The new structure allowed us to implement fallbacks when services were down, as a traffic monetizing agency has a main goal: to monetize as much traffic as possible. Prior to this new structure, we couldn’t have fallbacks if products went down.
With the new system, we created several fallback rules. Once the user account was created but our API would get a 500 http code from product API when submitting the other input, we would ping the product domain to see if it is still up. Based on the ping result, our API would send us different redirection links to use:
- The product redirection URL if the product was still up but their API was down.
- A redirection URL to another version of this service if a specific product we contacted was down.
- A third-party partner redirection URL, offering the same service, if none of our products were responding.
- If we would get a 500 from our own API, we would use a fallback set up at marketing tools level, redirecting to a third-party service matching what the users were looking for.
We would apply the same kind of fallbacks if we were not able to create the user account. Theoretically, 100% of registration tries should be successful.
Sign Up Flows
The last modification we did was to set up the different sign up flows on our side. Each form would send to our API a parameter to tell what sign up flow was used. Based on this, for specific flows where traffic needs to be qualified, API wouldn’t send a redirection URL when user account would be created. Instead, marketing tools would handle redirection to a final registration step page.
As users could come from very different pages displaying different form content, this redirection page content needed to be dynamic. If a user gave only his email address on the marketing tool, we would need to pass this information to the redirection page that it asked the user to fill all the other missing field for this specific flow. If the user gave several inputs on the marketing tool, the redirection page had to display less fields.
This way, we were able to replicate all the previous specific flows and we were able to add new flows easily as marketing department requested them.
All these changes made huge impacts. Apart from registration numbers impacted by them, improvements happened on all the production line..
On our team, designers avoided UX/UI mistakes using the form design guideline, speeding up design process. Front-end developers became owners of the form mechanics and code. Development, testing and maintenance became easier and faster.
On the back-end side, product teams got also benefits from it. They started to own again their code, after many years of layers and layers of code with no documentation. They could do changes directly on the product without impacting the acquisition process.
On users’ side, our marketing tools offered a better experience to users with proper and well-defined responses to their actions, almost no more technical issues preventing them to access a service they were looking for.