In 2014, hyperlocal food delivery in India boomed significantly, thanks to TinyOwl.
While TinyOwl was serving over a million users across the country in less than a year with a strong delivery force, the payment system struggled significantly with reliability and performance issues.
I had one simple goal. This was to deliver a seamless payment experience to our TinyOwl customers, while optimizing for scalability.
In 2015, I led the design of TinyOwl's payment experience and collaborated with Gaurav, product manager and Arbaaz & Hardik, our developers.
This project was 12 weeks long, during March 2015.
Keeping the mindset of the our Indian customers who were new to an on-demand food delivery platform, I worked in research, experience flows, visual design and prototyping for the payment experience.
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 whooping 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 roughly 30%
This is so frustrating especially when you are so hungry and trying to
order food asap!
TinyOwl super user
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
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.
Problems to solve
We used Feature Prioritization session to lead us in identifying the following problems to solve:
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
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.
Evolution of card viewing system aligned with the principles of relevance and familiarity.
The visual design of the card system was redesigned into list view just like the other modes of payment. I aimed for coherence across the entire payment experience to build familiarity and trust. We followed our design system— started by reusing rather than reinventing. I wanted the experiences to reuse and adapt for consistency.
For more preparedness of the TinyOwl delivery boys, a list view of getting type of change was introduced. It was an initiation to make the experience more intuitive and conversational.
Fixed broken payment gateways and designed relevant screens to inform the user the exact error issued. I needed to be thoughtful about what we present, to whom, and in what context.
Relooking at the visual design elements to assure how our brand manifests across the payment experience.
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
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.