User-centred Design by Charlot Felderhof

u s e r c e n t r e dd e s i g n g r o u pF 5

ma i nb o d y

C h a r l o tF e l d e r h o f k a t e l i j nv a nk o o t e n r a n i s k r a b a n j a ma x i mev a l l e n t i n s 1 5 8 7 5 2 s 1 6 3 7 6 0 s 1 6 7 4 5 6 s 1 5 0 0 7 1

Table of content Main body 1

Table of content

Week 1

2 2 3 3

A. B. C. D.

Week 2

3 4

A. Persona hypothesis B. Ethnographic interview

Week 3

5 6 6

A. The five requirements B. Perception, Cognition, Action cycle C. Mapping, Affordance and Constraints

Week 4

7 7 7 8

A. B. C. D.

Week 5

9 12

A. Low-fidelity interactive prototype B. Task description

Week 6

12 13 13 14 14

A. B. B. C. D.

Week 7

15 16 16 17

A. B. C. D.

Storyboard of the current situation Joint context of use analysis for the design case Experience goals and motivations Notions of effectiveness, efficiency and satisfaction

Scenario of use Task description Joint QOC analysis Conclusion

task description Heuristic evaluation Cognitive walkthrough Changes of the prototype Discussion of differences between heuristic evaluation and cognitive walkthrough

Setup user test according to DECIDE Framework Results of user tests Comparison of expert evaluation and user evaluation Redesigns of the app based on the user tests

Week 1 A. Storyboard for the current situa:on - Katelijn van Kooten

B. Joint context of use analysis for the design case  We’ve chosen for the case with target group teenagers and young adults. Teenagers and young adults should be made ready to stand on their own feet. They’re o;en spending too much money because they don’t have a good overview. They spend much money on food, clothing, drinks and new technologies. We’ve chosen to scope our target group further to HBO- and WO-students. These students borrow money from the government. You can borrow as much money as you want (to a certain limit) but in the end you’ll also have to pay it back, so for this target group it is extra important to keep track of their spendings. You can create enormous debts without really noFcing. Teenagers and young adults who work but don’t study can have difficulFes with their finances too but they receive a lot of money too and they don’t have to maintain a student loan. The target group has restricFve qualiFes for this case like being impulsive, acFng irresponsible, easily tempted, impaFent, easily distracted and having difficulFes with saving money. However, they also have useful qualiFes like being good with new technologies, literacy, good hearing and sight, able to adapt to new circumstances. We can analyze our target group within different environments. Their physical environment is that they’re relaFvely young, have an acFve lifestyle, their hands can work precisely and they’re physically strong so not easy to rob. Analyzing their social environment, they undertake many acFviFes with peers, they pay in groups, they can suffer from group-pressure, are o;en socially insecure and they are in a phase of self-development.

Our target group is o;en organizaFonally weak: they have difficulFes with organizaFon of transacFons and have difficulFes with planning. Considering their technical environment, they have good understanding of all different kinds of technologies, can learn quickly and have a good memory. The tasks that should be carried out for making a payment are: check your balance, find wallet, open wallet, find bankcard or cash, use bankcard or cash, receive change and receipt. Currently, there are a few boOlenecks in the way the tasks are carried out. Teenagers and young adults have difficulFes seeing the difference between spending 10 or 100 euros. They don’t get (much) feedback on if they’re doing the right thing or not. Also, they have a low threshold for temptaFons which results in impulsive purchases. Not only teenagers and young adults are involved in this case, there are also addiFonal stakeholders. The parents invest money in their children and they except their children to not just throw their money away. Banks want teenagers to save much money, which is good for their own business. The government invests money in you too and they want to see the money and a contribuFon to society in return.

C. Experience goals and mo:va:ons The experience goals include becoming more aware of how much money you are spending. The user should get the feeling of holding real money and how much bills it would actually be, but virtually. We think it is important that students have a beOer feeling on money, so they become more aware, but we ﬁnd it very important that it is not a tangible product, because it becomes something extra that they need to take with them, while they just what to pack light and be ﬂexible. The user should also go spend less money, because he becomes more aware on what he is spending is money on. But it sFll should be quick and easy to use and therefore also easy to understand. When it is not quick to use, the student will not use it, because we live in a society where Fme is very valuable.

D. No:ons of effec:veness, efficiency and sa:sfac:on Together we discussed the noFons of effecFveness, efficiency and saFsfacFon and we came up with a joint outcome. For effecFveness, we want our product to make people spend less money than in the current situaFon. For efficiency, we want the transacFon to go equally quick or quicker than in the current situaFon. For saFsfacFon, we want the target group to save more money than in the current situaFon.

Week 2 A. Persona hypothesis - Charlot Felderhof Lisa, 19 years old Lisa lives in a student home. This is the first Fme she is not living with her parents because she just started her study. For her room she has to pay 300 euros rent per month. She can afford this room, because she loans money from the government. She has set a budget for herself for 350 euros in a month, rent not included. But she finds it very hard not to go about her budget, because Lisa is very impulsive and unconscious. She spends the most money on clothes and going out with friends. She almost always pays with card, only when she goes to the club, she pays cash. She checks her balance and her incomes through her banking app. Tom, 23 years old Tom is already started on his master. He lives together with his girlfriend in a small apartment, for just 350 euros per month per person.  He has a job at a nog firm where he can do liOle tasks to earn a liOle more money next to his student loan. He has set a 3

strict budget for himself and has learned how not to go about his budget. He spends most of his money on dates and trips with his girlfriend and food. He also drinks the occasional beer at the study associaFon on Thursday.   He always pays with card. He checks is balance and spendings through is banking app.

B. Ethnographic interview   1. Process We took 12 interviews in total. From Students from the TU/e and the Fontys in Eindhoven, as students from other ciFes as Amsterdam, Utrecht and Den Haag. We interviewed six men and six women. They mostly lived on their self and some sFll lived at their parents houses. For our interview we were looking for: • What students their budget is. • How they make sure they don’t go about their budget. • What they think of the app/site of their bank. • Do students prefer to pay with cash or card and why? • Do they have the same feeling when they pay with card as they pay with cash. Our biggest insights were: • Students mostly pay by card • Students use the app on their phone a lot, but they would like a clearer overview in the app of their expanses. • Students don’t know how much money they are spending in a month on food, clothes or going-out, Students do know how much money they are spending in total in a month • Students spent too much money while going-out and they o;en feel guilty about it • Students also ﬁnd privacy and security important. The ﬁnal list of quesFons is included in the appendix.

2. Results: Personas - Charlot Felderhof and Rani Škrabanja

Sophie

Age Current situa:on Likes Dislikes

17 Student, living in a student home Going out with friends, pets, social media People who do not respect agreements and deadlines

Sophie is a ﬁrst-year student at university. With many friends, a study and a job she has a busy life. Her job makes her monthly budget slightly larger. Nevertheless she really likes shopping. Recently she noFced that she is spending more money when she is with her friends. To keep track of what she is spending she uses the bank app very o;en. Last month her grandparents gave her €200 for her birthday, but she immediately spent it on a new phone. When she got home she felt really guilty at ﬁrst. But a;er a couple of days she already forgot she spent so much and went shopping with her friends. She always uses her bank card or credit card to pay things, because she thinks it’s way faster than paying with cash. She also thinks cash is a waste of paper and trees. She wants to make people aware of how many trees are chopped down for paper. Also she wants to clarify that for this paper too many have disappear. Needs Awareness of money, fast payment, organized overview

Tim

Age Current situa:on Likes Dislikes

20 Student, Living in a student house, single and member of a student associaFon Going out, parFes, social media, playing guitar Gefng up early

Tim is a third-year student at Fontys. He has a busy life, because he is very acFve in his student associaFon. He loans a lot of money of the government. He spends a lot of money on drinks and going out. O;en the day a;er a party he regrets spending too much. He has a hard Fme saving money, because he doesn’t know how much money he is spending in a month on food, clothes, going out. On the other hand he does know how much money he is spending in total in a month. He uses the app on his smartphone to keep track of his purchases, but he would like a clearer overview. He mostly pays by card, because he thinks Fme is money. Needs Someone who tells him that he spends too much money, clearer overview

Week 3 A. The ﬁve requirements Func:onal requirement Example: The product should make you aware of the amount of money he/she is spending and should make spending money more meaningful. Type of requirement: FuncFonal requirement DescripFon: The product should make you aware of the amount of money he/she is spending and should make spending money more meaningful. Fit criterion: The product should track the spending’s of the user and give the user feedback of it to make him/her more aware of the amount of money he/she is spending at that exact money. The users should spend less money, when using the product. Customer saFsfacFon: 4,5 Look-and-feel requirement Example: The product should be privacy aimed, but also you should be able to always bring it with you. Type of requirement: Non-funcFonal requirements DescripFon: The product should be privacy aimed, but also you should be able to always bring it with you. Fit criterion: Other people don’t have access to your data, or should not be able to sense anything that your product is telling you. Also the product should be light-weighted and small. The product should not be heavier than 10 grams. When tested, the people surrounding the tester cannot see/feel anything the tester is seeing/feeling. Customer saFsfacFon: 4 Ease of use requirement Example: The product should be clear and with liOle acFons. Type of requirement: FuncFonal requirement DescripFon: The product should be clear and with liOle acFons. Fit criterion: Test how much Fme the acFons take and make sure that potenFal buOons have clear symbols. The users who are tesFng should take no longer than 7 seconds to ﬁgure out the buOons. Customer saFsfacFon: 3,5 5

Ease of learning requirement Example: Use of Skill-based interacFon or interacFon based on general knowledge Type of requirement: FuncFonal DescripFon: Use of Skill-based interacFon or interacFon based on general knowledge Fit criterion: Test if people understand the product without them having to read instrucFons. The users who are tesFng should take no longer than 3,5 minutes to ﬁgure out the product without reading the instrucFons. Customer saFsfacFon: 3,5 Performance requirement Example: As quick as or quicker to use than the current average transacFon Type of requirement: Non-funcFonal DescripFon: As quick as or quicker to use than the current average transacFon Fit criterion: Measure Fme. The transacFon cannot be longer than 8 seconds. Customer saFsfacFon: 4

