Project : MoneyGame Group Number: 12 

Group Name: LiamNeeson Document Type: Pass 2 Portfolio 

 Stephen Tai 35015114 

     Shaun Chang 33820119 

   Ted Wu 32471112   

 Aaron Cui 27330117  

 Jesse Wang 49542103 

     

Section A: Horizontal or Vertical Prototype, plus Re­Design Rationale  A1 Redesign rationale.   After reviewing our low­fidelity prototype with the instructor and the TA team, our group has decided to get in touch with our representative users again and refine the requirements of the money tracking app.  In pass one, we felt that we did not get as much insight into these users mind because we did not ask the right questions.  Our understanding of the users’ mental models was flawed and it resulted in us building an interface that did not appeal to our target users.  In pass two, we have conducted more interviews with our representative users and identified features that are worth preserving and features that require more thought.    The features/screens that we have decided to keep from our low­fidelity prototypes are  

1. A list of expense for TODAY 2. Functionality that allows users to save their favorite purchases 

 Justification After interviewing with our representative users, we found out that these two features from prototype 1 are the most critical ones. User would still want to see a list of expense for a specific day in order to remind them where do their money goes. Experienced users would also expect some kind of functionality that allows them to save their favorite purchases, so they do not need to enter the same expense every time.  New features/ screens: 

1. A setup page where upon first use,  user needs to pre­calculate and enter his budget and select whether he is tracking his budget  weekly, bi­weekly or monthly. 

2. Budget tab now displays a character with health percentage that matches the budget left for this week/month. 

3. Calendar tab now displays a list of expenses grouped by day for the current budget period (week, 2 weeks, month).  The tab will reset on the start of new set up budget.  

4. Error preventing feature, user can only enter positive integer when setting up the budget, if user enters something else such as symbols, negative numbers or strings, the screen will display an error message asking user to re­enter. 

 Justification 

After conducting a new list of questions and interviewing with our representative users, our team have decided to come up with a new mental model in order to let our users having more interaction with our app. We came up with an idea of changing the budget tab into a tamagotchi game, where a cute character with a health bar is being shown. The health bar is a reference to user’s current budget, its health will matches the budget left for a certain period in percentage.  We found out that most of the user set their budget period either weekly, bi­weekly or monthly. So when a user use this app for the first time, a dialog will prompt up, asking user to enter the budget and setting a suitable period for the budget. The input for budget  will also be checked in order to prevent errors. Calendar tab will be modified to total expense list, where users will be able to review their expenses in current budget period. After each period, the tamagotchi game ends and users will can start a new game.  Removed: 

1. Category settings. 2. Charts tab 

 Justification We want our app to be simple and lightweight for our users, so we decided to remove some unnecessary features. We found out that most of our representative users only cares about if they exceed their budget or not, they do not really care about the summarized chart after each period. So our team decided to remove the chart tab. We also decided to remove the category setting that user need to set a category every time they enter an expense, since a lot of users are saying that this extra step is troublesome for them, it will give users negative experiences.               

A2 Additional Analysis and evaluation.   Our team decided to have a different approach towards the low fidelity prototype design. In our new design, we decided to introduce an user interacting, animated screen which has a character that acts correspondingly towards the budget and spending amount. The character has a health point bar illustrating the spending/budget ratio. Users can tell immediately how much they spent in a time period based on the character’s expression and action. For example, the character would stay happy and energetic if the user hasn’t spent a lot of his/her budget, conversely, the character would fall asleep and show tiredness if there are not much left towards the budget. This design helps our system to be more user friendly and easier to understand, and the users would more likely to open our application and use it.   Scenarios:  

1. Kenny is an UBC student who needs to control his budget because he wants to save money for grad school. He found our app in the Google Play store. When he runs the app for the first time the system prompts for a budget limit and the time period. He earns $300 a week from tutoring math and his goal is to save $100 a week so he sets his budget to $200 for the next seven days.  

2. Derp is an experience user who regularly checks how much money he can spend. He really loves animals but the apartment that he lives in does not allow any pet. Therefore Derp spend a lot of time on his  tamagotchi and he enjoys taking care of his virtual pet. 

   Walkthrough:  Task 1: Set budget and time period  

● Step 1: Download our app from the Google Play store ○  

This step should be easy for experience smartphone users however it can be difficult if the person doesn’t not have much experience with the Google Play store.  

○  ● Step 2: Run the app and enter a budget 

○  The system will display a textbox for users to enter their budget. This step is pretty straightforward  even to novice users.The system will check the validation of the input in 

