PennyMADE BY GROUP G6 • Maud Berbé, Lars Giling,

Charlotte Leuverink and Naomi Swagten• User-Centred Design • Industrial Design

Penny

user, capabilities, limitations and experience goals (1)

stakeholders (2)

tasks that need to be carried out, bottlenecks, context and usability (3 and 4)

personas (5 and 6)

requirements and guidelines (7)

enhancing ease of use (8)

conceptual designand selection, interaction problems andstyles (9)

score table (10)

penny the piggy bank (11)

task description (12)prototyping, design questions (13)

paper prototype (14)

processing prototype (15)

expert evaluation,

task description and use case (16)

cognitive walkthrough and heuristic

evaluation (17 and 18)

user tests, determine goals, explore questions,

choose evaluation process (19)

identify practical & ethical issues (20)

evaluate, interpret & present data (21)

suggestions to improve (22)

comparison user evaluation and

expert evaluation + conclusion (23)

1

In this report, we will describe how we developed a concept that combines the advantages of electronic payment and cash payment. This is a project for the first year bachelor course ‘user-centred design’. We chose to focus on children as our main users. The process of developing this concept includes conducting interviews, creating personas, gathering requirements, designing and selecting concepts, prototyping and doing expert and user evaluations.

INTRODUCTION & USER

CHOOSE USER GROUP We decided to design something for children because in general, children are eager to learn new things in contrast to elderly who want to stay with their own habits and values. We want to teach the new generation how to use electronic payment systems because we believe that if you learn how to do something at a young age, you can do it for the rest of your life with less problems. We specifically chose to design for children in the Netherlands aged 10-12. We think this group is interesting, because children in this age group are often in a phase where they’re starting to become responsible for their own money and can buy things themselves.

CHILDREN ELDERLY

eager to learn new things

wants to stay with their own habits and values

generation of the future

difficulties with electronics

LIMITATIONS AND CAPABILITIES Children in the age of 10-12 have some capabilities and limitations that we should keep in mind while designing something for them. Based on our own experience and some quick research we made assumptions about them, displayed on the left.

relatively small hands

relatively smallnot that strongeasily learn new things

easily distracted

like to play

respect authority of adults

EXPERIENCE GOALS Based on the bottlenecks in the current situations and the context, we agreed on the - displayed on the left - user experience goals that are important for our concept intended for children appendix 1.1

engagingsatisfying

motivatingenjoyable

helpful

1

STAKEHOLDERS

USER PARENTS

FAMILY SHOP OWNER CASHIER BANK MECHANICWant to give the child money (on spec i a l occasions or regularly for a certain goal) and make sure they use this money in a proper way

Wants the system to look attractive and wants it to be easily installed in their store.

Wants the payment to be fast and easy in the store.

Wants to learn children how to use electronic payments and to put their money on their bank and save it.

Wants it to be easy to maintain

Children want to learn the concept of electronic payments in a fun way. They have a short focus period. The product should be easy and fun to use, because if it’s not fun they won’t use it. Children would use a system for electronic payments in a store and they also use it on their computer when buying things online. Additionally, they would use it for saving money at home.

They want to teach their children the value of money and the concept of electronic payment. Also, they want the children and their money to be safe. They want their children to learn how to be independent and want to teach their children how to save money for bigger expenses and help them save for the future. They buy things for their children or give children money to buy things themselves. They want to have insight in their children’s expenses.

When you’re designing for children, the children but also their parents are the most important stakeholders. The children will be the main users of the products but in this age group the parents still have the main responsibility of their child’s money so this should be taken into account. The following descriptions of the stakeholders consist of our thoughts and assumptions about children aged 10-12 and their parents. Later on we’ll find out if these assumptions are correct by interviewing these stakeholders.

We made a division between primary stakeholders and all the other stakeholders. Requirements of the main users will be considered the most important but the wishes of the other stakeholders shouldn’t be overlooked.

2

We made a list of the tasks that the children need to carry out,. From here we made different storyboards by looking at the current situation and problems that occur with children when paying in a store or performing an electronic payment. By doing this, we found some bottlenecks. Since children of this age category are just starting to go shopping themselves, they don’t know the value of certain products. Therefore children might spend too much money on unnecessary things or they might be short of money when wanting to pay in a store. Children can’t easily see how much money they have, only when they count it by hand or ask their parents how much money there is on their bank account. The storyboards can be found in the appendix.

TASKS THAT NEED TO BE CARRIED OUT AND BOTTLENECKS

Going to a store on their own and buying something using pin or cash money.

Buying something online.

Saving for something they want to buy. This includes counting

their own money.

TASKS THAT NEED TO BE CARRIED OUT

Getting cash from an ATM

3

This storyboard describes different situations in which the child buys something in a shop. appendix 1.2