B. Percep:on, Cogni:on, Ac:on cycle  What are perceptual issues? There can be absolutely no misunderstandings about any symbols. Money is a very serious maOer and a lot is depending on it and therefore nothing should go wrong. The users should also have a lot of confidence in what they are doing, there are no situaFons aloud in which there is an uncertainty about the end result. In such cases the product will be a predetermined failure. A bank must be defined by confidence and security.  Will the product be used frequently? The product will be used a lot, up to four Fmes a day, so the product should be simple to make it accessible for the user to use it o;en. The funcFons should speak for themselves. You should not feel retained to use it and it can not be Fme consuming. What foreknowledge will the users be expected to possess? Most of the students already have common knowledge about money, transacFons and their technologies. So there is no need for big explanaFons about what payments are. Instead we can cut immediately to a short and simple guide to show the product itself, all its funcFons and possibiliFes that come with it. Also students in this century have a lot of experience with modern technology and by using standard formats there will be no technical obstacles. Privacy is very important to the modern student that is why security is high priority.

C. Mapping, Affordance and Constraints We think an important condiFon of mapping that has to be fulfilled is that all buOons are ranked in a logical way and that the symbols expressed have clear meaning. The placing of the buOon on the screen should be logical. For example if the user presses the menu buOon placed at the le; side of the screen, the applicaFon should appear at the le; side of the screen as well, so in our brain the acFon is easily connected to the effect. An other example of good mapping is in an elevator, where the buOons are placed in a verFcal row and starts at the boOom with floor 1. In this case the highest floor is also the highest placed buOon. A bad example of mapping is the direcFon indicator of the car lights next to the steering wheel in a car. The direcFon indicator of a car is always placed at the le; side of the steering wheel and can be used to put it down for le; side or up for right side. This is really illogical. Logical would it be, if the buOon of indicator for the le; side would be a buOon on the le; side of the steering wheel and the indicator for right should be places at the right side of the steering wheel. That it nevertheless works well right now is because we have learned to use and also because it is the same in every car.

Week 4 A. Scenario of use - Katelijn van Kooten Based on persona Sophie Sophie really likes shopping and today she decided she wanted new shoes and a new coat. She doesn’t really need those but she’s going to buy them anyway. Sophie never wears cash money with her so she only uses her bankcard or her phone to pay. She recently discovered the app Student Banking which includes a funcFon of paying with your phone. She has already used the renewed app a few Fmes. To make a payment, she has to do mulFple swipes across the screen of her phone, depending on how large the payment is. If she wants to buy something that costs a few euros, she only has to do a few swipes. The shoes Sophie wants to buy cost €110,-. She has to swipe across her screen 22 Fmes, which makes her more conscious about how much she has to pay. A;er she has paid, the overview shows her spending and the tables and graphs are automaFcally However, now that Sophie has spent €110,- on shoes, she doesn’t have enough money le; to buy a coat too. She opens the Student Banking App and makes a Budget for a coat. This means she opens a kind of small saving account on which she can deposit any amount of money on any occasion. In this way, she can save money for a speciﬁc goal unFl she has enough to buy the product she wants. For Sophie this method of saving is very convenient because she can really work towards a goal, which gives her saFsfacFon. Also, because she has a hard Fme keeping track of her incomes and spendings, the tables and graphs really help her to see everything in perspecFve and it’s easy for her to compare a speciﬁc period of Fme to another period.

B. Task descrip:on - Rani Škrabanja USE case: Making payments with bankcard 1. The user wants to make a payment with bankcard. 2. The user opens the bank app. 3. The system shows the balance of the user. 4. The user checks his balance. 5. The user swipes to the payment screen. 6. The system requests the user if he wants to transfer money to another bank account or to his bankcard. 7. The user chooses to transfer money to his bankcard. 8. The system requests for the amount of money to transfer. 9. The user enters the required amount of money. 10. The system shows an arrow which need to be swiped to transfer the money. 11. The user starts to swipe. 12. The system reports that the transfer was successful. 13. The user closes the app. 14. The user goes to the cash deck. 15. The user pays with his bankcard.

C. Joint QOC analysis 1. 2. A. B. C.

How can the user become more conscious about his/her payments? OpFons Before paying, you have to follow a line in a speciﬁc paOern which changes every Fme. The length of the line depends on the amount of money you’re spending so a shorter line for a small payment and a long line for a big payment. You have to keep paying aOenFon to what you’re doing so it makes you conscious about your payment. To “charge” your bankcard, you have to swipe across the screen of your phone. Depending on how much money you want to transfer, the amount of swipes is small or large. By turning your phone upside down, the imaginaFve money is slowly falling out of your wallet. If you’re going to make a large payment, it’ll take longer for the money to fall out of your wallet.

3. A. B. C. D. E.

Criterion  Time Privacy Adding moFon Modern look (for target group teenagers) Low use of data on your phone

4. (1=low, 5=high) OpFon A

OpFon B

OpFon C

Criterion A

Criterion B

Criterion C

Criterion D

Criterion E

Total (sum)

Criterion A: Criterion B: Criterion C: Criterion D: Criterion E:

OpFon A takes a bit more (maybe too much) Fme to fulﬁl the task than opFon B and C. That’s why it got a score 3 out of 5. OpFon C is not private at all, you have to turn upside down and everyone can see that you’re making a big or small payment. OpFon A and B are more private. For opFon A and B you should acFvely do something which makes you conscious. OpFon C only makes you turn your phone and that’s it. OpFon A and B look quite like a game. OpFon B is even a reference to the modern hype of “blowing money”. OpFon C is a simple old-fashioned wallet. To make sure you get a new paOern every Fme you get a payment opFon A uses a lot of data storage. OpFon B and C use less storage.

D. Conclusion OpFon B is the opFon with the most awarded points. It scores above average for every criterion we set. OpFon B doesn’t make the payment a more fun or a more horrible experience, it connects a task to a movement. It looks modern, it is private and it doesn’t use a lot of space on your phone.

Week 5

A. Low-ﬁdelity interac:ve prototype

This is the first screen you see when you open the app. You fill in your five digit code to unlock the app. When you have filled it in correctly, you immediately go to the next screen.

This is the screen you go to when you have filled in the correct code. Also the homescreen.  Above you can see five buOons with each it’s own color and icon. These buOons can be seen through the enFre app. On this screen you can find your balance and your incomes and spendings. The incomes and spendings are visually separated by pufng the incomes on the le; en the spendings on the right. You can scroll further   down.  Also does every sort of payment has a different color and icon, which you can select yourself. Eventually the app will recognize itself that sort of store belongs to which category.   By separaFng and labeling everything, the user has a beOer overview on his or hers spendings.

This is the funcFon ‘Agenda’. You get here by tapping on it’s yellow buOon at the top of the screen. On this screen you can also see your balance. With this funcFon you can see if you have transacFons coming up. You can scroll further down. You have three buOons: ‘Plan a new spending’, here you can plan a new spending. ‘Plannend spendings’, here you can look at your plannend spendings. And ‘plannend incomes’, here you can see your plannend incomes. Also, you can see here again that every sort of payment has a diﬀerent color and icon, which you can select yourself. By this funcFon, the user can plan ahead with his or her money and can think over certain spendings by looking at there agenda.

This is the funcFon ‘Budget’. You get here by tapping on it’s pink buOon at the top of the screen. On this screen you can also see your balance.  With this funcFon you can set a budget for yourself. You can scroll further down. You can also see the colors and icons of certain transacFons here. On te le; it says for what the budget is. Then you can see what the budget is you set and how much you already spent and how much you sFll have le;. The black in the pie charts stands for how much money is sFll le;.  You also have two buOons: ‘Change a budget’, here you can change the amount of money for a budget that you have already set. ‘Form a new budget’, here you can set a new budget for yourself’. Also, you can see here again that every sort of payment has a diﬀerent color and icon, which you can select yourself.    This funcFon will make the user more aware of how much money he or she is spending a month on certain products or acFviFes.

This is main funcFon of our app. It is called ‘Swipe’. You get here by tapping on it’s green buOon at the top of the screen. On this screen you can also see your balance. The idea is that the balance on your card and your account are separated. So whenever you want to make a payment, you ﬁrst have to put money on your card. You do this by ‘blowing money’ as students say these days. You have to swipe the money to the card virtually. When you want to put more money on your card, you have to swipe more Fmes. You also have a buOon at the boOom of the screen. When you click on this, you can change the amount of money you want to put on the card.  This funcFon will make the user more aware of how much money he/she is spending, because you have to swipe each bill or coin to the card.

This is the last funcFon of our app. It is called ‘Charts’. You get here by tapping on it’s blue buOon at the top of the screen. On this screen you can also see your balance. You can have a look at charts in terms of percentage of your spendings. Here you can click on three sorts of charts for more explanaFon of the spendings of the month/year. Also can you see here again that every sort of payment has a diﬀerent color and icon, which you can select yourself. This will give the user a beOer overview on their spendings and so they will come more aware on what they are spending the most money on.

B. Task descrip:on - Charlot Felderhof The user has set a budget for this month for the food he can buy The system processes the data The user goes to the supermarket The user wants to buy five food related products in the supermarket The user checks how much the products costs together The user grabs his phone and opens his bank app by filling in his personal code The system checks if the code is right The user first sees his balance en checks if he has enough, he has The user clicks on the budget funcFon The system opens the budget funcFon The user checks if this will fit in his monthly budget, it does The user clicks the swiping funcFon The system opens the swiping funcFon The user selects an amount of money that he wants to put on his debit card, so he can pay the product The system processes the amount of money that is going to be transferred and how much swipes is necessary for that 16. The user swipes the amount of Fmes that is necessary 17. The system immediately puts the amount of money on the card 18. The user goes to the checkout and pays for his product with his debit card 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15.

Week 6 A. Task descrip:on The user has set a budget for this month for the food he can buy The system processes the data The user goes to the supermarket The user wants to buy five food related products in the supermarket The user checks how much the products costs together The user grabs his phone and opens his bank app by filling in his personal code The system checks if the code is right The user first sees his balance en checks if he has enough, he has The user clicks on the budget funcFon The system opens the budget funcFon The user checks if this will fit in his monthly budget, it does The user clicks the swiping funcFon The system opens the swiping funcFon The user selects an amount of money that he wants to put on his debit card, so he can pay the product The system processes the amount of money that is going to be transferred and how much swipes is necessary for that 16. The user swipes the amount of Fmes that is necessary 17. The system immediately puts the amount of money on the card 18. The user goes to the checkout and pays for his product with his debit card 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15.

