About the project

As part of a Product Design training bootcamp taught by The Design Crew, I was asked to work on a problem encountered by Lydia, the mobile app that enables easy payment between friends. In teams of 3, we had two weeks to understand the problem, explore potential solutions and test them with users in order to allow them to better understand the payment limitations of the app. We delivered an interactive prototype to Lydia's Lead Designer team, to give them an external solution to a problem they are trying to solve.

The P2P payment super-app

Founded in 2013 by two french entrepreneurs, the app quickly became popular among students thanks to its basic value proposition: offering a simple, fast and efficient way to pay back friends. Today, it has over 3 million users and claims to be used by 30% of the french 18-35 years-old.

In December 2020, the company has revised its ambitions upwards and now offers banking aggregation, a checking account with an IBAN and even consumer credit services. On top of the free version available to everyone, the company now provides paid subscriptions, Lydia Bleu and Lydia Noir, for €5 and €8 per month respectively.

After raising 72 million euros at the end of 2020, their north star is now to increase their profitability, and therefore their monthly recurring revenue. The main way to achieve this is to convert free users by getting them to subscribe to Lydia's monthly subscriptions.

The problem

One of the MRR levers identified is limiting the usage of the app features for free users. Since January 2021, the free version of the app is now limited in the volume of transaction and many other features that a user can use every month. The product design team was left with the following problem to solve:

We tried to solve this problem through a careful process comprising research, design and iteration, 1 month prior the implementation within the Lydia app.

1. Discover

We decided to tackle this complex problem using the double-diamond framework, with all the tools and knowledge we learned so far. First, we entered the Discovery phase to understand the roots of the problem, the context and the constraints we will face.

App Mapping

Early on, we decided to focus on the main feature of the app, P2P payments, as it's the one Lydia is known for as well as the most used. We put ourselves in the shoes of power users who use the app to its full potential. Our goal was to trigger the limitations and map what the app displayed. We succeeded, and discovered that it only displayed a pop-up asking if the users wants to complete the transaction even if it will be billed.

Overall, this analysis allowed us to get to know the current flow better of the app and identify its main strength : fluidity. Sending a payment is a flawless experience with little to no friction points, performed in less than 10 clicks; and it has to remain that way.

Understand the limitations

Lydia gave us the excel spreadsheet the business team worked on to summarize the monthly limitations. Our mission being to materialize those lines and columns into a tangible solution, we deconstructed and organized the table to better understand it.

Our first understanding was the difference between hard and soft limitations: the hard ones are set by banking institutions and cannot be exceeded ; the soft ones are set by Lydia and can be exceeded, but the user will be charged for it.

Our second understanding was that limitations seem hard to reach for a casual user, even under the Lydia Free plan: to reach the limitations, you must use the app 20 times a month. We assumed that the percentage of users directly affected by these limitations must be <5% monthly.

Personas Development

Once we understood the scope of the problem, we decided to use empathy and put ourselves in the shoes of the users by building personas. We decided to create one persona that encompasses as many Lydia users as possible.

Meet Adèle, a 26-year-old student living in a shared flat in Bordeaux. After being introduced to the app at school, she became a regular user: using it every time she goes out with friends and once in a while when she makes an online purchase.

User Interviews

With Adèle's background in mind, we decided to conduct interviews with Lydia users to understand their usage and expectations about the app. Prior to that, we had to formulate the following hypothesis to formalize our research and make the problem easier to address :

H1 - Users are aware that Lydia offers a paid subscription

H2 - Users know about features and limitations of the app

H3 - Users will churn once they understand the app is limited

With these hypothesis in mind, we built an interview guide to put them to the test and try to learn as much as possible from users. Our first objective was to understand how limitations can be clearly presented in the app without breaking the flow. The second one was to see how these limitations can be presented to users to incite them to subscribe to a premium plan.

We conduced 5 interviews with very different profiles, from casual Lydia Free users to Lydia Black power users to try to understand how they interact with the app and try to find users that have been exposed to the limitations.

2. Define

The second phase of the double-diamond process consists in synthesizing and analyzing the information gathered to formulate the problem to be solved as an opportunity.

Clustering interview answers

Once we conducted the interviews, we decided to assemble our notes to bring out trends and verbatim to assert or refute our hypothesis :

✅  H1 - Users are aware that Lydia offers a paid subscription

🚫 H2 - Users know about the features and limitations of the app

🚫 H3 - Users will churn once they understand the app is limited

We completed these hypothesis with the combined data from our interviews to formulate 3 learnings and illustrated them with verbatim from interviewees:

How Might We & Success Criteria

We decided to transform those learnings into the "how might we" format to address them as challenges rather than simple statements. We added KPIs that will allow us to measure the impact once our solution will be implemented.

3. Ideate

Now that our challenges are clearly stated, we were ready to enter the solution space. With all this data in mind, we started the ideation phase to generate several solutions to address our problem.

App Benchmark

At this point, we believed that our problem must have already been researched and solved by SaaS platforms working with a freemium business model. We scouted the web and app stores to look for the solutions already implemented by companies providing great user experiences and user-friendly design.

First, we decided to have a look at how companies tell the user they're about to reach a limit. We selected Slack and a few design projects from Behance focused on gamification and finance. They always present limits with a playful writing and use gauges to help the user visualise the limit and where is use stands actually is.