USABILITY AND CONTEXTHere we describe how children will interact with our product based on three different elements of usability; effectiveness, efficiency and satisfaction. Firstly, he product allows children to learn about the value of money. It should be and feel safe. It should give children the feeling of independence jet allow the parents to set certain limitations. Secondly, children should be able to use it in an easy and comfortable way. Carrying out a task shouldn’t take too much time since children can’t concentrate on one task for a very long time. The interface should be designed in a way that will avoid making errors. Lastly, children can use the product without irritation, buttons and other controls should work the way children expect them to work. The product should have the appropriate set of functions, not too much functions. Children should want to use the product again after initial usage. appendix 1.3

Children can pay in two different situations: at home buying something online using their computer or in a store. In this chapter, we will describe these different contexts; physical context, social context, organisational context and technical context.

The social environment comes down to the interpretation of children on how their social behaviour should be. At home the social behaviour of the user isn’t bound to expectations. The user can take their time to perform actions and has the privacy to do so. However, in a store the user may feel pressured to be faster in doing certain actions to not burden others around them, as well as having less personal space and freedom to perform these actions. This might result into making mistakes.

The physical environment of our design case states the sensible situations of our problem. At home the physical context is calm, relaxed, quiet and familiar. But a store the physical context is noisy, crowded and unfamiliar. Since children are easily distracted by their environment, they could lose track of what they’re doing when paying.

The organisational environment includes knowledge of payment systems, as well as the parental authority over the user.

The technical environment includes the different ways the current payment system can be used. This includes the whole bank card system, NFC as technique in stores for contactless payments and the use of Internet to digitally transfer money / check your current balance.

4

We all made persona hypothesis by using the information we gathered about the users. To make the personas more according the real users, we performed interviews. Firstly, we performed a pilot-interview, for which we interviewed four children aged 10-12. From this data we made new personas. Secondly, we interviewed seven children at a primary school for our final interviews. After each interview, we looked at whether the child fits in one of our personas, and if we should adjust the personas. Below you see our two final personas. ’Quint the quick’ spender was in our hypothesis personas, but in all our interviews we did not find a child of this type, so we ‘deleted’ him. appendix 2.1 + 2.2 + 2.3.1

NICK THENO-LIMITS SPENDER

doesn’t save

no rules about moneyno pocket money

gets (almost) everything he

wants

don’t know value of money

pocket moneylooks at price

thinks about what she wants to buy

SANDRA THE SAVER

saves money for certain big expenses

parents help with big expenses

do know value of money

money from chorescertain goal in mind

bigger expenses paid by parents

spends it directlydoesn’t save

looks at the price

pocket money

QUINT THE QUICK SPENDER

!Changes in the personas are illustrated with a gap-in-line yellow line. If the sentence is strikethrough, it means that we concluded after the interviews to delete that characteristic. If not, the characteristic is new.

PERSONAS OF CHILD

5

While thinking and researching the personas of the child, we also made personas of parents. We also did this based on interviews. `we started with pilot-interviews in which we interviewed three parents of children of our age group. `we performed these interviews in different locations such as a coffee place and at home. After this pilot interview we adapted our questions and interviewed 6 parents at their homes for our final interview. Based on these interviews we adapted out hypothesis personas to the personas below.

appendix 2.1 + 2.2 + 2.3.2

PERSONAS OF PARENTS

ERNEST THE EASY PROVIDER

spoils his children with

money

no restrictions

don’t teach childrenabout money

gives money when children require money

expenses are still discussed, final decision

lies with child

CHUCK THE CONTROLLER

sets up rules and restrictions on paying

prevent children from careless monetary behaviour

gives pocket money

spending money requires allowance

bank account is used for saving money

CLAIRE THE CONTROLLED EASY PROVIDER

gives pocket money to spend freely

to provide independence lets children explore money

no restrictions

keeps an eye on children’s expenses, by restricting bank account and/or card

provide advise on bigger purchases

6

REQUIREMENTS AND GUIDELINESWe set up requirements to specify what the product should do and how it should function. These requirement will help us to establish guidelines. These will guide us through the design phase and evaluation phase, working towards a product which is addressed to both children and their parents. In this chapter we will describe the main requirements our final product should meet. The requirements we set for our product are based on Dutch children and parents that have a basic understanding of the dutch language.

FUNCTIONAL

LOOK-AND-FEEL

PERFORMANCE

EASE OF USE

EASE OF LEARNING

easy to learn by children that are 10-12 years old + parents

80% of a test panel of children aged 10-12 shall be able to successfully complete a certain task without ever having used the product before

the product should be safe to use by children that are 10-12 years old

only the child and his or her parents have access to the child’s bank-account

make it possible for parents to easily and quickly set a limit on what the child can spend

only the child (to a certain extent limited by their parents) and his or her parents have

access to the child’s bank-account

80% of a test panel of children aged 10-12 should be able to complete a task within one minute

the product should be easy to use for children that are 10-12 years old (+parents)

the product should be attractive to use for children that are 10-12 years old