B. Heuris:c Evalua:on - Rani Škrabanja InteracFon Problems Reports Heuris:c violated: #3 user control DescripFon: To go back to the home screen of the app, you have to close it completely before reopening it again. Possible causes: There is no return/home buOon yet. Expected consequences: 100% of the users will overcome this problem, about 50% will ﬁnd the soluFon to close and reopen the app. Heuris:c violated: #9 errors DescripFon: The user can go over his budget without knowing. Possible causes: The system doesn’t provide yet a warning message if you’ve used you’re budget completely. Expected consequences: 100% of the users will not get a warning message, about 55% could get a problem because of spending too much. Heuris:c violated: #10 help and documenta:on DescripFon: When the user doesn’t understand something, he can’t go somewhere he can ﬁnd the answer on his quesFon. Possible causes: There is no help buOon and help database yet. Expected consequences: 20% of the users will need the help funcFon.

B. Cogni:ve walkthrough - Katelijn van Kooten CogniJve Walkthrough Our users are teenagers and young adults, studying at a HBO or WO educaFonal insFtuFon. In general, this user group is familiar to modern devices and technologies. Our app consists of a few different screens: a screen with an overview of your spendings and incomes, an overview with graphs and tables, a screen in which you can swipe to pay and a screen in which you can make a separate saving account to save for a specific goal (a bike for example). One of the goals of our app is to clarify the financial status of the user. The graphs and tables will definitely add to this, because it transforms the enormous amount of transacFons into a clear overview. However, the swipe&pay funcFon should also give some form of feedback when you want to make a payment. We have kept this funcFon really simple, not much text and no cool effects. You should just swipe the arrow unFl you’ve charged your phone enough to make the payment. It would be saFsfying for the user if they would have clear feedback on this acFon. For example, by making the screen turn green when you’ve done enough swipes or maybe by giving a warning when you’re about to make a large purchase, to get even more conscious about the money you’re about to spend.

C. Changes of the prototype We have decided to make a few changes to the prototype. This is to add an home buOon, so users can actually go back to the home page without having to close and open the app all the Fme.   Furthermore, we have added that you receive a message when you are about to go over your about, or went over your budget: a warning message. The main addiFon is the tutorial. When you use the app for the ﬁrst Fme, you get a guided tour through the app. Every funcFon is explained through a walkthrough so you can use the app right away.

D. Discussion of diﬀerences between heuris:c evalua:on and cogni:ve walkthrough   In a cogniFve walkthrough, you research the sequence of the tasks and if it’s clear when and how to use the buOons. The emphasis is on the tasks. It’s about problems and gaps you’ll face in real-life. A heurisFc evaluaFon is based on usability principles and is preferably done by a system specialist. It’s very structured and organized. You’re looking at how the products will work in an ideal case. However, there are also similariFes. Both methods research many usability-problems. Both methods take the user’s point of view into account.

Week 7 A. Setup user test according to DECIDE Framework

Determine the goals of the evalua:on addresses This formaFve evaluaFon will be carried out, because our team wants to know if we have a funcFonal app. Also we want to detect if the errors shown by the expert evaluaFon are also found by the user. Furthermore we want to check if the app suits our target group.

Explore the specific ques:on to be answered By using this user evaluaFon we want to know if the app is easy to use. Also we will try to find out if they noFce the same errors during performing tasks as we did with the expert evaluaFon. Also we want to find out if the user encounters new problems we haven’t seen yet. This will give us new insights about our app and help us create a beOer design without missing funcFons. Furthermore we do not only want to know if our system works, we also want to know of our test users think they would actually use the app.

Choose the evalua:on approach and combine techniques to answer the ques:ons In this evaluaFon we will approach our test persons in a place with not many distracFons. We approach them on university campus so they don’t have to really pay something. This gives them the comfort to easy explore the app and don’t have to be afraid someone will judge them because of not understanding a funcFon. The evaluaFon contains three tasks that need to be performed and a self-exploring part. Overall the evaluaFon will take about 10 minutes per person. First we will ask the test users to do some tasks. Tasks we will ask these users are swiping money to their bank card, looking at upcoming incomes and spending’s and checking if you didn’t go over your budget this month. A;erwards they can explore the app a liOle more by themselves and gives us feedback about what is clear and what is missing.

Iden:fy prac:cal issues PracFcal issues within the user evaluaFon could be that the app isn’t a real one yet. This makes it diﬃcult to go from screen to screen, because swiping and clicking buOons doesn’t work yet. To solve this we will print each screen on a diﬀerent paper, so you can switch from paper to paper to change the screen. Decide how to deal with ethical issues Keeping the privacy of our test persons in mind, we have made a consent form that informs our test users what we are going to do with the informaFon. They also can choose if we’re allowed to make pictures of them doing the evaluaFon and using it for further documentaFon.

Evaluate, interpret and present the data The test persons thought the app was overall clear, but they were missing some things. They noFced the app had no return buOon and thought this was very clumsy. Also at ﬁrst the swiping part was not clear to them. A;er explaining the funcFon they all understood it. The test users thought it was a very handy app and had a clearer overview than the bank app they have now. Not all were sure if it would help them to save money, though.

Consent form included in the appendix

Introduc:on to why the user is tes:ng our prototype University students have a lot of costs during the year. Many of them are living on their own and have to pay rent. More money is spent on their groceries and tuiFon. A student is not a student without a party and that’s where a lot of money goes to too. Also a student wants to look good and more money is spent on clothing. This numeraFon makes people forget what there is said at the beginning of it and that is why we wanted to make the overview of spending’s 15

clearer. We wanted a product that makes you more aware of your spending’s and what shows you where you have spent your money on. We introduce “Student Banking”, an app with all your spending’s and funcFons to help you become more aware of your spending’s. Also it will help you detect your weak points and helps you to save money on those areas. We would like you to test our prototype and help us to make it even beOer. We will ask you to perform three tasks and provide you with help when needed. A;erwards you can explore the app further and tell us what you think about it. We also want to know if you would use the app and if you think you can save money with it.

B. Results of user tests For the user test, we decided not to tell the testers anything about how it works, only what it is for: gefng a beOer overview of your money. Even tough we wanted to add a guided tour the first Fme you use the app. We thought that in this way, we would get beOer feedback. The people that tried our paper version of the app over all really liked it. Everybody said that they would really like to use this app and think they can save money with it. But some people said they maybe would not use a certain funcFon, like the Budget or the Charts funcFon, but everybody said something different. Although we did not help them at all, all of the testers could figure what every funcFon meant. Only the Swipe funcFon was a bit harder to understand and it took the testers two minutes longer to figure out. So we think our app is very clear and understandable, even when you use it for the first Fme. But we think, that maybe a short adverFsement movie would help people to understand what the Swipe really means. And then we can leave out the guided tour. People also said that is someFmes was a liOle harder to understand because the app was on paper and you don’t automaFcally go to a different screen, when you tap somewhere. Moreover, some funcFons were not fully worked out and that made it harder to understand.

C. Comparison of expert evalua:on and user evalua:on The expert in our case was our group itself, so the expert evaluaFon is from the designers point of view. In this case we could miss some important mistakes, because we know everything about our app. The user evaluaFon gives our design group new insights from the users point of view. The user doesn’t know at the first Fme what all the funcFons in the app are. Like this the user has to explore the app himself. In results there were no big differences. In both the expert evaluaFon and user evaluaFon it became clear the return buOon was missing. From the expert evaluaFon we concluded the help buOon was not there, but the user didn’t ask specifically for one. Even though they needed some help performing some acFons, so the help buOon would be very handy. The money swiping part was very clear for the experts, but some users had a liOle trouble understanding what to do.

D. Redesigns of the app based on the user test The users came with good feedback to redesign our app. First of all we have added a reward for when you do not go over your budget. You receive a message when your on track. This will give the user a saFsfying feeling a reason to go on. Secondly, we have added that when you go over your budget, the amount that you went over, turns red in the pie chart in terms of percentage. This will give you a warning that you need to watch out, because you already went over budget. We have also worked out the screen where you can add the money to swipe. From the user test we learned that when people try the paper version, they want to see what happens when you press a certain buOon. This is more an extension of our prototype, you just make clear what we mean, than an improvement. What we would like to add if we would develop this app further, is that you can swipe money to an other bank account. That you point you phone to the other persons phone and you virtually ‘blow the money’. Furthermore we have cleared up the Charts funcFon. It is now more clear what the funcFon implies. By pufng the charts in slightly different posiFons, it is now more clear that you can click on one. And when you have clicked on one, you can see how much money one part of the pie chart is. The different colors stand for the different sort of spendings and you will recognize these for there category, because it returns all over the app. And when you scroll further down, you see the name and the icon of the category and how much more or less it is than other months etc. we think that with these changes, the user will become more aware on how he is spending his money. We think the app is now clear enough to let go of the guided tour when you first use the app. The only funcFon that needs to be explained is the Swipe funcFon, but we think there are different ways of doing that. For example, before buying the app, you already know what the funcFon is because you have seen it in adverFsements. The final prototype is included in the appendix.

u s e r c e n t r e dd e s i g n g r o u pF 5

a p p e n d i x

C h a r l o tF e l d e r h o f k a t e l i j nv a nk o o t e n r a n i s k r a b a n j a ma x i mev a l l e n t i n s 1 5 8 7 5 2 s 1 6 3 7 6 0 s 1 6 7 4 5 6 s 1 5 0 0 7 1

Table of content Appendix 1

Table of content

Week 1

2 4 5

A. Storyboard of the current situation B. Experience goals and motivations C. Application of notions of effectiveness, efficiency and satisfaction

Week 2

7 9 9 10

A. Persona hypothesis B. Ethnographic interview 1. Process - The final list of questions 2. Results - Analysis of patterns

Week 3

11 15

A. The five requirements C. Mapping, Affordance and Constraints

Week 4

23 24

A. Scenario of use B. Task description

Week 5

B. Task description

Week 6

28 30 31

B. Heuristic evaluation B. Cognitive walkthrough C. Changes of the prototype - The Final Prototype

Reflections

44 45 45 46 47 48

Peer review Individual reflections Reflection Charlot Felderhof Reflection Katelijn van Kooten Reflection Rani Ĺ krabanja Reflection Maxime Vallentin

Week 1 A. Storyboards for the current situa;on

Charlot Felderhof

Rani Ĺ krabanja

Katelijn van Kooten

Maxime Vallen:n

