AppDynamics signup flow

Why redesign

There were a number of issues with the old design:

•  Signup flow was hosted on a different platform, making it difficult to update the messaging and visual styling
• Large promo in the hero section of the landing page pushes main content down and distracts from the signup form
• 
  Progress chart on third screen of the signup flow was confusing to users

First redesign (early 2015) - brevity and ubiquity

In this iteration, we attempted to increase the volume of signups by minimizing the amount of input required from users and by creating more entry points across the website to the free trial.

Demo and free trial user flows

I also tried to plan ahead for a new user flow that would offer a choice between the free trial and another upcoming offer, an interactive demo. Both offers were created for practitioners who have the technical knowledge to navigate and understand the product. In most cases, the demo is easier to start with. It provides read-only access to the product and does not require users to install AppDynamics on their system. Nevertheless, some users also want to test the product with real data from their applications.

To help users pick the offer that matches their needs, I generated user flows and ways to convey the differences between free trial and demo.

Simplification

Based on feedback from stakeholders and developers, I looked into ways to consolidate and simplify the hosting and OS selections. Since all users have to choose where to store their data before starting a free trial, I moved the hosting selection to the signup form. The OS selection remained on a separate screen because it was itself a multi-step process (choose between 32-bit or 64-bit architecture, then read the corresponding download instructions).

After researching different input types to simplify the design, I decided to use a toggle button for the hosting selection. Compared to the original radio button design, the toggle places the hosting choices closer together and makes it obvious which state is selected. This allows users to quickly get through the signup process but also switch between hosting options with confidence and ease. For the OS selection, I designed a three-state toggle with icons for each choice to increase recognition speed. The toggles for both hosting and OS selections also display the most common option first, saving an additional click for most users.

Launch

We narrowed down the user flow options to ones that began with a signup form embedded in a pre-footer block. Instead of having to click to another page, users would naturally come across the form while browsing the website. We also tried to minimize decision fatigue by keeping the form as short as possible, collecting just enough info for sales to follow up.

By the time we needed to ship the new signup experience, the demo was still a work in progress. That left free trial as the only offer available. I modified the user flow to reflect this.

We introduced the new signup form at the end of every page on the website (whereas the old signup form existed on a separate page). Because there were simply more instances of the signup form, we expected conversion rates to increase. Unfortunately, there were issues with how we implemented Google Analytics across the website so much of the data from that time was not reliable or accurate.

But the first redesign did fulfill other success metrics. We created a streamlined signup flow that was easier to update and link to third party technologies. It was a flexible, robust foundation that we continued to build on for a better user experience.

Second redesign (late 2015) - collecting more data

After a few months with the new signup flow, the sales team requested that we add more fields to the form. They were experiencing some difficulty in following up with customers due to the lack of certain information (full name and phone number) that couldn't always be inferred through third party technologies. While it's possible to ask for additional details later in a product onboarding process, we wanted to test whether or not users would mind providing the information up front through the signup form.

How many more fields did the sales team deem necessary? A lot. Although best practices usually suggest minimizing the length of a form, I decided to take the request from sales as a challenge to balance the needs of the business with those of the user.

The form became long enough that I decided to explore placing it on its own page. This option also restored space to convey the value of a free trial in greater depth.

Influencing perception

Simply adding more input fields to the previous design did not work. It resulted in a massive tower of white blocks that was visually unappealing and could discourage users from signing up. To streamline the appearance and make the longer form seem less overwhelming, I tried a few visual techniques:

• Decrease contrast between input fields and background
• Reduce the height of each input field
•  Remove outlines around social links and hyperlink underlines

We also introduced new technologies (Demandbase and Clearbit) that can auto-populate information and thus reduce the amount of effort to complete the form.

Getting comprehensive and accurate data

To ensure that users fill out the form completely and correctly, I created error and instant validation messages with the following best practices in mind:

• Use specific, positive and helpful language
• Display messages next to the input field triggering the error
• Use a combination of color change, message text, and icons to reduce ambiguity (especially for colorblind and visually impaired users)

Versatility

