1 Introduction

Regarding the demographic shift, an increasing number of technological developments strictly related to the healthcare sector occurred over the past decade. Still an ongoing trend and a topic of great importance (e.g. the main ICT-Agenda of the European Union: Horizon 2020), research projects dedicated to the development of technology for the care-giving sector invited participation. In this regard, we describe the process of ICT developments for the healthcare sector as promising as well as problematic. Our assumptions are based on findings from a three-year research project, which was funded by the German Federal Ministry for Education and Research and was conducted in Germany primarily within the years 2009-2012. The research was dedicated to the application of service robotics in a stationary nursing home. Due to the sensitivity of the field with its morally charged context and its characterization as a highly human driven “relational” work sector, the development was guided in part by participatory methods - i.e. the development should have been driven completely and without any exception by user’s needs. Even though the adopted method for mediating the users’ needs and the technological feasibility were very helpful and delivered promising results, some weak points and misleading processes became apparent.

In the case study “Scenario-based Design” [1] was examined as a procedure for a participatory technology development [2, 3]. Scenario-Based Design (SBD) as an instrument for participatory technology development – according to the optimistic descriptions in the literature [4] – at first sight offers significant potential for early inclusion of future users. The obvious clarity along with the iterative process of coordination and implementing pilot applications ensure an ideal exchange among users and designers. Ultimately, this process should allow an optimal balance with regard to the social desideratum and the technical feasibility. In the course of the above-mentioned three-year research project, this process is almost complete.

Nonetheless, some weak points were identified during the case study. (A) One is related to the graphic nature of the scenarios. In some cases, the development follows an approximated interpretation of a drawing showing the new technology in action, while at the same time, the user follows an interpretation of the same drawing. As we show with clear empirical evidence from the case study, this might result in completely useless development simply because the two primary groups involved in the adjustment process have two very different ways of imagining the implementation of new technology in the social field in question. (B) Another main issue is related to the problem of always following the users’ notions. As we also will prove with data from the case study, sometimes this could obviate the development of very innovative solutions due to lack of imagination on the part of the users, who are usually guided by the technologies they already know and use. (A) will be discussed in Sect. 3.1, (B) in Sect. 3.2.

2 Characteristics of Scenario Based Design

The basic idea behind SBD is to enable the developer of highly innovative technologies to imagine the needs and wishes of the target group at stake. The core process of the method consists in iterative adjustment-loops. The graphical and narrative scenarios become increasingly detailed, ensuring user-oriented development. SBD is a very useful method for the inclusion of elderly user target groups in the development of (very) innovative technologies because of the graphic nature of the scenarios (easy to understand) as well as the iterative adjustments between the involved groups of developer and user.

“Like other user-centered approaches, scenario-based design changes the focus of design work from defining system operations (i.e. functional specification) to describing how people will use a system to accomplish work tasks and other activities […]. However, unlike approaches that consider human behavior and experience through formal analysis and modeling of well-specified tasks, scenario-based design is a relatively lightweight method for envisioning future use possibilities.” [1: 1033].

As scenarios are generated in most cases anyway, it is only important to make them explicit and write them down. The advantage of scenarios lies in their dynamism and how easily they can be comprehended, which arise from their development in relationship to the user and, amongst all those involved in the developmental process, eases communication about the planned execution and/or implementation of a technological innovation [5].

2.1 Scenarios in Scenario Based Design

A scenario contains a sequence of actions and events that lead to a concrete result. The defining characteristic of a scenario consists in sketching a narrative description of activities that a user will typically employ in accomplishing a given task. The description should be detailed enough that design-relevant conclusions can be drawn and later discussed. Scenarios are usually graphically portrayed, and are accompanied by a series of individual drawings, each accompanied by short written commentaries which “narrate” the planned action, as in a comic strip or a storyboard [6].

Generally, scenarios are set from the perspective of the potential user and take into account the user’s social and emotional background, as well as his or her personal motivations and goals. The scenarios themselves involve one or more participants interacting in the form of “personas” with the aid of various instruments in order to achieve a certain goal. Personas are fictitious participants and/or characters who incorporate the typical characteristics of a certain group of users, possess a concrete usage pattern, and should be representative of the majority of actual subsequent users. From the outset, personas should be designed to minimize the development of an end result that is not actually possible for a potential user. Therefore, a unique scenario should be developed for each persona and narrated in the third person [7].