C. Experience goals for the target group Charlot Felderhof The experience goals include; becoming more aware of how much money you are spending, spend less money, easy to use and easy to understand. Katelijn van Kooten Individual set of experience goals. These include: • Doesn’t add :me on the transac:on itself • Clarifies your financial situa:on • Intui:ve use: we don’t want people to have to read a whole manual before being able to actually use our product Rani Škrabanja • The most important experience goal should be that the product should make the user more aware of his spending’s. Students spent a lot, because most of them live on their own. They need to pay for basic things like rent and groceries, but they also want to have fun. So par:es and new clothing are also included. Some:mes they won’t see that they have spent so much money on par:es that they almost can’t afford their groceries anymore. • Another experience goal should be that the product is quick to use. Students don’t have a lot :me either and they are not willing to make a transac:ons take longer so they know more about their spending’s. They want to make the payment quick and leave the store again. • One more experience goal should be that the product doesn’t cause making transac:ons a horrible thing to do. The user shouldn’t feel horrible because he made a payment, but should be more aware of what he has been spending. Maxime Vallen;n • Helpful   AQer all, we want to create a design that combines the benefits of electronic paying and paying cash. It should help our users making payments in an easier way. If our design does not help our users, the design would be useless. •

Quick to use  For payments is the transac:on :me a very important element. It is clear that the speed of payment transac:ons has grown in recent years. Through the ages the weight of the means of payment diminished constantly; from gold to coins and paper money. Also the transac:ons :me diminished, especially in recent decades when digital payment facili:es were developed. Paying by card increased the number of the transac:ons. Today we can even pay wireless by card and that increased the payment speed even more. People want to as pay fast as possible. Our product will meet this desire.  Except for making payments, the product will also have other ﬁnancial func:ons. For the other func:ons less has to be focused on speed and more on security and safety,

•

High usability  Our product should combine the advantages of tradi:onal (analogue) payment and digital payments. The product should have added value to the user. Making payments means making choices and asks al lot of human consciousness and therefore a lot of energy. It also has consequences for our deposable budget and inﬂuences our way of living. To have more :me available to manage these purposes the transac:on system should minimize :me costs.

D. Applica;on of no;ons of effec;veness, efficiency and sa;sfac;on   Charlot Felderhof • Effec;veness  The effect I want to get from our product is that people become more aware of how much money they are spending and because of becoming more aware, also start spendings less money.  In this way they are being less impulsive and are more confedera:ve. • Efficiency  The normal transi:on should not take longer than it does right now. But I think that you could spend more :me on thinking about it before the actual transac:on. Also the efficiency is that you spend less money. • Sa;sfac;on  For sa:sfac:on I want our user group to get feedback on what they are doing and if they are doing it right, so they can be proud when they actually spend less money.

Katelijn van Kooten To define the usability of the product I came up with no:ons of effec:veness, efficiency and sa:sfac:on. These are the no:ons: for effec:veness I want our product to make people more aware of how they’re financially doing. For efficiency, I want the transac:on to go equally quick or quicker than in the current situa:on. For sa:sfac:on, I want the product to be innova:ve and not something that’s similar to a product that people have already ever bought.

Rani Škrabanja • Eﬀec;veness – The user should spend less money than in the current situa:on. • Eﬃciency – The transac:on should take a maximum of about 10 seconds. It should take less :me or as much :me as a transac:on takes in the current situa:on. • Sa;sfac;on – The user should save more money than in the current situa:on so they have more money on their accounts.

Maxime Vallen;n • Effec;veness  The way a product supports users in carrying out their task.   We want our product to make people spend less money than in the current situa:on. They should be more sa:sfied by the choices make and the products they spend their money on. Thus reducing unnecessary impulse purchases that people might regret in a later stage. The user should easily be able to accomplish these tasks. At least 93% of all tasks must be successfully completed by the users.   We can create a test where we measure how many mistakes students makes before they understand how to operate the design. Our design should be easy to use. Although students learn quite fast and are familiar with the use of new techniques. It should be a clear and easy design. Again, we can test this by leang students use our design and see how many mistakes they make. If the test shows that the students make too many mistakes; more than 93%. We know we should adjust things to make it easier and more effec:ve. •

Efficiency  How fast and efficient an user can accomplish a task with our product.   We can measure the transac:on :me of the payment func:on. We want to speed up the transac:on :me compared to het transac:on :me of the current card products :me. In the current situa:on a transac:on has an average :me of 7 seconds*. So measuring this is simple. If the average :me of making a payment of our product is more than 7 seconds, we should improve our product or reset our goals.  For the use of the other possible func:ons we need to set a different :me goal. This :me goal depends on the defined characteris:cs of the users (students). Students get impa:ent and distracted easily and a lot of students do not want to put a lot of effort in finance.   5

The main goal of the design besides the func:on of payment of the product, is to get grip on the level of expenses and on making the right choices.   We should keep the way of opera:ng the product easy, clear and fast. We can test the efficiency and set an average :me for students to use the different func:ons of our product. If too many users (90%) fail to finish their tasks or experience irrita:ons, because there are too many ac:ons needed for example, or a task or the design is not clear enough, we know our design isn’t efficient enough.    *We did a liele survey, with a group of 25 students and measured their payment transac:on :me in a supermarket. The survey was targe:ng card paying. In this survey we found an average payment transac:on :me of 7 seconds. The transac:on :me was defined as the period from the moment the casher men:oned the total amount and the customer (student) had paid by card. In most cases the :me of opening the wallet is included. •

Sa;sfac;on  Does the product make the user feel sa:sﬁed.   We want the target group to save more money than in the current situa:on and feel beeer and more comfortable with their spending habits.   We can evaluate this by ques:oning students in a survey. The students can tell us how they experienced our product. If they liked working with it and if it made them feel comfortable. We can also test this aQer they used the method more oQen. Does the sa:sfac:on rate of their purchase changes? If 80 % of the students say they would want use the product in the future, we know the design meets the sa:sfac:on requirement.

Week 2 A. Persona Hypothesis  Charlot Felderhof Lisa, 19 years old Lisa lives in a student home. This is the first :me she is not living with her parents because she just started her study. For her room she has to pay 300 euros rent per month. She can afford this room, because she loans money from the government. She has set a budget for herself for 350 euros in a month, rent not included. But she finds it very hard not to go about her budget, because Lisa is very impulsive and unconscious. She spends the most money on clothes and going out with friends. She almost always pays with card, only when she goes to the club, she pays cash. She checks her balance and her incomes through her banking app. Tom, 23 years old Tom is already started on his master. He lives together with his girlfriend in a small apartment, for just 350 euros per month per person.  He has a job at a nog firm where he can do liele tasks to earn a liele more money next to his student loan. He has set a strict budget for himself and has learned how not to go about his budget. He spends most of his money on dates and trips with his girlfriend and food. He also drinks the occasional beer at the study associa:on on Thursday.   He always pays with card. He checks is balance and spendings through is banking app.

Katelijn van Kooten Original persona hypothesis Students between the age of 16 and 22. They have money struggles because of their student loan and it’s the ﬁrst :me they are ﬁnancially independent. We think they always spend too much money. They don’t set a limit and if they do, they go over their budget. We want to show gender diversion: a girl who spends much on clothes and a guy who spends much on drinks, for example.

Rani Škrabanja Product: Student Banking app Roles: students Students Goals: Save money, Get an overview of their spending’s Behaviors: Students are impulsive buyers, They pay almost always with bankcard, They check their bank app on their phones. Environments: City, Shopping center, Super market, University

Maxime Vallen;n What different sorts of people might use this product?   Not fully experienced people, only just financially independent. Our target group are students. We focused this further to university students and (HPE) degree (Dutch for HBO). We intent to design for them a product to pay with. It is the first period in their lives that they, are generally speaking, fully responsible for their own behavior and their own ac:ons. They understand the value of money, but they some:mes do not make the right decisions. In the situa:on that students are for the first :me standing on their own feet's, they need to organize and pay everything by their self's.

How would their goals, needs and behavior vary?   Every student has a different personality. Some want to have the most incredible student :me they could. These students might not care how high their student loans will become. Some others want to live as minimalis:c as possible and therefore to borrow as liele as possible. Some students have a limited social life, while others have a very challenging social life and have to endure a lot of social pressure, which is usually will be accompanied by high expenses. The product should therefore focus on a variety of characters.   What ranges of behavior and types of environment need to be explored?   As described above, some students save a lot of money or try to loan as less as possible, while others are very impulsive and spend a lot of money. Some students have an enormous social live, while others don’t. The environmental and social circumstances might change as well. For example the availability of external money factors, number an culture of friends, housing facili:es. Product: System/product to pay with   Roles: Student, parents, bank and Government Student  Goals: managing their finance on their own. Saving money. Keep grip on their expenditure.   Behaviors: Use few :mes a day, impulsive   Environments: They must finance their own living. Are fully responsible for their acts. Very social and busy live. Parents  Goals: Want their children to be finical healthy and happy.  Behaviors: mo:vated  Environments: Amount of money they earn, way they grew up themselves Bank   Goals: Earn money, get clients to use their system/products.  Behaviors: Mo:vated   Environment: Have a lot of money and a lot of clients. Government  Goals: want a financial healthy student popula:on, want to save money on loans. Want happy voters.  Behaviors: Mo:vated   Environment: Has to less money. Has voters who trust on them.

Persona 1  Sophie, 18 years’ old ﬁrst year student at the Fontys She lives on her own, together with friends in a student house. So she has to pay rent. She gets 200 euro a month from her parents. She Loans 500 euro a money from the government. Her total budget is 700 euro. She has a very busy social live with a lot of friends. She uses the app of her bank a lot to keep grip on her expenses. The most of her money she spends on her rent, 250 euro monthly. Monthly she spends 150 euro on food, 150 euro for drinks and snacks, 100 euro for cloths and makeup and the rest 50 euro for remaining costs.  Finds it hard not to go beyond her budget but she oQen does. She spends oQen money without really thinking about it, especially while going out on Tuesday, Thursday, Friday and/or Saturday. During going out she pays almost everything by card. During the day, when she is shopping in a tradi:onal way she likes paying cash. Persona 2  Koen, 23 years’ old, third year student at the TU/e. He has a busy life, because he is very ac:ve in his student associa:on. He also has a small job one day a week at the library of the university. He lives together with his girlfriend. He loans 800 euro a month of the government. So he already has a big study debt. He is not very good in keeping grip on his expenses. He never pays with cash, only with card because he thinks that is much easier. He uses the app on his smartphone to keep grip of his purchases, but he would like a clearer overview.

