UX Case Study: Budgeting Mobile App for Beginners
As part of Vertical Institute’s UX Design Bootcamp, I was tasked to create an application based on the topic of finance. Hence, I decided to take on a problem close to my heart, personal budgeting for young working adults.
Define The Problem
With the rising cost of living, many young working adults need an easy and efficient way for them to track their finances. Needing to key in every individual expenditure can be such a huge hassle. Imagine having to enter every dollar spent after each meal and online shopping.
The product should also guide them on how they can go about segmenting their earnings to avoid overspending and plan for the future. As habits are more easily sustained with the support of others, the app should also have a collaborative/ communal element. The goal of the app is to create a systematic manner in which users can track their income and expenditure, as well as create shared financial goals with their friends and family.
User Research
Since the first step of design thinking is to develop a deep understanding of users, I went about conducting research to uncover their motivations, struggles and frustrations when adopting the habit of tracking and documenting their finances. As there are many existing money management apps out there, I went about conducting competitive market research to figure out what users like about some of the popular budgeting apps out there, and what areas they think are lacking by looking at app store reviews and Reddit forums. The next logical step is to uncover links and patterns within user insights using affinity mapping.
Using How Might We statements and crazy eights, some ways on how to solve the problems are generated. Namely, HMW statements help reframe the issue by challenging assumptions, thereby aiding in the conjecturing of effective solutions by fusing the rational with the creative. With crazy eights, potential solutions are sketched. Some leaned towards gamification, some emulated existing solutions, and others went about overcoming user constraints and frustrations. While some ideas may seem wild, there is no such thing as a bad idea.
User Personas
The user personas inform the decision making process in the design of app interface (which features to choose or scrape), logic of user flow given their goals (what they want) and purpose (why they want it).
The first being Chloe who knows little about personal budgeting but sees the need to start correcting her spending patterns. Chloe represents many beginners who need a more guided and structured approach, but needs some flexibility and leeway as well.
The second would be Syafiq, a to-be groom who has just paid the downpayment for his BTO flat. In his mid 30s, he has more commitments than before and sees a greater need and urgency to lay out a proper financial plan for the future. Syafiq represents the population which sees greater importance in money management as they begin to take on greater responsibilities and start to lay out their retirement plans.
Information Architecture
To figure out how to structure my app, I first used Trello to sort user stories into Must Have, Should Have, Could Have, Won’t Have. The MoSCoW prioritization method forces me to focus on what makes a Minimum Viable Product (MVP) based on the target audience my app is intending to serve and its intended goal. This way I can direct my efforts on building the non-negotiables first before moving on less important features that still contribute to the business value of the app. Next, I grouped and categorized the user stories using card sorting to figure out the logical flow between the different screens and features, in order to build the site map. The information architecture diagram below outlines an information flow within the application — starting from the initial step to task completion.
User Testing
User testing sessions were conducted on Zoom. Users are told that the Figma wireframe is a clickable prototype which links multiple screens through hotspots. Testers are encouraged to ‘think out loud’ while exploring the prototype and completing the task given, so useful insights can be collected. The evaluation of the efficacy of the prototype is made based on the level of confidence in carrying out the task (lack of confusion, minimal error, little clarification of doubt), and general feedback on solution and user interface (using “I like, I wish, I wonder”).Iterations and edits were then made to the medium fidelity wireframes.
Logic behind Design Decisions (in High Fidelity Wireframes)
For each new transaction, users are prompted to categorize their expense, and decide whether it is a want/ need. After which, the sum spent would be deducted from the respective “Want” or “Need” envelope. The user would see a pop-up if the allocated limit for the category chosen has reached, prompting users to reflect by viewing expense insights. An alert notification would also be sent if the 85% of each envelope funds has been used. When the limit is breached, a pop-up notification would direct users to review expense insights. This allows users to do corrective measures, i.e. set a budget for the next-month for each category. This also allows them to see what their daily, weekly and monthly (see actual ‘wants’ and ‘needs’) spending patterns.
Users can choose whether to use the default 50/30/20 ratio, or set their own based on the goals set earlier. Upon keying in their income, this would generate the numerical values of how much they have in each envelope (based on the % assigned). This structured system makes users aware of how much they have available in each category.
The group feature is the unique selling point of this budgeting app, exceptionally for users who need company and encouragement to inculcate a habit. Using the sync feature, users can make sure the joint goal or budget is up-to-date as there might be concurrent updates across multiple users. In the event that the group goal cannot be achieved due to unforeseen circumstances, the ‘Delete Group’ feature would ensure that each users’ contributions be returned accordingly when the group is terminated (i.e. the Spain trip is canceled). The couple budget feature works like a third-party ‘treasurer’ whereby either user can add money to a category, and subtract away the amount used. It can also be used to track savings for specific needs (i.e. BTO).
Conclusion
At the beginning of the project, I wanted to create a comprehensive one-stop-shop solution that can serve the needs of busy working adults, especially those who lack a foundation in financial literacy. However, I realized that having too many features can bog down users as it seems too much of an uphill task to jump into so many habits at once. Thus, I decided to trim down the number of features to make the interface cleaner, and thereby lower the barriers of entry to usage for the newbies to budgeting. For instance, rather than building a brand-new discussion forum feature on the app, users may benefit more from tapping on well-established communities out there like that of Seedly and The Woke SalaryMan.
The process of building this prototype also made me realize that UX is a highly iterative process whereby we can never find the perfect solution; all we can do is to keep trying to improve the existing solution. This entails learning from other methods of solving the problem, and keeping a lookout on technological trends that would uncover better ways to streamline the users’ experience. Next steps for the app can include gamifying the dashboard interface further to make the experience of tracking and planning finances more interesting for users, and adding a onboarding questionnaire to better tailor the app interface for each user’s needs.
You can view the complete case study here, and view prototypes here.
Thank you!