Deliverable - STARR · This document can be used in several ways. The executive summary, and the...

| P a g e | 1 D 3 . 3 : F i n a l R e q u i r e m e n t s a n d R e c o m m e n d a t i o n s

Decision Support and self-management system for stroke survivors

Deliverable D3.3 Final requirements and recommendations -

living document

Workpackage WP 3 Lead beneficiary

ULUND

Due date 2018-10-31 Submission date

2018-11-08

Type RE, PU

Author(s) Kirsten Rassmus-Gröhn, Charlotte Magnusson, Margarita

Anastassova, Sabrina Panëels, Stéphane Bouilland, Mathilde

André, Djamila Aouada, Abd El Rahman Shabayek, Renato

Baptista

Abstract The deliverable describes the last iteration of the user

requirements studies and their major results.

Keywords User requirements, interface requirements, service requirements, stroke survivors, one handed use, brain fatigue, iterative testing, user experience design, user centered design

Ref. Ares(2018)5709161 - 08/11/2018



History of changes

Rev.

N

Description Author(s) Date

1 First draft of the document Kirsten Rassmus-Gröhn 10/10/2018

2 ULUND contributions Kirsten Rassmus-Gröhn 18/10/2018

3 More ULUND contributions Charlotte Magnusson, Kirsten

Rassmus-Gröhn

19/10/2018

4 First attempt at re-organizing

requirements

Kirsten Rassmus-Gröhn 24/10/2018

5 CEA, HOP and ULUX

contributions

Margarita Anastassova 30/10/2018

6 Edited tables to save some space Kirsten Rassmus-Gröhn 02/11/2018

7 Re-organizing requirements Kirsten Rassmus-Gröhn 03/11/2018

8 Writing summary and finishing up Kirsten Rassmus-Gröhn 07/11/2018

9 Final revision Margarita Anastassova 08/11/2018



Table of contents

Executive summary .................................................................................................................... 5

1 About this deliverable............................................................................................................ 6

1.1 The user of STARR ........................................................................................................... 6

1.2 Method .............................................................................................................................. 6

1.3 The target audience for this deliverable ............................................................................. 7

1.4 Outline of document .......................................................................................................... 7

2 Balance mat pilot tests and workshop ................................................................................. 10

2.1 Pilot tests ......................................................................................................................... 11

2.2 Workshop with physiotherapists ...................................................................................... 12

2.3 New or strengthened requirements / recommendations for design .................................. 13

3 Chat bot mock-up tests –ULUND ........................................................................................ 14

3.1 Results ............................................................................................................................ 15


4 Chat bot mock-up tests –HOP and CEA ............................................................................. 18

4.1 Results ............................................................................................................................ 18


5 Home based training application usability test – ULUX, CEA & HOP .................................. 20

5.1 Results ............................................................................................................................ 20


6 Development and tests of the walking game – ULUND ....................................................... 22

6.1 Design: First prototype .................................................................................................... 22

6.2 Design: Second prototype ............................................................................................... 24

6.3 Beta testing ..................................................................................................................... 24

6.4 Conclusion ...................................................................................................................... 25


7 Serious games testing – HOP ............................................................................................. 28

7.1 Participants ..................................................................................................................... 29

7.2 Major results .................................................................................................................... 29


8 Analysis of clinical tests and questionnaires – HOP & CEA ................................................ 32



8.1 Clinical tests .................................................................................................................... 32

8.2 Usability questionnaires ................................................................................................... 32

9 Final list of requirements ..................................................................................................... 34

9.1 Usability requirements (T3.2) ........................................................................................... 34

9.2 Service requirements (T3.3) ............................................................................................ 36

References ............................................................................................................................... 39

Appendix A ............................................................................................................................... 40



Executive summary

User requirements are those requirements that are put on the STARR system from the user’s

point of view and deal with creating a foundation for designing a system for high user

experience – which is a term for practical and subjective aspects of product-person interaction.

The requirements are divided into user and service requirements. The service requirements

answer mostly to the question “what should be developed?” and the usability requirements to

“how should it be developed?”

The STARR requirements have been iteratively developed from early investigations like

interviews and co-design workshops, to evaluations of mock-ups and sytem components.

The result is a list of 28 usability requirements, and 44 service requirements targeted to the

user group who are primarily stroke survivors and their families. For them, there are no

previous general requirements to fall back to, which is the reason for the lengthy list. The

medical personnel are also a target group, but they are better covered by general, already

known requirements (see below).

The requirements are grouped in several categories:

User requirements

o Hardware requirements

o Software requirements

Service requirements

o Stroke survivor side

o Medial personnel side

o Exercise related



1 About this deliverable

This document concludes the trilogy of requirements reports in the STARR project. It attempts

at collecting all the requirements into one single document, reporting both service requirements

and usability requirements that have been discovered or emphasized by this particular project,

relevant to self-management and persons who have had a stroke. Naturally, there are many

standard requirements or guidelines for designing digital systems in order to achieve good

usability, for example (Nielsen, 1993; Norman, 2002; Schneiderman, 1992). There are also

guidelines when designing for older persons (e.g. Díaz-Bossini & Moreno, 2014) or persons

with cognitive difficulties (e.g. Funka Nu AB, 2012). Such requirements are not repeated here

if they have not proven themselves to be particularly important. Isolated general requirements

may also be overruled by requirements in this document.

The requirements are not enough in themselves either – it is the process of elicitating them,

and continuously being open to additional requirements that will ensure the success of the

system and its good usability (see also 1.2 below).

In an attempt to make this deliverable readable, the reports on single tests have deliberately

been kept short, and no lengthy justifications for each requirement have been presented.

1.1 The user of STARR

The end user of the STARR system is a stroke survivor who needs help in managing their risk

factors. This is quite a broad audience, with different needs and wishes. Therefore, the primary

STARR user is someone who still has notable difficulties – perhaps with motor skills, cognitive

skills and fatigue. Therefore, usability and service requirements need to be adapted to that

particular user group. There are, as yet, no general requirements for this particular user group,

therefore, the resulting list is quite extensive.

The user is also not isolated, but is found in a social and medical context. It is assumed that

the person has some sort of regular contact with a medical doctor. In addition, the person could

have carers – formal health care personnel or informal carers lite family members – that could

be affected by the stroke survivor using the STARR system.

The medical doctor or other relevant helath personnel is also a user of the system. The doctor

needs to be able to get an overview of the person’s data, and to fit this into their already tight

schedule. However, less specialized requirements have been found for this user group, as