B. Ethnographic interview  1. Process - The ﬁnal list of ques;ons  1.

Age/Gender/ Current situa:on

A. What’s the name of your bank?   B. What is your budget?  C. On what do you spend the most money?  D. How oQen and in which way do you check your transac:ons?  E. Why do you use this method and what do you think about it?  F. What would you like to change/add to the app (or desktop version)?

A. How do you make sure you don’t go about your budget?  B. How oQen do you go about your budget?

A. Are you conscious of the size of your spending’s when you pay by card?  B. Are you more conscious about your payment when you pay by cash?  C. Do you mind spending more :me on a transac:on when it makes you more conscious of your purchases?

Do you spend more/less money in the presence of others? Do you know why?

How oQen do you go to an ATM and how much money do you extract?

A. How oQen does it occur that you want to pay but suddenly don’t have enough money leQ?  B. Did you have no clue about this or did you already expect that you didn’t have enough money leQ?

How much :me would you max. want to spend on a transac:on?

How oQen do you feel guilty for spending too much?

10.

A. How oQen do you use your bank card and how oQen do you use cash?  B. What do you prefer, paying with cash of paying by card?  C. In what occasions do you pay by card / cash?

11.

Do you know how much is on your bank account before paying? Do you check your bank account before making a payment?

12.

A. Where do you keep your bank card?   B. Do you have a wallet?   C. Does cash ﬁt in your wallet?

13.

How do you feel about Touch free payments (posi:ve/nega:ve)? Do you no:ce a diﬀerence between paying Touch Free and paying with a card in the normal way?

2. Results - Analysis of paWerns

AQer the ethnographic interview we recognized a couple of paeerns. Most of the students we interviewed spent the most money on groceries and going out with friends. Also almost all of them used the app of their bank to check their balance on their phone. They also pay as much as possible with their bankcard.

Week 3 A. Requirements   Charlot Felderhof

A funcJonal requirement Example: Easy to use Type of requirement: Func:onal requirement Descrip:on: The product shall be easy in usage for teenagers Fit criterion: The product needs to have a few bueons Customer sa:sfac:on: 4

A look-and-feel requirement Example: Have a good overview Type of requirement: Non-func:onal requirement Descrip:on: The product shall have a good overview of the spending’s in an app for teenagers Fit criterion: The product needs to have diﬀerent columns Customer sa:sfac:on: 2

An ease of use requirement Example: More meaningful Type of requirement: Non-func:onal requirement Descrip:on: The product shall give teenagers a meaning to spending a lot of or a liele money Fit criterion: The product needs to have an in-store system that helps this Customer sa:sfac:on: 3

An ease of learning requirement Example: Easy to have control on your spending’s Type of requirement: Non-func:onal requirement Descrip:on: The product shall give teenagers a control on their spending’s Fit criterion: The product needs to have an Customer sa:sfac:on: 5

A performance requirement Example: Fast Type of requirement: Non-func:onal requirement Descrip:on: The product shall be fast in usage for teenagers Fit criterion: The payment should be no longer than 15 seconds Customer sa:sfac:on: 5

Katelijn van Kooten

Type of requirement: FuncJonal requirement Descrip:on: The product should give feedback on how you’re financially doing Fit criterion (or test case): If the people using the product have a clearer view on their financial status aQer using the product, it fits the criterion. Customer sa:sfac:on: 4/5 Type of requirement: Look-and-feel requirement Descrip:on: Aerac:ve to teenagers/young adults (modern look) Fit criterion (or test case): Not a clunky product: clean lines and not too big Customer sa:sfac:on: 3/5

Type of requirement: Ease of use requirement Descrip:on: Strong use of informa:on visualiza:on Fit criterion (or test case): Not too much text, use of symbols Customer sa:sfac:on: 5/5 Type of requirement: Ease of learning requirement Descrip:on: Use of Skill-based interac:on or interac:on based on general knowledge Fit criterion (or test case): People don’t have to use instruc:ons to understand the product. It’s intui:ve. Customer sa:sfac:on: 3/5 Type of requirement: Performance requirement Descrip:on: As quick as or quicker to use than the current average transac:on Fit criterion (or test case): Measure how long the current average transac:on takes. Measure how long a new transac:on takes. Customer sa:sfac:on: 3/5

Rani Škrabanja

FuncJonal requirement Requirement type: 9 Descrip:on: The product should make the user (more) aware of the amount of money he or she is spending at that moment. Fit criterion: The product should track the spending’s of the user and give the user feedback of it to make him or her more aware of the amount of money he or she is spending at that exact moment. Customer sa:sfac:on: 4

Look-and-feel requirement Requirement type: 10 Descrip:on: The product should not make other people than the user aware of the amount the user is spending. Fit criterion: The product must contain privacy so the user isn’t afraid of going somewhere to spend money. Customer sa:sfac:on: 5

Ease of use requirement Requirement type: 11 Descrip:on: The products can be used with basic skills and general knowledge. Fit criterion: The product should be usable without reading instruc:ons. Customer sa:sfac:on: 3,5

Ease of learning requirement Requirement type: 11 Descrip:on: The product should be used by any young adult, no maeer what educa:on he or she has had. Fit criterion: The product should be that simple that every young adult could use it, whatever educa:on he or she has had. Customer sa:sfac:on: 5

Performance requirement Requirement type: 12 Descrip:on: The product should not take longer on a payment than it is now. Fit criterion: The product must act fast and should not make the payment longer than the way we pay now. Customer sa:sfac:on: 5

Maxime Vallen;n   FuncJonal requirements Example: The product should make the user more aware of its spending habits. So the user will be able to make beeer decisions. Type of requirement: Func:onal requirement   Descrip:on: The product should make the students more aware of the amount of money they are spending, and also make the transac:on results more insighsul. Fir criterion: There should be interac:on between the user and the product, so the transac:ons are more insighsul. Customer sa:sfac:on: 4.5

A look-and-feel requirement Example: The product should be very clear and clean. Type of requirement: Non-func:onal requirement Descrip:on: The product should have nice clear overview, so you can immediately see what your transac:ons are and the total amount of money of certain number of transac:ons. The product should make this very clear. Fir criterion: The product should have mul:ple screens with all a really clear purpose. Customer sa:sfac:on: 4

An ease of use requirement Example: The product should be very clear from the ﬁrst moment. Type of requirement: Func:onal requirement Descrip:on: The product should have nice clear bueons, so one immediately sees what is needed to accomplish a task. Fir criterion: The product needs to have clear bueons and symbols.   Customer sa:sfac:on: 3.5

An ease of learning requirement Example: Knowledge based on the general knowledge and the interac:on of the product. requirement: func:onal requirement Descrip:on: The product should be based on general knowledge. The knowledge of students is already rather good. Fir criterion: 90% of the people who will test the product need to understand the product and accomplish all its tasks. They have to be able to accomplish the tasks without any help. Customer sa:sfac:on: 4.5

A performance requirement Example: The product should be fast during transac:ons. Type of requirement: Non-func:onal requirement Descrip:on: The opera:on speed of the product must be high, that means as fast as the average, tradi:onal, transac:on :me measured in our users group. Fir criterion: The transac:on :me of the product should be as fast or quicker then 7 seconds. That is the average transac:on :me of the tradi:onal transac:ons in our users group. Customer sa:sfac:on: 3

C. Mapping, Aﬀordance, Constraints Charlot Felderhof

Mapping Good mapping The Magic trackpad from Apple

Scrolling with the trackpad of an Apple computer when you don’t set in the seang natural. When you want to go up, you drag your fingers up. If you want to go down, you drag your fingers down. When you want to zoom in, you drag push you fingers out. And when you want to zoom out, you push your fingers together.

Bad mapping The bueons on a microwave

There are too many and it is hard to understand which does what because it is not in a logical order.

Aﬀordance The Magic Mouse from Apple

The size and the way it is formed shows that you are supposed to put your hand on it and when you do, it ﬁts perfectly in your hand.

Constraints Physical constraint  A pair of scissors

The smaller hole implies that you should put your thumb in there and the rest of your ﬁngers in the larger hole.

Logical constraint To unlock your iPhone, you have to slide it in a certain direc:on. The path of how you have to slide it, lights up.

Cultural When you want to open your iPhone, you click on the home bueon. When you want to go back to the home screen, you click on the home bueon.

Katelijn van Kooten   Mapping Good mapping  iPod shuﬄe

In the picture you see an iPod shuﬄe. It’s an MP3 player. It only has a few bueons, with clear symbols on it. To me, this is an example of good mapping because you immediately see what every bueon stands for.   Bad mapping Microwave

In this picture you can see the microwave I recently bought. When I ﬁrst tried to warm my food in this microwave, I didn’t understand anything of the bueons. I wasn’t sure what the symbols represented and the turning knob only worked for a few bueons or for speciﬁc combina:ons of bueons. I s:ll don’t understand how it works. The only way to understand when to use what bueon is to read the manual. 18

Affordance  Example of affordance for your mobile phone: The size of the phone (it has a smaller width than the palm of your hand) implies that you’re supposed to hold it in your hand. Constraints Physical: It’s physically not possible to move the cursor outside the screen. I’m not sure if this is a good example, it’s quite logical that you can’t touch a screen on a place where there is no screen. Logical: If we want to navigate to a restaurant in Eindhoven on our mobile phone, the phone tells you there are 41 restaurants in Eindhoven. Then, if you immediately see 10 restaurants you know, logically, that there are 31 restaurants off the screen. Cultural: The fact that the graphic on the right-hand side of a display is a scroll bar and that one should move the cursor to it, hold down a mouse bueon, and drag it downward in order to see objects located below the current visible set is a cultural, learned conven:on.

Rani Škrabanja

Mapping Good The volume bueons on a phone: the upper bueon is for turning the volume louder, the lower bueon is for turning the volume down. Bad The control bueons for stove: you always have to ﬁnd out what bueon is for what plate on the stove.

Aﬀordance There is one big bueon down the screen that you want to press immediately. If you press it one :me the screen will light up. If you push it another :me the unlocking screen will appear.

Constraints Physical The charger only ﬁts in the hole on the boeom of the phone. Logical The upper bueon of the volume control is to turn the volume up and the lower bueon is to turn the volume down. Cultural In the calls list the names in red are the calls you missed and the black ones you didn’t miss.

