Work

This case study is password protected

Please click on the button below and enter password to continue to view the full case study

Next Project - Splitwise

Previous Project - FinBox

Introduction

Background

Splitwise is a platform where people can add, split and settle expenses with single or multiple members. It helps in keeping track of personal and group expenses. When users want to settle up any amount with their friends on Splitwise, they have to adjust the amount on Splitwise and pay the exact amount to the other party using alternative methods of payment (most commonly used methods in India are Google Pay, Paytm, Phonepay). This creates a detachment from the app causing a simple process to be unnecessarily complicated, which can also cause human errors while entering the amount in either the payment app or Splitwise.

Objective

By better understand the user’s journey, I aimed at creating a payment feature inside the Splitwise app. The users should be able to choose between popular digital payment methods (India only) like Google Pay, Phonepay or Paytm and send money to their friends directly from the app.

My Process

Understanding Users

Interviews and Surveys

Assumptions

Analyze data and Ideate

Competition analysis

Solutions to pain points

Workflow and key screens

Create Design Solution

Wireframes and key feature workings

User testing and design iterations

High fidelity design

User Research

Interviews

I conducted 10 interviews with Splitwise users to gain insight into their usage, needs and goals.

Surveys

I distributed among 20 Splitwise users to gather quantitative data on user needs and preferences.

Key questions & answers that aided the design solution

What is the target audience for the feature update?

The target audience for the feature update is the existing user base of the Splitwise mobile app. Since most of the users are educated young people in their 20s.

What is the user journey from getting a group bill to paying the users dues?

Generally the most common group expense in the target audience is restaurant bills and utility splits between roommates. The total expense is paid by one person and then equally divided in the people which participate. The addition of Splitwise allows users to create a cumulative expense report since most people pay some amount at some point, the total sum owed is given at a mutually agreed time. This amount is then given by the borrower using a digital payment method (most popular form of currency transfer between urban youth in India).

What are the usual methods of money transfer between friends?

The most common method of transferring money between urban youth is digital payment apps like GooglePay and Phonepay.

Target audience & Personas

The target audience for this feature is the existing user base of Splitwise. Young professionals and students in their 20s. These demographics usually go out to restaurants and bars and/or have rents and utilities to split with roommates. Based on this research and user interviews, I created the following 3 personas:

Finding the opportunity

Based on the user’s needs and goals, none of the features in Splitwise cater to the stage of “making payment” in their journey. To not consider it causes multiple points of potential errors and also forces the user to change platforms.

Assumptions

Users settle up expenses in a timely format and don’t just let it pile up over time

It is assumed that users generally settle up expenses in a timely manner even though there could be a back and forth in who pays and who owes. The users hence would use some kind of a payment transfer

Users prefer to transfer money via a digital method over cash

Since the pandemic in 2020, the urban population has shifted towards a digital mode of transfer over cash, especially the youth. Thus settling up expenses usually entails that the users would use some kind of a digital payments app.

There are no technical or regulatory limitations in adding this feature to Splitwise

Splitwise is a successful and well established company thus it is safe to assume that their data is secure. Apps like CRED, Swiggy, Zomato allows users to pay in-app or request ‘X’ amount via UPI apps.

Users use either GooglePay, Phonepay or Paytm

These are the most popular UPI apps used my millions of Indians. A post launch analysis can be performed to see if users prefer different methods, but for stage one it can be assumed that users use these 3 apps.

Ideation

Current Flow

The current flow causes the users to go outside the app for a part of the process. This leaves a gap between what is owed and what is paid and is a potential point for human error.

Usability Issues

Users need to go outside the app

Users need to remember what amount to transfer when they are out of the app

Users need to search and find their friend in the other (digital payment) app and then proceed to transfer the money. This causes an unwanted delay in the whole process

Competition Analysis

I carefully examined the payment process of two very popular apps, Swiggy and CRED. Swiggy uses an external method with payment request method and CRED uses an inline UPI integration. Their drawbacks and benefits paved the way for the flow of the feature.

Swiggy

Pros

Multiple payment method options

Direct payment request, user can click on the notification to directly go to the gpay app’s payment screen

Amount and person is prefilled in a request, thus no room for error

Feature is relatively low cost to build.

Pain points

User still needs to go out of the app

User needs to go back to the Swiggy manually app after the payment

CRED

Pros

The entire process is in-app, user never needs to step out.

Multiple payment methods available.

Pain points

User needs to register their UPI Id with the platform.

The in-app process takes higher amount of company resources (both business and dev)

New Task Flow

Since this is a brand new addition to the app, the request payment link is the best approach. After we gather further user data regarding adoption and preference, we can add the in-app feature. Error points are still controlled since there is no human intervention. Additionally, the new flow requires a shorter amount of time and effort from the user.

Storyboard

By eliminating the error loops (scenarios) and reducing friction in the flow, the new storyboard allows for a much positive user experience.

Design Solution

Initial Wireframes (Key screens)

Derived Solutions: Iteration #1