they mostly are covered by general guidelines nad recommendations (see above).

1.2 Method

Several different methods have been applied throughout the project lifecycle. In the beginning,

exploratory activities were employed to both gather broad requirements and to inspire and

inform the design work. These activities were:

Literature studies on related work D3.1 D3.2

Interviews with stroke survivors, their carers and personnel D3.1, D3.2

Focus group discussions about exercise D3.1



Workshop with user involvement partners, discussing the results of initial interviews

(result, see Appendix A)

Co-ideation with stroke survivors and their spouses D3.1

Tests with mainstream activity monitoring – competitive analysis on data quality,

usability, utility and user experience D3.2

After these activities, the main focus has been on iterative testing of sketches and prototypes

in different stages. This is in line with the user centered design (UCD) method (ISO, 2010)

which advocates iterative testing and involvement of real users. The UCD method also

explicitly points out that: “Some requirements only emerge once a proposed solution is

available.” This underlines that the purpose of these tests has been two-fold: 1. To gather

usability feedback to improve the designs. 2. To refine the requirements.

1.3 The target audience for this deliverable

This is a restricted deliverable, as planned. Therefore, the document is meant to be used

internally – to report the progress of the internal tests and to exchange knowledge. The final

list of requirements could perhaps be extracted and be used independently of the tests, and

also be of use to someone designing self help systems in other areas, but they might also

loose their context and therefore be difficult to understand.

1.4 Outline of document

This document can be used in several ways. The executive summary, and the final summary

of the requirements can be used for reference.

Additional chapters cover the iterative tests that have been carried out in the 3rd year of the

project.

1.4.1 Chapter 1 (this chapter)

May help to navigate the document and to understands its preconditions.

1.4.2 Chaper 2: Balance mat pilot tests and workshop – ULUND

A report on a pilot trial of a collection of exercise equipment for the home consisting of a

balance mat with visual and auditory feedback connected to a data collecting server. Seven

(7) participants tested the system, and iterative improvements were done to it during and after

the tests.

1.4.3 Chapter 3: Chatbot mockup test – ULUND

Three members of the Stroke Association i Sweden were introduced to the first mock-up of the

chat bot designed by INIT.

1.4.4 Chapter 4: Chatbot mockup test – CEA & HOP

Two expert users from the medical field (occupational therapist and research engineer)

evaluated the chat bot mock-up by INIT.



1.4.5 Chapter 5: Home based training application usability tests – CEA & HOP

A home-based training application developed by ULUX underwent a heuristic evaluation by 2

usability specialists, an occupational a physiotherapist and a research engineer.

1.4.6 Chapter 6: Development and test of walking game – ULUND

ULUND have developed a motivating outdoor walking game for iPhone and evaluated the first

iterations together with five stroke survivors.

1.4.7 Chapter 7: Serious games tests – HOP & CEA

Report of method and qualitative results from clinical tests of serious games for exercising on

an indoor exercise bike.

1.4.8 Chapter 8: Analysis of clinical tests and questionnaires – HOP & CEA

Analysis of data collected in the serious games test (chapter 7).

1.4.9 Chapter 9: Final requirements list

A condensed list of requirements divided into service requirements and usability requirements

based on previous deliverables and the results of the iterative tests reported in this deliverable.





2 Balance mat pilot tests and workshop

In conjuctions with a nordic project – ActivABLES, a setup of home exercise equipment has

been developed. It revolves mainly around a balance mat prototype (ActivFOAM), that

provides a soft standing surface that challenges balance but does not tilt. ActivFOAM comes

with a selection of interactive activities:

you can play music from a music player,

play a couple of music pieces and soundscapes interactively

play games (an audio game and a pong game)

see visual pressure feedback that visualizes your own pressure distribution and center

of balance, and thus be made aware of your weaker side

FIGURE 1. LEFT: THE BALANCE FOAM, TOGETHER WITH THE FEEDBACK DEVICES – A TABLET FOR THE

VISUAL PRESENTATION, AND LOUDSPEAKERS FOR SOUNDS. RIGHT: THE REDESIGNED LAMP - EACH

BRANCH LIGHTS UP ACCORDING TO DIFFERENT EXERCISES.

The mat can also be connected to feedback lamps via a local server that can display the

progress. The reason to this is to make a display that calls for attention. If the result is only

hidden in an app online, the user is required to remember to do the exercises. The lamp display

could remind the user to do their exercises.

The server can be used to set a daily goal for balance training, e.g. 10 or 20 minutes per day.

Training can be divided into several sessions per day. ActivFOAM registers when it has been

stepped onto and stepped off, and counts a use session that way. This setup has not been



connected to the STARR system, due to the lack of a health partner in Sweden we do not have

the possibility to store personal data online. Everything is instead stored locally in this particular

test.

The reasoning behind creating a balance mat is that balance is a central part of being able to

do exercise (and can be an exercise in itself), which is a major part of self-managing stroke

risk factors. We have worked with motivation to do exercise more than rehabilitative exercises

per se, motivated by not having a health partner to collaborate with locally (e.g.

physiotherapists).

2.1 Pilot tests

The following two tables give an overview of the pilot tests.

TABLE 1 PILOT TEST PARTICIPANTS AND THEIR MOTOR RELATED DIFFICULTIES

Gender Age Stroke? Motor problems Other stroke related problems

1 F 76 N Arthritis, uneven balance

2 M 71 Y Minor balance problems Tinnitus, fatigue, some remaining aphasia, mood swings

3 M 68 Y Minor balance problems, less strength in right side of body

Less stamina, some aphasia (talks slowly), difficult to motivate to do exercise

4 F 74 Y

Right side of body very much affected. Uses wheelchair. Has orthosis on right leg and can walk short distances indoors with some difficulty Fatigue

5 M 77 N None

6 F 81 Y Problems walking longer streches than 500m. Multiple fractures in ankle.

Cognitive problems, difficulty understanding the need for training

7 F 79 N Scoliosis, uses walker

TABLE 2 SETUP DETAILS OF BALANCE MAT TESTS AND DURATION OF TEST. THE BASIC SETUP WITH MAT,

SERVER AND TABLE ON A STAND WAS THE SAME FOR ALL PARTICIPANTS OR PARTICIPANT GROUPS.

PARTICIPANT 4 HAD TECHNICAL PROBLEMS, AND THE REAL USE WAS LESS (APPROXIMATELY 3 DAYS).

Placement iPod Lamps Loudspeakers Duration