The advantage of scenarios as opposed to use cases lies in how easy they are to comprehend, even for non-specialists. Moreover, use cases often proceed from a determined sequence of actions and reactions between users and a system whose characteristics are already relatively certain. While scenarios are concrete, they are nevertheless incomplete and painted in broad strokes, allowing new perspectives on design to emerge and preventing any assumed, fixed “best solution” from arising prematurely. Via a gradual and iterative adjustment of concept and detail, scenarios successfully model the entire phase of analysis and conception [8].

2.2 The Relevance of the Prototype and Evaluation Phase

It is a fundamental requirement of SBD to make an early evaluation of conceptual ideas, and to repeat this regularly throughout the design and developmental process. If, however, user orientation is significant in the application of SBD [5] and design-focused development is understood from the outset as a social process in which heterogeneous groups are brought together and come into dialogue via the scenarios [6], it is precisely the narrative character of the procedure that poses a significant risk:

“Part of the appeal of scenarios is that they are short, fun, and vivid. But when used uncritically, without proper attention given to data quality and representativeness, scenarios will be no more expressive of the needs of real users than the musings of engineers or researchers unaided by a representation of user experience. It is easy to feel that one has captured a user’s experience because it is represented in a narrative or storyboard, but these accessible representations can easily be inflated into more than they really are. We should be careful to distinguish the form that the information is packaged in from the quality of the content therein. As we attempt to design for broader and broader classes of users who are less and less like designers themselves, it is critical that we find a way to pipe stimulating input to designers that faithfully captures users’ needs and problems.” [9: 397f].

An important method for avoiding blundering into this “scenario case” is intensive and repeated adjustment to users [8: 373]. Whether or not SBD is suitable as a procedure for participatory technological development is finally determined not by accommodating the desires of the user – and/or the developer determining the scenario’s technological feasibility beforehand – in the version of the scenario as it appears “on paper.” It is rather only trial runs that can provide evidence as to the efficacy of scenarios intended for participatory technological development [8: 371f].

3 Case Study: The Application of Scenario Based Designs for the Advancement of Service Robotics

The primary objective of our case study consisted of creating and optimizing a knowledge transfer between developers and users through the choice and application of suitable procedures. For these requirements, SBD presented itself as the method of choice: SBD’s descriptive quality and relative openness were characteristics which not only permitted caregivers and inhabitants of stationary nursing facilities to evaluate planned usage ahead of time, but also allowed developers to identify technically feasible applications.

In each of the two, one-week pilot runs, the use scenarios developed and conceived on the basis of SBD were generated to provide a successful knowledge transfer between the users in the nursing facility and the team developing the two robots. A central result derives in this context from supplementing SBD with “rapid prototyping.” From the experiences in the project serving as a case study (from which generalizations cannot yet be drawn), one would have to seriously consider the systematic implementation of rapid prototyping in the pilot phase for projects using SBD – at least with regards to certain applications that will be discussed in the next Sect. (3.1).

In the following Sect. (3.2), we will take a step back in the chronology of the project to discuss some important observations with regard to the application of SBD, which probably arise due to the particular characteristics of the field of deployment (caregivers and seniors in need of a stationary nursing facility).

3.1 Prototype and Evaluation Phase - Pilot Use

During the prototype and evaluation phase, it became evident that aside from further developments in the service robots and the design of the user interface, elaborations were also necessary with regards to the interaction concept, as well as the screen design for the respective control surfaces of the robots in use; these were often – as far as possible –carried out “on site.” While the general conception and the basic screen design for the control surfaces were prepared during the design phase, this phase focused on specialization and detailed changes. It quickly became apparent that the work took on the characteristics of rapid prototyping during the pilot phases. Johnson et al. had addressed the importance of rapid prototyping within the context of using SBD early on [10].

Two examples from the case study here should confirm the importance of a systematic combination and/or integration of rapid prototyping with SBD. At the same time, they cast a helpful light on a problem related to SBD in a brief discussion following the examples. The examples concern two particular scenarios that were tested within the context of the pilot applications: The beverage scenario (conducted by a service robot provided with a manipulator including a three-finger gripper) and the transportation scenario (conducted by a less sophisticated service robot, a revised automated guided vehicle).