The initial design solution is aimed to introduce the feature to the users at minimum cost to the company. It aims to provide user with an option directly accessible through the app itself and reduce points of error and provide a seamless experience.

Failure cases and screens

There are multiple points of technical failures that can occur in the process, right from user enters the wrong passcode to server issues on the payment gateway.

User Testing

The objective of the user testing was to gain insight into how the users would use the new feature and their interaction with known pain points and search for new ones. These sessions were fundamental to create the Iteration #2 which addresses the key issues found in user testing.

Equipment and environment

I met several people in cafes and homes. The users were given an iPhone with the Figma prototype and other apps like Swiggy, CRED, etc to interact with.

Testing sessions and tasks

Users were given several tasks based on the prototype as well as other apps to observe their actions and behavior. The tests conducted were short, lasted for no more than 15 minutes each session.

Observations and analysis

User testing revealed that the notifications from payment apps are not reliably regular, thus users often switched to the apps manually. The users also had to confirm the success of the payment.

Key Takeaways

Switching apps

It was observed that the notifications didn’t always come immediately. Thus users had to manually switch apps to complete the payment step.

Manual confirmation from the user

Since the transaction was between two third parties, Splitwise cannot confirm the success of the transaction. Hence the user had to manually confirm, thus introducing a potential point of possible error.

Iteration #2 - Future scope

Analyzing the pain points through user testing and platforms like CRED, we can see that there are a few points that need to be addressed. After post launch data like user adoption, preferences, etc are thoroughly analyzed, then the company can allocate more resources to further develop the feature.

Learning

Learnings

As a UX Designer, we often discount the technical cost to build a feature. Creating a initial milestone feature with known pain points to gather user data, adoption and insight to later re-iterate on a well based feature gave me a greater knowledge and insight on creating a product, not just designing it. This is one of the most crucial learnings that I apply in my capacity as a professional Product Designer working in a startup with limited resources and an iterative environment.

Future Scope

Looking ahead, based on high user adoption of the feature and additional data, we can re-iterate iteration #2 to better the feature to accomodate users based on their behavior and needs.

Additionally, we could also work on an AI model integration that would allow Splitwise to track users expenditure, give insights regarding the same and send alerts based on limits set by the user.

Next Project - Google Calendar

Previous Project - Splitwise

Introduction

Background

Google Calendar is one of the most popular calendar and scheduling apps for both businesses and individuals. Users can add public calendars, create personal or work events, invite co-workers, conduct video conferences and much more. One of the most crucial aspects of event scheduling is the ability to create a recurring event. The current flow on the mobile app forces users to follow several steps, creating a high amount of friction and introduces potential points of possible error. First time users have a hard time creating and customizing recurring events to their liking. Additionally, users cannot share video conference links directly while creating an event.

Objective

By understand the pain points in a user’s journey, their needs and goals I aimed at redefining the process of creating a recurring event and sharing video conference links. The main goal was to streamline the process and create a compact UI which allows users to accomplish their tasks with minimum steps and friction.

My Process

Understanding Users

Interviews and Surveys

Assumptions

Analyze data and Ideate

Competition analysis

Solutions to pain points

Workflow and key screens

Create Design Solution

Wireframes and key feature workings

User testing and design iterations

High fidelity design

User Research

Key questions & answers that aided the design solution

What are the major pain points of the user in the journey of scheduling their events?

Users commonly encounter pain points during the event scheduling process, such as difficulty in navigating the app, time-consuming event setup procedures, limited customization options, and challenges in finding efficient ways to manage recurring events.

What is the target audience for the feature update?

The target audience for the feature update is the existing user base of the Google Calendar app on iPhone. This includes professionals, students, and individuals with busy schedules who rely on the app to manage and organize their events and appointments effectively.

What aspects of an event does the user customize?

Users have the ability to customize various aspects of their events, including the event title, date, time, location, duration, reminders, and recurrence patterns. They seek flexibility to tailor these elements according to their specific needs and preferences.

What are the users goals?

The primary goals of users are to efficiently manage their schedules, ensure timely attendance to events, and maintain a well-organized calendar. Users aim to achieve these goals by utilizing features that provide them with a seamless and intuitive experience for scheduling, customizing, and tracking their events.

Target audience & Personas

The target audience for the Google Calendar feature includes individuals who seek an efficient and user-friendly solution for managing their schedules and events. These users span various demographics and professions, ranging from busy professionals and students to retirees, each with unique scheduling needs and preferences. On the bases of this and the overall interviews, the following 3 personas were created:

Assumptions

Users have already determined the specific customizations they want to apply to their events.

It is assumed that users have a clear vision of the customizations they want to make, such as setting specific reminders, notifications, or recurrence patterns. They expect the app to provide an interface that allows them to easily apply these pre-defined customizations.

The existing logic and features within the Google Calendar app are sufficient to meet user needs.

It is assumed that the current functionality and logic implemented in the app are already capable of fulfilling the users' requirements. Users do not expect any significant technological innovation but rather expect the app to leverage its existing capabilities to provide a seamless event scheduling experience.