an anonymous survey shall show that 80% of children aged 10-12 years thinks the

product looks attractive

readable by most dutch children aged 10-12

the controls and functions are easily understandable by children aged 10-12

all functions are clear in usage and labelled as such

the process of doing certain actions doesn’t require an excessive amount of (previous) knowledge

security of the product falls under parental control, with limited customised access for children

in case of confusion, a way to find help or additional information

REQUIREMENTS GUIDELINES

7

appendix 3.1 appendix 3.2

With our final product, we want to make sure that it is easy to use. We want to design a product which the user understands how to use. Also, the product should focus on the needs, preferences and limitations of the user. To explore examples of good and poor design, we searched for examples for mapping, affordances and constraints

ENHANCING EASE OF USE

RADIO CLOCK BAD MAPPING

RADIO CLOCK BETTER MAPPING

AFFORDANCE PHYSICAL CONSTRAINT

LOGICAL CONSTRAINT

CULTURAL CONSTRAINT

It’s not clear what the buttons with ‘1’, ‘2’ and ‘3’ ‘snooze/ivr/sleep off ’ m e a n . t o o m u c h functions.

It’s a bit more clear, even though there is a snooze button with two functions on it. on/off button is clear, but description above - ‘source’ - confuses us.

Back in the days the main affordance of a phone was receiving calls and calling. Nowadays, a phone can be used for much more (e.g. personal assistent, calling, r e ce i v i n g c a l l s , t ex t i n g , receiving texts, using the internet, play games). Pressing the green calling button will give you the option to call. However, if you do not understand this, you are c o n f u s e d a n d c a n n o t complete the action.

Physical constraints are constraints on possible actions t h r o u g h t h e physical properties o f ob jec t s . An e x a m p l e i s a charger that can only go one way into the mobile phone.

Logical constraints are constraints on possible actions that are understood through common-sense reasoning, for example the volume button on the side of your phone. By pressing the up arrow (on the top), the volume gets up, while pressing the down arrow (on the bottom), the volume gets down. This is an example of a good principle, because it is easy to understand.

C u l t u r a l constr a ints are conventions that we have learned a n d t h a t a r e shared within a culture (e.g. green means ‘go on’, red means ‘stop’). For e x a m p l e , t h e l e t te r s on the k e y b o a r d a r e aways arranged in the same order, which allows you to type fast.

8

appendix 4.1

We first thought of which problem we wanted to address, then we started to think about solutions ourselves. We discussed these solutions and chose an idea by using a score table. Also, we will explain what is good about this design and how it is used.

In order to come to a product that will help our user, we should know the problems that the user faces. To find this out we individually wrote interaction problems we think children and parents face. With this information, we came with interaction styles.

CONCEPTUAL DESIGN AND SELECTION

feel uncomfortable to pay

parents and children don’thave an overview of the total amount of money the child has

INTERACTION PROBLEM From our interview we learned that both children and parents do not have a total overview of how much money the child has in finding a solution for our project idea. We also found out that children feel uncomfortable to pay in a store, however, we chose to focus on the other interaction problem. An issue for children is that they are unaware of the amount of money they have saved up unless they actively keep counting all their incomes and expenses and write these down somewhere. This issue is incredibly time consuming and can easily fall prey to calculation mistakes, especially in our user group. If a child doesn’t keep track of how much money they own, a parent is instantly also bound to be unaware of how much their child owns. Furthermore, parents don’t always know what their children buy with their pocket money. For example, children could buy candy even though their parents don’t want them to, but because both parties are unaware of the child's’ cashflow, parents wouldn’t be able to stop or even notice this. After we established this interaction problem, we started brainstorming about concepts that could fix the problems. It was interesting to see that we found multiple really divergent ideas that we will describe now.

€21,34

Application with an overview of frequency, amount of money,

expenses, income which the child understands in a child-friendly way.

A card on which parents can put money and the

child can see visually how much money he or she

has saved.

A bank card which usage becomes heavier when

there is more money on it to let the user physically feel the value of money.

A system in which you can put money within different cubes to

save for a specific goal. Every cube can have it’s own saving goal. One box functions as the main savings box, which acts as a regular piggy

bank.

A money box which counts the money of the child automatically. Also, it gives an overview of the total amount of money the child has, both cash and on their bank account. Parents can also see this on a app on their phone.

9

appendix 5.1

We made a score table, to make a selection of the ideas we have just described. We set a certain weight, because we think that the user goals are not equally important. We thought that the product should be very helpful, safe and useful, because we want to help children achieving their goals in a safe way. Because we design for children, we think it is important that the product is enjoyable and aesthetically pleasing. From the score tables, we found that the piggy bank scored the highest; 3 people scored the piggy bank the highest, one person scored the piggy bank on the second place. The application scored the lowest; 3 people scored the application lowest, one person on the 5th place.

SCORE-TABLE

CRITERIA WEIGHT

engaging 3

