Abstract
Purpose
Digital systems for independent aging, support and care are not being adopted as hoped. The purpose of this paper is to examine the results of three studies to derive key factors during the development and engineering process of care and support systems for older people that can impact acceptance and uptake to provide support to future projects.
Design/methodology/approach
The paper analyzed the results of three qualitative studies, including two detailed case studies and a further study with 35 participants, to derive key factors. Methods for deriving factors are based on thematic analysis to identify common factors across cases and participants.
Findings
The findings point to a broad set of interconnected factors that give developers of these types of systems specific recommendations. These highlight what makes these projects complex and identify implications for the development process. Furthermore, they show way the needed user-centered and iterative methods may be in conflict with funding processes.
Originality/value
While others have reported on single projects or looked at acceptance, these studies were the first to explore aspects of the development process that may contribute to the lack of success to date of these types of systems. The results here support more successful outcomes in the future, both by helping people involved in the development of these systems to avoid some of the issues others face and providing input to improve the performance of the engineering process.
Keywords
Citation
Hallewell Haslwanter, J.D., Fitzpatrick, G. and Miesenberger, K. (2018), "Key factors in the engineering process for systems for aging in place contributing to low usability and success", Journal of Enabling Technologies, Vol. 12 No. 4, pp. 186-196. https://doi.org/10.1108/JET-12-2017-0053
Publisher
:Emerald Publishing Limited
Copyright © 2018, Jean D. Hallewell Haslwanter, Geraldine Fitzpatrick and Klaus Miesenberger
License
Published by Emerald Publishing Limited. This article is published under the Creative Commons Attribution (CC BY 4.0) licence. Anyone may reproduce, distribute, translate and create derivative works of this article (for both commercial and non-commercial purposes), subject to full attribution to the original publication and authors. The full terms of this licence may be seen at http://creativecommons.org/licences/by/4.0/legalcode
Introduction: care and support systems for older people
Due to an aging society, many countries face new challenges. There are fewer young people to care for the growing number of older people, and also to finance the social system (European Commission, 2006). Care and support systems offer one possible solution by enabling people to remain in their own homes and receive needed care, also termed “aging in place.”
Turner and McGee-Lennon (2013) categorized systems that support aging in place as: systems to support well-being and health, telehealth, telecare and other systems. Systems to support well-being include smart-home systems that allow people to turn on the lights by pressing a button and robots to fetch things. Telehealth systems include systems to monitor blood pressure or blood sugar. Telecare systems use sensors to monitor the activities of people, e.g., to see if they have fallen or have not moved. In addition to the older people, these systems also involve people that respond to the alarms, e.g., carers. Finally, other systems include comprehensive systems combining these features and also other systems that support a more independent and self-determined life style. As such these systems may include assistive technologies (AT) and also have to interface with the existing AT.
Despite the potential and investment in their development, there are not many systems in the market. As an example, the ambient assisted living (AAL) program of the EU invested €600m in 130 projects from 2009 to 2013. The evaluation report concluded that systems were still restricted to “niche markets” and decided it was necessary to extend the program with a focus of getting systems to markets (Busquin et al., 2013). Furthermore, even when systems are made available, uptake has been slow (Sanders et al., 2012). Thus, it is worthwhile to gain understanding about what is contributing to this lack of success.
Due to the perceived importance and also the problems, researchers have investigated aspects relevant to the success of these systems. Some people have investigated the acceptance and adoption of these systems (Greenhalgh et al., 2013; Peek et al., 2014). Others have investigated their effectiveness (Cartwright et al., 2013). There have also been investigations into improving the design of the systems, e.g., by increasing reliability or privacy (Eichelberg et al., 2014). In addition, some people have also proposed techniques for successful collaboration with older people (Uzor et al., 2012). However, prior to our research, no one had studied what actually happens during the development of these systems. Studying the development processes for interactive systems has brought insight into ways of improving design processes more generally (e.g. Blomquist and Arvola, 2002). We suggest that this could be particularly useful in this domain since older people have diverse needs, something that poses challenges in the development (Gregor and Newell, 2001). Not only do they range from 60 to 120, they have a diverse range of abilities due to different life experiences and also diverse physical and cognitive limitations due to aging.
Taking a human–computer interaction (HCI) perspective, we studied what happens during the actual engineering and got input from people involved in development projects to better understand the factors that may affect the success. Whereas our earlier studies focused on identifying some issues, here the main factors were derived to guide teams developing these technologies. These include aspects of the engineering process that should be considered by teams that can lead to both low usability and impact success, and also factors, e.g., in the funding process, contributing to these. Not all of these factors are specific to the field, but their particular instance within the AAL is specific and they are still important to ensure future success.
Methodology
This paper used the results from three separate qualitative studies providing issues and recommendations to derive key factors to support developers of future projects. It is based on:
an ethnographic case study of a project during the development of a monitoring system (Hallewell Haslwanter and Fitzpatrick, 2013), called Case Study 1 in the following;
a retrospective analysis of a more comprehensive system known in advance to have not been entirely successful (Hallewell Haslwanter and Fitzpatrick, 2016), referred to as Case Study 2; and
a study consulting people with experience in these types of development projects that aimed to identify common issues and elicit recommendations (Hallewell Haslwanter and Fitzpatrick, 2017), called the third study.
The focus of this study was to step back and examine the results across these studies and develop a descriptive theory of key factors during the engineering process. For this, the method thematic analysis as described by Braun and Clarke (2013) was applied. First lists of the issues and recommendations from the previous studies were compiled to regain familiarity with the data. The categories identified by the third study served as initial codes. To make sense of the data and develop the initial themes, diagraming and memos were done. When reviewing and revising these themes, the initial data, including the audio recordings, artifacts and transcripts, were revisited as needed. The themes were then refined to a set of categories. Finally, the results were written.
We took an HCI perspective, studying how users were considered and the role of technology. Since the research investigated the development process, it also looked at the methods that were applied and on what basis decisions about functionality were made. This supported analyzing whether engineers and development projects use appropriate methods, and whether they have the tools and skills to address the requirements of this diverse target group in a domain that has strong links to AT and accessibility and to manage a user-centered development process for this diverse end user group. Since these were the first studies looking at the development process, they also remained open to further aspects. The studies used focused on companies, which aim to get products to market, and systems incorporating monitoring, which are important due to health conditions such a balance or heart problems, and provide peace of mind to both older people and informal carers (Turner and McGee-Lennon, 2013). The factors derived in this study reflect these choices.
Using results from this combination of studies supported the quality of the results. The case studies identified problems teams were not aware of and provided information to understand what happened, why and what the effects were; the third study supported including issues faced by multiple projects to give a more complete picture from a wider range of projects and people; all studies supported gathering recommendations from practitioners for the issues identified. Credibility and validity (Braun and Clarke, 2013) are supported by building on case studies based on a larger volume of data; the transferability of the results is supported by using the results of the third study with a broader set of participants. All factors were supported by more than one participant and/or study.
Summary of studies used
Before presenting the synthesized findings, we first highlight findings from the studies used. Full details of these studies, including both the research methodology and results, are available in the publications referenced above.
Case Study 1, News of Kin, was a small project done by a start-up developing a tablet-based monitoring system. This study based on observations, interviews and analyzing documents. In this project, the focus changed over time. Although the needs of the older people were considered in detail at the start, the focus shifted from the users to the sensors. In the end, no interface was developed for the older users, so they were reduced to signal generators. At the same time, the needs of the carers gained precedence, and functions, like a reminder to go to bed, wanted by carers but which would may not have been acceptable to older people were considered. In parallel, the focus got more technical, in part due to problems reliably recognizing when people needed assistance and issuing alarms. False positives were especially a problem, such as those caused by a broken muffler of a car that triggered a false alarm several nights in a row.
Case Study 2, Handy Helper, based on a larger project developing a system incorporating both services and monitoring features. This retrospective study based on analyzing documents and interviewing people involved. A series of tensions were identified through this project. These included difficulties in getting accurate input from users. Even though older people were consulted through a show home and four-month pilot, features such as a shopping service suggested by users were not used in practice, and the most popular feature, “calling the lift,” was one not suggested by older people. Due to financial difficulties, the target group was changed from private homes to care homes; even though the residents in the care home had just moved in, their needs changed in unexpected ways. The team also struggled to ensure simultaneously the reliability of the monitoring features, and the usability of the interactive services. In practice, reliability was given priority, but the older people were confronted with poor usability on a daily basis. Another tension was around the prerequisites of the funding, that on one hand provided valuable know-how through project partners, but at the same time increased the amount of communication needed, and required that additional services be added that increased the complexity of the system and impacted the usability.
The third study used interviews, workshops and an interactive poster to get input from 35 people from nine European countries. It confirmed and added to the findings from the case studies, resulting in 33 issues experienced by multiple teams that can impact success. The issues were categorized under: financing, users, project, product and marketing, with all groups identifying issues related to financing and users. Furthermore, participants in these studies rated issues and suggested recommendations for addressing some of the issues.
Relevant factors when developing
The analysis yielded six overarching themes or categories for the issues from these previous studies:
users: very diverse and changing;
product: complex technology involved;
marketing: many aspects need to be considered;
financing: grants add to the complexity; and
project: complex structures require good management.
The key factors and implications derived are described below structured by these themes. Although some of these are illustrated by an example from a single case study, all of these factors were encountered by more than one participant or project.
Users: very diverse and changing
The unqualified use of the word “users” should be avoided, as it can hide complexities that affect the design of the system (linked to the category product). The third study highlighted the diversity with regard to users and that many systems have different user groups beyond the older people. For monitoring systems, there are also those receiving the alarms, e.g., the carers, and there may also be emergency services that are contacted if a serious problem arises. Systems incorporating only services may also have multiple user groups, e.g., medical personnel to configure telehealth services or interpret the data. Furthermore, many systems have people responsible for installation, maintenance and/or updates.
The user groups need to be described in detail, as there is diversity in each of the user groups that may be relevant to the functionality and design of the system. The security features people valued most highly at the show home in Case Study 2 were not a reason to keep the system for care home residents. Also carers vary and may be informal carers (family and friends) or professional carers – in some cases both. With professional carers, there are also different care models: while some come by daily, others only come by when there are problems.
A diverse set of older people, in particular also those with disabilities with different accessibility needs and AT, should be considered and described, as developers are often younger and may stereotype older and disabled people, as happened in Case Study 1. For example, teams must consider people with different disabilities and those living alone, but also healthy older people living with a partner.
Document the reasons behind design decisions. This can help if the target or goal is changed, as in Case Study 2 when the focus was changed from people in private homes to those in assisted-living facilities. It can also help identify if the feature was derived from carers or older people. In practice, the needs of the carers can take over and lead to functions being added that older people do not want, or even ones they have objections to, e.g., a reminder to go to bed that was proposed in Case Study 1. Team members may also base functional decisions on their observations rather than user evaluations, as in Case Study 2. Moreover, technical aspects may also influence decisions, as in Case Study 1, when patterns chosen for detection by the sensors were based on what was easiest to recognize.
If projects are aimed at more than one country, there is additional variability that needs to be considered. Interviewees in the third study mentioned the languages spoken, amount of IT usage common among older people and also factors as mundane as the height of people – the latter can be important for fall detection systems. If telehealth functions are included, the regulations of each country may also need to be considered. If these too diverse, it was recommended limiting these features to a single country.
Older people should be included starting early in the project, as all studies showed that development teams do not always understand the real needs. Asking people in a show home, as in Case Study 2, is not ideal as it may encourage them to come up with a long wish list of functions. Moreover, the people visiting the show home may not be representative, as they are mobile and may have more experience with technology than their peers. If it is difficult to find people to include throughout the development, using detailed descriptions of people may be helpful as these can be returned to later in the process to help “reintroduce” the different user groups, especially the older people. This is important as emergent technical problems may take focus away from users and their needs, as happened in Case Study 1.
Working iteratively and allowing older people to give feedback on early versions can help in detecting problems early. Interviewees in the third study reported technical prototypes were in practice often difficult for older people to understand. Instead, they recommended employing use cases or storyboards to explain complex systems and privacy aspects.
Long-term tests are valuable for getting realistic feedback. Still they have their limits in predicting usage, as older people experience physiological changes which affect their needs. At the end of the four-month pilot of Case Study 2, people still wanted features like the shopping service to be available for the future, even though they had not used them during the pilot.
Product: complex technology involved
The project goals and functionality should not be set before a user analysis has been done. Participants in the third study reported that in many projects the functionality was determined by the goals of funding programs, research topics and “tech push.” This is complicated by the fact that with funding the contents must be set before the project has started, in which case knowledge gained in previous projects must be used.
Accessibility is an important consideration in these systems. Standard system engineering today starts from a standard (human) interface, which does not yet take ATs and accessibility requirements (e.g. ISO/IEC 40500:2012 (W3C) information technology – W3C Web Content Accessibility Guidelines 2.0) into account. As ageing is very much related to disabilities, standard interfaces are often not perceivable (vision and hearing), operable (motor skills) or understandable (cognition) and the design is not responsive to ATs needed by a growing number of users. Due to degenerative processes, the functions needed and AT used by existing users can change. This makes the functionalities of systems even more needed but many systems are not able to respond to changing requirements with respect to accessibility and AT integration. Skills of development teams going beyond the standard are not always taken on board, such as competences in user involvement in the engineering process with this diverse and changing set of users. Although guidelines, methods, tools and techniques for accessibility and AT for design and engineering exist, this body of knowledge is not yet a part of mainstream education and skills sets, as demonstrated by all studies. Therefore, particular care has to be taken to include experts from these domains and/or train team members so they are able to include these aspects in the engineering process and adapt project planning accordingly.
The expression “system” should also be used with care, due to the wide variety. In Case Study 1, consultants repeatedly mentioned aspects related to the analysis of past behavior, though the project was based on fixed time schedules, which complicated communication. Some systems include only monitoring, while others include various interactive services, e.g. telehealth or communication. Even with monitoring systems, there are different types of sensors, e.g. wireless, integrated through a tablet or installed in the home, and also different ways of recognizing activities.
Reliability needs to be tested, particularly for systems related to security, as it is difficult to achieve in practice. In Case Study 1, there were problems both generating alarms when there was a problem, and not generating alarms, when people were actually okay. Participants indicated reliability can be hard to prove. In practice, it can also be affected by things as simple as people unplugging the system or forgetting to charge the device. Some projects also experience difficulties with infrastructure – even in newly built assisted-living facilities, as happened in Case Study 2. If there are multiple configurations, all should be tested, for example if services can be added or removed. With systems based on tablet technology, this may also involve testing with tablets integrating different sensors, as was done in Case Study 1.
It is also important to design for maintenance, as it was found in Case Study 2. In practice, special functions and a centralized architecture may be necessary to support reliability long term, e.g., to allow people to be “checked out” remotely in case they forget to do so before they go on vacation, to check why a false alarm was generated, or to distribute bug fixes easily.
Participants of the third study recommended having an open system that allows components to be added or changed can support success, e.g., in case a component does not work as expected, is delayed or is no longer available.
Usability and appearance need to be considered in the design – and checked with users early on. In Case Study 2, even small design aspects, e.g., an LED, raised concerns about privacy. The appearance can even lead to people removing the system altogether – in a project from the third study a user did so because she disliked the black cables. Poorly designed configuration interfaces can reduce the reliability, as people enter incorrect or simplified parameters or rely on others who do not know their patterns in detail, as it was demonstrated in Case Study 1. Since developers put a focus on reliability, as in Case Study 2, participants suggested including a designer for the interactive components.
Participants stressed the importance of keeping it simple and reducing the functionality to a minimum, also to support usability. People may be confronted with these systems every day, as in Case Study 2, making it important. This is challenging, since there are different user groups (older people vs carers) and also individual differences within each user group. Some participants even suggested developing just small add-ons to existing products, such as robotic vacuums, rather than building dedicated systems with lots of features.
Even if privacy is considered, it needs to be explained, particularly with monitoring systems. Older people may have more concerns about privacy, also because many do not understand what the technology can do – in Case Study 2, some people thought someone could see them undress even though no cameras were included and wanted the system removed for this reason. People in the third study said mechanisms used to ensure privacy are hard to explain to people with less technical experience and suggested storyboards may also be useful for this purpose. And when people with disabilities are involved, appropriate methods need to be employed to attain a minimum level of informed consent.
Marketing: many aspects to be considered
Participants in the third study said that getting to market should be considered from the start. Like Case Study 2, if systems do not succeed in the market, it is immaterial if they fit the needs and work technically. Participants said getting information about competitors is essential when developing a new product but said this information is currently hard to obtain. This market differs from many others in that those who benefit do not pay, those who pay do not select, procure and order, and those who order are not those who will use it. Thus, an in-depth analysis is needed early on to understand the incentives, including viewpoints of users, insurance companies, funding agencies, end user organizations, informal and formal carers, and service and support professionals.
Consider a wide variety of factors in calculating what can be charged. In the country where Case Study 2 took place, the purchase of these systems was not subsidized. However, carers provide an alternative to technology and were subsidized. Participants of the third study indicated that the situation is exacerbated by the fact that currently there is a lack of evidence about what works and pays off to help convince customers. It is also relevant to consider who saves, whether it is the older people and their families who save on a care facility or the carer organizations that save by having to make fewer visits, and market the system accordingly. In countries with nationalized health care, participants reported people may not be willing to make concessions to save the state money.
The pricing structure should reflect the fact that older people are aware that they are likely to experience changes in the future. Large upfront costs may discourage investment – in Case Study 2, people were unsure how long the systems would suffice. On the other hand, large monthly fees can be daunting, since life expectancy is high.
The development costs should not be underestimated when the initial business plans are made. In practice, for some projects in the third study, a prototype was far from a working system, e.g., with regard to reliability. It can also take a long time to identify the right functions. And with assisted-living facilities, it can be a long time from when a project is first discussed to when it is actually installed and paid for, as in Case Study 2, by which time the hardware initially planned is no longer available.
The support costs also need to be considered, as these can be high, as shown in Case Study 2. Problems with infrastructure can add to costs and be difficult to fix, also because it can be hard to find competent partners to do repairs locally. The third study found that older people need a lot of support when a system is first installed, and carers and family members do not always provide assistance with this. Training becomes even more challenging if older people have cognitive deficits or less experience with technology.
Financing: grants add to the complexity
Many projects developing these technologies depend on grants from funding programs. At the same time, the framing of these grants can limit success as is described with the following factors. Unfortunately participants felt that the issues related to financing were out of the control of development teams, e.g., the ability to change the requirements mentioned previously.
The number of partners should be considered carefully. As found in Case Study 2, adding partners increases the complexity, as there are more groups of people who need to discuss and coordinate, which is especially challenging if partners are not in the same location. It also means know-how is split over multiple organizations. There may also be differences between partners that can make projects complicated, e.g., how much lead time there is for ordering hardware and the flexibility to change things during a project. In practice, this can lead to tension in the team, or even to one partner effectively being excluded from a project.
Participants suggested that regular meetings could support success when multiple partners are included. In Case Study 2, important details about user needs that were collected by one partner did not reach those designing the systems.
Ideally partners should be chosen for expertise and provide something that is not available within the company - but some just want to push their own systems. Academic partners can provide valuable know-how, as in Case Study 2. In practice, partners are often chosen primarily to fulfill the requirements of funding programs, e.g., to include certain countries or domains.
Companies should be aware that grants are unlikely to fund the entire development. Due to the fixed grant deadlines and unanticipated delays during development, the time to test may in practice be longer than the duration of the project, something identified as a factor in both case studies and the third study. However, it can be sufficient to get a good proof of concept.
Care is needed with regard to the innovation required by many funding programs. Using technology unfamiliar to the team or technologies that are not yet established increases risk. Even just adding features can make the system more expensive to develop and more complex to use, as in Case Study 2.
Project: complex structures require good management
Good project management is key and within control of teams. This was mentioned by participants in all studies. This is particularly important with these types of systems as both the technologies (as described with the category product) and project structures with multiple partners add to the complexity of the development.
If academic partners are included, the results may need to be checked before deployment. For example, they may not consider long-term maintenance, as happened in Case Study 2.
Discuss things explicitly that do not seem to be clear to all team members. Including diverse partners, as required by funding, can complicate communication between team members, as in Case Study 2. For example, the terminology used depends on the domain in which people work. In addition, people from different domains may have different methods or ways of working. There is also the question of what people take for granted, e.g., interviewees reported developers did not grasp aspects about older people that were self-explanatory to carers.
Although presented in categories and as individual factors, as described in some places above, there are many links between the categories. As an example financing programs usually set deadlines for completion. At the same time, they may have requirements to add innovative technology or features to the product, something that can lead to delays in the project. In practice, there is then insufficient time for tests with users to gather the needed information, which in turn causes problems when marketing the resulting systems.
Discussion
In the following, we show some links between categories and also to the literature. Moreover, the limitations of the research are described.
As indicated by the factors above, despite applying user-centered methods, all studies found that development teams do not always understand the real needs. This is partly due to the fact that the older people have a great diversity, also with respect to knowledge, as noted by Gregor and Newell (2001). This is complicated by the fact that needs change over time with older users, due to both physiological changes and the fact that people gain confidence with the technology (Spellerberg and Schelisch, 2009).
At the same time, the development of these systems is particularly challenging. New technologies are often incorporated, something that increases risk in software projects (Tiwana and Keil, 2004) and can also impact existing accessibility and AT solutions. Moreover, different types of know-how are needed, but developers and health care professionals have different ways of working (Pagliari, 2017). Much more adaptation of the engineering process is needed, in particular with respect to skills and know-how about AT and accessibility, and using adapted methods and tools for user-centered design and development. Most fundamentally, many of the factors identified point to the importance of small iterations and getting feedback from users before continuing, i.e., an agile way of working rather than more traditional methods.
Some individual aspects have been mentioned by others, e.g., appearance (Dahl et al., 2016), privacy (Blythe et al., 2005) or usability problems (Peek et al., 2014), which can contribute to the lack of acceptance. Their importance was confirmed by these results. Here, recommendations to address these are also provided.
Even though there are potential benefits of these products, a compelling argument is still needed to help diffuse the technology. Products in this domain are not complete solutions but just one part of innovative services contributing to independent living, support and care. The whole situation must be considered. This may not only require different development processes but also a redesign of workflows from planning, selecting, financing, installing, training end users and carers, using and maintaining. Since older people also consider non-technological alternatives for support (Peek et al., 2014), it is crucial to clarify the benefits. Although reliability is important for the majority of customers (Moore, 2006), participants felt that there is a lack of evidence of the benefits and that these are difficult to prove. Furthermore, reliance on intermediaries may result in the wrong features and design (Dahl et al., 2016; Mort et al., 2012). To be successful, users are key, as systems need to be accepted by older people, and be both useful and usable for them. Aspects such as training and support should not be neglected, as the initial phase is critical (Sallinen et al., 2015).
However, the more fundamental problem may be that marketing often aims to reach all older people. By aiming to cover all needs, in practice systems may not really be optimal for anyone, e.g., incorporating so many functions the systems are difficult to use. Thus, although “older people” are a group of potential customers, some important criteria of a market (Moore, 2006, p. 28) are actually missing:
due to the diversity discussed earlier, there is not a common set of needs; and
since needs change as people age, often quite unpredictably, there is not really a given set of products or services.
This is complicated by the fact that projects often rely on grants for financing. If the goals are taken from funding programs aimed at keeping people in their own homes longer to save costs (European Commission, 2006), developers are less likely to consider features like “calling the lift” that are in practice popular.
But many factors related to users are within control of developers through the methods applied. Using narratives from real people can help increase empathy (Grünloh et al., 2015), and also reduce the amount of access to users required. Furthermore, using sketches to convey the design not only gets feedback earlier, it saves older people the effort of having to learn to use an interface that is likely to be changed anyway (Thimbleby, 2008). Rather than always working with each group separately and prioritizing the needs, co-discovery may support finding solutions acceptable to all stakeholders (Dahl et al., 2016). Greenhalgh et al. (2012, p. 1) also supported this for the subdomain of telehealth and telecare and it could be anticipated that this may also apply to AAL: “If investments in these technologies are to bear fruit, more effective inter-stakeholder dialogue must occur to establish an organizing vision that better accommodates competing discourses.”
Limitations
The primary limitations relate to the exploratory nature of the research: the results provide a first basis and are not complete. An attempt was made to reduce the limitations by having two diverse case studies and the third study. Also, some factors were derived from less detailed interaction. We compensated for this by ensuring that each factor was supported by more than one study or participant. Furthermore, the suggested recommendations need to be validated via further research.
Conclusions
This research complements previous research on adoption by investigating aspects related to the development of AAL systems. The results describe key factors developers face that may impact the success of projects developing technologies to support aging in place. While some of the individual factors have been reported in single projects and other domains, their relevance to aging in place was confirmed by this study. The results also include ways in which teams can address some of these factors in the AAL domain, as suggested by participants in the studies used.
Due to the diverse needs of the users, in these projects it is more essential that development teams work in highly iterative way and have substantial know-how in accessibility, ATs and user-centered design. Care should be taken when selecting and applying methods. Project management is key due to the complexity of the domain, and can help ensure that older users are involved early and not forgotten when technical problems arise. To better reach the market, companies may want to consider developing smaller components to better adjust to the diverse and changing needs of older people.
Research funding programs provide additional requirements that impact success in many ways. Funding agencies may want to consider allowing more flexibility, e.g., so that the goals and functionality of systems can be adapted after the needs analysis, and also that results can be delivered later without additional funding in order to allow sufficient time to check that the solution matches the needs in realistic conditions. Allowing more flexibility in the choice of partners could help ensure partners are chosen for their capabilities and compatibility, and thus help reduce some current problems and the delays that ensue.
Researchers could support teams by investigating the type of methodological support that it is needed for developing these types of systems.
Furthermore, new models may be needed for marketing these systems. Case management shows promise (Katzmaier, 2016): first assisting people choosing appropriate functions, and then verifying the choice after a period of use. These same advisers could also support people later when their needs change.
Finally, educators can help better prepare developers of the future. There is a great deal of information about older people available, but developers do not seem to be sufficiently aware of the importance of gathering information about older people and their needs. Furthermore, students need to be prepared to work in the multi-disciplinary teams that are required for these types of systems.
Thus, although there are many factors that can impact success, many of these can be addressed to support more success of these valuable systems in the future.
References
Blomquist, A. and Arvola, M. (2002), “Personas in action: ethnography in an interaction design team”, NordiCHI 2002, ACM, pp. 197-200.
Blythe, M.A., Monk, A.F. and Doughty, K. (2005), “Socially dependable design: the challenge of ageing populations for HCI”, Interacting Computer, Vol. 17 No. 6, pp. 672-89.
Braun, V. and Clarke, V. (2013), Successful Qualitative Research, Sage, London.
Busquin, P., Aarts, E., Dózsa, C., Mollenkopf, H., Uusikylä, P. and Sharpe, M. (2013), Final Evaluation of the AAL-JP, European Commission, available at: www.aal-europe.eu/wp-content/uploads/2015/05/Final-report-of-the-AAL-Busquin-2013.pdf
Cartwright, M., Hirani, S.P., Rixon, L., Beynon, M., Doll, H., Bower, P., Bardsley, M., Steventon, A., Knapp, M., Henderson, C., Rogers, A., Sanders, C., Fitzpatrick, R., Barlow, J. and Newman, S.P. (2013), “Effect of telehealth on quality of life and psychological outcomes over 12 months”, BMJ, Vol. 346, March, p. f653.
Dahl, Y., Farshchian, B., Vilarinho, T., Helbostad, J.L., Nawaz, A., Nygård, A.J. and Wik, P.B. (2016), “Stakeholder attitudes toward and values embedded in a sensor-enhanced personal emergency response system”, Interacting with Computers, Vol. 28 No. 5, pp. 598-611.
Eichelberg, M., Busching, F., Steen, E.-E., Helmer, A., Thiel, A., Hein, A. and Wolf, L. (2014), “A technical platform for environments for ageing – lessons learned from three field studies”, Informatics for Health Social Care, Vol. 39 Nos 3-4, pp. 272-93.
European Commission (2006), The Demographic Future of Europe – From Challenge to Opportunity, European Communities, Luxembourg, available at: www.cedefop.europa.eu/en/news-and-press/news/demographic-future-europe-challenge-opportunity-dg-employment-social-affairs-and
Greenhalgh, T., Procter, R., Wherton, J., Sugarhood, P. and Shaw, S. (2012), “The organising vision for telehealth and telecare: discourse analysis”, BMJ Open, Vol. 2 No. 4, doi: 10.1136/bmjopen-2012-001574.
Greenhalgh, T., Wherton, J., Sugarhood, P. et al. (2013), “What matters to older people with assisted living needs?”, Social Science & Medicine, Vol. 93, pp. 86-94.
Gregor, P. and Newell, A.F. (2001), “Designing for dynamic diversity: making accessible interfaces for older people”, Proceedings of WUAUC'01, ACM, pp. 90-2.
Grünloh, C., Walldius, Å., Hartmann, G. and Gulliksen, J. (2015), “Using online reviews as narratives to Evoke designer’s empathy”, in Abascal, J. et al. (Eds), INTERACT, Springer, Switzerland, pp. 298-315.
Hallewell Haslwanter, J.D. and Fitzpatrick, G. (2013), “The Development of a sensor-based System for older People: A Case Study”, in Hone, K. et al. (Eds), HCI 2013 - The Internet of Things, British Computer Society, pp. 1-10.
Hallewell Haslwanter, J.D. and Fitzpatrick, G. (2016), “Why do few assistive technology systems make it to market? The case of the HandyHelper project”, Universal Access in the Information Society, Vol. 16 No. 3, pp. 755-73, doi: 10.1007/s10209-016-0499-3.
Hallewell Haslwanter, J.D. and Fitzpatrick, G. (2017), “The development of assistive systems for older people: issues that affect success in practice”, Technologies 2018, Vol. 6 No. 1, pp 1-21, doi: 10.3390/technologies6010002.
Katzmaier, S. (2016), “AAL-Case management”, in Miesenberger, K. et al. (Eds), ICCHP 16, Part I, Springer, Linz, p. 317.
Moore, G.A. (2006), Crossing the Chasm: Marketing and Selling Disruptive Products to Mainstream Customers, revised ed., Collins, New York, NY.
Mort, M., Roberts, C. and Callen, B. (2012), “Ageing with telecare: care or coercion in austerity?”, Sociology of Health and Illness, Vol. 35 No. 6, pp. 799-812.
Pagliari, C. (2017), “Design and evaluation in eHealth”, Journal of Medical Internet Research, Vol. 9 No. 2, pp. 1-14.
Peek, S.T.M., Wouters, E.J.M., van Hoof, J., Luijkx, K.G., Boeije, H.R. and Vrijhoef, H.J M. (2014), “Factors influencing acceptance of technology for aging in place: a systematic review”, International Journal of Medical Informatics, Vol. 83 No. 4, pp. 235-48.
Sallinen, M., Hentonen, O. and Karki, A. (2015), “Technology and active agency of older adults living in service house environment”, Disability and Rehabilitation: Assistive Technology, Vol. 10 No. 1, pp. 27-31.
Sanders, C., Rogers, A., Bowen, R., Bower, P., Hirani, S., Cartwright, M., Fitzpatrick, R., Knapp, M., Barlow, J., Hendy, J., Chrysanthaki, T., Bardsley, M. and Newman, S.P. (2012), “Exploring barriers to participation and adoption of telehealth and telecare within the whole system demonstrator trial”, BMC Health Services Research, Vol. 12 No. 220, pp. 1-12.
Spellerberg, A. and Schelisch, L. (2009), “Ein dreiviertel Jahr mit PAUL: assisted living in Kaiserslautern”, AAL 2009, VDE, Berlin, pp. 393-7.
Thimbleby, H. (2008), “Understanding UCD for people with special needs”, ICCHP, Springer, pp. 1-17.
Tiwana, A. and Keil, M. (2004), “The one-minute risk assessment tool”, Communications of the ACM, Vol. 47 No. 11, pp. 73-7.
Turner, K.J. and McGee-Lennon, M.R. (2013), “Advances in telecare over the past 10 years”, Smart Homecare Technology and TeleHealth, Vol. 1, pp. 21-34.
Uzor, S., Baillie, L. and Skelton, D. (2012), “Senior designers: empowering seniors to design enjoyable falls rehabilitation tools”, CHI 2012, ACM, pp. 1179-88.
Acknowledgements
The authors thank Özge Subasi for her valuable comments.
Corresponding author
About the authors
Jean D. Hallewell Haslwanter is Professor of Informatics specialized in Human–Computer Interaction and software development.
Geraldine Fitzpatrick is Full Professor at TU Wien, Head of the Human Computer Interaction Group, and ACM Distinguished Scientist and ACM Distinguished Speaker.
Klaus Miesenberger is Associate Professor at the Institute for Integrated Study, Johannes Kepler University (JKU) Linz. He does research in Assistive Technologies, Accessibility and inclusion of people with disabilities and the aging population.