Home of participants 1 and 2 Yes No Battery 5 days

Home of participant 3 Yes Yes, strip without diffuser Power connected

8 days

Home of participant 4 No Yes, strip with diffuser USB 9 days*

Home of participant 5 and 6, participant 7 was a visitor

No Yes, strip with diffuser USB 6 days



As can be seen by table 2 above, the setup changed during the pilot test run. When major

usability problems were encountered, these were remedied as soon as possible, iteratively.

The first and second pilot tests showed that there were issues with charging and the setup in

general – having too many devices. Since the mat was connected to the tablet via USB port,

which is also used for charging, the users forgot to disconnect the mat and connect the charger

to charge the device. Hence, when they wanted to use it, it was out of power. Another tablet

was used for later tests, that could be charged via a separate charging port. The iPod that was

used for remote control was removed, and the control app was put into the tablet instead. The

drawback of that was that users needed to be able to switch between apps (balance and

control) on the tablet, the original plan was to make each device have one single purpose. The

lamp feedback was tweaked as well. When used in a home, the original brightness of the lamps

was too intense, and the color pattern for signaling that the set goal was reached, disturbing.

Some user interface problems for the tablet apps concerning font sizes, colours, contrast,

placements were also discovered and remedied iteratively.

After all the pilot tests, the mats were prepared for a second round of long-term tests, and thus

the setup was refined once more. For example, a game was added (obstacle course game)

and the feedback lamps re-designed into trees (that also could give feedback for other physical

activities). Some work with the balance mat is reported in

2.2 Workshop with physiotherapists

During late autumn of 2017, an informal workshop with health care personnel was carried out

at the stroke unit at the Lund University Hospital. Participants were given the opportunity to try

the balance mat with basic feedback (Figure 2) and the feedback lights (Figure 1).

FIGURE 2 LEFT: THE BASIC INTERFACE. THE TURQUOISE FIELDS REFLECT THE PRESSURE FROM THE

FEET (THE LIGHTER AREAS INDICATE MORE PRESSURE). THE WHITE DOT SHOWS THE CENTER OF

BALANCE. RIGHT: THE PHYSIOTHERAPISTS EXPERIMENT WITH THE MAT, FINDING USES FOR HAND /

UPPER BODY EXERCISES.

Seven participants attended this workshop (2 rehabilitation/stroke physicians, 1 speech

therapist, 3 occupational therapists and 2 physiotherapists). The balance mat in particular got

positive comments, and in fact the physiotherapists basically wanted to use it immediately as

it was as they saw great potential for such a mat. Although the main use was expected to be



standing balance exercises, it was interesting to see that the physiotherapists thought the mat

could be used also for upper body/arm exercises (Figure 2).

Thus, it appears that also from a professional point of view the balance mat is a promising

development, that has great potential if it should be further developed.

2.3 New or strengthened requirements / recommendations for design

One major take-away is that as soon as the prototypes were taken out from the lab and put

into the home, only one or two pilot tests were needed to discover important usability problems.

Also, things that were no issue at all in the lab (like the intensity of the light) were shown to be

very important – things need to fit into the home.

Concerning recommendations, several specialized recommendations for this particular setup

were found, but some of these have generalizable implications. They are presented below,

with justifications when necessary. Note that these recommendations are foused on a system

that is targeted mainly at the stroke survivor themselves – as a part in a self management

system that should be possible to use without the support of family carers or health care

personnel. Service requirements are marked (SR) and usability requirements are marked

(UR).

1. The equipment needs to be tailored to home use: be movable, appropriate in size, sound

and lighting. (UR)

2. (Balance training) games need to have a wide range of difficulty settings. (SR)

3. Levels in games could be saved longer – having to start over on a too easy level might feel

like a waste of time (could drop 1-2 levels only). (SR)

4. Users are interested in detailed feedback, like high scores and if the exercise has been

carried out correctly. (SR)

5. Controling the app needs to be possible to do from a sitting position, so as to not tire the

user unnecessarily, for those who walk only short distances or where the handling of the

interface can cause the user to lose their balance. (UR)

6. The app UI should be possible to use with the off hand (if a stroke survivor has an affected

main hand) and thus be “forgiving” and not require exact fine motor skills. (UR)

7. The support for the tablet on the stand needs to be firm enough to stay in place when the

user uses their off hand in interaction (and thus is less apt at controlling the force used in

interaction). (UR)

8. If a standard tablet is used, users could need training and detailed instructions in their use.

Consider making a dedicated solution with only the balance mat control. (UR / SR)



3 Chat bot mock-up tests –ULUND

During the spring of 2018 the early design ideas for the finished system (front-end for stroke

survivors and health personnel) were tested. The initial evaluations of the wireframes were

made through a heuristic evaluation by usability experts in the project group. Based on the

feedback from these evaluations, a chat bot mock-up intended for the stroke survivor users

was developed in InVision (by INIT). This prototype was partly translated into Swedish and a

test undertaken with 3 members of the stroke organization in Sweden, who were active

participants of the local chapter. Parts of the Spanish prototype was used as well, the texts

translated orally. The test participants were:

Woman: born 1965. Aphasia, brain fatigue, short-term memory (memory for learning) problems, concentration difficulties, attention (hearing) difficulties.

Man 1: born 1955. Brain fatigue. Walking difficulties. Problems with one hand/arm.

Man 2: born 1949. Brain fatigue. Minor balance problems.

All three were quite used to computers, smartphones and tablets and owned a smartphone. The

mock-up was run on a SONY Z3 tablet (8 inches).

FIGURE 3 LEFT: THE PARTICIPANTS IN THE TEST WITH THE SWEDISH VERSION. RIGHT: EXAMPLE OF

POINT COUNTING INTERFACE IN THE QUESTIONNAIRE ABOUT MEDITERRANEAN DIET (SPANISH VERSION).

The test was sound recorded, and important comments transcribed. A short video was made

when they tested the Swedish mock-up version. They tested the versions in this order:

Alcohol scenario, translated into Swedish

Mediterranean diet, Spanish (with oral translation)

Menu with salt scenario and exercise scenario (oral translation)



New menu (no interaction, only a look at the design)

3.1 Results

Participants had minor problems interacting with the interface and were cautiously positive to

the chatbot concept, but underlined that its success depended heavily on the content. They

also commented that it was very limited or standardized. But the amount of text in the mock

up scenarios was considered appropriate (provided the user did not have aphasia).

It took a while until they managed to scroll down in order to see the buttons, despite being