aesthetically pleasing 2

motivating 3

helpful 5

enjoyable 4

satisfying 4

learnability 4

safety 5

flexibility 3

efficiency 1

usability 5

€21,34

€21,34

FINAL SCORE

10

appendix 5.2

PENNY THE PIGGY BANK

good overview of cash and virtual money

engaging (e.g parents can see child’s saving/spending behaviour)

playful (e.g oinks, twirlstail, smiles)flexible (e.g. both

cash and digital money)

stimulates saving (in different goals)

aesthetically pleasing (e.g when you seethe pig you know it is a piggy bank)

safe, because of a fingerprint lock (like the touch ID on the macbook PRO)

The coins will be counted automatically, however, notes have to be declared by hand. When the child wants to get money out of the piggy bank, all money comes out of the piggy bank and the piggy bank resets the amount of money to zero. The child can set a saving goal by clicking on 'set a saving goal'. Also, the child can change the saving goal for example when the product becomes cheaper or more expensive. Also, when the child does not want to save anymore for a specific goal, the child can delete this goal.

Adults have an application to keep track of what their child does with the money. The first thing the app provides when freshly installed is a way to set up a secure password and/or set a fingerprint to unlock the piggy bank. After this has been done, the app provides the parents with several useful options on the home screen. Parents can check the current balance in the piggy bank, recent bank transactions of their child, as well as the recent withdrawals and deposits in the piggy bank itself. Parents can also see the current and past saving goals the child set on the piggy bank. Furthermore, the app provides a way for parents to choose whether they want to receive notifications about things like changes in savings goals, withdrawals, deposits etc. The notifications can be toggled on and off, depending on how much parents value insight in how their child handles money. Below we describe what the advantages of Penny are.

11

TASK DESCRIPTION

In order to formulate the goal of our users and to describe the actions and steps that are necessary to achieve this goal, we all wrote task descriptions about children using the piggy bank. We will explain one scenario and one use case.

Sandra is an eleven year old girl, she is in the 7th class of ‘basisschool’. She likes to play with Playmobil and she already has a large collection. The only thing she still misses in her Playmobil village is the Playmobil mall. She already knows this will cost €70,00. She puts her new saving goal in her ‘Penny’. It wags his tail and moves his ears as the bar on the right fills up to a little bit over the middle. She can see that with the money from her Penny and on her bank account, she already has €44,30. The pig’s facial expression is kind of happy, she understands that means she is already almost there. She knows that she gets €4,00 pocket money per week. So she calculates how much she would still need: 25,30 euros, this means seven weeks of saving!

it could calculate how much money you still need

it could calculate how long it would take to get their based

on your regular income

I. The display on ‘Penny’ displays a button that says ‘set a saving goal’.

II. The user presses this button to set a saving goal.III. The system asks the user 'What are you saving

for?' A keyboard appears on the display.IV. The user enters 'saving goal' and presses the

checkmark.V. The system asks the user 'What does this 'saving

goal' costs?' A keyboard appears on the display.VI. The user enters the price and presses the

checkmark.VII. The system displays a bar filled to the amount of

money he already has relative to the money he needs for the saving goal. Penny changes facial expression depending on how close you are to your saving goal. A notification shows up on the parent's phone saying ‘Your child is saving for 'saving goal'’.

USE CASE‘set a saving goal’

SCENARIO

12

appendix 5.3

appendix 5.4

PROTOTYINGNow that we have an idea of what we want to design, we want to visualise and test this by making prototypes. We will first set up some design questions, then we will explain the prototypes. Before building the prototype we set up four design questions. These questions cover the things we want to confirm by testing our prototype with users of our target group (children aged 10-12).

do children understand how to set up and edit a saving goal?

do Penny’s interactions satisfy

the children?

does Penny work like how children

expect a piggy bank to work?

does Penny stimulate to

save money?

DESIGN QUESTIONS After we made the design questions, we searched for alternatives of how we are going to answer these design questions.We started with quick sketches of what the interface of the screen on the Penny should look like. Next we made a higher low fidelity paper prototype so that the icons and buttons are clear. Next, we made a prototype using Processing, so that children can interact with it and making it more real for them.

13

PAPER PROTOTYPEWe wanted to make a paper prototype to answer design question 1 “Do children understand how to set up and edit a saving goal?”. We worked out how we thought the design of the screen on the piggy bank should look. With this prototype we would be able to test if they know which buttons they need to press to fulfil these task, but not so much if they find it fun or enjoyable.

While retaining all the necessary information, the screen should provide the user (children in our case) easy to understand options that don’t require previous knowledge. We provided as less options as possible, to prevent the user in making mistakes. We made the options clear by using understandable icons and made them colourful to make them more aesthetically pleasing, because as earlier mentioned, children like a product to be colourful. Also, to improve the user’s feeling, we added a smiley, which stimulates the user to save money. While designing the paper prototype, we figured out that there should be a keyboard on the screen when you want to change or set a saving goal.

