Understadning dropouts

With the initial help of the Product Manager, I looked at the Web & App signup funnels and sliced data to understand where major dropouts happen. I additionally had a look at previous a/b test & learnings we got from that data.

In addition to this, I planned and carried evaluative research to understand the underlying reasons leading to the behaviours uncovered by the data. The main tasks I did for this usability testing include:

Carried a workshop involving key stakeholders, including the product manager and developers, to prepare the usability testing plan. I facilitated the workshop based on Katarina Bagherian's researching the right thing versus researching the thing right.
Prepared and carried the usability testing sessions.
Analyzed the results of the sessions and presented main highlights to the stakeholders involved in the workshop.

The main learnings of my discovery journey are summarized below.
‍

Plans page has the highest dropout rate

Both in the App and Web funnels, around 50% of visitors drop out from the flow after viewing the plans page. Given that there was no information about plans and prices anywhere in the Web prior to signing up, I formulated the hypothesis that visitors reach this stage out of curiosity and then dropout as they were no ready to commit.

Lack of information around plans and pricing

The above hypothesis was validated through the usability testing, where participants expressed the need to have access to more comprehensive information around the plans and prices before signing up. Additionally, the little information regarding costs available during the signup flow is easily dismissible due to its placement.

Cognitive load

Throughout the flows, several screens present a lot of information to people at once. However, as our brains have a limited amount of processing power, every added button, icon or text might overwhelm the user. This might lead to people abandoning tasks or simply missing vital pieces of information.

Lack of feedback on interaction

Throughout the signup flow, there is a lack of instant feedback on interaction. For instance, people that add discount codes fail to see that it was successfully applied, leading to frustration or lack of trust with the app. And overall there is a lack of meaningful error messaging to help users recover from mistakes.

Opportunities & experiments

This approach helped me and my team list a number of opportunities with assumptions to be tested. I've listed some of the most relevant ones:

Redesigned and a/b tested the page dedicated to showcase plans & pricing;
Redesigned and a/b tested the intro pages in the App, to clearly showcase benefits;
Redesigned the order summary & created a flow to add promo codes both on the App and Web Signup flow;
Re-assess where instant feedback on interaction is needed throughout the flow. Examples included here: promo codes + error messages.

As a team we selected the tests to prioritize, based on impact and effort. Some examples of experiments I worked on can be seen below. Initial designs are on the left, final designs are on the right side.

Designs handover in a remote setup

In order to make the design rationale of my work available to any stakeholder, I add in-context comments to my designs, wherever relevant. There are couple of advantages in doing so:

Working in a remote company with stakeholders located in different regions, it makes the main design decisions available to anyone, at any moment in an asynchronous manner;
The information will remain accessible in the future whenever (new) designers need to revisit why a given direction was taken in my absence;
Generally, async' communication "incentivizes higher-quality communication" as written communication forces one to communicate more thoroughly and clearly while inviting other to comment whenever they're ready;

Dev handover

Along with developers, I've created a design handover process that's optimized for asynchronous communication. In order to reduce the clutter and information overload, I create a separate file (Deliverables for Devs) with design and annotations that are relevant for the implementation process only. These might highlight specific changes or more specificity regarding the desired interaction.

I additionally, create a space where I highlight new components or changes in previous ones, along with some CSS properties, hoping this will proactively reduce changes when performing visual QA.

Building a design system

One area of focus has been scaling the design system and creating its documentation. From the design perspective, the goal is to increase work efficiency for product designers while ensuring design consistency & scalability. From a cross-functional perspective, the goal is to create a unified language that ensures consistency across platforms & departments.