quite used to smartphones and tablets. Additionally, one scenario (the salt scenario) had

clickable objects that were not immediately recognized as buttons.

They were particularly fond of the concept where answers to questions about their

(Mediterranean) diet rendered “points” (Figure 3, right), which may indicate that concrete

results that are displayed immediately are of interest.

When prompted about possible obstacles for users with aphasia, they commented that the

chat bot might need special design, perhaps with supportive images, and that it should talk

(voice feedback).

When the chat bot asked about contacting the doctor after the alcohol scenario, the participants

wondered why they were not recommended to contact their doctor themselves.

After filling in the questionnaire, they were confused as to what would happen to their answers

– would it be relayed to their doctor? If so, why didn’t the app ask if they wanted to as in the

case with the alcohol scenario?

When answering “No, I do not have time right now” the chat bot answered that it would come

back in 10 minutes. Here, the participants would like to receive a collection of possible answers

to choose from – e.g. 10 min, half an hour, two hours, tonight… This may of course be

contextual – if it is a reminder to take medicine, the options should be limited.

The new menu design was appreciated, particularly because of the images.

There were some other comments on the content (which may or may not be relevant for the

pilot prototype, depending on content choice) – both the factual content and the way some

things were expressed, e.g.:

It is difficult to know exactly the amount of vegetables / fruit that is “one piece” (grapes, melons, apples) – instead use grams / portions (servings) or take help from a table with “equivalents”, i.e. 1 small apple = 50 g, etc.

The amount of salt and olive oil that you use in total is difficult to estimate – partly because it is hidden in the food

In the salt example, both tablespoons and teaspoons (coffee-spoons) are used intermixed

The salt example rendered a long discussion about salt need, and examples were also given when participants had been in warm climate and because of perspiration required to eat salt tablet supplements. This may point to the need for individual and/or contextually adapted recommendations.

Some questions were raised as to what “processed” meat was – examples may be needed.




His is a shortlist of recommendations/requirements based on this particular test. Service

requirements are marked (SR) and usability requirements are marked (UR). Suggestions for

solutions are marked (SOL).

1. A chat bot could work as an interactive interface for stroke survivors (at least for those with tablet/smartphone experience), but more testing is needed to be certain. (SOL)

2. The content of the chat bot needs to feel relevant and rich enough. (SR) 3. The buttons need to fit on the screen and not require scrolling. (UR) 4. Clickable objects need to be clearly clickable – a button design. (UR) 5. Concrete results or immediate feedback about results / progress are appreciated. (SR) 6. If questionnaires about diets are used, make sure that the amounts of food ingredients are

understandable – use equivalents and measurable quantities. (UR) 7. Consider using images as reinforcement (for persons with aphasia) in the texts. (UR) 8. The chat bot should be able to speak (particularly for persons with aphasia, but could help

a broader audience). (UR) 9. When the user can choose to delay an activity, have multiple time frames to choose from,

based on the activity. (UR)





4 Chat bot mock-up tests –HOP and CEA

A version of the chatbot and the medical professionals’ interface, translated into French, went

through a heuristic evaluation in Hopale too. One occupational therapist (female, aged 36, 12

years of professional experience) and one research engineer (male, aged 50, 24 years of

professional experience) participated in the evaluation.

Notes were taken by the experimenter during the test. The medical profesionnals’ interface

was evaluated first, followed by the chatbot, with the same ofrder of presentation of the screens

as in ULUND, i.e.:

Alcohol scenario, translated into French

Mediterranean diet, French

Menu with salt scenario and exercise scenario (oral translation)

New menu (no interaction, only a look at the design)

4.1 Results

In general, the medical professionals’ interface was judged useful and usable. It was

suggested that the tabs corresponding to patients’ lifehabits, treatment and biomedical data

should change in some way (e.g. their colour), when an alert has been raised. When tested,

an icon was added whitihn the items of the tab, which was judged not explicit enough by HOP

professionals. It was also suggested that the questionnaires, originally in the patients’ profile

menus, be moved to a specific menu.

A possibility to personalize the interface according to the speciality of the medical professional

was also suggested, as different medical professionals do not need the same types of data.

As for the chatbot, it was stated that it has too much text and it asks very similar questions,

which can result into boredom and, eventually, abandonment. It was suggested that a speech

synthesis was added to make ti easier to interact with. For the same reasons, higher

interactivity was proposed, for example by including games. As for the messages of the

chatbot, it was suggested that they should be varied in order to adapt to patients’ profiles and

different contexts and situations.

It was also suggested that the font should be bigger in order to limit legibility issues.





10. A chat bot could work as an interactive interface for stroke survivors (at least for those with tablet/smartphone experience), but more testing is needed to be certain. (SOL)

11. Games may be included in the chatbot to make interaction funnier and to sustain motivation to use it. (SOL)

12. The content of the chat bot needs to feel relevant and rich enough. (SR) 13. Personalisation options should be proposed. (SOL)



14. Bigger fonts have to be used to improve legibility. (UR) 15. Concrete results or immediate feedback about results / progress are appreciated. (SR) 16. The chat bot should be able to speak (particularly for persons with aphasia, but could help

a broader audience). (UR)



5 Home based training application usability test – ULUX,

CEA & HOP

The home-based training application developed by ULUX also underwent a heuristic

evaluation in both CEA and HOP. In CEA, it was evaluated by 2 usability specialists (females,

aged 35 and 42, with respectively 10 and 16 years of professional experience). In HOP, it was

evaluated by one occupational therapist (female, aged 36, 12 years of professional

experience), one physiotherapist (female, aged 37, 13 years of professional experience) and

one research engineer (male, aged 50, 24 years of professional experience).

5.1 Results

The major results were the following:

o Add a possibility to load an exercise several times with different configurations and

test it.

o Add the possibility to record the skeleton on the patient side and transfer it to the

therapist side in order to visualize it.

o Make active only the buttons required for the interaction.

o The recorded exercise and the ongoing training should be shown side by side.

o Congratulation messages should be improved.

o Colour feedback should be added on the skeleton itself.

o Prefer visual graphical aids to text to show the next movement.

o The organization of the buttons and images should be consistent (e.g. image up and

buttons down).

o The text of the labels should be based on therapists’ and patients’ vocabulary.

o Set the number of testing iterations. Enable the patient to pause during the exercise.

Set a timer on the session length to be set by the therapist.

o Generate a report of many sessions to have a historical evaluation of the progress

through training sessions (both for the patient and the therapist).