Maxime Vallen;n Mapping Bad mapping  www.oase.com An example of bad mapping I think is Oase, the website the TU/e, used for communica:on about formal ques:ons with its students. For example for registering for courses and chairing informa:on for certain courses. In my opinion it is totally unclear what a lot of bueons and symbols mean on this website.   A good an clear overview is missing here. In my own case I have been several :mes wrong logged for certain courses. This is rather problema:c.     Good mapping   www.maloneyamsterdam.com   A good example of mapping is the website of the Company I work for. This website covers the planning of al materials and tools that is leased to customers. The used symbols here expresses a clear meaning. Misunderstanding the symbols is very rare. There are a lot of op:ons but it is never unclear what ac:ons should be proceeded of bueons used.

Aﬀordance My Smartphone has a lot of aﬀordance principles. For example I can use internet on my phone, call people, uses apps like WhatsApp and Facebook to communicate with people, listen to music and make pictures and a lot more. Example of something that Smartphone's cannot do: You can’t use it to drink something, you cannot use it for tooth brushing, food, as a pan or as a pillow.

Constraints Physical constraint Every phone model has a different size. If you got a less common phone it is much more difficult to find a nice case for you phone that fits. You cannot buy every case you like. This is a physical constraint. It is not possible to use someone else phone case. Logical constraint For me it’s logical that if I press the clock icon on my phone, it will lead me to my alarm seangs and when I press the + bueon I can add an alarm. This is common-sense reasoning. Cultural constraint When I have missed a phone call, this number will be colored red in my call history register. I grew up learning that red usually indicates that something went wrong. Or indicate danger or a warning. Therefore I know that if a phone number is colored red in my call register on my phone, something went wrong with this phone call and I understand that there never have been a conversa:on at all. It makes clear that I have missed the phone call.

Week 4 A. Scenario of use Charlot Felderhof Lisa went to the mall and went into a clothing store. AQer walking around for an hour and trying things on for half an hour, she made a selec:on of ﬁve items that she now wants to take home with her, in total of 160 euros. She selected two t-shirts, a blouse, a skirt and a pair of jeans. Although she already has 16 sorts of shirts, seven blouses, twelve skirts and eight pair of jeans, she really thinks this would be an addi:on. Because of her new app, before she goes to the check-out she ﬁrst has to put money on her debit card, by swiping. When she sees that she has to swipe 32 :mes, she is kind of shocked and aQer 14 swipes, she realizes that she doesn't really need the shirts, blouse and pair of jeans… So she just goes home with one t-shirt, that she really loves.

Katelijn van Kooten Sophie really likes shopping and today she decided she wanted new shoes. She doesn’t really need them but she’s going to buy them anyway. Sophie never wears cash money with her so she only uses her bankcard or her phone to pay. She uses the ING bankieren app which has recently been extended with a new func:on of paying with your phone. She’s already used the renewed app a few :mes. To make a payment, she has to do mul:ple swipes across the screen of her phone, depending on how large the payment is. If she wants to buy something that costs a few euros, she only has to do a few swipes. The shoes Sophie is going to buy cost €110,-. Because she has to swipe across her screen 22 :mes, she becomes conscious about how much she has to pay.

Rani Škrabanja Anna is an university student and out shopping for new jeans. In her favorite store she ﬁnds two jeans she likes and decides to buy them. She adds the prices together and comes to the conclusion she needs about €70. She grabs her phone and opens her bank app. The bank app shows her balance and she comes to the conclusion she has enough money on her bank account. Next she swipes to the payment screen and chooses transfer money to bankcard. She types in the €70 she wants to spend and an arrow appears on the screen to swipe the money to her card. AQer she has done this, she checks if the correct amount of money is on her bankcard. The amount is right and she closes the app. She puts away her phone and walks toward the cash desk. She pays with her bankcard and leaves the store.

Maxime Vallen;n It is Thursday aQernoon, Sophie, an university student, is shopping in the supermarket to buy dinner. She is at Albert Hein supermarket, not the a really cheap shop, but it is more important for her that she buy things in a nice shop, than that all the products are a liele bit cheaper. She want to buy food for two day and she thinks that she will spend around the 25 euro. In the line before the cash desk she take her Smartphone and opens her bank app. The bank app shows her balance and the amount of money she already spend on food that month. She comes to the conclusion she has already spend a lot this month on food and realize that she not really need to buy the salmon and the meet she like to checkout. She get the salmon and meet out of her shopping basket and put it back in the shopping shelves. She now has products of a total amount of 15 euro. She types 15 euro she wants to spend and an arrow appears on the screen to swipe the money to her card. AQer she has done this, she checks if the correct amount of money is on her bankcard. The amount is right and she closes the app. She puts away her phone and walks toward the cash desk. She pays with her bankcard and can leave the store.

B. Task descrip;on

Charlot Felderhof 1. The user wants to buy a product in a store 2. The user checks how much the product costs 3. The user grabs his phone and opens his bank app by entering the five digit code 4. The system checks if the code is correct, it is 5. The system shows the first home screen 6. The user first sees his balance en checks if he has enough, he has 7. The user clicks on the swiping func:on 8. The system opens the swiping func:on 9. The user selects an amount of money that he wants to put on his debit card, so he can pay the product 10. The system calculates the amount of swipes that is necessary to get the money on the card 11. The user swipes the amount of :mes that is necessary 12. The system puts the money on the card and off the balance 13. The user goes to the checkout and pays for his product with his debit card 14. The systems registers where and when the payment is made and what the category is. 15. The system calculates it into charts, budget and balance.

Katelijn van Kooten 1. The user wants to buy a product and goes to the counter to pay. 2. The app gets a signal from the paying machine how much the user has to pay or how much he wants to transfer to another bank account 3. The app decides how many swipes the user should do before being able to make the payment (based on a logarithmic scale) 4. The user does the required amount of swipes 5. The user can now make a payment 6. The app registers where and when the payment was made and makes a graph of what the user spent his money on

Rani Škrabanja 1. The user wants to make a payment with bankcard. 2. The user opens the bank app. 3. The system shows the balance of the user. 4. The user checks his balance. 5. The user swipes to the payment screen. 6. The system requests the user if he wants to transfer money to another bank account or to his bankcard. 7. The user chooses to transfer money to his bankcard. 8. The system requests for the amount of money to transfer. 9. The user enters the required amount of money. 10. The system shows an arrow which need to be swiped to transfer the money. 11. The user starts to swipe. 12. The system reports that the transfer was successful. 13. The user closes the app. 14. The user goes to the cash deck. 15. The user pays with his bankcard.

Maxime Vallen;n 1. The user wants to make a payment with bankcard. 2. The user opens the bank app. 3. The system shows the balance of the user. 4. The user checks his balance. 5. The user swipes to the payment screen. 6. The system requests the user it wants to transfer money to another bank account or to its bankcard. 7. The user chooses to transfer money to his bankcard. 8. The system requests for the amount of money to transfer. 9. The user enters the required amount of money. 10. The system shows an arrow which need to be swiped to transfer the money. 11. The user starts to swipe. 12. The system reports that the transfer was successful. 13. The user closes the app. 14. The user goes to the cash deck. 15. The user pays with his bankcard.

Week 5 B. Task descrip;on Charlot Felderhof 1. The user has set a budget for this month for the food he can buy 2. The user goes to the supermarket 3. The user wants to buy five food related products in the supermarket 4. The user checks how much the products costs together 5. The user grabs his phone and opens his bank app by entering the five digit code 6. The system checks if the code is correct, it is 7. The system goes to the begin screen, the home page 8. The user first sees his balance en checks if he has enough, he has 9. The user clicks on the budget func:on 10. The system opens the budget func:on 11. The user checks if this will fit in his monthly budget, it does 12. The user clicks on the swiping func:on 13. The system opens the swiping func:on 14. The user selects an amount of money that he wants to put on his debit card, so he can pay the product 15. The system calculates the amount of swipes that is necessary to get the money on the card 16. The user swipes the amount of :mes that is necessary 17. The system puts the money on the card and off the balance 18. The user goes to the checkout and pays for his product with his debit card 19. The systems registers where and when the payment is made and what the category is. 20. The system calculates it into charts, budget and balance.

Katelijn van Kooten One of our tasks the users can perform with your prototype is making a mobile payment, aQer they’ve “charged money onto their mobile bankcard”. In the middle of the screen there’s a big arrow poin:ng upwards. That is the direc:on in which the user should swipe to “charge” the money on the phone. Depending on how much money you have to transfer, you do more or less swipes. When the user has done enough swipes, from the boeom of the screen to the top of the screen, the money is charged on your phone and the arrow disappears. The user can then make a common payment but is more aware of how much money they’re spending.

Rani Škrabanja 1. The user wants to make a payment with bankcard. 2. The user opens the bank app. 3. The system shows the balance of the user. 4. The user checks his balance. 5. The user clicks on the swiping bueon to go to the payment screen. 6. The system requests for the amount of money to be transferred to the bankcard. 7. The user enters the required amount of money. 8. The system shows an arrow which need to be swiped to transfer the money. 9. The user starts to swipe. 10. The system reports that the transfer was successful. 11. The user closes the app. 12. The user goes to the cash deck. 13. The user pays with his bankcard.

Maxime Vallen;n 1. The user wants to make a payment with bankcard. 2. The user opens the bank app. 3. The system shows the login screen. 4. The user types his personal security pin. 5. The system shows the balance of the user. 6. The user checks his balance. 7. The user swipes to the payment screen. 8. The system requests the user it wants to transfer money to another bank account or to its bankcard. 9. The user chooses to transfer money to his bankcard. 10. The system requests for the amount of money to transfer. 11. The user enters the required amount of money. 12. The system shows an arrow which need to be swiped to transfer the money. 13. The user starts to swipe. 14. The system reports that the transfer was successful. 15. The user closes the app. 16. The user goes to the cash deck. 17. The user pays with his bankcard.

Week 6 B. Heuris;c evalua;on Charlot Felderhof 1.

9. 10.