To set a saving goal, you click on the pen. Nick wil l always see this screen, since he would not save his money. He would be happy to see his total amount of money. Sandra could also see this screen when she is not saving for anything and she k n o w s h o w m u c h money she has to spend.

After clicking on the pen, this screen will pop up, and you need to fill in the name of the saving goal and the amount of money it will cost by clicking on the thing you want to change, after that a keyboard will pop up.

By clicking on the 'OK' button, the user makes sure that the changes will be saved. The user can also delete the saving goal, which goes back to the first screen.

When you have set a goal, for example a Playstation the screen will be shown as you can see here. Sandra would be happy to see her saving goal displayed on the right, because then she has an overview of how much money she still need to save in order to accomplish their saving goal.

Clicking on the pen will again show a keyboard and you can either change a saving goal, delete the saving goal or do not change anything.

14

NEW INSIGHTS We concluded after our first p ro to type tha t we should put text on buttons instead of icons, so that the children wo n ’ t i n t e r p r e t i t incorrectly. However, we should make the text clear and easy to read. Also, we made different steps to adjust the saving goal, including 'change saving goal', ' change pr i ce ' and 'delete saving goal', as d e s c r i b e d i n t h e f o l l o w i n g t a s k description.

appendix 6.1

appendix 6.2

PROCESSING PROTOTYPE

15

With the paper prototype, we could easily test if the children were able to set and change a saving goal. But since we would probably have only one chance to conduct user tests with children we wanted to test multiple things at once to answer some more design questions. This is why we made an interactive prototype using processing. The processing prototype allowed us to not only test if the interface and buttons are clear but also if the children think it’s fun to use. We could also see if children will intuitively put the money in the top of the pig like a normal piggy bank. It makes sounds and it looks like a pig so it’s already more playful and fun for children. An aspect that we couldn’t easily test with a paper prototype. It also made it easier for us to analyse the results of the tests because when you work with children you don’t want to film them because of privacy reasons. But by using this prototype, we were able to record the computer screen and see which buttons they pressed and how much time it took.

Before we started prototyping, we set up some design questions. I. Do Penny’s interactions satisfy the children?II. Do children understand how to set up and edit a saving

goal? III. Does Penny work like how children expect a piggy bank

to work?These three questions can be easily answered by user tests with our processing prototype. This leaves only one design question unanswered, which is whether it motivates children to save. We believe that this question can be answered in a natural setting with an ‘in the wild’ study where children can take Penny home for some time and then we could see if they really use it and save more.

EXPERT EVALUATION AND TASK DESCRIPTION

To check if our prototype is understandable for children and to make the user test as efficient as possible, we made some expert evaluations. We made two heuristic evaluations (Charlotte and Maud) and two cognitive walkthroughs (Lars and Naomi). We add one heuristic evaluation and one cognitive walkthrough in this chapter and we will compare those methods. However, before we made these expert evaluations, we agreed on the different tasks the user needs to carry out.

When using Penny the Piggy Bank, the user needs to accomplish several tasks, like setting a saving goal, changing a saving goal and inserting money. We will describe these tasks with use cases. The user can either insert coins or paper money in the piggy bank. Since the piggy bank can only count the coins, the value of the paper money needs to be typed by hand. So we have two different use cases for inserting money, one with coins and one with paper money.

I. The user presses the button that says ‘click here to set a saving goal’

II. The system shows a textbox with the question ‘what do you want to save for?’ and a keyboard and a button that says ‘ok’.

III. The user enters the name of the thing he is saving for and presses the ‘ok’ button.

IV. The system shows a textbox with the question ‘how much does this cost?’ and a keyboard and a button that says ‘ok’.

V. The user enters the price of the thing he is saving for and presses the ‘ok’ button.

VI. The system shows a bar with the total amount of money you’ll need for your saving goal, filled to the percentage of money you already have.

I. The user presses on the button that says 'adjust saving goal'

II. The system displays three boxes, one with 'change saving goal', one with 'change price' and one with 'delete saving goal'.

III. The user presses on the button that says 'change saving goal'.

IV. The system displays 'your old saving goal was a play station, what is your new saving goal?'

V. The user types in 'iPhone'.VI. The system shows a bar with the total amount

of money needed for the new saving goal, filled to the percentage of money you already have.

I. The user picks up the coin and moves it to the piggy bank’ slot, which is located on top of the piggy bank.

II. The system will either, smile, wink, make a sound or becomes bigger in size.

III. The system will add the value of the coin to the 'money inside Penny'.

IV. The user smiles

I. The user picks up the paper money and moves it to the piggy bank’ slot, which is located on top of the piggy bank.

II. The system will either smile, wink, make a sound or becomes bigger in size.

III. The system will show a text field with a digital keyboard with the question: 'Select the amount of money you’ve put into Penny.'

