Daily Dollar
A traveller’s budgeting companion.
PROBLEM Hypothesis
It is challenging to track expenditures while traveling abroad due to currency changes and frequent cash spending.
PersonaS
Three personas were created to represent different user groups. One is shown below.
Jackie - the "super traveller"
Goals:
- Her budget goal is $50 a day and she is reasonably good at sticking to it (except on flight days), but has trouble with remembering what currency and conversion rates exist in the numerous countries she visits
Current Budgeting Solution:
- Right now she tracks the money she withdraws from the bank on her home banking site, and attempts to track each expense by writing them in the notepad app on her phone although that frequently gets forgotten
Needs & Desires:
- Jackie wants to stick to her budget of $50 a day and is hoping to lower that goal when she reaches Asia
- She needs to be able to quickly enter each expense in busy situations or at breaks in the day while she still remembers
- It would be great if she could review her spending for the week, or month so she can see where to cut costs
- She would love to know the conversion to USD at a glance to understand how much each expense is for her budget
Characteristics:
- 23 years old
- Single
- Has a younger brother, Tony, who looks up to her
Background:
- Graduated with a Tourism Management diploma from Humber College
- Bitten by the travel bug after completing a 12 day “Experiential Learning” trip to Paris as part of her diploma
- Has been traveling around Europe for the past 4 months and is about to guide her trip towards South East Asia
- Her trip is not planned and she drifts with the best crowd or with the weather. She enjoys the spontaneity of not knowing where she will be tomorrow but is rather strict with her money as she is traveling on hard earned summer job savings and wants to travel as long as possible
Wireframes
The following sections will focus on one of the five main screens of the app. The screen discussed will be the "Add Transaction" screen. The rest of the application went through the same process, but will not be shown here in order to limit page length.
Decisions about navigation and layout were made through wireframe experimentation. The OS selected was iOS.
The “add transaction” screen was selected as the home screen to satisfy the need to quickly record a transaction. It is the most frequent interaction for a user.
As soon as a number is entered in the text field, a user sees the amount converted to their home currency. Therefore, the home screen can also be used as a quick currency converter.
Selecting the category of spending when entering a transaction allows for a spending breakdown of the budget.
The category button is also the “enter transaction” button because it is the last thing you select when entering a transaction. Therefore one less action is required when entering each transaction.
A typical iOS keyboard is used for transaction entry.
Usability Testing - Round 1
A prototype of the wireframes was made in Balsamiq for usability testing. A script was used to guide the users through a realistic travel situation and to ensure consistency in testing. Below is a summary of the tasks each user was asked to perform.
1. Create a new trip with DailyDollar
2. Add a 3 euro expenditure on transportation
3. Determine the conversion rate and amount in US dollars
4. Add a 3 euro expenditure on activities
5. Add a 3 euro expenditure on transport
6. Review your spending compared to your daily and/or trip budget
7. Review your spending over time for the whole trip
8. See a list of your transactions
9. Add a 3 euro expenditure on activities
Qualitative results were gathered through questions after the test.
Five users were tested because testing 5 users will typically find 85% of the errors (Why You Only Need to Test with 5 Users, Jacob Nielson). Before testing, benchmarks were created as targets for user testing. The results clearly show that task 2 and 8 were above the benchmarks in both errors made (left) and time taken (right).
Difficulties when adding the first transaction (task 2) is problematic due to the requirement to add a transaction quickly. However, users were able to add the transaction eventually and the second time they were asked to add a transaction (task 4), they did this quickly and without errors. This shows that the learning curve was overcome by the second transaction entry. This is acceptable.
Difficulty with task 8 demonstrates trouble navigating to the Transaction List page, to solve this the navigation must be improved.
ITERATION
The wireframes were improved based on user testing results.
The title bar now displays the name of the screen “Add Transaction” instead of the trip name. This improves navigation by constantly reminding the user where they are in the app.
A budget remaining bar was moved from the “Review Spending” screen to the “Add Transaction” screen. Qualitative results revealed that users were most concerned about how much of their budget was left while entering transactions. To remove the need to switch screen frequently the budget bar was added to the home screen.
Based on user feedback, users can now edit the date/time of the transaction to add past (forgotten) transactions by tapping the date/time. They can also add notes to a specific transaction through the “add details” button.
A 5th category for “shopping” was added due to user feedback.
Moving to higher fidelity
Green was chosen as the application’s main brand colour due to it's association with money. Helvitica Neue was used to be consistent with iOS.
A bright salient blue was selected as the budget bar to draw attention to the user’s goal.
More appropriate icons were selected from a public icon bank.
usability testing - round 2
An updated prototype was created for this round of testing. A formal script was used for testing. Below is a summary of the tasks each user was asked to perform.
1. Set-up a new trip
2. Add a 4 euro expenditure on transport
3. Find list of today’s transactions
4. Edit transaction
5. Change daily budget
6. Find other previously made trips
7. Rename trip
8. Add a 4 euro expenditure on activities
9. Find overview of trip spending
10. Find list of trip transactions
11. Change the trip budget
12. Add a 6 euro expenditure on a gift for a friend
Qualitative results were gathered through questions after the test.
Only 3 users were tested due to time constraints. Benchmarks were once again created as targets. Task 2 and 10 were the most problematic in both errors made (left) and time taken (right).
The users struggled more with creating the first transaction (task 2) in this round of user testing. Users attempted to hit the category buttons before entering an amount which did not occur in the first round of user testing. Upon investigation, the text-box and cursor that appeared in the wireframes had been removed to reduce visual clutter. This inadvertently removed the signifier for users that they had to enter a number. The signifier should be added back.
Difficulty with task 10 revealed that the new navigation was not successful and navigation had to be further improved and simplified.
Final mocks
A navigation menu was added to clarify the navigation instead of a toggle. The new menu favors clarity instead of speed a as navigation between pages is infrequent.
The text box and cursor were re-added to the mock-up as a signifier to users that they must enter a number.
The "Budget Remaining" bar was iterated on to focus on how much of the local currency is left to spend.
The currency symbols were circled to signify that they are buttons, similar to the styling of the category buttons. The currency shown can be edited by selecting the currency buttons.
next steps
The project was submitted as part of an Interface Design course. A grade of 97/100 was received.
If the project was going to continue beyond this course, more usability testing would need to be performed to confirm the change to the navigation is more discoverable for users.
The rest of the application underwent the same process as was described above with the "Add Transaction" screen. There are three other changes throughout the app that also require further testing.
The designs are in a state that the development could start in parallel to the third round of testing as all the major components and workflows are captured in the mocks and prototype and most of the changes would be small visual tweaks.