The beverage scenario refers to the typical tasks at stations intended to manage the residents’ beverage supply, which in the case study were to be transferred by a service robot. Elderly seniors frequently tend to drink too little. Therefore, providing residents with a sufficient supply of fluids represents a crucial task in nursing facilities, and caregivers must make particular efforts to ensure that certain residents have enough to drink. In the case study, a service robot independently filled a glass at a beverage station, then offered it to the seniors in common rooms. The robot was to acquire the desired quantity of fluid, automatically document it, then add up fluids consumed by each inhabitant. Caregivers can thus quickly establish an overview of the conditions of the residents, and intervene if necessary. This way, at the end of their shift, caregivers only need to examine how much each resident has drunk, and then - if necessary - make their own, additional offers.

Within the context of the beverage scenario, it turned out that several of the residents in the common room did not notice the service robots because of how quietly they moved from place to place, so that the seniors were at times startled when a robot offered them something to drink. This undesired effect could be repaired on site by programming and activating an additional function which consisted of the robot announcing itself when it “entered” the room with simple phrases such as “Good Morning,” “Hi, it’s me again,” etc. Of course, this effect was difficult to recognize in the SBD’s visual aides, and accordingly was nearly impossible to predict and/or implement before the pilot study.

The second scenario that serves as an example of the problematic aspects of SBD is concerned with the transportation operations commonly used in nursing facilities. In nursing facilities such as senior homes, there are many transportation needs. From dirty laundry to meals to medication, heavy loads must be carried from A to B on a daily basis, often over long distances. Frequently, these tasks are carried out by experienced caregivers. The transportation scenario was developed in order to relieve these caregivers of this cumbersome routine and thus create more free time for care-giving activities. A driverless transport system could accomplish these tasks independently. Both regular transportation services as well as unique transportation tasks can be delegated to a driverless transport vehicle. The removal of dirty laundry and delivery of fresh laundry, for example, is a routine transportation activity that occurs daily, or several times daily. In addition, however, meal trays, beverage crates, mail, or medications could also be delivered by such a system from a central office to individual stations or floors, and/or collected from these stations. These tasks are generally perceived to be time-consuming and burdensome, as they prevent caregivers from spending more time on their key responsibilities to the residents.

This second example brings up a core element of the SBD, i.e. the visualization of the planned operation on the basis of drawn sketches. During the transportation scenario – which was adjusted several times between user and developer before the development and first pilot run, just as the beverage scenario was – it turned out that the containers for the dirty laundry presented a substantial stress to caregivers, since the opening of the container was too high. Laundry bags may contain wet clothing and can weigh up to 15 kg, which means that depending on their height, caregivers may have to lift this heavy load up to their chest in order to deposit it into the container. As was later discovered, an early sketch showing the revised automated guided vehicle with a laundry container was used for the scenario adjustment. For basic adjustment, this was completely sufficient.

With regards to the size of the container, the caregivers presumably regarded it symbolically, and did not note that the container was too small for practical use, nor indicate how big it could or – better yet – should be. For their part, the developers tacitly and naturally assumed that the container, in order to be functional, must be larger. Although in the long run the development of the transportation scenario was oriented by the rough guidelines of the scenario, in the end it obviously came to an addition of two opposing “deviations”: During the design phase, the caregivers did not “look too carefully” at the size of the container in the drawings (Fig. 1(a)), and the actual container was (obviously) larger in its execution than it appeared in the sketches (Fig. 1(b)) – too large:

Fig. 1.
figure 1

(a) and (b) The picture on the left shows the sketch of the laundry transportation scenario used in the scenario adjustment, and on the right the dirty laundry containers which were used in the pilot run. Both pictures are accurate sketches of the original drawing or photograph, made by Annika Metze following the authors’ instructions. The sketches were made to ensure the highest anonymity of the involved persons, firms, and organizations.

Full size image

As is made clear by the example, the figures used in SBD are not “merely” designs with a symbolic character, but representations of a prospective reality that should be taken seriously [11]. If this fact is not considered, any desired positive effect resulting from an adjustment of planned operations before the development work actually begins disappears all at once. The “problem” of the laundry container could obviously not be solved quickly through the use of rapid prototyping (a procedure that derives from software development [10]), and had to be delayed to the next pilot run, as a container with new dimensions had to be produced.