Visibility of system status The user receives liele feedback when he makes a move in the app. a. b. The user does not receives status feedback. Match between system and real world The symbols that the systems uses are clear and familiar. a. b. The informa:on is presented in a simple and logical order. Important controls are represented and the mapping between them is clear, for example with the c. transfer func:on. User control and freedom The user is able to undo unwanted ac:ons. a. b. Opera:ons taking a long :me cannot be cancelled. The app is usable with larger font sizes. c. d. There is no return bueon to the homescreen yet. Consistency and standards There is a lot of consistency in the app. a. b. The app uses similar words for similar tasks. Error preven:on The user conďŹ rma:on is required before carrying out a poten:ally dangerous ac:on. a. b. The system is safe enough for its surroundings. Recogni:on rather than recall The func:onality of the bueons is obvious from their labels. a. b. The rela:onship between controls and their ac:ons are obvious. Flexibility and eďŹ&#x192;ciency of use The system does not guide novice users suďŹ&#x192;ciently. a. b. It is not possible for expert users to use shortcuts. Aesthe:cs and minimalist design The system is orderly organized . a. b. The use of colors is not necessarily func:onal, but is does give a good overview. The font that is used is clear. c. Help users recognize, diagnose, and recover from errors There are no warning messages yet. a. Help and documenta:on There is no help bueon. a.

InteracJon Problems Reports Heuristic violated:

#7 Flexibility and efficiency of use

Description:

Users may not understand what certain activities or functions mean.

Possible causes:

The system does not guide novice users sufficiently.

Expected consequences:

70% of the users will not use those functions at all. 30% will find out on their own.

Heuristic violated:

#10 Help and documentation

Description:

When a user does not understand a function, he or she has no place to go to, to find out how it works.

Possible causes:

There is no help button

Expected consequences:

80% of the users will not use those functions at all. The other 20% will try harder to figure it out on their own.

Rani Škrabanja 1.

Visibility of system status a. The user receives full feedback about the results of his ac:ons. 2. Match between system and real world a. The system shows simple symbols and most of them are familiar to the user. b. The informa:on is presented in a simple and logical order. c. Important controls like the bueon to swipe money to the bankcard is clear visible. 3. User control and freedom a. The return bueon is not there yet, so if the wrong bueon is pressed you have to close the app and reopen it. b. Because you have to close the app it’s taken a bit of your :me. c. The app is usable in larger font sizes. 4. Consistency and standards a. There are similar words used for similar opera:ons. 5. Error preven:on a. The user conﬁrma:on is required before carrying out a poten:ally dangerous ac:on. b. The system is safe enough for its surroundings. 6. Recogni:on rather than recall a. The icons show clear the func:on of that bueon. b. It’s not possible to search informa:on in the app (yet). 7. Flexibility and eﬃciency of use a. It’s not possible to use shortcuts. b. It’s possible to access and re-use instruc:ons. 8. Aesthe:c and minimalist design a. The app is organized. b. The use of colors is not necessarily func:onal. c. The font makes the app clear. 9. Help users recognize, diagnose, and recover from errors. a. There are no warning messages yet. When the users go over their budget, they don’t even know. 10. Help and documenta:on a. There is no help bueon (yet).

InteracJon Problems Report Heuris;c violated: #3 user control Descrip:on: To go back to the home screen of the app, you have to close it completely before reopening it again. Possible causes: There is no return/home bueon yet. Expected consequences: 100% of the users will overcome this problem, about 50% will ﬁnd the solu:on to close and reopen the app. 29

Heuris;c violated: #9 errors Descrip:on: The user can go over his budget without knowing. Possible causes: The system doesn’t provide yet a warning message if you’ve used you’re budget completely. Expected consequences: 100% of the users will not get a warning message, about 55% could get a problem because of spending too much. Heuris;c violated: #10 help and documenta;on Descrip:on: When the user doesn’t understand something, he can’t go somewhere he can ﬁnd the answer on his ques:on. Possible causes: There is no help bueon and help database yet. Expected consequences: 20% of the users will need the help func:on.

B. Cogni;ve walkthrough Katelijn van Kooten Part I: CogniJve Walkthrough Our users are teenagers and young adults, studying at a HBO or WO educa:onal ins:tu:on. In general, this user group is familiar to modern devices and technologies. Our app consists of a few different screens: a screen with an overview of your spendings and incomes, an overview with graphs and tables, a screen in which you can swipe to pay and a screen in which you can make a separate saving account to save for a specific goal (a bike for example). One of the goals of our app is to clarify the financial status of the user. The graphs and tables will definitely add to this, because it transforms the enormous amount of transac:ons into a clear overview. However, the swipe&pay func:on should also give some form of feedback when you want to make a payment. We have kept this func:on really simple, not much text and no cool effects. You should just swipe the arrow un:l you’ve charged your phone enough to make the payment. It would be sa:sfying for the user if they would have clear feedback on this ac:on. For example, by making the screen turn green when you’ve done enough swipes or maybe by giving a warning when you’re about to make a large purchase, to get even more conscious about the money you’re about to spend.

Maxime Vallen;n We have designed the app in such a way that you don’t have to use or adjust a lot of different seangs because we want to keep the app as simple and understandable as possible. However, the app consists of many different tools because making a payment is a process that demands many different op:ons. Therefore, it’d be useful to get an explana:on of how to use the app the first :me you open it, for example by using speech bubbles. There can be a textballoon for every tool within the app. AQer a specific :me of use, text-balloons can appear with :ps at places of op:ons which haven’t been used yet. The symbols are said to be very clear, according to our test users. 1.  Conceptual model: Do they know what they need to do? Can the customer be expected to try to do this ac:on? The customer can be expected to try to do this ac:on. The arrow is really big in the centre of the screen and it is a very clear symbol. 2.  Visibility: Is the control for the ac:on visible? Can they see what they need to do? The task the user should accomplish is an very simple task. And showed in the screen really big with a liele anima:on of changing colors. When the user performs his task, the liele anima:on react also and there is a liele interac:on between the user and the app. The user can see how the money is transferring to the bankcard. It is also really easy to 30

see when the task is accomplished. The arrow won’t disappear un:l you’ve done enough swipes, so the user will also know when they can stop swiping. It is also clear that the user needs to swipe upwards, because the arrow is poin:ng upwards. 3.  Labelling: Is there a strong link between the control and the ac:on? The link between the control and the ac:on is strong. Swiping with you right hand over your leQ open faced hand appeals to the imagina:on. Nowadays rappers and people uses this gesture to show people they are spending money.

Also the user want to transfer money to their mobile bankcard, you want to charge it. Therefore, you have to move your ﬁnger across the screen un:l you’ve done enough movement to charge your bankcard. 4.  Feedback: Will the user understand the feedback? The feedback is really clear. The user sees in the app that the amount of money on their bankcard is reloaded. And is from that moment able to pay. Another feedback moment is when the user can actually pays with their bankcards.

D. Redesigns of the app based on the user tests - The Final Prototype: 31

4UVEFOUCBOLJOH

Ŕ ŗ

ŕ Ř

Ŗ ř

ś œ

Å½ ÊåÅâ >8œŔ TY\ œŔŕŖ ŗŘřŚ śŜ

Ƈ Ć Üâ Ù Ć œŘƠœŔƠŔŚ ǁƮ ŔœœƉœœ Üâå ¯ §¯Å ¯ Ù¯Å¨ œŘƠœŔƠŔŚ ƠƮ ŖƉřŘ ¿ Ùâ ¬ ¯ºÅ œŘƠœŔƠŔŚ ƠƮ ŕŖƉřŘ ¬ ÖÖĆ ¯â ¿Ć œŘƠœŔƠŔŚ ÄÊÅ Ć œŗƠœŔƠŔŚ ǁƮ ŚƉŘœ =Ǝ5ƎǤƎ 5 ÅÜÜ Å œŗƠœŔƠŔŚ

"HFOEB ¿ Å ƈ ƮŔŕŖƉŗŘ N8Ǥ> Ǥ > h TN > *>#ƕ*> B= Ö¿ ÅÅ ÜÖ Å ¯Å¨Ü N8Ǥ>> *> B= T âÊÄÊÙÙÊĀ œŚƠœŔƠŔŚ ǁƮ ŘœƉœœ ÄÊÄ Å > Ā ¿ Å ƈ ƮŔŚŖƉŗŘ ÄÊÅ Ć ŔŔƠœŔ ƠƮ ŚƉŘœ Üâå Ć ÜÜÊ ¯ â¯ÊÅ > Ā ¿ Å ƈ ƮŔřŘƉŜŘ §Ù¯ Ć ŔŗƠœŔ

CVEHFU ¿ Å ƈ ƮŔŕŖƉŗŘ ¬ Å¨ å ¨ â §ÊÙÄ Å Ā å ¨ â ÄÊÅâ¬¿Ć å ¨ âÜ

GPPE

ÜÖ Å ƈ ƮŖƉřŘ ¿ §âƈ ƮŗŔƉŖŘ

FBU PVU

ÜÖ Å ƈ ƮŖƉřŘ ¿ §âƈ ƮŔřƉŖŘ

ESJOLT

ÜÖ Å ƈ ƮœƉœœ ¿ §âƈ ƮŕœƉœœ

Good job! It is almost the end of the month and you are still on track with your budget!

CVEHFU ¿ Å ƈ ƮŔŕŖƉŗŘ ¬ Å¨ å ¨ â §ÊÙÄ Å Ā å ¨ â ÄÊÅâ¬¿Ć å ¨ âÜ

GPPE

ÜÖ Å ƈ ƮŘœƉœœ ¿ §âƈ ƮœƉœœ

FBU PVU

ÜÖ Å ƈ ƮŖŚƉœœ ¿ §âƈ ƮŖƉœœ

ESJOLT

ÜÖ Å ƈ ƮŕŕƉœœ ¿ §âƈ ƮœƉœœ

You went over your budget, keep a closer look on your spendings on drinks!

TXJQFO NPOFZ USBOTGFS UP DBSE ¯âƈ ƮŔŕŖƉŗŘ Ù ƈ œƉœœ

"EE NPSF NPOFZ UP TXJQF

TXJQFO NPOFZ USBOTGFS UP DBSE ¯âƈ ƮŔŕŖƉŗŘ Ù ƈ œƉœœ

"EE Ƈ BEE Ƈ 5

BEE Ƈ

DIBSUT ¿ Å ƈ ƮŔŕŖƉŗŘ

UIJT NPOUI

MBTU NPOUI

ZFBS PWFSWJFX

DIBSUT ¿ Å ƈ ƮŔŕŖƉŗŘ

UIJT NPOUI

Ƈ Ƈ Ƈ

Ƈ Ƈ

DIBSUT ¿ Å ƈ ƮŔŕŖƉŗŘ

UIJT NPOUI Ƈ

GPPE

This month you spent €50,00 on food. That is €5,00 more than your budget. That is also €7,50 more than last month. But it is €10,00 less than you did this year.

