The Development of a Sensor-based System for Older People: a Case Study

An aging population is creating increasing pressures on health care systems. Assistive technologies including telecare monitoring applications installed in the home are being promoted as part of the solution. These systems differ from other more interactive systems both in using sensor-based technologies and having older users, aspects that can affect the way the user is viewed, which in turn can affect what is prioritised in design decisions. However little is known to date about the processes involved in designing such systems, especially from the perspective of how 'users' are considered. To explore this we studied a development project in telecare with a focus on how the user discourse evolved. Using qualitative methods and thematic analysis, we identified two broad themes about how 'users' are considered: the disappearing older user, where the discussion moved from rich pictures of older people's lives to sense-able scenarios; and the privileged developer , where representations of older relatives were mediated by the developers' stories of their own relatives, inadvertently prioritising their own needs as carers for those relatives. The findings demonstrate some of the challenges for a user-centred design process that can occur when working with sensor-based systems and older people that could have implications for whether these systems will be accepted. Older people. Sensor-based systems. Telecare. User-centred design. User discourse.


INTRODUCTION
Assistive technologies (AT), including telehealth and telecare as well as Ambient Assisted Living (AAL) systems, are being promoted by many developed world countries as solutions to meet formal healthcare demands of an aging population.However, despite significant investment (European Union 2010) and potential benefits (Barlow et al. 2007), the uptake of such technologies has been slow (Sanders et al. 2012).Similar systems using home-based sensor technologies are also options for supporting informal carers looking after older relatives, but these might suffer from similar acceptance issues.Problems with acceptance may relate to the ways in which aging is (mis)understood (Tornstam 2005).Support for this hypothesis comes from Sanders et al who identify some of the barriers to adoption of telecare and telehealth, including "potential threats to identity associated with positive ageing and self-reliance" (Sanders et al. 2012, p. 3).Certainly, the diversity of older people creates unique challenges for designers (Lindsay et al. 2012;Blythe et al. 2005).Despite these challenges, few studies have investigated the actual development processes of projects in this area.Development processes have been studied more generally in user-centred design (UCD) projects to gain understanding about decision-making (Friess 2012).This indicates it is a worthy endeavour to study telecare projects to understand what happens in detail.
We studied one small company that operated from a deep concern for older people and engaged in a user-centred design and development process.We focussed on how users were considered and discussed by the team in a project based on sensor technology.Despite the fact that there were several independent external advisors, the development team could not gain access to a large group of older users.In still wanting to take a user-centred perspective, they chose to consider their own relatives in the design process.We identified how the user discourse evolved during the project: how the older user disappeared from focus and how the carers' needs were often given priority in the design.This paper starts with a summary of relevant literature in Section 2. Section 3 describes the project, including the methods applied and participants.Section 4 presents the results, including the themes identified.Section 5 discusses the results.
The Development of a sensor-based System for older People: A Case Study Jean D. Hallewell Haslwanter • Geraldine Fitzpatrick 2