17. Strive for consistency. (UR) 18. Strive for simplicity. (UR) 19. Strive for better user guidance. (UR) 20. Enable pose during exercising. (SOL) 21. Enable the possibility to set a time for an exercise. (SOL) 22. Generate aggregated data on patient’s history. (SR) 23. Provide the possibility to reload an exercise. (SR)





6 Development and tests of the walking game – ULUND

In the co-design workshop done during the initial user studies, one of the suggested design

ideas was a mobile treasure hunt game. Additionally, in comments in both interviews and focus

groups, games have been generally put forward as an interesting option. Thus, we decided to

implement a mobile activity game prototype to explore how such a game could be designed to

work well with stroke survivors. Based on our initial user requirements, the game should be:

easy to use (but not childish)

be possible to use with only one hand

be possible to personalize

be multimodal to support different abilities while at the same time avoid overwhelming the

user.

Since it was supposed to be a game, while also allowing the user to keep track of their activity,

we needed to provide feedback both on game progress as well as activity (in case these were

different). An additional recommendation for our user group is to make use of their language,

and also to provide instructions (a manual) on paper.

For the game design, we have been inspired both by Pokémon Go and an inclusive game for

visually impaired persons where you catch animals by making gestures with the phone

(Magnusson et al., 2011). In a location based game you need to tie content to locations – which

either means you have to support location editing for players, or you need to provide location

content yourself (automatically or manually). A problem is then that the user may find

himself/herself in an area without content (Pokémon Go as one example, works poorly in the

countryside where both stops and pokémons are few and far between). Since the game should

work “everywhere”, and also for persons who are unable to walk very far, we decided to base

the game on step counting/distance and not location. As the game is a mobile game, the initial

target user group are stroke survivors who are able to move independently and are able to use

a smartphone.

A first prototype was implemented, and tested first by members of the team, and then

extensively by one beta testing stroke survivor (updates were made iteratively in this process).

Once the game worked more reliably, four additional testers were recruited. Based on

feedback from these testers, a second version of the game was implemented and tested.

6.1 Design: First prototype

The game is implemented for the iPhone, and is built on a design where you specify both day

goals and game goals. The day goals are how much you want to be active over the whole day,

while the game goals are how much you want to do in a single game. You can select if you

want to track your steps, your distance or your active time. In the first prototype of the game,

the challenge is to catch stars. Since it is potentially hazardous to walk and look at the screen

at the same time, the game is implemented so that sounds and vibrations notify you when the

game needs attention, to allow you to keep the phone in the pocket while you are walking.



FIGURE 4 LEFT: THE MAIN GAME SCREEN. THE FOOTSTEPS WILL SHOW A WALKING ANIMATION WHEN THE

APP DETECTS THAT YOU ARE WALKING. THE ELLIPSE FILLS WITH BLUE AS YOU PROGRESS TOWARDS YOUR

GAME GOAL. RIGHT: THE POINTING MINI GAME. THE BLUE STAR IN THE LOWER CORNER IS A HELP BUTTON.

To catch the star, you have to succeed in a mini game. There are currently seven different mini

games in total. To launch the mini game, you press the star on the screen (Figure 4, left).

Games get more difficult as you progress to higher levels, and you will also get more games

(on the first level you only have three different mini games). The game will remind you when

you have reached half-way to your goal.

FIGURE 5 LEFT: GAME OVER SCREEN. MIDDLE: DAY RESULTS SCREEN. RIGHT: WEEK RESULTS SCREEN.



6.2 Once a game is finished you will come to the game over screen

(Figure 5, left). After this you will see your results for the whole

day (Figure 5, middle). In the day results screen you can press the

different items to see your results for a week ( Figure 5, right).

The app can also connect to LED feedback lights via Bluetooth LE

(see Outline of document

This document can be used in several ways. The executive summary, and the final summary

of the requirements can be used for reference.

Additional chapters cover the iterative tests that have been carried out in the 3rd year of the

project.

6.2.1 Chapter 1 (this chapter)

May help to navigate the document and to understands its preconditions.

Chaper 2: Balance mat pilot tests and workshop and Figure 1).

6.3 Design: Second prototype

The second prototype is quite similar to the first “under the hood”, but has a different theme:

you have a dog that wants to go walking (Figure 6).

FIGURE 6 LEFT: ENTRY SCREEN. MIDDLE: MAIN GAME SCREEN, RIGHT: REMIDER TO WALK (TEXT: WALK

THE STARR DOG, THE STAR DOG NEEDS EXERCISE).

As you walk the dog, you get different challenges (still indicated by stars on the screen). The

challenges have changed to dog related themes: Find a good tree where the dog can pee,

stop the dog from barking at a cat, follow the dog as it walks faster, slide a bowl of food to the

dog, throw a ball to the dog and guide the dog through a race course. In this version, you can

also get a reminder to walk (Figure 6, right image).



The design of the game is described in more detail in (Magnusson, Rassmus-Gröhn,

Rydeman, & Caltenco, 2018)

6.4 Beta testing

The first prototype was beta tested first by the team, to ensure the basic functionality worked.

After this we contacted a stroke survivor from the Malmö stroke organization (male, age 62),

who was willing to beta test the app. This tester would send almost daily reports with opinions

and suggestions which allowed us to improve and further develop the functionality. The “walk

faster” star, turned out to be quite unreliable, and we went through a whole series of iterations,

ending up relying on a combination of GPS and steps, before this mini game worked well.

Another mini-game, the pointing one, was also changed after getting feedback that it was

boring – on higher levels the star was made now to move, so that you would need to follow it

with the phone.

One thing we learned was how important it was that the progress shown in the app was for the

whole day – initially we had limited the results to activity done while the app was active, but

our beta tester was very clear on wanting to have “cred” for everything he did (also when not

playing the game). It was also interesting to see that given the choice, our tester preferred to

track distance instead of counting steps.

For this beta tester, the level progression was an important motivation. Initially the level would

not progress unless you had caught all the stars, but this was felt to be unfair, and we changed

the requirement to 80% of the stars. It also quickly became clear that more stars were needed,

and we added more mini games and more levels to the game.

We also recruited four more beta testers from the stroke organization in Malmö (three men

and one woman, ages between 43 and 68). All our test persons from the Malmö stroke

organization have had some remaining problems after their stroke, with walking, with balance

and with brain fatigue. We visited each of the new testers in their home, installed the app and

made initial settings. We also did a demo walk together with the user, to make sure he or she

was able to use the app (all of them were). They were also provided with a getting started

