User-centered design in AAL

This paper presents the results of an online survey conducted in Austria that aimed at investigating the application of user-centered design (UCD) methods in projects developing technologies that support older adults in their everyday lives. We explored which methods are known to teams, which methods have been applied in projects developing active and assisted living (AAL) technologies and the perceived suitability of these methods. The questionnaire considered methods for three different phases within the development process: gathering information about needs, communicating these needs to the developers and evaluating systems. Furthermore, we explored which stakeholders are included in gathering information about needs and in evaluating systems. The results show that more general methods that are not specific to UCD, such as interviews and questionnaires, are widely used. Older users were included in most projects, particularly for the evaluation. There was, however, an indication that the information about the needs collected may not be successfully communicated to the developers. Overall, the results support the need to spread information about the breadth of methods available and their suitability to people involved in developing these types of technologies.


Introduction
The age pyramid is shifting in many European countries as a result of a decreased birthrate and higher life expectancy. While there is concern about how to finance care for the growing number of older people, as a smaller proportion of the population will be working [10], this can also be viewed as an economic opportunity: "creating new markets for goods and services which respond to the needs of an older clientele" [10, p. 10], sometimes also termed the silver economy. During the past few years, the development of products and services for an ageing society has gained substantial attention and has also been promoted via various national and European funding programmes. As an example, the European Union (EU) co-financed the development of information and communication technologies (ICTs) within the Active and Assisted Living Programme with a total budget of around 600 million Euros between 2008 and 2013 [7].
These types of technologies also support human needs, as they may allow older people to stay in their own homes, something many express a desire to do [27]. There is a variety of possibilities [see [32]]: safety systems, e.g., to check if someone fell; security systems to support peace of mind, e.g., checking whether windows were closed; behavior monitoring systems, like those that detect changes in sleep patterns, something associated with the onset of dementia; systems to facilitate communication, e.g., video 1 3 conferences with family members; entertainment systems, e.g., to remind people their favorite show is about to start; and home automation systems, e.g., to facilitate opening windows or shades.
Despite the investments, wide market penetration of active and assisted living (AAL) solutions has not been achieved yet. According to Peek et al. [27] there are a number of barriers to adoption, e.g., concerns about costs, privacy, usefulness and ease of use. The ease of use can effect both the effort required to learn the system, but also the effectiveness in case of emergency. It is also a primary factor in acceptance by older people [8]. Moreover, there is consensus that user involvement and the integration of various stakeholders during the design and development process is important to success. However, an evaluation of the AAL Programme of the EU concluded that although end users are included in many projects, users are not integrated sufficiently and projects are not fully user-centered [7, p. 10]. Thus, the roots of the problem may lie in the development, as the needs may not be fully understood, or because these barriers may not be considered sufficiently.
In order to gather information about the use of user-centered methods in projects developing AAL technology, we conducted an online survey in Austria. The results show that there is a need to spread knowledge about the different methodological approaches that are available, which in turn could support the development of future AAL products and services.
This paper is structured as follows: In the next section, we describe the theoretical background, providing information about challenges when working with older adults and the importance of participatory and user-centered design approaches. Afterwards, we describe our methodological approach in section three, and present the results in section four. The paper finishes with a discussion (Sect. 5), as well as conclusions and suggestions for future work, which are presented in section six.

Background
User-centered design (UCD) and participatory design (PD) are generally thought to support success of projects developing software systems [2]. There are many methods to choose from, the best choice depending on various factors [5]. Thus, the choice of methods may depend also on the user group.