BACKGROUND
Assistive technologies have been promoted as the solution to the increasing burden of care for an aging population in many countries.We characterise the range of systems considered under AT as: systems to support independent living at home, e.g.reminding people to take medication; telehealth systems enabling contact to healthcare professionals, e.g.monitoring blood pressure; and telecare monitoring systems that monitor activities of daily living (ADLs) and react to detected exceptions to ADL routines, e.g.fall detection.These systems may be developed and implemented for use within the formal care sector, but can also be targeted to informal carers, as is the case in our study.
Various funding programmes exist to encourage development of these technologies.An example is the AAL joint programme of the European Union (EU), started in 2008, which specifically encourages the entry of small and medium size enterprises (SME) into this field (European Union 2010), such as the company in our study.
Despite this, these systems are still not yet widespread.Some studies have investigated the systems themselves and their adoption.Identified barriers to adoption of, or withdrawal from, such telehealth and telecare services include: the level of technical competence required, threat to independence and identity and fear of disruption of current health care services (Sanders et al. 2012).Of particular interest here are impersonal monitoring systems, like fall monitoring systems and the activity monitoring system like that studied in this paper.Some argue that this type of system may not really constitute care as it does not support personal interaction, but that these systems are important as they may be attractive to people not otherwise open to care (Draper & Sorell 2012).In these systems there is a tendency to add functions not originally planned that give more control to carers and may reduce the independence of people using these technologies (Draper & Sorell 2012), particularly if there is no possibility to adapt the system (Mort et al. 2012).This tendency to function creep indicates that it may be worthwhile to study the development process where such creep happens.
One characteristic that can make the development of monitoring systems challenging is that the systems are targeted at older people.It can be difficult for younger developers to understand less technical older users.There are also widespread preconceptions of older people (Tornstam 2005) that can inadvertently affect the design and choice of functions.To avoid such misunderstandings, and increase the benefits and acceptance of the system, a number projects have tried to use a participatory approach and include older users directly (Lindsay et al. 2012;Subasi & Fitzpatrick 2012).Besides participatory design, there are also other UCD approaches such as personas, where "actual users do not play a big role during the design phase" (Blomquist & Arvola 2002, p. 200).These are important as time constraints can make it hard for developers in companies include users (Lievesley & Yee 2007).However just applying a UCD method may not be sufficient to ensure systems meet end-user needs (Friess 2012).This suggests it could be useful to  (Greenhalgh et al. 2012).
In this paper, we wanted to investigate the user discourse in one development project that was committed to the principles of UCD and that involved a sensor-based application to monitor older people at home.How are the users discussed and considered in this sensor-based project?

STUDY
In the following, we introduce the project and the methods applied to study its development process.

