Building an efficient payment system for a million people new to ordering food digitally
TinyOwl introduced India to the first hyperlocal food delivery experience. With a strong growing delivery force, the digital payment system struggled significantly with reliability and performance issues. Problems encountered in the previous app had a 30% drop in success task rate with abandoned carts and increased failures in payment gateways. I had one simple goal: Deliver a seamless payment experience to our TinyOwl customers, while optimizing for scalability.
Arbaaz Abdul + Hardik Jagda- Developers
Reduced the time users spent navigating between various methods of payment, resulting in saving users 2 minutes per food order.
Improving task success rate to a 62% increase in completion of successfully making a payment.
Aided in improving the checkout process CTR which led to an increase in daily revenues by 30%
Evolution of payment card viewing system aligned with the principles of relevance and familiarity.
Designing for controlled transparency with a white label virtual wallet, TinyOwl Wallet with stronger integration in order to close the feedback loop faster.
Designing for perceived speed to retain continuous engagement with the TinyOwl experience. Staggering and disguised slow loading interactions initiated less waiting time for orders to be processed.
Designing for effective priming to gain a faster response by a stimulus visually identical to a previous stimulus than to one identical only in name.
Relooking at the visual design elements to assure how our brand manifests across the payment experience.
With the increase in growth strategy techniques like TinyOwl wallet and multiple payment methods, the payment experience became fragmented and user success tasks reduced by 68%. I had to look deeper in to the payment experience and create a strong foundation that embraces scalability and engages in a rapidly evolving business and more diverse customer base. Our high level goals were:
1. See through the user's eye by diving deep into every second of our user's interaction with TinyOwl mobile app.
2. Understand the user's intent and uncover their frustrations
3. Build platform for deeper engagement and quick solution for their hunger pangs.
See through the users' eyes
Without pre-existing insights, I partnered with our product manager, Gaurav to explore how the payment experience was performing. I started with observing heat maps of 62 users' interaction in the mobile experience. This was followed by understanding the intent of my users and the problems they were facing.
Observations & Interviews
I chose to observe users while they were ordering food through TinyOwl in order to better understand how the tool is used. I also interviewed users in order to learn more information about their history of use with the app, as well as their challenges, wishes, and favorite parts of the experience.
super users interviewed
super users observed
inactive users interviewed
This is so frustrating especially when you are so hungry and trying to
order food asap!
TinyOwl super user
After interviews, I chose to complete Affinity Maps in order to organize the information we learned from TinyOwl's user group.
I decided to create separate affinity maps for each user group, because many of the user groups were using different functions within the app. I wanted to easily separate each group's unique pain points.
From the interviews and affinity maps I identified many pain points and design ideas provided by our users. A few major pain points for each of our users is presented below:
Our users gave us many ideas for features they would like to see when we interviewed them. As a team, we discussed all user pain points and feature requests through the lens of our users. We utilized a Prioritization Matrix in order to decide which features and user pains should be addressed in the first iteration of the design.
We used product effort and user value as the metrics for our matrix.
How might we reduce the number of screens users have to navigate to find relevant payment methods?
How might we make the logic behind reports and codes more clear?
How might we provide our users with a familiar experience for all modes of payment?
Next, I created an information architecture diagram to help the team understand the navigation of the new application. As a team, we discussed any changes that should be made to the information architecture.
Then, I began to generate sketches based on the "how might we" questions we generated, and all that we learned from our users.
I got feedback on these sketches from our users and my team. Ultimately, we decided to move forward with the design that utilized many key components from TinyOwl's current design system.
Our users gave feedback on these ideas, and they also liked the design that included navigation that was most similar to other TinyOwl tools that they used.
Next, I created a sitemap to help the team understand the navigation of the new application. As a team, we discussed any changes that should be made to the sitemap.
Finally, after wireframe testing, hi - Fidelity prototypes were created to test with our users.
We put our prototype in front of our users to get their feedback on the first iteration of the design. We knew how valuable feedback from our users would be in determining our next iteration. Our users thought aloud while walking through the prototype, and we took notes in order to help us identify user actions, comments, confusion, and common themes.
After completing user testing, we received the following user feedback
Some users needed the ability to also search for the order reciept in order to complete one of many key tasks within their role.
Some users did not notice the arrow icon under total bill amount that was now available to them to pull down the receipt in the application.
The mode of payment tabs were created to offer users choice in the way that they could search for payment method, but many users did not click the tabs.
Design. Iterate. Test.
As the mobile app went through a new version installation, we utilized feedback from the user's experience to complete iteration two. Then, we tested iteration two with our users and got feedback. We repeated this as many times as we could in to get as much feedback from our users as possible. This helped us to make sure we are truly meeting our user's needs.
Buckle up to fail fast
It is always better to design quickly and fail fast. It is helpful to get users something better that they can use to do their jobs as quickly as possible. The more iterations and user testing you can do the more informed your final design will be.
Analyse from a 360 degrees view
Working closely with data scientists and developers help to get a 360 degrees view of your user's intent. The more you observe the patterns, the faster it will be to build intuitive experiences.
Leverage low fidelity prototypes
It's better to come up with Low - Fidelity prototypes to test before moving to High-Fidelity prototypes. Low - FIdelity prototypes are fast and easily disposable.