guide and a manual on paper. Unfortunately, this stage of the testing coincided with the

weather turning bad (winter), and it was only our initial beta tester who really kept using the

app during the winter. When the weather got better we contacted our testers again, and got

comments that led us to believe reminders were needed (one user stated he forgot to use the

app) but also a few comments that indicated that the stars were maybe a bit boring and

impersonal. This feedback led us to the redesign that resulted in prototype two.

Currently, 5 stroke survivors have tested the app for a longer period of time. The initial user

kept using the game and thought it was fun, while later test persons have been more sceptical.

One person, who had not previously played mobile games, felt stupid doing the mini games in

public. Two users also report the game element being “too much”, while still potentially finding

games like this interesting. The received feedback will be used in re-development.



6.5 Conclusion

The test results so far confirm that the design can be used by our users (all test users were

able to use it during the introductory walk), and we have seen an interest for this kind of games,

but our take away so far is that several different types of games are needed. Not everyone

enjoys mini-games, and too much feedback can be annoying (what is considered too much

varies between users). Based on the feedback received, we have designed two additional

versions of the game: one where you automatically pick up keys and treasure chests as you

walk (the keys can then be used to unlock the treasure chests at the end of the walk, Figure

7, left and middle), and one where nothing happens while you walk – but every time you finish

a walk, you progress in an image based “story” (a balloon travels through different landscapes,

see Figure 7, right). We have also included the possibility to select if you want a dog-theme or

the initial star-theme (which is less demanding visually). These designs will be tested during

the final test.

FIGURE 7 PICKING UP A TREASURE CHEST (STAR-THEME WITH TWO WALKING FOOTSTEPS FOR THE

BACKGROUND) MIDDLE: AFTER THE WALK YOU CAN USE THE KEYS YOU FOUND TO UNLOCK THE CHESTS

FOUND. RIGHT: THE BALLON “STORY” (THE LANDSCAPE CHANGES EVERY TIME YOU COMPLETE A WALK).


Based on our work with the app, we so far have the following requirements:

To see your progress is a major motivation, and you should see 1) your activity

progress and 2) game progress (SR)

The games need to offer a range of possibilities to cater to different preferences and

vary both the amount of feedback and the amount of game interaction (SR)



It should be possible to keep the phone in the pocket (with the game active) while

walking (UR)

If the game shows total daily stepcounts, distances etc, these should match the ones

you see in AppleHealth (UR)





7 Serious games testing – HOP

To date, only the clinical trial evaluating the serious games developed during the project has

started.

During the tests, patients receive three additional rehabilitation sessions per week over a

period of 6 weeks. During these sessions, the patient uses the serious games developed as

part of the project. The patient is installed on an ergocycle and has to pedal throughout the

session, the goal being to reach 20 minutes of pedalling in the session. The resistance of the

ergocycle is constant and identical for all patients; there is no link between the speed of

pedalling and the course of play so as not to incite the patient to risk a heart problem. The

movements are captured using a Kinect and the patient has to interact with the virtual

environment using the body trunk and the upper limbs. The level of difficulty is chosen by the

therapist according to the clinical objectives, the games also take into account the preferences

of the patients in order to improve their participation. Patients are assessed with clinical trials

(ARAT, Berg, Get up & go, 6 min test) at the beginning and at the end of the protocol and must

complete a usability questionnaire at the end of the first and last sessions.

FIGURE 8 EXAMPLE OF A REHABILITATION SESSION

A first series of three patients performed the protocol over the period of June/July 2018. The

second series (two patients) is on-going, therefore the results that are described in the

following sections concern only the first three patients and are quite preliminary.



7.1 Participants

Variable Mean Std Dev(N-1) Minimum Maximum

Weight (kg) 85.8 17.5 72.0 105.6

Height (cm) 178.0 4.3 175.0 183.0

Time since last stroke (months) 5.3 0.5 5.0 6.0

Age (years) 65.3 7.5 58 73

The first three patients recruited are male, aged 58 to 73 years, two are hemiplegic left and

one is hemiplegic right. The time since the stroke varies from 5 to 6 months. One uses a cane,

and another a tripod for walking.

7.2 Major results

In 6 weeks, games were played 75 times in total for all three patients. They played for about

16 minutes on average in a game but with a significant variability and pedalled 88% of the time

(75% to 93% depending on the patients).

Variable Occurrences Mean Std Dev(N-

1) Minimum Maximum

Total duration (min) 75 15.8 9.0 1.5 36.3

Pedalling duration in % of the total duration 75 0.88 0.12 0.44 1.0

Patients played each game roughly the same number of times; no particular preference

appears at this stage. The AquaNet and SpatioNet games were introduced later and were

therefore logically less used.

Number of sessions of each game per patient.

Game Patient 1 Patient 2 Patient 3 Total

AquaNet 3 1 3 7

Baudruches 8 6 11 25

Museum 8 5 7 20

SpatioNet 2 2 3 7

Bike 5 5 6 16

Total 26 19 30 75

If the right hand is almost always used, the left hand is only used in about 50% of cases.

Utilisation of the right hand Utilisation of the left hand

Modalities Occurrences % Modalities Occurrences %

False 1 1.3 False 35 46.7

True 74 98.7 True 40 53.3



In almost 95% of cases, patients were satisfied. The main reason for dissatisfaction was the

bike saddle, which was considered too hard. Unfortunately, the manufacturer does not offer a

more comfortable solution, thus our occupational therapist is currently making a cushion.

Satisfaction at the end of the game

Modalities Total %

Indifferent 2 2.7

Unsatisfied 2 2.7

Satisfied 71 94.7

A first principal component analysis was performed to check the consistency of the data. Active

continuous variables include the percentage of time spent by the elbow and shoulder in the 0°-

45°, 45°-90°, 90°-135°, and 135°-180° angular sectors, as well as the durations of each game

and the percentage of that time spent pedalling. The illustrative variables are the game used

(Baudruches, AquaNet, SpatioNet, Bike or Museum), the number of the rehab session (1 to

18), the patient ID, and the hand(s) used during the exercise. The following factorial planes

are obtained, with axes 1 and 2 accounting for approximately 45% of the variability of the data:

FIGURE 9 FACTORIAL PLANE OF AXES 1 AND 2 OF THE PRINCIPAL COMPONENT ANALYSIS

Axis 1 is essentially characterized by the use of the right hand. On the right are the games that

involve a moderate shoulder elevation and a large elbow extension, as in these games the