The customizations made by users will fall into daily, weekly, monthly, or yearly recurrence patterns.

It is assumed that users typically require event customizations that follow a daily, weekly, monthly, or yearly schedule. They expect the app to offer these recurrence options as part of the customization features, allowing them to easily specify the desired frequency for their events

Ideation

Current Flow

The current workflow in the app is very tedious and time consuming. Additionally there are multiple instances where users can make simple errors costing them additional time.

Usability Issues

Multiple unnecessary steps, thus the flow is very long

Options are confusing to the users

Error prevention is missing in certain instances

Users generally used the wording “I want to schedule the event daily except weekends” and not “I want to schedule the event every week on weekdays”. Current flow supports the later statement. Daily recurring events occur daily without exceptions.

Affinity Mapping

Affinity mapping revealed key themes from user research for the Google Calendar Scheduling Event Revamp:

Difficulty in customizing recurring events, such as setting recurrence frequency and event end dates (12 out of 18 participants).

Cluttered user interface, leading to confusion and overwhelming information display (14 out of 18 participants).

Lack of intuitive event management tools, including difficulties in adjusting event settings and finding customization features (15 out of 18 participants).

Time-consuming event scheduling process with long and tedious steps for creating and editing recurring events (11 out of 18 participants)

Competition Analysis

I did a thorough analysis of Apple’s Calendar and Microsoft Outlook Calendar, two of the largest competitors of Google Calendar to gauge existing solutions in the market, their pain points and advantages to gain a better understanding for solving the problem.

Apple's Calendar

Pros

Shorter task flow, thus less time consuming

Select increment number, duration, interval and days is in the same page

Compact design, yet intuitive

No additional custom option (doesn’t create confusion)

Pain points

User needs to click on add event, the button is not clearly highlighted

Less number of preset defaults, user has to add everything

Inability to add cross platform virtual meets (User needs to manually add a Google Meet link or Zoom link). Only FaceTime is supported.

Microsoft Outlook

Pros

Shorter task flow, thus less time consuming

Compact and overview page

No additional custom option (doesn’t create confusion)

Pain points

User needs to click on add event, the button is not clearly highlighted

Inability to add cross platform virtual meets (User needs to manually add a Google Meet link or Zoom link). Only Skype is supported.

Interval, On days and Until are all in separate page, increases the TACT time.

New Task Flow

The new task flow for customizing recurring events in the Google Calendar app was designed to improve efficiency and user experience. By implementing a simplified process with a single page, users could now easily select their desired interval, end date or occurrence, and other customizations.

Design Solution

Initial Wireframes (Key screens)

Derived Solutions: Choosing Intervals

Users have the flexibility to choose their desired interval and end date or occurrence, all on a single page. By providing complete customizability by default and eliminating preset options, the flow becomes more streamlined and less prone to errors.

End recurring event

The revamped "Ends On" section in the Google Calendar Scheduling Event Revamp project offers a shorter and seamless task flow, consolidating all recurring event scheduling actions on one page inspired by the Google Calendar UX on web.

More options in video conference customization and sharing

Users can directly share video conference links on other platforms like slack to share with their coworkers for a seamless process of joining meets.

User Testing

Equipment and environment

I conducted real-world testing with 20 participants in cafes, homes and offices with an iPhone with the figma app installed with the prototype.

Testing sessions and tasks

The sessions lasted 20-30 mins where participants were tasked with various tasks like creating recurring events with different customizations, sharing video conference links and more.

Observations and analysis

Sessions were observed and scored on different metrics. While most users were able to accomplish the tasks, several users faced issues. The insights dictated further iterations to cater to various pain points.

Key Takeaways

Confusing day picker

Day picker was a little confusing with only the first letter of the day. Adding the first three letter like “Mon” enhanced the experience and reduced the time taken by users to choose days as their options were clearer.

Redundant Ends On page

A simple three-option radio button menu now enables users to do all customizations on the same page. Displaying all three options upfront enhances user clarity in customizing the end for recurring events.

Lack of option to share video conference link directly

Users expressed their desire to share those links on their communication channels like slack immediately as they create the event. I assumed that there would not be any technical difficulty as that feature is present in the google calendar on web.

Learning

Learnings

I learned the impact friction reduction can have on user experience, and gained valuable insight from unexplored zones such as App Store and customer forums. These helped me to get a better understanding into getting a user-centric approach to design.

Future Scope

Looking ahead, exploring opportunities to integrate a smart suggestion feature for event management and scheduling with the help of Google’s Bard AI is an exciting avenue to explore. The AI integration can also be applied to customizing events, setting alarms and reminders, etc. IT can further be developed into an event prioritization feature to make the platform more intuitive.

Although Google’s workspace is an ecosystem in itself, we could consider avenues of partnership with 3rd party project management tools like Notion, Jira and more to increase the TAM and capture a larger range of audience which might prefer a variety of different tools.