case the users enter a negative value or invalid characters. if so the system will display an error message and ask the user to enter again.   

○  ● Step 3: Select time period 

There are three options in the drop down menu. the default is set to one week and the user can also choose to record bi­weekly or monthly. The use of a drop down menu prevents the user from entering an invalid input.   

● Step 4: Click OK to start There is only one button on this interface which is the OK button. The user should not have any problem with this step.    Task 2: Check budget status  

● Step 1: Click on the budget icon on the bottom right This step is obvious to the user because the icon is clearly labeled. 

● Step 2: Check the percentage of budget left The system shows the percentage of the budget and also provides visualization of the budget by displaying a character. The users should not experience any difficulty because they do not need to perform any actions other than looking the the screen.                     

A3 Prototype Illustration.   Our team has made a Axure prototype before the pass 2 design review. The prototype shows a the basic walkthrough for our application. Users can input weekly/monthly budget and a character will appear on the screen. The health bar corresponds to the budget left for users. The users can also view their daily spending in the middle tab on the bottom.  Axure Prototype Link: http://oxinm7.axshare.com/setup.html   After the pass 2 design review, our team has refined the prototype by building a basic iphone app using objective­C.  The app is a vertical prototype with the functionality such as entering new entry and saving favorite entry fully implemented.  It is the app given to the user for our control experiment.  (Figure 1 ­ Figure 3)  For the experiment, we have also developed a desktop game using the Unity game engine. (Figure 4) 

 Figure 1   

  Figure 2  

 Figure 3     

 Figure 4                        

Section B: Plan User Evaluations   B1. Purpose and goal The purpose of this study plan is to collect opinions from different users.  As developers, we would like to find out whether users are more likely to continue to use a budgeting application when we give them entertainment as a feedback to using the app. By comparing our MoneyGame app with a regular budgeting app such as Expense on Appstore, our goal is to see if the users have more desire to use our application due to our design than the original and ordinary budgeting application.  B2. Methods Type of Study We will use participatory observation.   Participants 10 university students who had tried to use some kind of budgeting application but stopped because of boredom.   B3. Tasks  The control experiment is made of two 30 minutes sub­experiments. In each sub­experiments, we will give every participants 10 number to remember every 3 minutes.   Participants are encouraged to use their personal computers to do whatever they want during the evaluation period. They can use any method to help them remember the given numbers.  However, we will provide our MoneyGame app and a commercial app called Expense during the two sub­experiments.  Half of the participants will be given Expense first and  the other half will be given Money Game.  At the end of each sub­experiment, participants will be asked to recite the numbers back to us.  We will measure during each sub­experiment 

1. how many times did each user use the provided app 2. if they did, how long does it take them to enter each entry 3. Did they recite the correct numbers at the end 

 Task 1: Users are given a number every three minutes Task 2: We ask the users to recite the number back to us.   

B4. Independent variable/ dependent variable Independent variables 

1. Users 2. Provided application: MoneyGame vs Expense 

Dependent variables 1. number of times a user uses the provided app 2. time for entering an entry 

Nuisance variables 1. things a user is doing during the experiment. 

  B5. Hypothesis  H1: There is a statistical increase in usage of budgeting application once we gamify the budgeting app H0­1: There is no difference in usage between a gamified budgeting application and a normal budgeting application.  H2: Entering an entry in MoneyGame is faster than entering an entry in Expense H0­2: Entering an entry in MoneyGame is not faster than entering an entry in Expense                  

Section C: Carry Out and Analyze User Evaluations   C1 Subjects  Our subjects are all UBC students that come from different faculty  Arts: Vivian Tina Yoome  Engineering: Jacky Kerby Michael Isa Catherine  Science: William                 

C2 Evaluations Results  First Set ­ Expense First then MoneyGame Second                 

  Expense                     

Subjects  1st  2nd  3rd  4th  5th  6th  7th  8th  9th  10th  Correct 

Kerby  15  11  0  0  0  0  0  0  0  0  Y 

William  16  11  10  10  0  0  0  0  0  0  Y 

Michael  18  0  0  0  12  0  0  0  0  0  N 

Yoome  18  0  0  0  0  0  0  0  0  0  N 

Vivian  19  11  10  0  0  0  0  0  0  0  Y 

 MoneyGame                   

Subjects  1st  2nd  3rd  4th  5th  6th  7th  8th  9th  10th  Correct 

Kerby  11  10  9  9  9  9  0  0  0  0  Y 

William  11  10  10  10  10  10  10  10  10  10  Y 