IV. The user types in the amount of money he or she had put in Penny.

V. The system will add the value of the paper money to the 'money inside Penny'.

VI. The user smiles 16

From the cognitive walkthrough we found the following things we need to change in our prototype. We should add feedback on what happens when scanning your finger, for example a circle that indicates how far you are with scanning. We should add feedback after typing, for example 'Your (new) saving goal is Playstation. How much does it cost?' We should change the keyboard into one with only letters while typing a saving goal, and a keyboard with only letters while typing how much it costs. We should make the on/off button more clear by using an on/off button symbol. We should use 'Change name' instead of 'Change saving goal', because it is too confusing with an earlier 'Adjust saving goal' and it is more clear what the user will change when clicking on it. Also, there should be a cross to cancel the action and go back to the home screen. After typing there should be the option to go back to an earlier screen or to confess that you want to change it.

COGNITIVE WALKTHROUGH

children from 10 to 12 years old that are familiar with digital screens

USER TASK

the user changes saving goal

ACTIONS

the user clicks on 'adjust saving goal'

the user clicks on 'change saving goal’

the user types in ‘iPhone’

is effect current action the same as the user goal?

is the control for the action visible?

will the user recognise action as correct one?

CONCEPTUAL MODEL QUESTIONS

THE USER CLICKS ON ‘ADJUST SAVING GOAL’I. Yes, because if the user wants to adjust the

saving goal, they can adjust it by clicking on it.II. Yes, because the screen shows a button.III. Yes, because you can only click on one button

and the text on it is understandable.IV. Yes, the system will show a few options to adjust

the saving goal

THE USER CLICKS ON 'CHANGE SAVING GOAL'I. Yes, because if the user wants to change the

saving goal, they can change it by clicking on it.II. Yes, because it is a button with text on it.III. No, because similar words were used in the first

step and also, there are more different buttons. I would suggest to use 'Change name' instead. Also, there should be a cross to cancel the action and go back to the home screen.

IV. Yes the screen will show 'Your old saving goal was… what is your new saving goal?'

THE USER TYPES IN 'IPHONE'I. Yes, because when the user wants to fill in their

new saving goal, they can type it.II. Yes, because it is asked in form of a question and

a keyboard pops up.III. No, because after typing they cannot do

anything. I would suggest an OK button or a cross to cancel the action.

IV. No, because there is no feedback. I would suggest some feedback, like 'Your new saving goal is: iPhone'.

17

will the user understand the feedback?

appendix 7.1

From the heuristic evaluation we found the following things we need to change in our prototype. We should add a warning dialog after the user changes his or her saving goal For example, 'Do you know for certain to change your saving goal. Your old saving goal will be deleted' with an option to say if you would like that or not. We should add a cancel button on all boxes to go back to a previous screen. We should add a backspace button when typing on the keyboard to be able to change a mistake.

HEURISTIC EVALUATION

ERROR PREVENTION When changing your saving goal you can unknowingly

delete your previous saving goal, because there is no warning dialogue telling you

that your current goal will be gone when you change it.

Major. If you accidentally change the saving goal, the only way to fix it is to

change it again to the previous goal. This will take an unnecessary amount of time.

USER CONTROL AND FREEDOM Once you’ve clicked ‘change saving goal’ you can’t go back, because there is not an exit button.

Major. When you click ‘change saving goal’. You need to change it, you can’t go back. This could give a lot of users unwanted consequences.

USER CONTROL AND FREEDOM You cannot remove text you already typed when setting or changing the saving goal, because there is no backspace button

Major. The only way to fix it is to set the goal you just typed and then change it but it will take an unnecessary large amount of time. For children, spelling mistakes are easily made so there should be an option to go back.

USER CONTROL AND FREEDOM If you change your saving goal, you can’t go back to your previous one, because there is no undo button. Major. If you accidentally change the saving goal, the only way to fix it is to change it again to the previous goal. This will take an unnecessary amount of time.

D I S C U S S I O N E X P E R T EVALUATION After we made both the heuristic evaluation and the cognitive walkthrough, we found two similar things we should change; a cancel button and after typing a button to confirm if you want to change it. However, we found that the other things were different, because those methods of expert evaluation are focussed on different things. The heuristic evaluation focusses more on errors that the user can make, while the cognitive walkthrough is more focussed on feedback that the user receives. For examp le , f rom the heur i s t i c e v a l u a t i on we c ame to t he conclusion that we should add something like 'Do you know for certain if you want to change your saving goal? Your old saving goal will be deleted' to prevent the user from making mistakes. From the cognitive walkthrough we found for example that after typing your saving goal, the system should say 'Your (new) saving goal is Playstation. How much does it cost?'.

18

appendix 7.2