goal is to catch virtual objects on the ground. These are also the games in which the stimuli

appear intermittently and where the subject spends more time with the hand on the handlebars

of the ergocycle. On the left, the SpatioNet and Baudruches games involve a greater elevation



of the shoulder to scan the entire screen but it is not necessary to work with arms outstretched,

the targets are permanently present.

Axis 2 is characterized by the use of the left upper limb and seems to separate patients by

right or left-injury.

These results indicate that it will be necessary to recode the data according to the healthier

side / the injured side rather than the right / left side for the final analysis of the data.

Pedalling durations are not discriminating at the moment and there is no apparent schema in

the course of sessions.


Based on our work with the game, we so far have the following requirements:

Strive for simplicity. (UR)

Provide the possibility of personalization. (UR)

Use the healthier side (and not the paretic one) for calibration. (UR)



8 Analysis of clinical tests and questionnaires – HOP & CEA

8.1 Clinical tests

During the serious games trial, clinical tests were made on the patients that participated in the

trial. Table 3 shows the change in values for the items of the clinical tests, between the

beginning of the rehabilitation and the end, six weeks after. This is an average value over three

patients, thus purely indicative.

TABLE 3 CHANGE IN VALUE FOR CLINICAL TESTS FROM FIRST SESSION WITH SEROUIS GAMES TO LAST

SESSION

Variable First session Last session

ARAT - Grab /18 8.667 9.000

ARAT – Hold /12 4.000 6.000

ARAT - Pinch /18 5.667 5.333

ARAT – Global movement /9 3.000 5.000

BERG - Transfers 4.000 3.667

BERG - Pick up an object on the ground 3.667 4.000

BERG - Turning to look over the shoulder 3.667 4.000

BERG - Rotate on the spot 3.000 3.667

Get-up & go - Duration (sec) 19.363 18.380

Test 6 min - Distance travelled (m) 365.000 358.333

Test 6 min - Time to return to the rest frequency (sec) 155.333 84.333

Eight of the 11 modified parameters show improvement. There is a noticeable decrease in the

time spent to return to the resting heart rate, a sign of the effectiveness of the exercise training

performed by the patient. In the absence of a control group, however, it is not possible to

attribute this result solely to the serious games sessions, as the patient continues to receive

care and rehabilitation from other therapists.

8.2 Usability questionnaires

The usability questionnaires were completed at the end of the first session and at the end of

the last session. The table below show answers to qualitative questions posed to the

participants. Although it is difficult to draw conclusions with so few, the first results show an

essentially positive evolution of the way patients perceive the use of serious games as a tool

for rehabilitation.

Qualitative questions:

UP4) Using games helps me reach my therapeutic goals

FUP1) My interaction with therapeutic games is clear and understandable



FUP2) Interacting with therapeutic games requires a lot of thought.

FUP4) I find the use of the software intuitive.

IM1) I feel valued to use therapeutic games.

QS1) Therapeutic games provide good quality rehabilitation.

RD2) The results of rehabilitation using the therapeutic games are easily visible to me.

PP1) I find that the use of therapeutic games is enjoyable.

QL3) I recommend other patients to use therapeutic games for their rehabilitation.

AEI1) I could do rehabilitation on my own using therapeutic games if someone showed

me how to do it beforehand.

TABLE 4 RESULTS FROM USABILITY QUESTIONNAIRE. NOTE THAT ONE QUESTIONS (FUP2, MARKED WITH

*) IS PHRASED NEGATIVELY.

UP4 Completely

disagree

Somewhat disagree Somewhat agree Totally agree

First session 0 1 2 0

Last session 0 0 3 0

FUP1



FUP2*



FUP4



IM1



QS



RD2



PP1



QL3



AEI1





9 Final list of requirements

The list of requirements has undergone a development during the project. The initial

requirements and the updated requirements collected both service and usability requirements

in one list. Here, we attempt to separate them even though it is sometimes difficult. The service

requirements answer mostly to the question “what should be developed?” and the usability

requirements to “how should it be developed?”. Some of the initial requirements were more

expressed as technological solutions and are not relevant any longer (in this context) and have

therefore been omitted from this deliverable.

The origin of the requirements that have been kept in the comprehensive lists below can be

found either in their original form in D3.2 (though rephrased), in the new tests in this document

(above) or are a combination of several overlapping bullets. Not all of the above-mentioned

new requirements have made it to the list below. Those that are not repeated here are deemed

as specialized to the context and solution for the particular module of STARR and are of small

use as a general guideline.

9.1 Usability requirements (T3.2)

The usability requirements deal with details and specific requirements and are closer to the

solution – i.e. how a self-management system for stroke survivors should be designed.

9.1.1 Hardware requirements

The system should:

1. Be safe and secure

2. Allow for one-handed operation

a. Measurement devices need to be easy to take on and off with one hand

b. Measurement devices need to be large enough to fit swollen limbs

c. Charging connection needs to be easy to handle with one hand

3. Allow for operation with the off hand (since the main hand could be the one affected from

the stroke) – be robust enough, and forgiving in the interaction

4. Allow all interface components to be possible to manipulate from a wheelchair or sitting

position

5. Use the healthy side for calibration of movements or technical devices

6. Be tailored to home use: be movable, appropriate in size, sound and lighting.

9.1.2 Interface requirements

The system should:

7. Have an interface with simple and consistent design

8. Have an interface that fits on the screen and not require scrolling 9. Have an interface with clickable objects visually designed as buttons (affordance) 10. Strive to have an encouraging and positive design and phrasing

11. Be designed for “plug-and-play” use



12. Be provided in the native language of the user

13. Be designed with hemi-negligence in mind

14. Be designed with aphasia in mind:

a. Be multimodal: provide the same information through multiple channels (text,

images, sound, speech, vibration, etc.).

b. Give information in a sequenced way, not all the information together.

c. Leave time to process the information and to answer.

15. Be designed to cater for sensory input problems (hearing / vision)

a. Be multimodal: provide the same information through multiple channels (text,

images, sound, speech, vibration, etc.).

b. Be visually designed with clear and large enough text and images for a broad

audience

c. Be possible to adjust in font sizes and color schemes

d. Be possible to adjust in sound volume and to turn off sounds completely if needed

16. Be designed to cater for memory problems

a. Avoid login information that needs to be remembered

b. Include instructions, don’t require users to learn the interaction

c. Avoid long sequences where the user has to remember the initial steps

d. Require the user to perform one activity at a time

17. Be designed to cater for fatigue