Michael  10  9  9  0  0  10  0  9  0  0  Y 

Yoome  12  10  10  0  0  0  0  0  0  0  N 

Vivian  11  10  10  10  10  10  0  0  0  0  N                        

Second Set ­ MoneyGame First then Expense Second               

 MoneyGame                   

Subjects  1st  2nd  3rd  4th  5th  6th  7th  8th  9th  10th  Correct 

Tina  11  10  10  10  10  10  10  10  0  0  Y 

Isa  13  11  11  11  0  0  0  0  0  0  Y 

Catharine  11  10  10  0  0  0  0  0  0  0  N 

Jacky  12  10  10  10  10  10  10  10  10  10  N 

  Expense                     

Subjects  1st  2nd  3rd  4th  5th  6th  7th  8th  9th  10th  Correct 

Tina  18  0  15  0  10  0  0  0  0  0  Y 

Isa  17  12  10  11  0  0  0  0  0  0  N 

Catherine  19  0  0  0  0  0  0  0  0  0  Y 

Jacky  17  0  0  0  0  0  0  0  0  0  N 

Here is how you read the spreadsheet.  In the first set of experiment, 5 users are given the Expense app first, then MoneyGame.  In each of the sub­experiment, we gave users a number to remember every 3 minutes for a total of 10 number.  If the user decide to enter the number into the app, we will record approximately how long it took them to do so.  If the user did not bother to enter the number into the app, we put a 0.  At the end of each sub­experiment, we ask the user to recite back the 10 numbers.  If they were correct, we put a Y in the correct field, otherwise we put a N.     Summary of Findings We will discuss the findings according our two hypotheses.    H1: There is a statistical increase in usage of budgeting application once we gamify the budgeting app H0­1: There is no difference in usage between a gamified budgeting application and a normal budgeting application.  Regardless of the order in which users were presented with the app, there is a higher frequency for people to enter the number into the app with MoneyGame.  On average, people enter an additional 3.78 times with MoneyGame.  In addition, when we present Expense first then MoneyGame, people still enter the number into the app during the second sub­experiment even though they realize it was the same experiment.  On the other hand, when we present MoenyGame first then Expense, people only attempt to enter the number a few times before they found the task tedious.  In conclusion, we have shown that there is a difference in usage with a gamified budgeting application so we reject the null hypothesis.  H2: Entering an entry in MoneyGame is faster than entering an entry in Expense H0­2: Entering an entry in MoneyGame is not faster than entering an entry in Expense   We will only consider the case when user did enter the number into the apps.  The average speed of entering an entry into Money Game is about 10 ~11 second.  The average speed for entering an entry into Expense is 13.8 seconds.  However, this is due to the fact that Expense has more functionalities and a higher learning curve.  If we don’t count the first time use of the Expense, on average, the speed is 11 second.  This is the same as using MoneyGame.  In conclusion, we are not able to show that there is a significant difference in speed for using MoneyGame versus Expense, so we accept the null hypothesis.    

Problems/Bugs/Limitation  

1. One problem we have noted in our experiment is that we should have given our users time to play with each app and get familiar with the interface.  This way, we will get a more accurate measurement of how long it would take them to enter a number into each app. 

2. We showed that people would be more likely to enter a number into the app if they are rewarded with a chance at the game.  However, we did not consider the possibility that people might get bored of the game after some time. 

3. We only had a small number of representative users to work with, and most of them are our friends.  We trust that they are trying their best to be themselves during the experiment.  However, our data might be biased if they tried to impress us by doing the things we want them to. 

4. The experiment was done in a one hour period and so we could not generalize the result for the long term use of this app.  There are aspects of the app, such as comparing ranks with your friends, playing a different game, that could potentially affect the success of this app but were not tested.  

                   

