wm | ux

CASE STUDY: Rhino Splits  

Company: Rhino Splits — fictional tech start-up

Project: Rhino Splits app — a person-to-person payment application, or digital wallet

My Role: Research and design of app

Project Duration: 12 weeks

Project Background: In Spring 2018 I enrolled in “UI & UX For Digital Product Design”, a 12-week course at Nashville Software School. Our instructors created fictional client company Rhino Splits and assigned each of us the task of designing their product. Each student in the class worked independently, leading to a variety of different design solutions by the end of the course. The following is my Rhino Splits app! 

Client Vision:

The first step in building a solution was understanding the problem -- the goals that have yet to be met.

When I joined Rhino Splits the owners were in the initial stages of building a person-to-person money transferring app, a.k.a. a digital wallet. We discussed their goals, constraints and concerns, and I was able to better define the challenge at hand.

• Their goal was to be “the most trusted, most used digital wallet” for individuals exchanging payment with individuals.
• They know there are a ton of these apps out there already but believe there’s room for another.
• Primary users will be middle-income millennials and moderately tech-savvy.
• Rhino Splits’s values to translate to the app: innovative, trustworthy, and customer-focused.
• Users must sign up and connect their bank accounts to the app. 
• Transferring money is free except when using a credit card, which requires a 3% fee paid by the credit card user.
• No business transactions at this time.
• The platforms (desktop, mobile, etc.) can include whatever users want.

The main takeaways were evident - we’re building a user-focused product, our goal is to be trusted and easy/desirable to use, and we’ll let users tell us what they want this app to do. From the client’s insights, I was able to create the initial Challenge Statement: 

Investigating the competition:

I thought about how individuals currently resolve the need to pay each other, including the use of cash and checks, and further researched several competing person-to-person money transfer apps. I focused on the three most successful competitors — Venmo, Zelle, and Square Cash. To understand each of these apps better, I:

• Performed a S.W.O.T. (Strengths, Weaknesses, Opportunities, Threats) analysis on each
• Read case studies where I could find them
• Tested them personally
• Observed other users in action when possible
• Asked questions that invited users to talk about competitor apps during interviews

This process led to the accumulation of some key insights on each major competitor and general insights about apps in this space. The image below documents these insights:

This analysis illuminated opportunities for Rhino Splits to improve on other products’ designs, but nothing jumped out yet as a means of setting our product apart. The major takeaway was that each competing product appeals to a different subset of users. Those qualities or features that one user loves in an app, another user may hate.

Understanding Users:

I conducted interviews with 5 target users and had some informal conversations with a variety of individuals about exchanging payment with others. The interview script I prepared can be found here. I asked interview participants questions about their need to pay other individuals and receive payments, how they currently accomplish the task, and their feelings about their method. I also asked about related subjects like:

• How couples split payments 
• How friends and coworkers use digital wallets
• What users love and hate about their favorite/least favorite of these apps
• How they decide which apps to trust with their money
• What influences users’ choices in digital wallets
• Current use of technology to manage their money 
• Their relationship to their finances in general; their goals and anxieties

After interviewing users, I used card sorting and journey maps, and I created a user persona to discover patterns and better understand my findings. I documented these as “User Themes & Insights.”

It became clear from the research exactly what Rhino Splits could do to satisfy an as-yet unmet need — Rhino Splits would be a tool for sending/receiving payments, but it would also be a means of setting and reaching financial goals. It would be easy to use, and the complexity of setting financial goals and transferring money between those goals’ funds would not get in the way of the core payment feature.

It was time to refine my challenge statement to encompass these findings:

Designing the App:

Next, I dove into the high-level design for Rhino Splits. I thought about everything the user would need to be able to do and where it should be accessible. I knew that a thoughtful information architecture would be key to ensuring interactions that wouldn’t confuse users or leave them feeling lost, so I spent a lot of time on this step. I designed the structure of the app to include 2 main sections — the Payment UI and the Dashboard UI — and 2 secondary sections — User Settings (where account numbers, security settings, etc. can be found) and a Utility menu (including a log out feature, a F.A.Q. page, and a contact-us feature).

As I gained confidence in Rhino Splits’ information architecture, I began working on wireframes for individual screens and interactions within the app, including user flows for success/error interactions and rules for when to use them.

I tried to keep wireframes less detailed than the end prototype would be, as this prevented my getting bogged down in aesthetic decisions and helped me concentrate on designing interactions rather than details I could focus on later.

I iterated through ideas via wireframes, refining the design when I realized an interaction was more complex than I intended or that there was a better path than the one I’d gone down. Where possible, I used some informal testing to verify my design’s ease of use and ability to engage users. In one instance, I began to design a payment process that entailed using one screen for each step (a Contact UI, an Amount UI, a Note UI, etc.). I asked two individuals previously interviewed to provide feedback, and I learned that my design actually seemed to overcomplicate a relatively simple process. When I switched to a single screen version of the payment form, the user reaction was much better as the process was immediately more intuitive and less stressful.

The Prototype:

When I felt confident in the interactions and wireframes I’d designed, I tackled the interactive prototype, seen here. Currently, you can use the prototype to:

1. Split concert tickets 3 ways and request payment from 2 friends (hint -  Eric and Rob are your friends).
2. View a goal fund that’s reached 100%.
3. View a goal fund that’s yet to reach 100%.

Next Steps:

Usability testing thus far has been limited, so my next step will be to test the current Rhino Splits design with 5 users and make any changes that come out of that process. 

I would also like to build in a few more interactions — perhaps the transfer of funds between a wallet and a goal fund or the transfer of funds from the app to one’s bank account — and conduct another round of usability tests including these new interactions.

Conclusion:

Focusing on the user throughout the Rhino Splits design process revealed a key insight that I otherwise would not have known — that our target users have no trouble or anxiety exchanging digital payments with one another, but they do have difficulty saving money. This insight helped me design a product that I'm confident will be easy and pleasant to use and will actually help individuals in their daily lives.

Lessons Learned:

Following are a few of the lessons I learned about the design process while working on Rhino Splits. The lessons are not specific to this project, and I would not necessarily included them in a client-deliverable case study. I account for them here to emphasize my desire to grow as a designer and continue to learn through experience.

• If Rhino Splits were a real company, or if I were working on an existing product, I'd want to talk with the development team during the research phase to clarify what data we'd have access to on the front end.
• Establishing a rapport with interview subjects allowed me to go back and ask them clarifying questions after the initial interviews. It also made it easy to request their engagement in usability tests.
• Documentation of all design decisions when they are made is vital. I know this logically, but stopping to document decisions is an easy step to skip. Unfortunately, skipping this step makes life much harder later.

Thanks so much for reading the case study!

home