For other marketing campaigns, I designed landing page templates with a variety of content blocks. Each template used the same form module, thus decreasing development and production time for creating new pages. Depending on the asset or offer, content publishers can choose which input fields (apart from the basic requirements) to include in the form module.

Third redesign (2016) - more offers

In early 2016, freemium product managers approached the web team about introducing a new offer—a free trial with a sample application. This offer would bridge the gap for users who want to test the full capabilities of AppDynamics but do not have their own application or the technical knowledge to configure the product.

At the same time, the freemium team was also finalizing the demo for public release. We then needed to create a user flow for three distinct but similar offers: 

• Interactive demo with read-only access to simulated data
• Free trial with a sample application provided by AppDynamics
• Free trial with an application provided by the user

Internal user testing - setting up the sample application

Working with the freemium team, we conducted two user testing sessions for the sample application flow—from initial signup to deployment. We tested with two different groups of employees from various teams who had not previously tried the sample application. Most were engineers, a few were not. Testing with users of varying technical expertise provided valuable insight on how to market the future offers to the right audience.

Testing with real users - choosing between offers

After the internal user testing sessions, I conducted a separate test to understand how real users would navigate through the signup process and choose between the different offers. My goals were to:

• Validate the benefits and requirements of each offer with our target audience. 
• Understand which of the proposed user flows, messaging and designs would increase conversions.

I worked with a remote usability testing vendor to define, plan, and execute the test. The result served as a proof of concept to help us create a business case for future user testing.

Target audience

We needed to find test participants that represented AppDynamics' target audience—enterprise employees who use and/or are responsible for purchasing application performance management solutions. With the help of our vendor, we recruited users from companies of 200+ employees and tried to get an even distribution among the following personas/roles: 

• DevOps / IT engineers 
• CIOs and CTOs
• Product managers and marketers

Variations

Brainstorming with the freemium team, we came up with two user flow proposals to test:

1) Single CTA leading to the different offers
We hypothesized that having one entry point to all of the offers would reduce the initial friction for users who want to see the product in action but need more context to understand which offer would best fit their needs. Introducing the offers on a separate screen allowed for more space to explain the benefits and requirements of each one.

2) Separate CTAs for demo and free trial
This proposal assumed that users would understand the fundamental difference between a demo and free trial (read-only access with simulated data vs. full interaction with live data) at first glance.

Test experience

Because I wanted to understand how real users would react to the proposals in a real-life setting, I tried to mimic the actual experience of the website by creating a high fidelity prototype for each path variation.

To help orient users, I gave each persona a different scenario. This is what I asked of engineers:

"Imagine you are evaluating performance monitoring solutions for your site/app and you heard about AppDynamics. After browsing the content on the homepage, you want to learn more about the AppDynamics platform and decide to try it for yourself. What would be the next step you take? After going through one offers, try accessing the other offer(s)"

Insights

We had all users (8 total) go through both path variations and followed up with questions after they completed exploring the prototype.

Users validated the following benefits and requirements for each option:

Users also provided feedback on which of the proposed user flows, messaging and designs would be more likely to help them make an informed choice and motivate them to sign up for an offer:

Future development

With proven demand for the sample application and demo, we shipped variation 2 with updated the messaging for each offer based on user feedback. We also refined third party integrations to pre-fill information on the forms without making users feel uncomfortable. Changes included:

• Detect a user's country but keep the field hidden (to reduce the length of the form and keep users focused on other input fields).
• Auto-populate the "Company" field only after a user enters an email address that can be matched with a company in the database.

Limitations

Because the remote user testing session was a proof of concept, we had to limit the prototype to certain interactions. For instance, we were unable to include a functional version of the signup form or the product itself in the prototype. This led to some confusion when users launched the demo and free trial but couldn't explore the dashboard's features. A few users commented on the lack of tooltips or a guided tour which exist in the real product. Because the rest of the prototype was created in high-fidelity, users likely expected full functionality in the product screens. It may help in the future to explain the limitation of features beforehand to users.

A more detailed usability study can be done to evaluate the signup form and product experience in the future. But for the purpose of the remote user test, we were still able to fulfill our goals related to the overall flow and messaging of the signup experience.