a. Avoid too much simultaneous information (keep the interfaces “clean”)

b. Be possible to interrupt whenever needed

18. Be possible to personalize regarding

a. information content

b. goals

c. guidance

d. sharing settings (who to share data with and which data to share)

e. balance between gaming / non-gaming activities

f. amount and frequency of feedback information

g. precision

h. handedness

i. severity of consequences

19. Be visually designed for outdoor use with good contrast (dark text and detail on light colors)

20. Contain both online help and paper manuals for reference

21. Be accompanied by tutorials, courses, videos, presentations

22. Display progress in a respectful manner, such that a user is motivated also through dips in

their performance

23. Provide feedback through different media (diagram, graphs, point system, etc.)

24. Display concrete results / data that are understandable to the user

25. Display momentary results, history and progress

26. Messages from the system should be clear, timely and possible to repeat (in case they are

missed)

27. Provide timely and reassuring information for when it is time to charge (and how long it will

approximately last).



28. Use familiar measurement units when asking about quantities of foods or diet

measurements

9.2 Service requirements (T3.3)

The service requirements establish high-level requirements, overall goals and which services

and which content that should ideally be implemented in a self-management system for stroke

survivors.

9.2.1 Overall requirements, stroke survivor side

The system should focus on self-management, how the person who has had a stroke can be

empowered to manage their risk factors.

Furthermore, it should:

1. Support independence

2. Have content that is relevant and rich enough for the target group

3. Be possible to use throughout the rehabilitation process (from rehabilitation unit to home

use)

4. Provide relevant information about stroke, its causes and consequences

5. Provide relevant information about risk factors and their impact on stroke recurrence

6. Provide relevant information about available technologies and tools to manage risk factors

7. Provide up-to-date guidance on medication, exercises, nutrition, habits etc.

8. Contain information about motivation and emotional support, as well as how to deal with

cognitive difficulties.

9. Consider the social context (friends, informal carers, family…)

a. when introducing the system

b. for support of the stroke survivor concerning nutrition and similar factors

10. Provide technologies that require minimal installation or a palette of technologies the

survivor can choose from

11. Ensure that the survivors and carers are not stigmatized

12. Divide goals into sub-goals, ensuring that the user “wins small victories often”

13. For users with hemi-negligence

a. Support with appropriate reminders to think of and use the neglected side

b. Promote awareness

14. For users with memory problems, apraxia, inattention, abulia (mutism)

a. Support users with appropriate reminders

b. Make help available throughout the interaction

9.2.2 Overall requirements, professional side

The system should:

15. Integrate well with current methods of working

16. Strive for simplicity

17. Be efficient and not overwhelm the user

18. Provide reliable information about the health status of the stroke survivor



19. Provide filtering of the data

20. Provide technologies that could be easily installed by the carers

9.2.3 Exercise, stroke survivor side

Exercise is one of the major risk factors and one of the major hurdles in stroke rehabilitation.

The stroke survivor might not be able to do the same exercises as before, or be unused to

doing any exercise at all. The requirements have sub-headings that hopefully help the

understanding.

General

The system should:

21. Promote movement to avoid prolonged inactivity

22. Offer training programs, exercises or games

23. Promote balance confidence

24. Encourage daily exercise

25. Encourage exercise also without a goal of improving results

26. Focus on core activities for an active and healthy life:

a. Moving limbs (also affected side)

b. Balance

c. Walking

d. Cardiovascular training

27. Promote both outdoor and indoor activities

28. Be designed for motivation

a. Empowerment

b. Fun, enjoyable

c. Design for good and bad days

Measurements and monitoring

The system should:

29. Record and display health status measurements that make sense to the person using the

devices

30. Enable the monitoring of physiological indicators and unobtrusive monitoring of physical

activity for those less inclined to exercising

31. Have step measurement that is good enough for the purpose. If a person is just able to

walk a few steps, an exact measurement of steps is more important than if a person can

walk farther

32. Display momentary figures of exercise results

Physical stroke consequences

The system should:

33. Stimulate extending muscles rather than contracting

34. Avoid positions where the spastic muscle can be shortened



35. Be compatible with physical aids, like orthoses

36. Encourage the use of the affected limb(s)

37. Promote a secure gait

38. Promote transitions

39. Provide coordination and dexterity exercises

40. Contain activities for a range of consequences and also for users in wheelchairs

Fatigue

The system should:

41. Not force users to long and very vigorous exercises or activities

42. Support the person in dividing activities into “chunks”

43. Promote and allow pauses in activities, and be designed to encourage appropriate pausing

Games

The system should:

44. Be flexible when it comes to leveling, not force a gamer to begin from the first slate



References

Díaz-Bossini, J.-M., & Moreno, L. (2014). Accessibility to Mobile Interfaces for Older People. Procedia Computer Science, 27(Dsai 2013), 57–66. http://doi.org/10.1016/j.procs.2014.02.008

Funka Nu AB. (2012). Guidelines for the development of accessible mobile interfaces. Stockholm, Sweden. Retrieved from http://www.funka.com/contentassets/5f2704e1efa942a29f9bbb20facea4d1/guidelines_for_the_development_of_accessible_mobile_interfaces.pdf

ISO. (2010). 9241-210:2010 Ergonomics of human-system interaction -- Part 210: Human-centered design for interactive systems.

Magnusson, C., Rassmus-Gröhn, K., Rydeman, B., & Caltenco, H. (2018). Walk after stroke: initial development of a step counting game for stroke survivors. In MobileHCI ’18 Proceedings of the 20th International Conference on Human-Computer Interaction with Mobile Devices and Services Adjunct (p. 237). ACM. http://doi.org/10.1145/3236112.3236145

Magnusson, C., Waern, A., Rassmus-Gröhn, K., Bjernryd, Å., Bernhardsson, H., Jakobsson, A., … Hedvall, P.-O. (2011). Navigating the world and learning to like it - mobility training through a pervasive game. MobileHCI. Stockholm: ACM SIGCHI, SIGMOBILE.

Nielsen, J. (1993). Usability Engineering. Morgan Kaufmann.

Norman, D. A. (2002). The Design of Everyday Things. New York, NY, USA: Basic Books, Inc.

Schneiderman, B. (1992). Designing The User Interface (Vol. 2nd). Addison-Wesley.



Appendix A

Date post:	17-Jul-2020
Category:	Documents
Upload:	others
View:	0 times
Download:	0 times

Deliverable - STARR · This document can be used in several ways. The executive summary, and the...

Documents