FBU PVU

This month you spent €40,00 on eating out. That is €0,00 less than your budget. But is also €20,00 more than last month. And it is €25,00 more than you did this year.

ESJOLT

This month you spent €20,00 on drinks. That is €0,00 less than your budget. But is also €20,00 more than last month. And it is €25,00 more than you did this year.

Reflec;ons Peer review 1. How effec;vely did your group work? During our mee:ngs we were always very effec:ve and produc:ve and had dynamic group discussions. We have slightly different personali:es and quali:es and those really complemented each other. We all contributed in our own way. We also found out mee:ngs with Dey very helpful and he was a very good and suppor:ng tutor. 2. Were the behaviors of any of your team members par;cularly valuable or detrimental to the team? Maxime is a very enthusias:c person. He always brought joy and life to the group. He is very social, so for him it was never a problem to ask people to fill in the ques:onnaires. Also he could give feedback very easily and no one would feel assaulted. Although his enthusiasm gets in his way some:mes, being very overac:ve and easily distracted, it always gave him the best crea:ve ideas. Rani is a trustworthy team player. If you ask if she can do a task, she will fulfill it perfectly within :me. It always was a bit hard to plan a mee:ng with her, but we could always figure it out and she always was there. And when she was there, she contributed to group work. We have the feeling that Rani could open up a liele bit more over :me and then take part in discussions. Katelijn is always on schedule. She is one person in the group that always did her homework in a quality manner and aeended every mee:ng on :me. And during the mee:ngs, Katelijn would always say the right things and very ac:vely contributed to the discussions. Her work is always qualita:vely good. Katelijn was the center of our group, always knowing what already has been done and what s:ll needs to be done and lead the group. Charlot is very communica:ve and undertaking. She is not afraid to share her opinion but she also listens to what others have to say. Also, she can work very detailed and she put a lot of effort in the digital prototype, with great results. She couldn’t always aeend the mee:ngs but when she was there, she definitely showed ini:a:ve: when there was uncertainty within the group she would ac:vely try to solve it.

Individual reflec;ons Charlot Felderhof When star:ng this course, my main learning goals was to find the answer to the following ques:on, when designing a new product: ‘How do you get to know the user?’ It is quite obvious that this was the learning goal, but nevertheless very important. Because the course I followed in the first quar:le ‘From Idea to Design’ was very focussed on the design process and how you could get explore your product further and make it beeer every week. With the other design course that I followed this quar:le ‘Design for the Here and Now’ we focussed on experience, feelings and rituals. Nothing really specific about the user yet. But when designing a product, nothing is more important than the users. What I also found important was to find my role in the group, because I have not really figured out what kind of person I am and want to be. What I found unusual at first was that this course is very guided. Every week you get clear homework and you know that when you finish that, you are on track. I found this very different than at the course FITD, where we were more free in what to do. But now being at the end of this course, I understand why we were so guided. If they did not guide us as much, we probably would not have done it and would have focussed less on the user and more on our product and therefore I am glad that the course was set up this way. Because now, when I design something again, I can follow these steps, knowing how valuable they are. When designing the prototype, I always kept in mind how our target group would like the setup. But when I did the user tests, somethings were not as clear as I found them to be. And that was when I realized how easy you can forget about the user. You want to focus so much on aesthe:cs, that you some:mes put your aeen:on to the wrong aspects. Through this course I learned various techniques to get to know the user and not just one. I think that that is very valuable, because only then you get the full picture of the user group. So what I learned from this course is that you have to take a step back on your design process, check if everything is s:ll fit for your user group and then develop further. I really liked our group F5. Together we were the perfect combina:on and worked really well together. Our group mee:ngs were always very efficient and therefore we did not saw each other a lot, but only when necessary. And I think our good group dynamic was also always no:ceable from our feedback from Dey that was oQen very posi:ve. In the group there was a lot of space for me and the rest to share opinions and we would always listen to it and discuss it. I think we as personali:es really completed each other. Where Maxime is very crea:ve and social and always comes up with the most fun ideas, he some:mes needs to be hold back a liele and needs guidance on the assignments. And Rani is a very hard worker. She has a really busy life being a top athlete, but nevertheless she would always have her work done, no maeer what. But Rani was a liele bit shy and would not always dare to give her opinion, but I think she would open up more when you get to know her beeer. And I really liked working with Katelijn. She always had her facts straight. She is a very hardworking person that always had good ideas and could elaborate more on ideas from others. She also could steer the group very well and in a nice way. Mostly because of her, we made progress every week. And then there is me. I am a undertaking person that takes a lot of ini:a:ve. I can have good ideas and I can listen to other peoples ideas. In this project I got leaded more than I took the lead and I think that was good for my learning path, because normally I am more of the leader type. I could not always aeend the mee:ngs and I always felt very guilty, but I hope I balanced it with the work I did at home, like the prototype.

Katelijn van Kooten  This quar:le I followed the course User-Centered Design. I expected to learn how to do research on the wants and needs of the user. Also, I expected we would learn about design processes in which the user is the center of importance and we did: we learned different methods for different stages of the design process. I like the fact that we didn’t learn just a few but many different methods for collec:ng data from an about the user group. We learned to look at a product from the user’s perspec:ve by making for example personas, scenarios and a cogni:ve walkthrough. Also, we learned how to research what our target group wanted and needed by taking an ethnographic interview and doing a user evalua:on by using the DECIDE framework. Those are all things I consider to be very useful for all the design processes I’ll do in the future. Personally, before the start of the project I had a very clear goal. I wanted to improve my organiza:on within a group project, improve in showing leadership and in feeling involved in the project. This is something that I was really able to improve during the last eight weeks so now I can say that my expecta:ons are fulfilled. This course seemed very different to me from the previous project course From Idea to Design which I followed during the first quar:le. I no:ced that during From Idea to Design I was very focused on the look and feel of the design itself instead of the users of it. This is something that changed in a posi:ve way during this period because now I’m aware that there is more behind the appearance of a product. Design is also considering all the parts and liele aspects which lie behind the surface. I learned this by the results of the interviews we did, by the research and all the feedback we received. I will definitely take the new things I’ve learned during this quar:le in considera:on for my next projects. I really liked working together with Charlot, Rani and Maxime. We were all mo:vated and we all had different quali:es that helped us make progress. We always made a clear task division we’d almost always s:ck to it. I think we all contributed to the same extent but in a different way. Maxime was very social and crea:ve, though he some:mes struggled with understanding how to make the exercises and with wri:ng in English. Rani delivered qualita:ve work and had a serious working aatude. However, she oQen remained quiet within group discussions. I really liked working with Charlot because she had a combina:on of being communica:ve and delivering good work. On the other hand, she could be late on the mee:ngs. I feel like my role within the group was the coordinator. I tried my best to keep everything organized and support the others whenever needed. I would oQen provide the overview of completed tasks and what s:ll had to be done. This fits perfectly within my personal goals. Altogether, I think this course has helped me a whole lot in becoming the industrial designer I hope to be in the future.

Rani Škrabanja For User-Centered Design we were divided in groups and had to follow a certain design process. The lecturer gave us as lead to design something around making payments. So first we had to decide what target group we would choose and what we wanted to give them. I expected the process to be simple, but I found out that this user based designing was more complicated than I thought. When we had our first prototype I didn’t think we were missing parts, but doing the evalua:ons you come to conclusion that there are. I learned that you have different kinds of expert evalua:ons. Also I found out that the results of the expert evalua:on and the user evalua:on can be different. Working in a group lead to different perspec:ves and new insights about the project. For me it was some:mes difficult to join group discussions, because I really have trouble telling people what I think before knowing them well. Some:mes I felt a liele bit suppressed, because others had such a strong opinion. I think the User-Centered Design course was important for Industrial Design and life aQer as a designer. For an industrial designer it is useful to know how to design for a specific group or user. Some:mes a company will give you certain leads you have to follow, but what is coming out are you designing. With this course we learned how to do this kind of designing and what process you can follow. In the future I can try to put myself more out there and really join group discussions. I also can use now the things I learned for e next design case, l because I now know how to design for a specific group of users.

Maxime Vallen;n When I started following this course ''User Centered Design'' I did not expect that this course differed so much from my former course ''From Idea to Design''. In both courses we designed a product in a small team. That is why I expected some similari:es in the both courses. But immediately aQer the first assignment I realized that this was not the case. This course is not really about a brilliant or really crea:ve idea, because the final product was almost completely determined by the professors. This course was about examining the whole process designing a product for the user. The inves:ga:on of the en:re design process was analyzed from the way in which the user will experience the product. That was a perspec:ve I did not really focused on yet. In this course I learnt to understand and to analyze this process. I learnt that analyzing the product from the point of view of the user, this includes a more complete set of condi:onal ques:ons, that have to be answered during the design process. I feel much more comfortable now to run through the process directed on the coming up with a good design. Another insight I got during this course was, that it is not needed to start immediately with all kind of design idea's or design solu:ons. I learned to take my :me to make an inventory of all aspects that are important to make the design more complete and more effec:ve. My overall conclusion is that the inventory of all condi:ons is even more important for the user before even I know what kind of product I will or have to design. Thirdly I learnt how I can use interviews to come to a beeer design. The interviews are something I never expected to be so inspira:onal as part of the design process. I made also a liele extra survey for this reason and that has led to more insights about the way a user thinks and acts. That is an added value to get my design technique on a higher level. This beeer technique is of course instrumental to the coming design processes for all future designs. The most important thing I learnt from this course is how to design in a much more structured way. The DECIDEframework, scenarios, evalua:ons, requirements and personas were all new aspects for me. Designing is a really crea:ve process, but I like to learn how to follow a more structured process in order to make a more complete, effec:ve and innovated design. I like to get some experience with this kind of methods and get feedback on them of our tutor every week, so I immediately know that I use all the methods in the correct way. Out of the followed methodological process in this course I discovered that with every decision I make, I have to analyze why I am making this decision and if there is not decision to solve the problem in a more effec:ve way.     My conclusion is therefore that I should take my :me and consider the possible solu:ons beeer and longer before making a decision, about all the aspects in my design and about the design as a whole.   Even if I have not started making a design, it is important to analyze the problem that I want to solve.  The key ques:on I have to answer before I even start any design process is, did I define the problem I want to solve in a clear way and did a make the right analyze of the way it has to be solved. The process always should be started with the considera:on that enough :me should be taken to run the process.