C3 Final design rationale and discussion of the state of your design.   After having experiment with our representative users, we realized some features are unnecessary and will have a bad influence to the user experience, so we did some adjustments  for our design. We have removed some features such as different types of summarize graph, history system and item categorize feature. We also modify our user interface by removing some unnecessary tabs and buttons in order to minimize the GUI, to provide the users a clean user interface environment. Our team has also turn the Axure prototype into an actual iphone application, our team has refined the prototype by building a basic iphone app using objective­C with basic functionality fully implemented.  Due to the time constraint issue, we did not have enough time to fully implement and develop our product. There are still a lot of functionality and graphic user interface feature that we could have work on, however, we did cover the basic functionality and feature and came up with a usable final prototype. The overall quality of the interface design for our app is not absolutely amazing, however, it  has meet our expectation. Our main  design approach was to build an app with simple and clean user interface , to make it easy for the users to navigate through the app. We have tried to stick with our goal during the design phases and came up with an application that fulfilled our expectation.   The setup page of our application work well, we realized that the setup page is very important for our app, if the users cannot enter their information properly or correctly, our app will not be that helpful for the users. We spent a lot of time to make sure the setup page delivers the correct message to the users, we made sure the graphic interface is simple enough that even for the first time user, they can enter the information properly without any extra instruction or tutorials.   We have integrated our app with a simple game that user can play at the end of every few entries, however, our gaming design still needs a lot of improvement such as leader board system.  We have been trying different games such as tamagotchi, ping­pong game, and 2­D unity game and we do not think any of them is the best fit to our app. The point is that we have been trying to come up with a method that will make our application more interesting and engaging so it will encourage the user to use our app and make the users think it is fun and interesting to use our app rather than just a boring expense tracking app.    

We believed that our system would work well for our identified users and tasks. Our identified users are college students who wish to set up a budget for a certain period and  keep track of their expenses. Our system is designed for these purposes, to keep track of all the expenses in the simplest way. Our system is really simple and easy to use , so our users will have no problem executing tasks.  

  C4 Reflection on your design process. Discuss your responses to the issues raised in Step 8  

Throughout the design process our prototype was constantly changing based on users’ feedbacks. For example, we used to categorized the spendings into several categories such as: food, accessories, gas...etc. We thought the user might be interested in how much they spend in the category, but it turned out that their only concern was to spend under the overall budget.   

The outcome of our evaluation did help us improve our design. We got a better understanding of what features do the users needed by interviewing them. The evaluation is important as well because it was the only way to figure out how much the users care about their budget. By evaluating the users we also saw the differences between our project and similar application that is already on the market.  

 The most valuable part activity in this project was making a low fidelity prototype 

on Azure. Prior to having this prototype we had to use paper prototype to it was difficult to simulate the connection between each hand­drawn interfaces. Even without all the functionalities the Azure prototype still gave a good view of how each components were linked together. Making two alternative designs was the least helpful activity because as developer we tried to make the favoured design as good as possible and intentionally added flows to the other alternative designs to prove that they would not work.  

In our next interface design project we will apply a the materials that we learned in class, especially prototyping and evaluating. In the past we all had experience with designing user interfaces, however we underestimated the importance of receiving feedbacks from the users. After we went through this project we learned a lot of techniques on assessing the interface from user’s perspective. 

  

Section D: Resource Management Aaron Cui Main tasks: Experiment from high­level designs down to detail designs (3­5 hours), game design used in experiment (5­7 hours), analysis of gathered data & forming conclusions for experiment (2­3 hours). Side and/or team tasks: Generating hypothesis (1 hour), preparing and acting in promotional video (2 hours), tested 3 subjects for our experiment (2 hours), preparing relevant presentation slides and the actual demonstration (2­3 hours). Total estimated time spend for pass 2: 20 hours with an error range of up to 3­4 hours. Noteable details: Constructed a test game associated with our app in unity using existing free assets and demo provided by Unity where it can take a user input to affect in game variable (eg. budget percentage as heath percentage). Came up with the overall idea for the experiment in how to compare our app to an average app in measurable data quantitatively with as little bias / difference to real world scenario as possible.  Stephen Tai Report writing 

1. sections A1, A3, all of B, C2 (5 hours) Prototype Development: 

1. Axure prototype used (3 hours) 2. Iphone MoneyGame app used for experiment (3 hours) 

Miscellaneous 1. Prepared presentation slides (1 hour) 2. Experiment with representative users (2.5 hour) 3. Video making ( 2 hours) 

  Shaun Chang Report writing/modifying 

2. sections A2, B (2 hours) Prototype Development: 

3. Unity game (5­6 hours) Miscellaneous 

4. Prepared presentation slides (1 hour) 5. Experiment with representative users (2 hour) 6. Video filming ( 2 hours) 

 

Ted Wu Report writing: 

1. sections A1, A2, C3 (3 hours) Prototype Development:      1. High level design down to low level design (10~ 15 hours) 

­ Designing proper mental model ­ Designing GUI idea ­ Designing proper game idea to integrate with the application  ­ Designing interview questions  ­ Doing actual interview with representative users ­ Task/walkthrough  

Miscellaneous:     1. Prepared presentation slides ( 0.5 hour )     2. Designing experiment ideas  ( 1 hour ) 