Differences when working with older users
Older users are a very diverse group, which can make it challenging to design systems that are usable for them [16]. Older people include a wide age range from 60 to 120 and have gained different experience during their lives. Hence, when developing systems for this particular user group the challenge is to adequately address the breadth of needs that exist. Many older people have physiological limitations. Some of these limitations differ from those experienced by younger populations. For example, there are age-specific vision problems, e.g., age-related farsightedness (presbyopia), cataracts and age-related macular degeneration (AMD). There is also an age-related form of hearing loss (presbycusis) that effects higher tones in particular. Older people are more likely to have arthritis, making it difficult or even painful to grasp things such as pens, knobs and buttons, and thus also potentially make it more difficult to operate technical devices. Statistics show that older people are more likely to have multiple disabilities [22]. Thus, although older people are not characterized primarily by their limitations, these need to be considered if systems are to be usable for the broader user group. Another difference with older people is that some have little experience with ICTs. At the same time, older people do not want to use technology specific to older adults that may brand them as frail [27].
Moreover, in telehealth, there are often many different stakeholders involved, each with different goals [28]. For example, there may be informal carers (e.g., family members) and professional carers who receive notifications or alarms. There may also be medical professionals that interpret the data. Furthermore, managers of care organizations and policy makers may also be involved. It can be challenging to satisfy the different needs of these groups, as care givers and older people often have different priorities, for example, carers putting a higher priority on security, whereas older people also consider other aspects, such as the aesthetics [9].

Importance of methods
In projects developing AAL technologies, the choice of methods applied may need to be adapted based on the aspects described above. To this end, after the aforementioned evaluation report, the EU-funded AAL Programme provided a toolbox of methods for this domain [36].
There may be special considerations when older users are involved. The UCD paradigm does not really account for the fact that the needs of user groups may change over time, for example, due to ageing [16]. Some projects have also found that even small aspects about the environment that at first do not seem to be relevant can be important when designing for older people [35]. Perhaps due to this, special methods have been developed for co-designing with older users (e.g., [30]). Furthermore, researchers have reported on different ways to work successfully with older users [24,33,34].
Many projects developing AAL technologies include users, as indicated by the evaluation of projects funded by the the AAL Programme of the EU [7]. However, a closer analysis indicates that, at least in funded projects, users and stakeholders are still not involved sufficiently, especially in the early phases [14].
In other areas, researchers have carried out studies to gain understanding of the UCD methods applied by practitioners. This has been done both through surveys [25] and interviews [15,23]. There have also been investigations about specific contexts [3,21]. In the area of AAL, previous research has studied the application of UCD in specific projects developing AAL technologies [12,17]. However, the choice of methods may be based on attributes specific to projects, such as how restricted the budget is, access to users, how complex the task is, or how customizable the product is [4,5]. Thus, it is of interest to investigate the application of methods more generally and also their suitability from the perspective of the people working in this area. Furthermore, decisions made early in the development process [11] can be hard to change later, so the point at which information is gained from stakeholders is also relevant.
Based on this, we set out to look at what methods are being used in projects developing AAL technology, which of these are thought to be useful, in which phases users are involved and which user groups are included. Since projects may split the development between different teams, we also looked at the communication in projects, e.g., between the people who research user needs and those who design and develop the systems.