Second, we had a look at how companies like UberEats, Spotify or WeTransfer encourage their users to subscribe to a paid plan. They display on a one-pager the advantages that the premium version offers in a list display, and focus on incentives such as a free trial or a price reduction to convert users.

Literature Review

We had a quick look at the academic research about freemium model to better understand its perks and limits.

We learned that by providing satisfactory services to users, companies can retain users, but the users may not have an intention to pay for the services (Kim, Lee & Zo, 2018). We also learnt about free mentality, where users that think a service is a commodity with the right of free disposal perceive a stronger sacrifice when a premium service is offered, and consequently have a more negative attitude towards paying aswell as less intention to do so (Niedman et al., 2015).

For our problematic, it means that even if users are satisfied with Lydia's experience, they might not subscribe to a paid plan. It also means that we need to take into account the free mentality problem, especially when Lydia's core service, P2P payment, is perceived to be 100% free for many users.

Mind-Map

We put everything we learned so far on a large piece of paper and drew a mind-map with our problematic in the center and explored different solutions without any limitations. We aimed to propose as many initiatives as possible, and stimulated our reflections with a Crazy-8 exercise.

Once we finished the mind-map, we had a wider vision of our solution space and were ready to explore potential solutions.

Exploration

To explore product solutions, we had to rebuild the original design of the app in Figma. First, we built an up to date design system for iOS devices that allowed us to build the original Lydia designs quicker.

We first tackled the homepage and many small ways to display limits, with the constraint of keeping the original  fluidity of the app in mind. During this exploration, it became very clear that the implementations will be incremental rather than game-changers.

We then explored ways to notify a user that is about to be billed for exceeding the limits on the free version on the transaction page. This specific page gave us a hard time, as we were split between keeping the original experience as pure as possible or adding elements that will make the limitations clearer.

Finally, we decided to build a limitations page that summarizes all the limitations. As this page was not existing before, we had greater creative freedom but decided to stay in the Lydia universe, as we believed continuity was key. We tried several ways to express limitations, from ratios to visual compositions.

4. Deliver

After exploring many ideas, it was time to materialize our most promising solutions into a prototype, test them and iterate to implement the best one.

High-Fidelity Prototype

After agreeing on the most relevant solutions for each screen that will provide the most suitable experience, we stitched them together and built a functioning prototype with realistic transitions in Figma.

We created an experience centered around the P2P payment, as we believe it is both the most used feature and the one that users are the most familiar with.

User Testing

To test the prototype, we created a scenario to carry our user testing sessions. The scenario consisted in sending two payments: one within the free usage limitations, one above. We created a more realistic context by asking the tester to behave as he was paying his friend back during a night out.

We conduced five 30-minute tests. First, we introduced the testers to the scenario, and let them explore the app with the objective of sending two P2P payments in mind, without taking any action. Then, we did a walkthrough of every step of the process they went through, to ask questions about the specific actions they perform and why they did so. Lastly, we took 5 minutes to ask them general questions about the prototype and the payment experience.

Iteration

These interviews helped us understand if our solutions had the intended effects. We gathered the data from the tests and understood that our solution needed some more work to convey the message we wanted to.

We took those feedbacks and iterated, learning from our mistakes and the verbatim and statistics interviewees shared with us. We refocused on fluidity and simplicity, in order to deliver the experience users expect.

Our first goal was to make sure users understand limitations in a clearly way in  without breaking the flow. On the homepage, we added a tag on the top-right that states the users' plan and a horizontal carousel that summarizes the main limitations. We left the transaction page untouched, and decided to notice the user when he reaches 75% of a limit and allow him to go premium. Finally, we reshaped the limitations page by allowing to easily go to the previous or next month, categorized the limitations and added a total.

Our second goal was to make sure the limitations will lead to conversion to premium plans. To do so, we transformed the swipe-up into a non-skippable pop-up right when the user is about to pay its first transaction fee. Through this page, he can subscribe in one-click to Lydia Blue for free after quickly discovering the main features of the plan. Finally, the overall UI evolves and becomes all-blue when a user subscribes to a premium plan.

Final Prototype

Here's our final work, that you can see on video. It goes along the following scenario : complete two separate payments back-to-back and have a look at the complete limitations page.

Conclusion

After spending two weeks trying to figure out how make the limitations of use more transparent to convert free users to paid plans, we presented our final work to Félix Le Poutre, Head of Design @Lydia. He gave us constructive feedback to avoid inconsistencies that we can resume over three points:

First, we wouldn't have been able to add our limitations summary the Lydia homepage, as it's a page that must remain as clean as possible.

Second, our limitations page is relevant, but would have been clearer if we displayed the number of transactions remaining instead of the ones already completed, as it will help users visualise limits better.

Third, limitations would have been better explained and more impactful using graphs or progress bars, rather than simple ratios.

Personal takeaways

This project was the first one where we did the double-diamond design process all the way, working on both the problem and solution spaces. It helped me better envision the work of a product designer, identify weaknesses in our process and avoid future mistakes. After seeing what Lydia implemented, I would like to think that our solution was relevant and needed some rework regarding the feedbacks given by the company's lead designer.