Now that we have done the expert evaluations, we can test our prototype on the users by the means of a user test. For our user test we use our processing prototype. After the user test, the data will be analysed and some design suggestions will be made. We will also compare the (results of) user evaluation and the expert evaluation. The purpose of our user test is to test whether our target group understands the functions our product provides, as well as if they can perform a more complicated task on their own without any help or previous knowledge. Our study requires us to provide a basic introduction to Dutch children aged 10-12, after which they’re given three different tasks on a sheet of paper with the question to perform those tasks. No help or instructions will be provided to ensure the user group is capable of handling the product to it’s full extend on their own. We will describe the user test according to the DECIDE framework.

USER TESTS

can the child complete the tasks?

EXPLORE SPECIFIC QUESTIONS

does the child enjoy the prototype?

how does the child react during the tasks?

would the child like to have such

a product?

what does the child not like about our prototype?

how many errors does the child make per task?

DETERMINE GOALS The goals of our user test are to find out if children can complete the tasks successfully, how long it takes them to complete the tasks, how many errors they make per task. Also, we want to know if they enjoy the interaction of our prototype, for example if they like the sound the piggy bank makes when the child inserts money. Additionally, we like to know whether the child is satisfied with the product.

PRECAUTIONS

the child can’t see the computer yet.

the tasks are hidden.

the questioner and the note taker are both

ready

the child is paying full attention to the test.

the sound of the computer is turned on

all necessary programs are opened and working

You want to save for a playstation, it costs €228. Set this saving goal.

The price of the playstation has

changed to €208. Change the price of the saving goal

TASKS

Put in the coins in Penny.

19

We chose to do a user test, because we want to evaluate on a set of tasks for our interface. The child is asked to complete three tasks on the computer by using the computer mouse. During the user tests, the computer screen is recorded. The child will receive task cards and is asked to perform these tasks. The observer will observe the child and notes how the child responses during the tasks by looking at for example the facial expressions. Afterwards, the child is asked what he or she thinks of the general product and if he or she would use it themselves if available in a store. Also, the child is asked whether things could be improved.

CHOOSE EVALUATION PROCESS, PRACTICAL AND ETHICAL ISSUES

DECIDE HOW TO DEAL WITH ETHICAL ISSUES We will only film the screen, because of the privacy of the child. Also, it would maybe be scary for a child to be filmed while completing those tasks. We have asked whether we may interview the children and if they could test our prototype at the one who is responsible for those things at the school. The following is an informed consent form which she signed, so that we are sure that we can use the information and are allowed to film the screen.

PARTICIPANTS

EXPECTED TASKS

RECORDING

EXPERTISE

we want to film the screen on which the children interact, so that we can use these videos to analyze data.

We do not want to film the children, because of their privacy.

we want to test both girls and boys, so that this does not influence our user test.

they may make mistakes, because that will only help us finding important things to change in our prototype.

we need access to enough children, so we will test them at the primary school

we want to test a diversity of children, so that we know how each persona would react and if they can all use it. We want to interview 12 children

IDENTIFY THE PRACTICAL ISSUES

the children will be asked to do three tasks within 3 minutes. Those tasks are the main tasks of the concept and therefore the most important.

Also, we think that it could influence the data we gather, since it could make them feel

comfortable.

we want to control the testing conditions by giving each child the same tasks in the same order. Also, we are testing at the same location.

20

appendix 8.1

the location in which the evaluation is conducted does not influence or distort the results, because how the children act during school is not very different from how they act at home. Also, we increased the ecological validity by making sure that the participants do not know that the screen is filmed and they are not filmed themselves

the evaluation method m e a s u r e s w h a t i t i s i n tended to measure , because it measures if they like the product and if they can use it

t e s t e d i n t h e s a m e circumstances. For example, they need to carry out tasks in the same order and the location is the same. Also, we made sure that our user test is structured with a protocol.

We want to make sure that we do not make biases by making sure to ask everything we can ask in a user test and not selectively gather data that we think is important. During the user tests, we will pay extra attention to our tone of voice, facial expressions and the way questions are phrased.

We should carefully look at how much the information can be generalised.

RELIABILITY

VALIDITY

ECOLOGICAL VALIDITY

BIASES

SCOPE

EVALUATE, INTERPRET AND PRESENT THE DATAI. Ask the child for their age and name.II. Tell the child that this is a computer version of a piggy bank we designed named ‘Penny’. In reality the

product shall be a physical piggy bank with a touch screen. Tell the child that we are eager to know their experiences with Penny to improve our design.

III. Tell the child that he or she will be asked to perform three tasks. The child is only allowed to use the computer mouse. Tell the child it is no problem to make mistakes.

IV. Turn on the screen-recording program and make sure the recording indicator isn’t visible.V. Now you allow the child access to the computerVI. Give the child the task cards one by one in the right order and let the child perform the tasks

themselves. VII. Note how the child responds (facial expressions, physical stance etc.)VIII. Afterwards, ask the child what they thought of the general product and if he or she would use it

themselves in a real situation. Make sure to also ask what could possibly be improved.

