Post on 17-Jul-2020
transcript
| 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
| P a g e | 58 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
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
| P a g e | 3 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
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
3.2 New or strengthened requirements / recommendations for design .................................. 16
4 Chat bot mock-up tests –HOP and CEA ............................................................................. 18
4.1 Results ............................................................................................................................ 18
4.2 New or strengthened requirements / recommendations for design .................................. 18
5 Home based training application usability test – ULUX, CEA & HOP .................................. 20
5.1 Results ............................................................................................................................ 20
5.2 New or strengthened requirements / recommendations for design .................................. 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
6.5 New or strengthened requirements / recommendations for design .................................. 26
7 Serious games testing – HOP ............................................................................................. 28
7.1 Participants ..................................................................................................................... 29
7.2 Major results .................................................................................................................... 29
7.3 New or strengthened requirements / recommendations for design .................................. 31
8 Analysis of clinical tests and questionnaires – HOP & CEA ................................................ 32
| P a g e | 4 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
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
| P a g e | 5 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
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
| P a g e | 6 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
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
| P a g e | 7 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
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.
| P a g e | 8 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
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.
| P a g e | 9 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
| P a g e | 10 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
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
| P a g e | 11 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
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
| P a g e | 12 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
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
| P a g e | 13 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
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)
| P a g e | 14 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
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)
| P a g e | 15 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
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.
| P a g e | 16 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
3.2 New or strengthened requirements / recommendations for design
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)
| P a g e | 17 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
| P a g e | 18 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
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.
4.2 New or strengthened requirements / recommendations for design
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).
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)
| P a g e | 19 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
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)
| P a g e | 20 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
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).
5.2 New or strengthened requirements / recommendations for design
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).
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)
| P a g e | 21 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
| P a g e | 22 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
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.
| P a g e | 23 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
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.
| P a g e | 24 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
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).
| P a g e | 25 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
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.
| P a g e | 26 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
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).
6.6 New or strengthened requirements / recommendations for design
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)
| P a g e | 27 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
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)
| P a g e | 28 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
| P a g e | 29 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
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.
| P a g e | 30 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
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
| P a g e | 31 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
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
| P a g e | 32 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
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.
7.3 New or strengthened requirements / recommendations for design
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)
| P a g e | 33 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
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
| P a g e | 34 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
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
First session 0 0 1 2
Last session 0 0 3 0
FUP2*
First session 1 1 1 0
Last session 2 1 0 0
FUP4
First session 0 1 2 0
Last session 0 0 2 1
IM1
First session 0 1 0 2
Last session 0 0 1 2
QS
First session 0 1 0 2
Last session 0 0 2 1
RD2
First session 0 0 1 2
Last session 0 0 3 0
PP1
First session 0 0 0 3
Last session 0 0 1 2
QL3
First session 1 0 0 2
Last session 0 0 0 3
AEI1
First session 0 0 1 2
Last session 0 0 0 3
| P a g e | 35 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
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
| P a g e | 36 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
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).
| P a g e | 37 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
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
| P a g e | 38 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
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
| P a g e | 39 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
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
| P a g e | 40 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
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.
| P a g e | 41 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
Appendix A