Tate
Tozer

Consumer Sign Up Funnel

The Upside app had a leaky sign-up funnel. After a period of diminished returns attacking parts of the flow, an opportunity to step back and simplify the flow lead to dramatic improvements.

Role

UX

Problems

• The existing sign up flow asked too much from Users. Through user surveys we learned the number one barrier to sign up was a lack of perceived value. We knew from surveying existing users that they considered Upside to have best in class offers. In MixPanel, we could see the dropoff with each task. How do we get new users to see value in the app and on to making their first transaction?
• Leadership was reluctant to approve projects longer than a few sprints. How could we show them the value in taking a step back and turning the sign up flow on its head?

Solutions

• We paired with the Research Team to tease out JTBD from user feedback, support tickets, FullStory, and MixPanel and came up with a list of themes. We reviewed company OKRs and prioritized our list of themes by how well we thought they could support the OKRs. We spent free cycles wireframing potential solutions and developing a backlog of design vision to pitch at a later date.
• The team reviewed exploration on a weekly basis, to see if anything merited further discussion. Anything with promise we spent further time developing and socializing outside of the group.

Results

• The process helped breakdown an aspect of shared culture that discouraged thinking outside of the current roadmap.
• Exploration lead to novel ideas, learning from one another, excitement from the team, and discovering new ways to unblock features.

Wireframes exploration of the discovery experience

Problem

• I pitched a sign up flow that deffered sign up, permissions, and marketing interventions until after the app displayed offers. The prototype got mixed reactions, with most agreeing it would take a lot of Engieering work to realize.
• Without access to location, the existing app would not render offers.

Solutions

• I spent a lot of time talking to Engineering trying to understand if we could break the sign up flow into modules. A new wallet feature in development had the ability to drop in during different flows, and I set out to understand if we could do the same thing for sign up, permissioning, and marketing.
• I worked with the team to understand if we could render offers based on a generic location (via IP), as opposed to a specific user device provided location. This approach satisfied the location requirement for our offer generation service.
• Clearing the path for a test, conversation turned to how we could test this new approach. An MVP build was served to a limited audience to test the new approach. We used Iterable to serve new screens, and triggered location permissions on map pan, notification permissions after the end of the transaction flow.

Results

• As a result using IP for offer generation, the service fetched many more offers for the User on app load. More offers were attractive to Users, and spurred the User to zoom the map in - at which point we asked for location permission.
• Users discovered the wallet requirement, while they were exploring at home or when it was time to make a transaction. Users were much more likely to add their card details for the offer they claimed.
• The MVP is being revisited as a new feature and is currently in development.

Comparing the old flow with the proposal, its easy to see how Users converted. I pitched this flow as a "what if"

Documenting IA to keep track of all the elements in the Consumer App