Research methods applied
In order to investigate the usage and suitability of methods in the AAL context we carried out an online questionnaire. Rather than looking at a single project, in this paper, we focus on the methods applied and their perceived suitability in projects developing AAL technologies.
The questions about methods based on the phases of UCD of ISO 9421-210 [1], i.e. understanding the context of use, specifying the requirements, design and evaluation. Since we were focusing on the involvement of users, the phases specifying the requirements and the design were not considered. However, many decisions are made during the design and development. Furthermore, the development itself may be done by a different team or partner. Thus, we also asked about methods used to communicate the requirements, e.g., between those who investigate user needs and those who design and develop the solutions.
The choice of methods in the questionnaire included wellknown methods. In an effort to determine whether people were applying the chosen methods because they did not know other methods, we also asked about their familiarity with these methods. The methods were not defined explicitly to the participants and so based on each participant's interpretation of the named method. An effort was made to select specific methods in order to allow less room for interpretation. An overview on the methods that were included in the questionnaire is provided in Sect. 3.1.
Finally, we asked about the user inclusion. So that people did not just list all stakeholders, for this question we asked respondents to consider one specific project.
The analysis evaluated each question and calculated the percentage of people with each answer. For the questions relating to knowledge of the methods, usage of them and stakeholder inclusion, the absolute counts were used, so that the total number, or n, is constant. Thus, the percentages shown in the figures can be compared. The results were then evaluated to determine which methods were the most and the least known. To simplify comparisons for the readers, the methods are presented in the same order in every figure and table.
For the perceived suitability of the methods, only those who know the method can judge its suitability. Thus, the percentages presented are based only on those participants who knew each method. In order to be able to compare the results despite the different number of people who know each method, it is necessary to consider the standard error of the sample compared to the whole group. The standard error can be calculated as follows [18, p. 160 where n is the total number and p is the proportion of the people who know the method. The proportion can be calculated using p = n1 / n, where n1 is the value shown (i.e., those who know the method) and n is the total number of participants (i.e., 28). If the intervals defined by the result plus/minus the standard error overlap, the methods can be considered to be equally suitable (although, the inverse is not necessarily the case) [18, p. 64]. The 'best' methods are shown in bold in the tables, i.e., those for which the intervals overlap with the method rated by participants to be most suitable. Those described in the text as 'least' suited are those where the interval overlaps with the method rated least suitable.
With regard to the suitability, suitability for functionality and interaction aspects were considered separately. According to the definition of usability from ISO 9241 both the effectiveness and efficiency of the system are a factor. These are impacted by both functionality or requirements, i.e., if the system does what the users need, and interaction or design, i.e., how they do it. It was expected that some methods, both for the gathering needs and evaluation phases, would be more suited to one of these. Thus, we asked for which of these, or both, each of the methods was suited.
To gain access to a wide group of participants, the questionnaire was advertised through AAL Austria, which has approximately 60 members from Austria, including companies, care organizations, universities and research organizations. The questionnaire was available for two months.
In all, 47 participants took part in the survey. Of these, 28 questionnaires were complete enough that they could be considered in the analysis. Since the questions build on previous questions, for a questionnaire to be considered it was necessary that people answer all questions, i.e., if they knew the method, if they had used it and if they thought it was suitable, because if the final question was not answered, it would be unclear if the method was not used due to lack of knowledge about the method or due to the perceived suitability.
Including only one country, ensured a more comparable set of results, since in the wider European context, other things might effect the methods chosen, e.g., cultural aspects, social norms or educational system. It is important to stress that although small, Austria is one of the countries with the greatest involvement in those projects funded by the AAL Programme [14].

Items included in the questionnaire
In the following, the methods included in the questionnaire are listed and briefly characterized. The phases considered included gathering information about the needs, communicating the needs to developers and evaluation. Whereas gathering information about the needs relates to the first phases of UCD, i.e., understanding and specifying the context of use and specifying the user requirements, the methods for communicating the needs to developers serve to transmit this information to those who do the actual design and development. Methods specifically for design were not included, as these do not have a direct link to the users.
Observation can provide valuable insights [29]. Shadowing also involves observations, but also allows for questions to help understand behavior. The cultural probes [13] and mock-ups methods allow feedback based on artifacts. Contextual inquiry is a more extensive UCD method, including observations and discussions in the normal context. Focus groups, questionnaires, workshops and interviews can be used in a user-centered approach [29], though are more general methods that are not specific to UCD. Both focus groups and workshops involve multiple people at the same time.
The use case method is used to describe the interaction with the system to achieve a goal, and may be limited to the interaction with users, or may also consider other actors, such as external systems. The other methods are specifically from the user-centered tradition: personas describe fictitious users, scenarios describe some situations in which the system may be used and storyboards show the interaction including the system graphically.
Heuristic evaluation is based on expert input and does not involve users, while co-discovery always includes users and cognitive walkthrough can be done with or without users. The diaries and experience sampling methods allow users to record their usage and impressions over a longer time. The Wizard of Oz and paper prototyping methods allow for earlier feedback using prototypes, before a system version is working. Non-verbal feedback, physiological measurements and eye-tracking allow for a more objective feedback, and can also be used with people with cognitive impairments who are less able to express their impressions. Again, questionnaires, workshops and interviews can be used in a usercentered approach, though are more general methods. We did not explicitly ask about usability testing, since it is not interpreted in the same way by all people, i.e., whether it must be done in lab or not, though some methods included, such as eye-tracking or physiological measurements imply usability testing was done.
Information about stakeholder inclusion was only gathered about the phases gathering information and evaluation, since the methods for communicating the needs do not require users.
Types of stakeholders include: -primary end users; -family and friends; -care experts; -end user organizations; -public bodies; -insurance companies.
For most AAL systems, the primary end users are the older users. Family and friends, and care experts are people who know about the target group, but also may use the system, for example, to communicate with older people or respond to alarms. End user organizations potentially provide access to a larger number of older users and represent their interests. Public bodies are particularly important in countries with nationalized health care and social services, like the one studied, as the costs of these systems may amortize for them in a few months [6]. Insurance companies were included, because just as they give a discount for people having burglar alarms, they may in the future support systems that, for example, reduce the incidence of falls.
Of the methods included in the questionnaire, the toolbox of methods for AAL [36] also includes the methods shadowing (for gathering information), personas and storyboards (both for communicating needs), as well as co-discovery, cognitive walkthrough, Wizard of Oz and paper prototyping (all for evaluation). With the exception of storyboards, all of these methods are recommended for use with users; shadowing, personas, co-discovery and Wizard of Oz can also be applied with users who have impairments [36].
Furthermore, basic demographic data was collected about the participants, including their sex, level of education, professional background, type of organization they work for, e.g., research or company, size of the organization they work for and experience in AAL, i.e., number of projects they have been involved in.

Information about the participants
Of the 28 participants who completed the questions being evaluated, more than half of the participants were female (57%), 43% were male. Moreover, the majority of participants had higher education, i.e., university or a college degree (93%). The rest (7%) of the participants had at least a high-school equivalent.
Regarding the professional background, people from a wide variety of fields were included. One fourth (25%) studied computer science or mathematics. Almost one fifth indicated that they have a background in sociology or communication science. A small percentage of participants had a background in health care or therapy (14%) or economics, including health economics (11%). A small amount of participants indicated social sciences (7%). Other areas that were mentioned were political science and law (4%), export and administration (4%), telecommunications (4%), management (4%) and psychology (4%). One person (4%) did not specify their professional background.
More than two thirds were working in the field of research (68%); more specifically 36% were working at a university and 32% in other types of research institutions. A small percentage of the participants were working in companies (14%) or provided services (11%); 7% of the participants chose the category 'other', one with a comment that they worked as a lobbyist.
Finally, there was a good distribution of organization sizes. One fourth of our sample was working in a microenterprise (i.e., fewer than 9 employees). Almost one-fifth (18%) indicated that they were working in a small-sized enterprise (i.e., fewer than 50 employees). A small amount of participants (11%) indicated they were working in mediumsized enterprise (i.e., fewer than 250 employees) and almost half of the participants (46%) chose the category large-sized enterprise. By looking at the types of organization and size, it is possible to conclude that at least 12 different organizations were included.
Regarding their experience in AAL, participants reported being involved in between 1 (18%) and 15 projects (7%), with an average of 4.5.

Methods used in AAL projects
The results about the methods used in projects developing AAL technologies are presented by the phases described previously: first gathering information about needs, then recording and communicating the results and finally evaluation. At the end, the results relating to the stakeholders included are presented.
The results are structured as follows: -first, we present how frequently each of the methods were used in projects developing AAL technologies; -since familiarity with methods affects the methods applied, we then present which methods were known to the participants; -next we present the perceived suitability of the methods.
For this, only those methods known to the respondents were considered in the results; -finally, after presenting all of the results about the methods, we present which stakeholders were included and in which phase(s).

Methods for gathering information about needs
The methods people used in projects are shown in Fig. 1. The methods used most often were interviews, questionnaires, focus groups and workshops. All of these methods have been used by more than two-thirds of participants. The methods used least were shadowing, contextual inquiry and cultural probes. All of these were used by less than one-third of the participants. This may be in part, because these methods were also known by fewer participants (see Fig. 2). The UCD specific method contextual inquiry was known by only 43%, although it has existed since 1990 [20]. As expected, the general methods, i.e., workshops, questionnaire and interviews were known by all.
This leads us to the question of whether the usage relates to the perceived suitability or the knowledge about the method. In Table 1 we see the perceived suitability, both for gathering information about functionality and the interaction between the users and the system. The percentages in this table are based on those participants that indicated that they knew the method (shown in the column labeled n1). Note that the functionality needed is related to the task and environment, and the interaction is more closely related to the users and the technology. Results show that focus groups, workshops, questionnaires and interviews were thought to be most suitable for gathering information about functionality (over 85% of those who knew). The mock-ups and observation methods were thought to be most suited for understanding the interaction. Overall, both cultural probes and shadowing were thought to be among the least suitable methods for gathering information in projects developing AAL technologies, either about the functionality or interaction.

Methods for communicating needs to developers
In Fig. 3, we see that all methods have been used by more than two-thirds of participants, with use cases and personas being the most common (both 86%). Figure 4 shows that scenarios, use cases and personas are known to all, and even  Fig. 2 Knowledge of methods for gathering information (n=28) storyboards were known to all but one of the participants (96%). Table 2 shows the perceived suitability, again based only on those who knew the method. For visualizing needs, all methods can be considered as equally suitable. Use cases and scenarios, which include information about the tasks, were thought to be most suited for evaluation (57 and 68%, respectively).
The methods rated best for communication were the same, regardless of whether communication was with project partners or external stakeholders. The personas, scenarios and use cases methods were known to all participants, and were thought to be suited for communication by at least 68%.

Methods for evaluating systems
The methods used for evaluation are shown in Fig. 5. Of these, only co-discovery was used by less than one-third of participants. A wide variety of methods are used widely (over four-fifths of participants), including diaries, physiological measurements and eye-tracking. As with gathering information, we see the general methods, i.e., questionnaires, workshops and interviews, were most widely used by participants.
Methods such as Wizard of Oz were not widely used, which may relate to the fact that they were also known by fewer participants (see Fig. 6). Figure 6 shows that the least used methods were also less well known. Co-discovery was least known (only 32%), even though it is in the toolbox of AAL methods [36].
The perceived suitability of the methods is shown in Table 3. We asked about suitability with regard to both functionality and interaction, as was done for the methods for gathering information about needs. Again this is based only on those respondents who knew the methods. This shows a different picture. The Wizard of Oz method was thought to be the most effective for evaluating the interaction by participants who know the method. For evaluating functionality, the general methods questionnaire and interviews were among those thought to be most effective, along with diaries and Wizard of Oz (all at least 80% of participants who knew it). The co-discovery method, although unknown to most and not widely used, was still thought to be suitable for evaluating functionality by 67%, and was not among those rated least suitable.

Types of stakeholders included
To get a more accurate view about the inclusion of stakeholders, we asked participants to answer the questions 48% ± 10 37% ± 9 37% ± 9 30% ± 9 Scenarios 28 57% ± 9 68% ± 9 71% ± 9 57% ± 9 Use cases 28 50% ± 9 82% ± 7 71% ± 9 68% ± 9 Personas 28 57% ± 9 68% ± 9 71% ± 9 43% ± 9 with one particular project in mind. Please note that one person did not answer this question, so the total number here is 27. Figure 7 shows the stakeholders that have been included in gathering information about the needs. Older people were generally consulted most, while insurance companies were not consulted. Regarding functionality, end users and end user organization are included most often (both 74%), followed by care experts (67%). With regard to aspects related to interaction, end-user organization and care-experts were included most often (63 and 59% respectively).
With regard to the evaluation, end-users were included by almost all (93%) respondents (see Fig. 8). Both enduser organizations and care experts were included by more than half of the participants.

Discussion
In the following we discuss aspects related to the choice of methods, user inclusion and communication in teams.

Choice of methods
In terms of methods used, we see that the expert review methods, heuristic evaluation and cognitive walkthrough, are less commonly used. Since 96% of participants had used eye-tracking in a project and eye-tracking is done in combination with usability tests, the results indicate usability tests were widely done. The prevalence of usability tests is in accord with what has been reported more generally in projects by Lindgaard [23]. The usage of diaries for evaluation (by 96%) indicates that in many cases the evaluation were done for an extended period of time. The extent of eye-tracking is surprisingly high. This, however, may relate to the fact that in Austria eye-tracking is widely used in the usability community, for example at CURE (Center for Usability Research & Engineering in Vienna), the usability labs at some universities (including the University of Salzburg and the University of Applied Sciences Technikum Wien) and also some of the more established usability consulting groups.
Both during gathering information and evaluation, general methods such as interviews, questionnaires and workshops were widely used. Although these methods are not specifically included in the usability planner [5], they are considered to be part of UCD [29]. These findings match the research of Gray [15] that many developers think being user-centered is more of a mindset than a method, and apply "remarkably few explicit user research methods" (p. 4049). Also other studies in Europe have found that more general methods that are not specific to UCD are applied in UCD (e.g., [3,21]). Bednarik and Krohns [3] found that this was due in part to perceived costs and lack of UCD know-how. For some methods, the results on perceived suitability support that it may indeed be due to know-how, e.g., Wizard of Oz and co-discovery were not widely known, though were thought to be appropriate by those who knew these methods. The choice may also be related to the fact that people from other disciplines were included. In the area of health services, methods such as interviews and observations are often applied rather than UCD specific methods, such as mock-ups for gathering information or co-discovery for evaluation [26]. Generally, a high level of knowledge of methods was present, even though participants included people from other professions, such as health care and sociology. This may, however, also relate to the fact that most had been involved in more than one project (72%). The fact that people gained knowledge about UCD through previous projects could help to explain why the contextual inquiry method was not widely known, even though it has been in existence for many years [20] and has been considered by other recent studies of UCD (e.g., [15]). However, Bednarik and Krohns [3] reported that this is a more advanced method and was also not used by any participants in their study.
Other researchers have reported the difficulty of dealing with intangible issues with older people [24]. At the same time, AAL systems may include intangible concepts, such as the sensors that are needed for monitoring activity. With regard to this, it is interesting to note that methods that could support making the functioning of the system more tangible before the system is completed, such as mock-ups and Wizard of Oz, were widespread and also among those rated most suitable.
It is also interesting to compare the results to methods described in the toolbox for AAL [36]. Some methods recommended there were not widely known, such as co-discovery. With regard to suitability, most of the methods from the toolbox included in the questionnaire were also thought to be suitable by those participants who knew them: personas, codiscovery, Wizard of Oz, cognitive walkthrough and paper prototyping (all considered to be suitable for some aspect by more than 60% of people who knew them). Wizard of Oz was considered to be one of the best methods, and also paper prototyping was thought to be suited for evaluation (both thought to be suitable by at least 86% of those who knew it). This is of particular interest as these methods support getting early feedback. The situation with shadowing and storyboards is less clear, for although some rated these methods as suitable, they were among those rated to be least suitable. This is particularly striking with storyboards, where all but one of the participants knew the method, though less than 50% found it to be suitable, even for communication between project partners for which the toolbox specifically recommends it.

Stakeholder inclusion
The results indicate that primary end users were included in many projects, both for gathering information about the needs and during the evaluation. This is interesting, since another study also done in Austria concluded that users were included too little [14]. It is also remarkable, since it may be difficult to test with older people due to a variety of factors, e.g., cognitive or physical limitations, but also the effort to learn a new system due to limited knowledge about ICTs, so that some even suggest using more indirect methods with older users [31].
This perceived lack of involvement may be because actual end users, i.e., the older adults, were only included during the evaluation, whereas end-user organizations and care experts were included earlier in many projects, i.e., for gathering information about user needs. The focus on input from care experts early on is concerning, as Dahl et al. [9] found that with emergency response systems, care experts were more concerned with security (i.e., functionality), whereas older people put focus on aspects such as aesthetics and usability. In practice, it was precisely about aspects related more to the interaction rather than the functionality about which end-users were included less frequently. However, since users were included in evaluation, these aspects may still be able to be corrected. This underlines the importance of methods that enable earlier feedback, like Wizard of Oz and paper prototyping-which were also thought to be suitable by a high percentage of those who knew them.
The lack of inclusion of older adults in the early phases does not have to relate to a bias against older people. In a certain sense, the care experts represent the customer. In their study of UCD practice in small companies, Bednarik and Krohns [3] found that also in other areas developers did not distinguish between 'users' and 'customers'.

Communication in teams
Another interesting aspect is the communication of the needs. Most methods studied were known to the participants and had also been used in a project. However, unlike the other phases considered, here only one method was considered to be suitable by more than 80%-use cases, a method which is also used more generally in software engineering and which is not specific to UCD. It was considered to be suited specifically for communicating between project partners, at least some of which will be developers. This is interesting in view of results from a previous study looking at specific projects [12], in which it was found that there are problems with the communication in teams, specifically between those carrying out the needs analysis and the developers. It is essential that developers understand the needs, as during the development they may make decisions both about the functionality and design. These decisions can have a decisive impact on whether products can be a commercial success, even when comparing systems from the same company [19]. Furthermore, it has been demonstrated that even technical design decisions made during the early phases development, e.g., regarding the system architecture, affect qualities of systems that are crucial to success and can be difficult to change in a later stage [11]. This indicates that additional methods for communicating the needs to the developers could support having more successful AAL products in the future.

Conclusion
This paper presented a survey of UCD practice in projects developing technology to support older people. Due to the shifting age pyramid, there is great potential in these technologies, however, there are also many barriers to adoption. This study aimed to support future teams in choosing appropriate methods by investigating the perceived suitability of different methods.
Results show that many projects rely on general methods that are not specific to UCD, such as interviews, questionnaires and workshops. Despite this, if known, more advanced methods are perceived as suitable for gathering information about stakeholder needs and for evaluating systems, e.g., mock-ups and Wizard of Oz. Based on this, it can be concluded that the use of more advanced UCD approaches can support projects developing AAL technologies in gathering the actual needs of all relevant stakeholder groups and evaluating systems. Furthermore, results indicate that the primary end users are often included only later, i.e., for evaluating systems, indicating promise also in methods supporting earlier inclusion of older people.
With regard to methods for communicating needs to developers, results indicate use cases were thought to be best suited. However, generally, the methods studied for communicating needs between project partners were rated with a low level of suitability, so further methods seem to be needed. Furthermore, since use cases is a method from traditional software development, it may be advantageous to investigate more versatile methods, that can be used both with project partners and external stakeholders without software development knowledge, and that are also suited to communicate the different types of information developers need to ensure the systems are effective, efficient and satisfactory.
In conclusion, future work should focus on raising awareness of more advanced methodological approaches among stakeholders involved in innovative projects in the field of AAL. To achieve this, also toolkits that support the selection of appropriate methods and their application could be useful.
In addition, the development of new methods for communicating stakeholder needs within projects could support more success in the future.