As part of my part-time ten-week User Experience Design course from General Assembly, I wanted to research and analyze a problem that I suspect many people encountered. For me, my area of interest was trying to come up with a solution to something I've personally dealt with in the past. I believe that many couples find themselves spending frivolously on items and outings without having a defined system to keep track of their joint expenses. My goal was to come up with a solution to incentivize or penalize partners in relationships so that they can make the right financial decisions and control their personal and joint finances. During my ten weeks at General Assembly, I conducted user research, completed a competitive analysis of the market, mapped users' journeys through user flows, and created wireframes, mockups, and prototypes to test on myriad user groups and demographics. To see a copy of my final presentation, click here.
I believe many couples do not have a defined system in place to keep track of their joint expenses. However, partners keep a mental model of how often they pay and how often they let their partners pay. Couples might be reluctant to discuss finances because a negative societal stigma exists around talking about finances. Another reason to avoid discussing financials might be the underlying dynamics of a particular relationship (e.g., if one or both partners struggle with financial difficulties or if one partner feels as if the other spends money irrationally).
Technologies and applications exist to allow users to split and share expenses but few apps focus on centralizing financial management for couples.
Prior to conducting my research, I identified three main goals or objectives that I wanted to understand or learn more about.
Firstly, I wanted to learn if and how married and unmarried couples manage their finances. By understanding users’ current process, I would be able to pinpoint pain points and discover workarounds that couples were using to accomplish their goals.
Secondly, I wanted to understand the source of any social frustrations or barriers that couples face when discussing financial issues. For me and many of my friends, talking about money is difficult, and I wanted to know how other couples handle discussions related to money.
As a result, I came up with a list of eight questions that I was going to ask individuals in relationships. Once each individual in a partner completed his/her individual portion, I was going to interview the couple together and ask them to openly discuss a list of 3 more open-ended questions. By starting with individual questions first and then moving onto open-ended questions, I would be able to determine whether partners in these relationships were being candid or if they were being disingenuous.
For my interviews, I interviewed a total of six couples, or a total of 12 people. I wanted to select as diverse a pool as possible, so the demographics of those who were interviewed varied in amount of time together, age, relationship status, sexuality, as well as other factors. Out of the six couples, one couple was married, two couples were engaged, and three couples considered themselves dating. All but one set of interviews was conducted in person. The last interview with one of the couples was held virtually.
From the answers gathered, I mapped each answer to a traditional affinity map, with six top level categories - pain points, feelings, wants, motivations, values, and needs. Overall, it appeared that most couples did not closely keep track of what they spent or how much they spent each time they went out to eat. In addition, I sensed a lot of guilt in both individuals that let their partners pay the majority of the time as well as couples that felt as if they should have had a system to keep track of their expenses. Couples also judged their relationships based on several criteria - fairness, independence, and sacrifice.
From the diverse group of interviewees I spoke to, I came up with two main personas. When constructing my personas, I had to decide whether or not I was going to separate couples into individuals or if I should keep them together. As a result, I decided to target couples as my persona because the system should be shared by both partners, and both partners will have shared pain points and goals that are based on compromises and what was explicitly shared during their interviews with me.
From the interviews conducted with couples, I came up with a list of criteria that were important in helping them manage their finances. Aside from the standard set of criteria that apply to all human-facing technologies such as overall usability and accessibility, common pain points users voiced include low maintenance and ease of initial setup (specifically account creation).
From my external research, I wanted to determine whether there were other applications or alternatives already in the market that would allow couples to keep track of their finances together. I was able to find four main alternatives, all mobile-first applications. Out of the dozens of alternatives out there, I narrowed down my competitive analysis and focused on four applications designed to help target the issue of personal or joint finances. The four alternatives I identified were Honeydue, Our Expenses, and Honeyfi, and Twine.
Based off of feedback and pain points that users voiced for these four applications, one major issue users faced was the long duration of the signup process. From this analysis, I created a first pass at the user flow for a first-time user. To improve upon the process, I evaluated the four alternative apps and went through the sign up process for each. Points of friction exist when these apps require a user to add and link an existing bank account, without providing the ability to skip this step in the process.
After a user is logged in, there are a variety of different outcomes they will want to achieve. These outcomes include logging new transactions, editing or adding bank information, or reviewing previous transactions.
To begin the design stage, I started by creating some high-level sketches for the different screens a user would encounter in each stage of their user flows. These initial sketches were done using pen and paper, and I wanted to map out the flow of a user's journey throughout the app to make sure there weren't any complications or difficulties.
After these sketches were completed, I transferred these to more high-fidelity wireframes to allow users to test the skeleton and structure of each page. I wanted to make sure users weren't confused by the layout as well as the design of common components such as buttons, input fields, and labels.
The overall feedback on these initial sketches from test users was generally positive. The only feedback I received was the overall legibility of text and whether specific fields within the sign-up screen should be made required or optional. Some of these changes were made and are reflected in the wireframes below.
In order to better organize and visualize some of the pages and screens a user would encounter during their journey, I drew an information architecture map that contained all the content users would interact with. Creating this map allows me to identify how the site will be laid out from a practical perspective. Additionally, if I were to hand my work off to a third-party, this IA map would allow other people working on this application to visualize the hierarchy of information.
I wanted to organize and lay out information in an effective way that makes sense to users, so I based this off the vocabulary that was mentioned in the interviews I conducted as well as from the research I conducted. By labelling items in an organized manner and in a way that is consistent with the way users understand them, users will be able to browse and move through the screens more easily.
I used and focused on two typical mobile navigation paradigms - tabs and nested doll. I chose to implement tabs as my main navigation pattern because the number of pages a user can access from the home page is limited. However, once users get to each one of these tabs, they can navigate down a tree to additional menu options. Each main action a user performs is linear, so a nested doll pattern is well suited for this type of lateral movement.
At its core, every application that's built must be functional. However, as the functional requirements are satisfied, users will request additional features that are less "needs" but more "wants". Prioritizing these features is essential to maintaining a focused roadmap that ensures the features that provide the most value are completed first.
To keep track of which features are most important to users, I created a four-grid prioritization matrix which lists out which features and requirements are highest priority. These features come straight from research and interviews I conducted with my initial user group.
From these different features, I plotted the complexity and business value to determine which features should be prioritized. The core features that should be implemented first are the ones in the upper right-hand quadrant, where as the nice-to-have features are the ones in the bottom left-hand section. My prototype tackles most of the core requirements that users desire, but as I continue to work and refine it moving forward, I'll continue to add additional features from this prioritization matrix.
As my background is more focused on the technical implementation and development of applications instead of the visual or design aspects, I had to learn about art direction and design. This was by far one of the most interesting parts of my project, and I really enjoyed learning more about the visual side of building and dictating how applications should look and feel.
One of the deliverables of my project was to create a mood board. I hand-picked images and colors that I thought would be representative and make sense in the context of Mokanei. The three primary colors I picked mean different themes and convey different emotions. The primary color, blue, provides a sense of security associated with most banking or financial applications. Hints of green and pink also are sprinkled through the application; green is associated with money and wealth, where as pink is a color that denotes love and safety.
The name Mokanei comes from the Japanese word "Okane", which is a respectful term for money. It's an honorific term that is usually used to address the topic of money politely or with respect. Money is a sensitive topic both in the United States as well as many other countries around the world, so I wanted to convey that nuance by alluding to a culture whose backbone is deeply rooted in respect and good etiquette.
At the end of the day, I designed the overall look and feel of the application to use more of a subdued color palette and rely on traditional design patterns. Because Mokanei is a financial application, users will want their data to be secure and protected. The more complicated an application is, the less likely a user is to using or trusting it.
All of my work culminated in a final prototype I developed using Invision. I shared and presented this to the rest of my class, who all provided valuable feedback that I have implemented in the latest version of my prototype. This prototype was also tested with a small subgroup of users that I interviewed during my research phase. If the demo doesn't load below, try clicking here.
Thanks to everyone who helped me accomplish this case study. I learned a lot about the formal UX process and best industry practices during this class. I know taking this ten-week bootcamp is just an introduction to the expansive world of UX, but it's helped me get a foot in the industry. I've always had an interested in the design side of building digital products, so I'm glad I could take this course.
I'm grateful to all the cooperative interviewees I had the pleasure of talking to. I appreciate their candor in talking about a topic that can be difficult to talk about. I also want to thank Aaron Scott, my instructor at General Assembly for taking the time to mentor and lecture me in and outside of the classroom. I also want to specifically thank Jason Guenther and anyone at Putnam who helped make taking this class possible for me.