RESULTS From our user test, we found that 83% of the children were able to fulfil all three tasks within three minutes without any problems. In our requirements we stated that 80% of a test panel of children aged 10-12 shall be able to successfully complete a certain task without ever having used the product before and that 80% of a test panel of children aged 10-12 should be able to complete a task within one minute.

These requirements were both successful. Also, we found that the children liked the playfulness of Piggy and that most children said they would like to have one. For example they all smiled when they heard Piggy oinking. In our requirements we stated that 80% of the children should think the product looks attractive so we definitely achieved this. Also, they found it useful, because by using piggy they don’t need to count their money by hand. Another thing the children liked is that you can determine yourself what you want to save for. A child was scared about people seeing how much money he has via internet. This is an important aspect and we should make sure that it is safe to use for children. So for further research, privacy would be an important aspect.

21

appendix 8.2

After concluding our user tests, we analysed our results using the notes we made. From the results of this analysis we came up with several design improvement suggestions that meet the requirements and guidelines we set for ourselves. Those suggestions are:

SUGGESTIONS TO IMPROVE OUR DESIGN

CHANGE LOCATION OF BUTTON One participant suggested to change the location of the button, so that if children have more bank accounts there will be more place to put them on the screen, however from our interview, we concluded that most children have only one bank account. However, changing the location of the button will give a better overview.

MAKE SURE THAT IT IS SAFE TO USE Two participants stated that they felt as if Penny was not very safe because they wouldn’t like strangers to be able to see how much money is on their account. But after an explanation of our idea using a fingerprint scanner they felt more comfortable. The idea of this wasn’t in our user test and would most likely require a more lengthy and in-depth analysis test to see how children would feel about using it that way.

DIFFERENT COLOURS FOR PENNY A piggy bank is based on the shape of a pig, and is therefore usually displayed in pink. To adapt to the wishes of children that do not like this colour, we can provide the product in several other colours too.

MAKE SURE THE TOTAL AMOUNT OF MONEY IS CLEAR The par ticipants sometimes had trouble finding the total amount of money they actually possessed. This can easily be made more clear by adding a summation line above the total amount.

FIRST CLICK IN TEXT BOX, THEN TYPE A cultural constraint which popped up while performing a user test was that 9 out of 12 participants clicked first on the text box before starting to type, as a means of saying “I want to type something in this location”. Probably, the children apply this to other online boxes. To adapt to this behaviour we could make it so the text box has to be clicked first.

SPACE BAR AND COMMA During the user test, we found that the participants were searching for a space bar. So you could add a space bar to make a savings plan for products which names consist of multiple words. Also, a decimal point that could be added when you want to add the numbers behind the decimal point.

BIGGER LETTERS In the user test, we found that the users found it hard to read the text, because they bend forward to read the text. Also, the text of our product proved to be difficult to read by children with dyslexia. This problem is easily fixed by enlarging all text and numbers.

ADD HOW MUCH YOU STILL NEED TO SAVE When asking some questions during the user test, one boy had some trouble to find out how much money he still has to save to fulfil the saving goal. Our prototype does show how much money you already have and how much you need to be able to purchase your saving goal, but it doesn’t tell you how much you still need to save. Adding a value next to the savings plan bar for the amount left to save up fixes this issue.

22

appendix 8.3

Both the expert evaluation and the user test provide suggestions to improve the prototype.

COMPARISON EXPERT AND USER TESTING

23

The expert evaluation focusses more on the interface of the prototype, while the user evaluation focusses more on the interaction between the user and the prototype. Furthermore, with an expert evaluation you give suggestions based on interpreting the user, which does not prove 100% certainty whether these suggestions will lead to a better design.

With the user evaluation you test your prototype on real users, getting to know for sure what the user understands and does not understand about your design, however you’re limited to the capabilities of the participant. Additionally, a user test costs much more time than an expert evaluation because o f the t ime requ i red for preparations, planning and interviewing your user group. It can turn out to be challenging to find enough participants in the first place and when you want to interview a user group like children, you’re required to have permission from their parents too.

All in all, both the user evaluation as well as the expert evaluation were valuable assets in our process of making a better product, they both proved to be extremely useful in finding and solving different types of issues.

CONCLUSION By taking the user-centred design approach, we developed an idea focussed on the users. The personas helped us in getting to know our user and what they want in the final product. For example, we first assumed that children could not use too complicated systems, however, during the ethnographic interview we found that they already understood contactless payments without ever having used this system before. Since we had a good idea of what our user wants in the product, we could more easily choose an interaction style that helps the user. After we built our first prototype, much has changed by doing the expert evaluation and the user test. To get an even better prototype, we suggest an ‘in the wild’ research to test if the user is really motivated to save by using this product. Also by more iterations, the prototype can be improved.

OINKMADE BY GROUP G6 • Maud Berbé, Lars Giling,

Charlotte Leuverink and Naomi Swagten• User-Centred Design • Industrial Design