Apart from the obviously important evaluation of the scenarios, which inhere in the procedure of SBD and must occur as early as possible within the pilot tests [8: 371f], these examples also point to another important factor: SBD was developed in the context of software development, and was initially applied and discussed only within this field. The examples reveal the limitations of and improvements necessary to the procedure in different regards: Firstly, it was clear that when using SBD for the development of complex robots designed for complex social environments, early pilot studies are particularly important, and also that SBD would be much more efficient if rapid prototyping formed an integral component. Moreover, the transfer of the procedure to the development of robots (in contrast to software) makes it much more susceptible to unforeseeable effects. Reversing the conclusion, this means that in such test scenarios rapid prototyping becomes all the more important (as far as possible), but also that – precisely because rapid prototyping is much more difficult to apply given the materiality of equipment development – considerably greater attention would have to be given to the mode of representation in the scenarios [11].

3.2 Generating Scenarios - the Design Phases

Two field-specific aspects that were noticeable during the design phase are briefly discussed below. It was apparent from the survey of the operational procedures that caregivers remained wedded to the procedures provided by the documentation software already in use at the facility. This tendency was revealed particularly clearly in situations in which the information and interaction scenarios with the user interface design were concerned. In the questionnaire on suggestions for improvement, the (on paper) theoretically more complex and intuitive operation of the robots and/or documentation (e.g. the quantity of fluids consumed in the beverage scenario) could hardly be determined. This was because it was nearly impossible for caregivers to deviate from the documentation routines of the EDP software used in the facility, even though this represented a substantial improvement from the viewpoint of its usability. The tenacity of a work routine and the deeply-embedded nature of EDP systems in such routines is evident from this, and may make improvements impossible. The question thus arises to what extent relying too much on user interface in an efficiency-increasing innovation may even prove an obstacle, if the imaginative power of the users is restricted by the “habit of practice.”

A further aspect related specifically to the field of providing care is related to the seniors’ ability to integrate. Different factors come in to play here, which, depending upon their field of deployment, can vary greatly. In the case study the field of application and accordingly the inclusion of user groups were restricted to stationary nursing facilities. The senior citizens at such facilities are often very close to death, which usually leads to a general lack of interest in future developments [12, 13].

Moreover, it seems justified to raise the question as to how the scenarios concern changes that exceed the imaginative power of this particular group of people, and consequently makes feedback regarding the planned employment of service robotics difficult if not impossible. Despite repeated interviews with a large number of residents at the nursing facility, the responses received from this user group were scant. Thus the question arises to what extent SBD is either too concrete or not concrete enough. On the other hand, these findings may under no circumstance be applied to seniors generally, since – as was already mentioned – the inhabitants in need of care at a stationary facility form a special “sub-group” [13].

A presumably more trivial circumstance – yet not insignificant for the iterative application of SBD – which puts the practicality of this procedure for this particular user group in doubt, is the fact that the group’s mortality rate is very high, so that even before the conclusion of the design phase, and shortly before the beginning of the first pilot and evaluation phase, approximately half of the seniors involved in the coordination process and the generation of scenario had passed away.

4 Summary

In summary, the fundamental precept of SBD consists in aiding usually interdisciplinary product development teams and other stakeholders to imagine themselves in the position of the target group, use context, and product ideas via scenarios and personas. The increasingly specific nature of the phases during the design process afford a needs-based technical development, thus providing a good basis for participatory technical development. Moreover, an iterative procedure is supported via increasingly concrete and detailed scenarios, which provides sufficient freedom for experimentation in problem-solving and design, while also ensuring continuous workflow management that aids technological advancement. In consideration of the difficulties that arose during the use of SBD, the following conclusions for future applications of this method can be drawn:

Ad (3.1) With regards to scenario generation, their clarity should continually increase, so that the last version of the co-ordinated scenarios has achieved a very high level of detail; moreover pilot runs should be carried out as early as possible, in order to single out aspects that do not “graphically present themselves” as soon as possible.

Ad (3.2) In some cases it can be quite sensible to ignore user feedback, above all if the planned development represents an “obviously” better solution than the system currently in use; regarding the integration of certain user groups two things should be considered: Does the technology being developed lie beyond the intellectual horizon of this particular user group? Is the affected user group sufficiently motivated to aid in developing the technology?