Information about the project
The company is an SME that has previously participated in an AAL funded project.It received new funding to develop a prototype of a system to sense the status of an aging family member and send messages to a younger family member to notify them of potential problems, using sensor technologies that have been proven in other projects (Cucchiara et al. 2004).The system was conceived as working on mobile devices (tablets, smartphones) and as an add-on to their existing interactive communication system.(The details of the systems will not be described to protect the company's commercial interests.)The funding was sufficient to cover one developer/programmer to work full-time on the project for 2 months, plus a part-time project leader.The developer had previously worked on projects for disabled people, but not systems with sensors or for older people.The project leader had a business background and has worked on other AAL projects.Three advisors from other organisations with expertise in sensor systems and AAL, with whom the project leader had worked previously, were included in the project team, plus the researcher.
Frequent project team meetings were held that included the project leader, developer and at least two of the advisors.The meetings were initiated by the project leader and developer and took place at irregular intervals, on average more than once a week.Because the advisors were located in three different countries, these meetings were held via Skype, with the project leader and developer sitting at the same computer in a meeting room.The project leader planned to apply methods including persona-like descriptions of exemplar users and usage scenarios to analyse user needs, iterative design, prototypes without user testing and extended user testing with later prototypes.The methods planned are ones recognized as UCD practices (Vredenburg et al. 2002).

Methods applied
Qualitative techniques, such as observation and interviews were applied for the study, with the researcher in the role of participant observer.Data collection involved visiting the offices, participation in project meetings, interviews, and studying documents and artefacts from the project.The main focus was put on the project meetings, where the bulk of the interaction between team members took place.Audio recordings were made of all meetings and interviews.Signed consent forms were obtained from all members of the team.
Data collected included nine of the project meetings with a total of more than 10 hours duration.In addition, five semi-structured interviews with team members were held by the first author: one with the project leader just before the start of the project, one with the developer during the design phase, then interviews with the project leader, developer and one advisor after the project.In addition, project documents, transcripts of Skype chats between and during meetings and all five versions of the resulting prototype were studied.The project documents included minutes of those meetings, where minutes were taken, instructions on using the prototypes and slides about the technical solution.
The data was analysed using thematic analysis (Braun & Clarke 2006) with a focus on how the user was discussed and at which points they were mentioned.Notes taken during meetings were transcribed and supplemented by audio recordings as necessary.Full transcriptions were made of all interviews from the audio recordings.A software tool, Atlas.tiTM , was used to facilitate navigating the text, but all coding and analysis was done manually.The thematic analysis included a line-by-line open coding of notes, transcripts and documents.After the last project meeting had been coded, but before the last interviews, common themes and sub-themes were identified.A selective coding was done before the final analysis, using the themes to gain more understanding, e.g. at what point in time themes emerged and how prevalent they were.

RESULTS
This section starts with an overview of the meetings and then presents the two main themes identified by the thematic analysis.These related to issues of how the 'user' was first central and gradually disappeared (theme 1) and effects of having to consider older people they cared for thereby privileging the developers and their needs (theme 2).Words in italics are taken directly from the data, with an ellipsis to indicate where something has been left out.Pseudonyms have been used to protect the identity of the people involved.Materials in other languages were translated by the authors.

The meetings
Eleven meetings were held throughout the project, the first two of which focused on requirements analysis: describing the users, their abilities and limitations, the environment in which they live and their activities, especially those aspects related to this system.In the 1st meeting the project goals and constraints were also discussed.There was some concern about the technical feasibility.With regard to the users, it was anticipated that the team would have access to a group of carers that could provide access to a wide group of older users, but it was announced at this meeting that the user group would not be participating after all.At the initiative of the project leader, he, the developer and two of the advisors in the team described parents or grandparents for whom the system could be of interest.In interviews after the project, two of them said they based their input on things their relatives had told them in conversation in the past.The relatives described included two men and three women between the ages of 70 and 84, four of whom lived alone at home and one of whom lived in an independent living facility (see Table 1).Regarding technical skills, this included two people who regularly used computers or smartphones, and three people who did not.The descriptions were recorded in the minutes.During the 2nd meeting a few days later this was followed up with situations or patterns for each of these people which could potentially be recognised by the system.After this, the potential sensors were discussed.
In the 3rd meeting, first solutions were discussed with a focus on what could be recognised in practice, e.g., using a microphone to recognise whether someone was talking and the problems associated with this, such as how close the person has to be to be detected.A first working prototype was issued a few days later -just two weeks after the project started.This prototype primarily visualised sensor values, e.g. if a sound above a threshold was detected.In between meetings, the members of the team tested the prototype by using it in their own contexts to see what it 'recognised'.The next meetings (meetings 4-9) involved discussions of experiences with the different prototypes (five in all) and deciding next steps.During these meetings technical issues, such as thresholds and modelling the patterns, were often discussed.
The final two meetings focused on results from more realistic tests of the prototypes conducted by the members of the team, where the prototype ran in the background during 'normal life' over a period of several days.The focus of the discussion changed to what could be detected or recognised in practice.The prototype now included the sensing side of the solution with a trigger for generating a summary message, e.g.via e-mail, to another person, when a deviation from 'normal' patterns was detected or a pre-defined threshold was exceeded.
The configuration of the patterns and thresholds was done in Java and XML files.Although the sensing and recognition seemed to be working, these tests found that the message generation wasn't working.As a result, the application was not tested with the older relatives of the team as planned, as the project leader felt these messages were essential, something he confirmed in an interview after the project: "Which is the, you know, the absolute bare minimum test -I expected to get the e-mail, you know.No one got an e-mail." In summary, the project ended due to funding constraints.The project leader was unsure whether to continue the project, because it was not yet clear whether it would work in practice.Our focus here is not on the success or otherwise, but on how older people were considered in the development of this sensor technology.We go on to discuss the two broad themes identified: the disappearing older user and the privileged developer.

The disappearing older user
As the project progressed, the users seem to "disappear": the rich descriptions were recorded in abbreviated form, the complete people become passive signal generators, and were finally generalised.In the design, the specific person-centred aspects gradually become secondary to the technical aspects.

Timothy: summarising his rich story
The relatives who were included as exemplar older people were discussed in the 1st meeting, and summary information was recorded in the meeting minutes.This included age, where they live, health problems, ability to operate mobile phones and computers, and social contacts.To illustrate the way they were described by their team member relatives, a single older person has been chosen: Timothy.Here is an excerpt of his son's description of him during the 1st meeting: "Timothy is 84, male, has mild, well actually now moderate, dementia, that can be classified as Alzheimer's.We all know it will get worseit's just a question of when and how fast.Later in the same meeting, it was mentioned that this "fun senior" was his partner and neighbour.In this context she was mentioned as someone who might be able to interact with the system on Timothy's behalf: "Another input would be that another person basically confirms that everything is okay." The rich stories told by his son, as illustrated above, were then very simply summarised and recorded in the minutes as (here with some line feeds removed):  "84 years, maledementia (Alzheimer's), forgets a lot"  "has female neighbour ( 86) who takes him out regularly: neighbour is very agile could possibly be included as contact person"  "cannot handle a computer: sees badly, less than 10%, because of that anything to touch is tricky.Cannot really use touch displays" In the 2nd meeting, the focus was to look at typical activity patterns of each person that could potentially be recognised by the system.As an example for Timothy, getting up late was mentioned as a bad sign because it usually meant he had a fever or felt dizzy.Not coming home was also concerning as it could mean he was in hospitalsomething that happened once or twice a year.The project leader's description of why he would like to know about such things (here about going to bed late) indicates the system is really for a concerned relative: "either a mild indicator, where I would just like to know it and do something or it means he isn't feeling well." Following these detailed discussions, the minutes recorded a summary of what were considered the bad signs, good signs and regular patterns for each of the older people described.For Timothy the bad signs included the main ones mentioned above, but not the weaker indicator of going to bed:  "gets up late -doesn't feel good; had no breakfast  doesn't leave home; does not come home at night" In the minutes of this 2nd meeting, the daily visits are also recorded, including the "neighbour" mentioned at the last meeting.Specifics about which rooms she visits, how long she stays, whether he also visits his neighbour, etc. were not included:  "almost daily, his partner comes by  almost daily, someone from the home looks in" Not only does the amount of detail recorded decrease, the amount of time spent considering the users decreases as the project progresses.Despite the extensive focus on the individuals in the first two meetings, in the subsequent meetings, Timothy is not mentioned by name again.

From people to signals
Although the team started off talking about their older relatives by name and giving rich pictures, as exemplified with Timothy, in later meetings they are not discussed explicitly.Instead their lives became increasingly reduced to their patterns or signals they generate for the sensors.This started in the 2nd meeting which, while mostly still about the older people and 'patterns' in their lives, also included a discussion of sensors that could be used in the application.Thus the patterns that were determined interesting were those that could be sensed.This passivity is also demonstrated by the fact that no user interface was developed for the older users.
The progression is also illustrated by the way in which people were explicitly referred to in meetings.In the 1st and 2nd meetings, the 'users' were introduced and discussed by first name, but this changed in subsequent meetings, where they were described by their relationship, for example "my father", "my grandmother".For example, in the 5th meeting: "With my father, I want to know right away when he got up." The last time one of the people was referred to by name was in the 3rd meeting, which focused on design, when Catherine was mentioned by name.Instead, their stories were used as placeholders for the person.Examples of sense-able scenarios that became proxies for a specific person include going to bed (Timothy) and the door gong (Helene).The team still seemed to know that these referred to a specific person as evidenced in the 9th meeting, where Helene's son was asked to describe the pattern for the door gong.
In later meetings, the people were referred to by more general terms, such as "seniors", "your seniors" and "person".For example in the 5th meeting: "Even just entering the values isn't possible for my senior."In the last three meetings these general terms became more common, even as the team discussed testing with them: "test intensively, so that we can get to seniors quickly".

Generalisations and stereotypes
Although the project started with rich descriptions of five specific people, the talk in the project often fell back onto generalisations and stereotypes about old age, often not supported by the data that had been presented in the first meetings.There was evidence even in the 1st meeting, where the excerpt from the minutes describes Helene's condition as "rheumatism, typical elderly weaknesses".
Another stereotype that the team quickly fell into was the lack of computer experience, which was raised as an issue in many meetings.For example in the 3rd meeting when discussing the design: "They always say this: I can't do it, it's beyond my grasp".While this may be the case for three of the five older people, the others had computer experience.Helene, for example, used to work in IT and checked her e-mail daily.In the minutes, however, it was recorded only that she: "has a PC, can browse, use e-mail; but very limited interest, needs a strong motivation and clear benefit".Later in the same meeting, the developer mentioned that menus could be confusing and suggested that only a few buttons should be included in the interface.To reinforce the stereotype of the older person who can't use computers, two user modes were considered in the design: a restricted mode with little interaction required and a passive mode where no interaction was required from the older person.For the latter, it was assumed that there would be a type of 'delegate' who could be defined to manage the account on behalf of the older person.
Another example of generalisation was loneliness, as illustrated in the following: "[older people] are typically alone, they don't meet their old mate on the street just like this, they aren't so mobile…and increasingly kind of get forgotten." The extent of generalisation may be due in part to the fact that patterns are necessary for a sensor system such as this to work as a commercial product.This tension is noted by the project leader in the interview before the project started: "If every old person is actually different, then we never have a chance of picking up anything that means the same." At other times the team was aware that generalisations weren't possible.For example, in the 10th meeting when discussing if the team can assume that only one person is using it.The project leader, whose father is one of the oldest and has a partner, recognises he needs to re-think things midsentence: "That's not a big problem -I think most seniors are single, at least those that need care.Is that true??The majority maybe, well, at younger ages it doesn't have to be the majority.(pause)"

Technology decisions take precedence
It is interesting to note then the tension between describing rich stories about older people, and the move to design decisions without systematic attention to the information gathered.This was reflected also in the choice about what was going to be implemented.Furthermore, in contrast to the information about the users, most of the design decisions and technical discussions were not recorded in the minutes, making it hard to account for the decisions in retrospect.
An example is the choice of the first activity pattern to be implemented -"closing the blinds".This pattern was mentioned for the first time in the 5th meeting, and had never been mentioned previously with respect to any of the five older people, neither in the minutes nor in meetings.Instead it seemed to arise from the experience of the team members themselves, who all lived in countries where blinds were often closed at night.When asked at the end of the project why this pattern was chosen first, there seemed to be confusion about where it had come: the developer said he did it specifically for the project leader's father, but in the 6th meeting when discussing this pattern, the project leader said "My father doesn't put the blinds down." The developer acknowledged that technical aspects played a large part when asked what decided which patterns were chosen: "Well, probably more the pure technical view: which activities could be easily recognised, were primarily decisive for the prototype." One advisor mentioned using more advanced algorithms for detecting patterns in two different meetings.Given the lack of time, the team agreed that these were not really options: "I know some, but they are mostly very complicated, they are doctoral theses… We should just get started." At the end of the project, the project leader recognised ways they could have had a stronger focus on the user, despite the limitations of accessing users: "I should have been even more stringent or strict about the use cases and I should have forced [the developer] in fact to have a real table of these use cases and all the rules that follow from them and really have an online picture of which of these we have now."

The privileged developer: proxy and carer
Since the user organisation dropped out, the team drew on their own family members as exemplar users, and in the process inadvertently made themselves a key user group, i.e. the carers who get the messages.Although the team did not acknowledge they too were users, they were in a privileged position: being able to mediate the representation of their relative, being able to project their own needs as informal carers, and being able to decide what functions would be implemented, even considering functions the older person may not want.These aspects are explored below.

The wishes of the unacknowledged users
As the project went on a second, unacknowledged, user group emerged: the relative caring for the older person who gets the messages.They are referred to in the 5th meeting when the project leader revisits the goals of the project: "There is a relative who has a bad conscience.They have an older person they are looking out for, for whom he cares.
… And this person wants…" This user group was never named or described explicitly, even though their needs are a key motivation for the project.
The concerns of these relatives are voiced again and again in meetings, as indicated in some of the previous quotations: worries about the older person going to bed, eating, exercising, etc.
Three of the four team members who described a family member mentioned the lack of communication.They hoped that the system would help address this lack by indirectly communicating on their relative's behalf.When asked at the end of the project to describe the users, the team members interviewed did not include the carers or themselves as users.In retrospect, the project leader conceded it was the case: "Well, okay, we, we being the relatives, are also users, right?But we didn't give us names in those use cases, right?We gave the seniors names.We should have done this as well by the way."

The developers as privileged users
Since the team described family members, implicitly the team members were direct users.This put the development team into a privileged position to have their needs heard and prioritised in the development process.In fact, 3 people who described an older relative said what they would like: "For me personally, it would be sufficient if it could just..." The configuration is one of a number of subtle ways that this played out.In the prototypes, this was done using a series of Java-based files.When asked whether a graphical user interface was necessary to make do any configuration, one of the team members said: "I can handle a config file."This would not be the case for 4 of the 5 described older people, implicitly making the younger relatives the ones doing the configuration.
This group of users also decided which functions got implemented based on their needs.In the last meeting, Timothy's son suggested a new function to remind his father to go to bed and notify him, reflecting the concern he had voiced in the 1st meeting: "Is the reminder to go to bed a possibility, or do most of you say, I definitely don't want that."Most team members agreed with the team member who said "mine wouldn't need it", and so this function, of interest to one younger user, was not included.
Later, the developer commented: "At the beginning, it wasn't clear to me to what degree (we are also users), although unconsciously it played an important role."

DISCUSSION
We set out to look at how a company developing a sensor-based AT system with a desire to help older people dealt with the challenges of an older user group using non-participative UCD methods.
The descriptions of the older people provided valuable information for the project.As described with personas in other projects (Friess 2012), one person dominated: Timothy.At the beginning of the project, the users were considered as complete people, but this gradually shifted and they became represented by scenarios about what could be sensed.The empirical tests also recommended elsewhere (Blomquist & Arvola 2002) were planned but not done.Based on what happened in projects meetings and the interviews, we can summarise the project as follows:  Relevant aspects about the older users and their lives "disappeared". There was an unacknowledged user group: the younger relatives whose needs as informal carers dominated the discussions. The functions selected were chosen in part based on generalisations and technical limitations, even though real users were considered by proxy through rich descriptions. No user interface was developed for the older users being sensed.
Our most interesting findings relate to how users are considered in such sensor-based projects.Below we also explore the way the user discourse changed during the project and the implications for research and development projects.

How sensors change the meaning of 'user'
In the end, the very word 'users' takes on a different meaning when working with sensors.It is no longer just an issue of users being considered either as complete people or only in terms of system usage, because usage can be passive or active with sensor-based systems.While the team talked about their seniors as the 'users', the seniors were inadvertently treated purely as signal generators, similar to the "objects" terminology used in other sensing projects (Cucchiara et al. 2004).
It was the younger people, the relatives getting the messages, who were the real 'users', the active ones.This shaped design decisions in undefined ways, since they neither recognised themselves as users nor tracked the design decisions.As a result, for example, the interface in the prototype was more suited to the high level of technical expertise of the team members than the general public.
Furthermore, the resulting prototype was not tested with older people because the system was not considered useful by the team while the messages for the younger relative were not working.However some of the sensing aspects did work and these could have been tested in the homes of the older relatives.This would have been important, as the main goal of the project was to see if there were common patterns that could be sensed.Since people didn't go back to ask their family members, they could not be certain whether the activity patterns chosen and encoded in the system would or would not apply for their own family members.The tests could have given valuable input on whether the activity patterns, selected largely based on technical constraints and not on the 'users' described, in fact did apply and whether they worked in the 'user's' context.

The way the user discourse evolved
To explore the user discourse is it useful to draw on the discourses identified by Greenhalgh et al in their discourse analysis of publications (Greenhalgh et al. 2012, p. 1) to see how these play out during the course of the development.They suggest that "If investments in these [telehealth and telecare] technologies are to bear fruit, more effective inter-stakeholder dialogue must occur to establish an organising vision that better accommodates competing discourses."We suggest that the same applies within the development process itself, not just stakeholders -design processes need to accommodate competing user and sensor discourses, and negotiations between these stances need to be made more explicit.
In this project, in which the team members were also informal carers, we can see evidence of two of these stances: the humanist, which is focused on a 'reality-based' person-centred view, and the modernist, a more technology-centred stance.Having studied the meetings where the bulk of the interaction between team members took place in a project with more than the average number of project meetings (Kinney & Panko 1996), we found some minor conflicts, such as whether the goal was for relatives to feel comfortable or how precise the algorithms should be.We found the stances did not talk past each other.Instead, the stance taken by the team as a whole changed as the project progressed, something we suggest relates to the sensor-based technologies used.

Starting with a humanist perspective
The project leader recognised the importance of understanding the users as complete people and recorded this information in detail in the minutes, indicating a strong humanist stance, such as is associated with UCD.The meetings referred little to aspects like efficiency, intelligence and technological progress valued by the modernist stance (Greenhalgh et al. 2012).However, there were a number of issues in how the humanist stance played out that are specifically related to this being an older and presumed familiar user group.
The overall perceptions of older people as reflected in the rapid shift to generalisations showed possible misconceptions of the experience of aging.The changes people undergo as they age are multifaceted and may be misinterpreted by younger people, for example, as in this project, emphasising loneliness of older individuals.Tornstam's theory of Gerotranscendence, by contrast points out that many older people are not lonely, but value solitude as part of a positive experience of aging (Tornstam 2005).Researchers have reported the difficulties of understanding even their own needs (Erickson 1996).Unlike teams working with other types of user groups 'more like them', the team may not be aware of their misconceptions.This is exacerbated in a case like this where the users were people the team members had known all their lives.They were so close they may not understand the current needs of their older relatives.This could directly lead to a failure of the system.For example, a visit of a "neighbour" will produce different signals than a "partner" visiting the apartment regularly.The perception of being a close family relation with the person may also have led the team members to feel less compelled to ask when they felt unsure or to check the stories they were telling.
At the same time, their own unacknowledged roles as family members put them into a position to prioritise their own needs as carers over the needs of the older users.Other authors have noted the different prioritisation of functions like safety by relatives and older people (Blythe et al. 2005).Here, the team considered functions, like "going to bed", that were of interest to them and would give them more monitoring control.Draper & Sorell argue that when information from this type of impersonal monitoring systems is made available to carers outside the home it can actually undermine the independence of the older users (Draper & Sorell 2012).

Moving to a modernist stance
In the meetings, we see how the project discourse shifted from a humanist to a modernist stance, characterised by a more technology-centred view of patterns that could be sensed.We suggest that the very nature of the application, using sensors for passive monitoring, contributed strongly to this shift.It has been reported elsewhere that user requests can be tempered by the device capabilities in sensor-based systems (Cucchiara et al. 2004).Here it is not so much that the user requests were tempered, since there weren't any requests directly from older people, but which scenarios were chosen.From early in the project, the activities chosen for discussion were filtered by what could be sensed, reducing the 'presence' of the older user.
The dominance of the modernist stance is further evidenced by there being no interface for the older person to interact with the system, since it was viewed as something that others could do on their behalf.This was in part due to the generalisation that older users are less computer literate and in part that they are, by virtue of the system, being sensed and hence interacting indirectly with the system.The fact that some users had a high level of computer experience was lost in the project discourse.That no interaction was possible could actually limit the acceptance with other users like them (Sanders et al. 2012).It could also limit the effectiveness, as no adaptation is possible directly.Without the possibility to adapt it, the system can even become coercive (Mort et al. 2012).

Implications
This project is an example of a project to develop a sensor-based monitoring telecare system for older people at home, here for use by informal carers.Smaller teams like this are more common in SMEs (Tosun et al. 2009); the geographical spread is also not uncommon (Kinney & Panko 1996).We have already noted that telecare systems are having difficulty gaining acceptance as part of a formal care system (Greenhalgh et al. 2012;Sanders et al. 2012).We can make no claims about whether the system being developed here would have similar acceptance problems.All we can say is that, to this point, it did not meet its own goals of having a working prototype for a variety of reasons, and its good user-centred intentions did not play out in the ways initially planned.
Nonetheless, the issues identified in this case suggest useful starting points to explore in other projects developing AT: how the user discourse and the passive nature of sensors impact design decisions and ultimately user experiences with, and acceptance of, such systems.For example, to what extent is it an issue of not having enough direct involvement of older people in projects; or the conceptualisations held by younger people about older people; or hidden agendas of more privileged users such as carers or the formal health care system?How much of an impact does the passive nature of sensor-based technologies have in pushing the discourse about 'users' to what can be sensed generally; or is this particular to sensors and older people only?
The question then is how to support a more successful UCD process and help maintain the humanist stance.The team applied methods related to user requirements analysis that have been found important in other studies (Vredenburg et al. 2002).The source of the information was indirect, something that is not uncommon (Vredenburg et al. 2002).As found in projects in other domains (Friess 2012), merely using personas is not sufficient to ensure people's needs are considered sufficiently.At a more pragmatic level, other SMEs like the one here may have difficulty finding user organisations to incorporate participatory design methods recommended by some (Lindsay et al. 2012).Given the constraints of the project, including the short time frame, difficulties finding users, disabilities of some users, and precision required in pattern recognition, the "Usability Planner" recommends stakeholder identification, work context analysis and early prototyping in addition to evaluation (usabilityplanner.org).The team used the analysis and prototyping; they planned to test, but did not due to technical problems.The stakeholder identification was missing and could have helped them become aware of the unacknowledged users.
With respect to the disappearing older user, one option might be to do what the project leader suggested, and track the information about the users to the design decisions.Existing techniques for tracking data that describes users could also be useful in this regard.One example is HODI, a multi-panel representation technique where data reflecting the various discourse perspectives can be collated in one place to make the relations between them and emerging design concepts more explicit (Subasi & Fitzpatrick 2012).Since it requires designers to revisit data and document their design choices explicitly, this may have helped identify problems, such as that "closing the blinds" did not refer to a specific person.Revisiting the data in this way could also help make the user 'reappear', helping perhaps to avoid the transition we saw here from a humanist to a modernist stance.HODIs can also be used in activities with designers and users, and could help get feedback from older users removed from the experience of the team, even if tests are not deemed possible.

CONCLUSION
This study set out to examine how UCD was applied in one specific sensor-based project developed by an SME, using qualitative methods to examine the methods used, i.e. how users were discussed and considered throughout the project.Unlike the Greenhalgh et al review of publications (Greenhalgh et al. 2012), we found that in this pro-ject the stances were less in conflict with each other, but rather the technology-centred view gradually took over from the humanist user-centred approach.It demonstrates some pitfalls that can occur in UCD when working with older people and sensors.Two developments characterised the user discourse during the development process.Starting from rich pictures of older people, the older users were quickly reduced to a simplified set of senseable activities, and so the sense of the whole person being monitored was lost.The second development was a continuous increase in the role of the developer/carer and their 'monitoring' needs.We hypothesise that these issues may be typical for the development of sensor-based assistive technology.This changed the user discourse so it wasn't just an issue of whether the user was considered as a complete person or only in terms of the system, but also whether they were just being sensed or an active user.While the monitoring system developed here is targeted at informal carers, our results relate to telecare systems more generally.Our findings about the user-sensor situation in the development process highlight how the design process itself can contribute to the non-adoption reported for telecare systems.If we want to raise the acceptance of sensor-based systems for older people, we need to investigate how non-interactive monitoring solutions such as these might shape the way users are considered, how older users are discussed differently and whether certain techniques could help teams to keep the 'user' in mind, even when they are not or cannot be included.

Table 1 :
The people considered by the project