­ Hypotheses, IV, DV.  Jesse Wang Report writing: 

section A2, C4 (2.5 hours) Prototype Development:   low­fidelity prototype design (2 hours) 

high­fidelity prototype discussion (1 hour) Miscellaneous: 

Making presentation slides ( 1 hour ) Video filming (2 hours) 

    

  

  

     

 

Appendices   Interview questions for redesigning prototype 1. Do you budget by week or by month? Do you know how much you have to spend per month before the month starts? 2. What do you expect from budget control app? 3. Do you ever look at spendings for last month? last year? last week? If so, how often? 4. On a scale of 1 to 5 (1 means doesn’t care at all), do you want to look at a chart representation (like pie chart / bar graph) of your overall expense?  What if that means you need to categorize your expenses every time you enter them, Would you change your mind? 5. Is it realistic to ask you to budget all your spendings after every purchase? Would you change your mind if you see all your friends do it?   Completed Interviews Interviewee: Vivian 1. Do you budget by week or by month?     By week. 2. What do you expect from budget control app?     be more aware of my spending and have more control of money 3. Do you ever look at spendings for last month? last year? last week? If so, how often.     very rarely 4. On a scale of 1­5(1 means doesn’t care at all), do you want to look at a chart representation (like pie chart / bar graph) of your overall expense ? What if you need to categorize your expenses every time you enter it, rescale it again.      4, changed to 3 after she learned that users need to enter expense with category with tradeoff 3 5. what if your friends do it     no until they learn all their friends do it  Interviewee: Kerby 1. Do you budget by week or by month? Do you know how much you have to spend per month before the month starts?     Biweekly 2. What do you expect from budget control app?     Breakdown of spendings in each category, eg food, gas, grocery, entertainment 

3. Do you ever look at spendings for last month? last year? last week? If so, how often.    look at spendings up to a few months ago.  look at them once a month 4. On a scale of 1 to 5 (1 means doesn’t care at all), do you want to look at a chart representation (like pie chart / bar graph) of your overall expense?  What if that means you need to categorize your expenses every time you enter them, Would you change your mind?     5, with tradeoff  becomes 1 5. Is it realistic to ask you to budget all your spendings after every purchase? Would you change your mind if you see all your friends do it?     probably not even if friends do it  Interviewee: Tina Lin 1. Do you budget by week or by month?     by week 2. What do you expect from budget control app?     control the budget 3. Do you ever look at spendings for last month? last year? last week? If so, how often.     last month. once a month 4. On a scale of 1­5(1 means doesn’t care at all), do you want to look at a chart representation (like pie chart / bar graph) of your overall expense ? What if you need to categorize your expenses every time you enter it, rescale it again.      3, changed to 2 after she learned that users need to enter expense with category with tradeoff  5. Is it realistic to ask you enter your budget after purchase? what if your friends do it     no until they learn all their friends do it  Interviewee: Isa Cheng 1. Do you budget by week or by month? Do you know how much you have to spend per month before the month starts?     by month 2. What do you expect from budget control app?     send alerts when i’m close to the limit 3. Do you ever look at spendings for last month? last year? last week? If so, how often.     last month 4. On a scale of 1­5(1 means doesn’t care at all), do you want to look at a chart representation (like pie chart / bar graph) of your overall expense ?     3 5. Is it realistic to ask you enter your budget after purchase? what if your friends do it     yes, but may stop using it after a while 

  Interviewee: Catharine Fan 1. Do you budget by week or by month?     by month 2. What do you expect from budget control app?     record the items I bought 3. Do you ever look at spendings for last month? last year? last week? If so, how often.     last month 4. On a scale of 1­5(1 means doesn’t care at all), do you want to look at a chart representation (like pie chart / bar graph) of your overall expense ?     4 5. Is it realistic to ask you to enter every spending after every purchase? what if your friends do it     yes, will use it regardless  Interviewee: William 1. Do you budget by week or by month? Do you know how much you have to spend per month before the month starts?     by month 2. What do you expect from budget control app?     notification when almost hitting budget line, statistic on spending, slope diagram etc, pop up notification. event spending reminder 3. Do you ever look at spendings for last month? last year? last week? If so, how often.     per month, look at it along with credit card bill  4. On a scale of 1­5(1 means doesn’t care at all), do you want to look at a chart representation (like pie chart / bar graph) of your overall expense ?     n5 if it is default to the general category.  If need to manually choose one, then 1 5. Is it realistic to ask you enter your budget after purchase? what if your friends do it     no, too lazy to use one at the moment