A New Method for Structured Integration of User Needs in Two Health Technology Development Projects: Action Sheets

ABSTRACT

An early integration of users and stakeholders is needed for a successful innovation process. Nonetheless, the integration of users is often hard to realize – especially when dealing with persons with chronic diseases. In addition, patients or users in general often are not able to formulate the requirements in a technical manner. Therefore, even if user requirements are collected, it is not certain that the developers know or understand ‘what is really wanted’. To overcome these ‘gaps’, we have developed so-called Action Sheets (AS). This article presents the use of AS in two projects: the development of health technologies for people with cancer (INFOPAT) and dementia (QuartrBack). Depending on the project context, group sessions were conducted with different stakeholders to identify the needs of (potential) users. Within the INFOPAT project, ten focus groups were conducted with patients, physicians and other healthcare professionals. In QuartrBack stakeholders like e.g. care professionals, technical assistance organizations and citizens participated in two focus groups and three world cafés. Their requirements were then ‘fed’ into the technology development by the use of AS. AS appear to be a promising tool to make user needs based on social values more tangible and implementable into technology development processes. In addition, it shows up that four phases seem to be necessary for transferring identified user and stakeholder needs into AS, which can therefore be seen as essential to translate non-technically formulated requirements into technically feasible ones. The case study shows as lessons learned that despite the successful integration of user needs, context-sensitive adjustments are still necessary.

KEYWORDS:

• Health IT assessment
• user-centered design
• requirements engineering
• interprofessional cooperation
• interdisciplinarity
• technology development
• demand-orientation

Background

Considering the growing relevance of information and communication technologies (ICTs) in healthcare, it is very important to merge different ideas of how final ICT products should be designed in terms of technical aspects. Therefore, it is indispensable to take into consideration user needs from the very beginning and combine these aspects with technological know-how and knowledge of the contextual factors of the healthcare system.¹ Furthermore, high-quality requirements engineering is an essential part of efficient technology and software development.² For this reason, applications and devices for people with impairments have been increasingly designed with involvement of end-users (see inter alia.^3–5 and⁶) Recently “the benefits of user-led research or end users involved as co-researchers is gaining momentum“.^7–9 Nevertheless, researchers remain of the opinion that those affected by technology like citizens and the end-users are still too little involved in the development^10–12 or that the involvement takes place only in the validation phase of many technology development processes (cf.¹³) Another challenge is that needs or requirements named by future users often do not meet criteria and theoretical considerations of technology developers in general and IT specialists in particular, especially in terms of technical feasibility. Reasons for this are, on the one hand, a lack of anthropometric data or human models for the very heterogeneous target group of impaired or elderly people and, on the other hand, the lack of life experience and the gap in knowledge e.g. about gerontological aspects and specific user needs among many product developers. This shortcoming hinders the developers’ ability to put themselves in the position of the end-users, and prevents them from relating empathetically to their requirements.

To overcome this “design-reality-gap”,¹⁴ a large number of tried and tested approaches to integrating future users in innovation processes, such as “user involvement”,^15,16 “participatory design”,^17,18 “activity analysis”,¹⁹ “user- or human-centered design and development”^20,21 are already known. Besides, the concept of boundary objects,^22,23 in particular for user-oriented software development, is common currency. The authors state that “coordination mechanisms can become boundary objects that facilitate and stabilize cooperation between different social worlds, whose actors relate differently to, but cooperate through these”.²⁴

Moreover, scholars consider that reorganizing teamwork can help to break up established ways of communication or uniform thinking patterns.^23,25,26 In this context, functioning cooperative work between different actors is a core aspect of designing products that meet the needs of future users (see for example studies on Computer Supported Cooperative Work (CSCW).^27,28 However, integrating future users into the development process is time-consuming and not always easy to realize.²⁹ This is especially true when dealing with people with chronic diseases like dementia and cancer – the target groups of the two projects highlighted in this case study. Even if user opinions are collected, it is not sure that all persons involved in the development process know about or understand the resulting requirements. This might affect the uptake of newly developed solutions into care delivery because they cannot become embedded into care coordination and workflow design.³⁰

Objectives

To overcome this problem, Action Sheets were developed to serve as an instrument for merging agile working methods and user-centered design (UCD). General information on the form, the content and the structure of Action Sheets, as well as involved persons can be found elsewhere (see Kunz et al. (2016).³¹)

As Figure 1 shows Action Sheets can be built up of several parts covering the requirements that were named by future users. Category 1 might consist of quotations or summaries of the connected user requirements, a short and precise definition and – if feasible – sketches of the functionality that needs to be developed. The second category comprises more structured instruments to describe the requirements by using standardized methods like user story or acceptance criteria. Furthermore the (structural or technical) preconditions that need to be fulfilled in order to successfully realize the requirements summed up in a specific AS as well as the relevance for the overall development context can be part of this section. Category 3 describes the context in which the requirements in question need to be considered and therefore can consist of topics like factors that might jeopardize the realization of the AS content (Risks), uncertainties or contradictions occurring in the overall context of the innovation development, or activities that need to be done in a next step. The Miscellaneous-category offers space for additional potentially important input. Despite for the wide range of potential content of Action Sheets the extend of one AS should not exceed a limited space (e.g. one DinA4 page) in order to guarantee that every project member can use them in order to get quick and still comprehensive knowledge on the user requirements covered by it.

Figure 1. Example of action sheet content and the instruments’ integration in development projects

The core concept of this instrument is to illustrate how users will expect the standard product to be. Furthermore, Action Sheets are a kind of Communication Bridge between different methodological approaches. They help to streamline actions within an ongoing project and can serve as a commonly accepted working base for development projects. To highlight different characteristics and functionalities without giving too much attention to details is the central idea of Action Sheets. They are supposed to help provide a robust basis for collaboration and break traditional communication and agreement procedures. In addition, they give a better idea of the final product by systematically reorganizing and clarifying user requirements and technical feasibility.³¹

Thereby, Action Sheets combine a number of different, already existing approaches and try to overcome common challenges – see for example^32,33 – within a comprehensive method that offers an instrument for proper clarification of the tasks on the one hand. On the other hand, it also sets clear principles for interprofessional cooperation within the development process.

Against this background, the case study outlined in the present paper aims to answer two questions: How can Action Sheets be implemented in structured needs analysis, and what are the main strengths and weaknesses of this approach? To this end, the authors propose a reflection process based on an inductive comparison of two projects that used Action Sheets for their purposes. This process starts with a brief consideration of two-way structured user needs analysis.

Methods

Information technology for patient-centered healthcare (INFOPAT-PEPA)

The pilot project “Information technology for patient-centered healthcare” (INFOPAT) was initiated in the Rhine-Neckar region in Germany from 2012 to 2017. The aim of INFOPAT was to improve care across different healthcare settings, placing special emphasis on chronically ill patients. To reach this aim, a patient-controlled electronic health record (PEPA) was developed.^34,35 PEPA is a web portal that allows patients to access copies of their healthcare information (for example, physician’s letters, diagnostic findings, or radiological images and reports).^31,36,37 Furthermore, patients can share access rights to these documents with other persons such as attending physicians and other healthcare professionals, or relatives. Besides the patient portal through which patients can manage their PEPA, there is a professional portal allowing other persons – authorized by the patient – to access the PEPA content.³⁷

The INFOPAT-PEPA project addressed patients with gastrointestinal cancer – especially those with colorectal cancer – because this patient group faces a quite complex care situation with many contacts to different physicians (either in the in- or out-patient sector) and other healthcare professionals. Therefore, a PEPA would serve them as a vehicle to gain a better overview of their treatment related documents and information. The INFOPAT-PEPA project consists of two subprojects: a technical research and development project and an implementation project. The first subproject deals with the concept, design and implementation of the PEPA system’s architecture and its components as well as integration aspects, while the second one focuses on the evaluation of user requirements and the integration of PEPA into the care of cancer patients.

The use of action sheets

The perspective of future users was pivotal right from the beginning of the development process. Thus, social scientists built up an extensive requirements catalog including data on users’ opinions on how a personal electronic health record should be like. Therefore, different user integration methods were used, e.g., the organization of focus groups with different participants such as patients, physicians and other healthcare professionals.^34,35 All participants gave their written informed consent. The participants’ anonymity and confidentiality were ensured throughout the study. The transcripts of the conducted focus groups were analyzed by using a preliminary category system as search grid and qualitative content analysis according to Mayring.³⁸ Because of the disease burden, the patients integrated in the focus groups were not able to be included into the ongoing project for a longer period of time but gave their input only selectively.

The infrastructure and user interfaces of the future product were developed by the project team of the technical research and development project using the Scrum¹ approach. For the development of the PEPA platform, close cooperation between the two subprojects was mandatory.³⁹ However, reality showed that it was often difficult to reach consensus on important aspects of the future PEPA among the different experts (medical IT specialists and social scientists). Therefore, the social scientist and medical IT perspectives had to be combined in a manner agreed on by all persons involved. To this end, the members of the implementation project developed a set of 26 Action Sheets that were afterward discussed with the development team. This measure was aimed at aligning the content of the Action Sheets with all requirements – both in terms of technical feasibility and user needs.³¹

District-wide emergency chain for people with dementia (QuartrBack)

People suffering from dementia undergo multiple and significant behavioral changes as the disease progresses, among them disorientation, restlessness and agitation as well as a tendency to wander. Following a dementia diagnosis, many sufferers withdraw from their social environment: feelings of shame and fear caused by their cognitive and functional decline can lead to a reduction in autonomy, independence and engagement with society. For many people, the transition to an institutional care setting is unavoidable, particularly in the later stages of the disease. Against this background, the project “QuartrBack – District-wide intelligent emergency chains for people with dementia”, funded by the German Federal Ministry of Education and Research, addresses people in the (very) early to middle stages of dementia who are still living at home.² The overall aim of the project is to delay the transition to an institutional care setting and the associated loss of mobility, social participation and access to the accustomed living environment. To that end, “enabling structures” in the local environment of people with dementia can be created by combining technologies for tracking, monitoring, access control, and information storage with a system of voluntary and professional support workers. This social and technical support approach aims to involve the community including formal (caregivers) and informal (family, neighbors, volunteers) stakeholders in the development of and transition to an “intelligent emergency chain” supported by a so-called HelperApp. The technical support is based on innovative soft- and hardware components, such as a miniaturized GPS (Global Positioning system) tracker worn as a watch or trinket by the person with dementia. This provides a way to locate the user at any time by locating the device via satellite, compares current movement patterns with recorded patterns and correlates these with data from the care documentation (case histories) to detect significant deviations from habitual routes in combination with timing. All this data is sent and stored at the so-called ServiceCenterPflege (SCP) and processed using specific algorithms which recognize and evaluate support and emergency situations (e.g., the mentioned deviations from habitual routes) in order to initiate the most effective measure to avoid an emergency situation.

The use of action sheets

The project was designed to include potential future users (demand-oriented approach) in the early stages of the development of information and communication technologies. However, despite the potential advantages of this approach (see Chapter 1), its practical implementation proved to be challenging especially concerning the participation of people with dementia themselves. This is why at this early stage in the project, citizens as well as different stakeholders in the field of (in)formal care were asked for input to assess the needs of future users. To this end, the project organized several workshops in two study areas.³ Two of the workshops involved 56 citizens overall, acquired by random sample, who were invited to discuss the socio-technical system of QuartrBack in a world café setting. Two other workshops, held in a focus group format, included specific stakeholders like formal carers from social associations or institutions, representatives of the cities, the police or members of an already existing local alliance for people with dementia. An additional workshop was conducted with the members of the expert advisory board that accompanied the project. In all workshops, the participants were asked to discuss the technologies to be developed in the project and the design of the helper network from two different perspectives – that of the system’s user (person with dementia) and that of a helper in the helper network.⁴

The discussions were recorded and transcribed. The contents of these transcripts were then structured and categorized using the qualitative content analyses after Mayring³⁸ to identify, analyze and report patterns (themes). This analysis was neither derived from nor linked to a specific epistemological or theoretical position. The transcripts were read and reread by two of the authors. Individual and recurring themes (codes) were linked to the data using an inductive approach. Topic frequencies and coincidences were recorded and similarities, patterns and consistency of the topics were checked. This process was repeated until a consensus on the topics was reached. This resulted in a list of 128 user needs – one list addressed to the technology developers and one list of demands of the technologies themselves. To make these 128 identified user needs more readily accessible to the technology developers, they were then transferred into the Action Sheet format (following³¹) and included information such as title, origin, citing examples from the transcripts, as well as interdependencies with other needs. These Action Sheets were forwarded to the interdisciplinary project consortium and the technology developers, who were asked to evaluate the user needs from their particular professional viewpoints. In the process, the technology developers (n = 5) reduced the list of user needs drawn up by the workshop participants to 87 items by eliminating all user needs that were unfeasible for technical or data protection reasons or that did not fit with the remit of the project. However, the technology developers added six additional user needs in order to ensure robustness of the solution.⁵ Furthermore, user needs that were deemed non-technical were analyzed by a provider of ambulatory and in-house care services (consortium leader), and investigated for their practical relevance.

Compared phases of user integration in INFOPAT and QuartrBack

In the following section, the authors juxtapose the different phases of the two user integration approaches described above (see Table 1), pointing out similarities and differences between them and including some methodical reflections. For both projects, the entire process of identifying and integrating user needs into the software and technology development was continuously controlled and the research results were verified.

Table 1. Project phases of user requirement integration

	INFOPAT	QuartrBack
Phase I: Identification of user needs
Preparatory activities	Development of a semi- structured, pilot-tested interview guide, based on a literature review and expert discussions and used to conduct focus groups [interdisciplinary team without technology developers]	Literature review and analysis of the research findings of a pre-projecta, used as a basis for workshops [interdisciplinary team without technology developers]
Integration of users	Ten focus groups with a total of 47 participantsb [three with patients; four with physicians; three with other healthcare professionals]	Two focus groups with a total of 37 participants [stakeholders in care settings, police, technical assistance organization, etc.]; three world cafés with a total of 69 participants [two with invited citizens, one with a multidisciplinary group of experts]
Phase II: Evaluation of the named needs
Qualitative content analysis	Development and use of a preliminary category system as search grid and qualitative content analysis according to^Citation34 (based on theoretical considerations, expert discussions, and literature review) [interdisciplinary team without technology developers]	Development and use of a preliminary category system as search grid and qualitative content analysis according to^Citation34 (based on the project context, experiences from the pre-project [see footnote 1], and literature review)
Setting up of categories	The category system was adapted when new information was available that did not fit into the previous category system [interdisciplinary team without technology developers]	The category system was adapted when new information was available that did not fit into the previous category system [interdisciplinary team without technology developers]
Creation of the requirements catalog	Key findings were presented in categories, subcategories, and aspects; the final requirements catalog consisted of 245 aspects/user needs [interdisciplinary team]	Key findings were presented clustered into four central questions and 24 categories for the development process; the final requirements catalog consisted of 171 aspects/user needs [interdisciplinary team]
Phase III: Creation of the Action Sheets
Restructuring of the user needs	245 user needs from the requirements catalog were restructured and prioritized [interdisciplinary team without technology developers]
Translation into Action Sheets	Based on the central issues, a first set of 26 Action Sheets was developed, forming the basis for the ongoing interprofessional coordination process [interdisciplinary team]	Based on the user needs, a set of 128 Action Sheets was developed, forming the basis for interprofessional discussion [interdisciplinary project team without technology developers]
Division of the Action Sheets into technical and non- technical categories		The Action Sheets were divided into 51 non-technical Action Sheets (social innovation) and 81 + 6 technical Action Sheets (technical innovation) (further focus of this paper will be on the latter) [interdisciplinary team]
Phase IV: Further use of the Action Sheets
Prioritization of the Action Sheets according to the phases of development	Classification of the Action Sheets into three categories according to urgency (relevant for usability tests/relevant for feasibility study/relevant for routine use of PEPA) [interdisciplinary team]	Definition of a set of 9 Action Sheets as priority actions (“to do first”) which formed the basis of the prospective priority system. Action Sheets that could not be implemented within the project period or due to technical restrictions were excluded. [technology developers]

^aThe aim of the MOVEMENZ project “Mobile, self-determined living for people with dementia in the neighborhood” was to develop specifications for mobile technologies in order to provide the infrastructural preconditions and conceptual standards that allow people with dementia to move as freely as possible in their neighborhood according to their individual needs and requirements. This pre-project followed a demand-oriented technology development approach, analyzing the needs of potential users of technical support and considering the actors involved in the care process (dementia patients, relatives, professional caregivers, service providers, etc.) and in the neighborhood (storeowners etc.).

bDetailed information on the conducted focus groups and the participating users can be found in separate publications.(^30,31)

Table 1 shows that the two projects went through four almost identical phases in the development of Action Sheets based on the needs identified by the focus group and workshop participants. These four phases can therefore be regarded as essential steps in the integration of user needs into technology development processes using Action Sheets. Besides, there are analogies in the methods used in phases I, II, and IV, while the selection procedure in phase III differed slightly. In the course of the INFOPAT-PEPA project, all needs indicated by the involved users were considered, combined (if possible), and prioritized according to the urgency of implementation. In the QuartrBack project, 34 Action Sheets were sorted out due to non-feasibility (e.g., for reasons of limited project time and technical feasibility). Furthermore, in the two projects the prioritization category “urgency” was defined in different ways: “relevant for” and “to do first”. Moreover, in the INFOPAT-PEPA project, the translation of user needs into Action Sheets was preceded by a restructuring process. This step was not required in the QuartrBack project. This was due to the fact that the project not only aimed at technical but also at a social innovation by activating a so-called helper network (see the project description above). So, in contrast to the INFOPAT-PETA project the Action Sheets in QuartrBack were divided into two groups, social and technical ones.

Based on the insights gained from the comparison of the two approaches, the validity of the methods, plausible causes for the identified weak points, and lessons learned are discussed in the following chapter.

Lessons learned from working with action sheets

This paper is based on an analysis of two experiences from implementing the “Action Sheet” method in demand-based technology development processes. The examples illustrated here point to key aspects that may serve as starting points for further research on the structured integration of user requirements in technology development processes. In the following, we will discuss the experiences with Action Sheets and, based on this, draw some lessons learned.

Experiences with action sheets in INFOPAT

Members of the development and implementation project INFOPAT stated that it was easier for them to capture the ideas of the other parties involved by discussing the content of Action Sheets. Consensus could be reached more easily because different interpretations of user requirements were quickly identified within the interprofessional discussions. Moreover, Action Sheets provided a general direction for how to discuss all relevant factors. However, it took some time to develop the Action Sheets by resurveying the initial requirements catalog. Additional time was needed for personal consultations and meetings between members of the development and the implementation project required to coordinate the process. However, the development process was smoothed especially by re-discussing important aspects of the PEPA-concept.⁶ Thus, not only the PEPA as a technical output became clearer but also the underlying processes of implementation and the idea of how patients and physicians might use it within real life.

Experiences with action sheets in QuartrBack

Based on the experience of the QuartrBack project, the use of Action Sheets can be seen as a promising method for other projects aimed at translating non-technical and technical requirements of technology into a useful format for technology developers. The action sheets made it possible for the technology developers to convert the requirements, which often originate from everyday life or are formulated in a life-world context, into technical requirements much more easily. However, there are some remaining challenges and the approach should be further developed and adapted to different types of projects and their objectives. The challenges include the workload and time required to survey the needs, to analyze them carefully and to translate them into the Action Sheet format, which could be remedied by considering the time needed for this process already in the planning phase of the project. However, the authors are convinced that the time needed to understand user requirements must be included in the project duration. For only by involving, for example, patients with cancer or people with dementia is it possible to achieve meaningful results and to develop technologies that meet the needs and are therefore accepted. Here, funding bodies should think intensively about longer project durations. Another challenge is the process of “translating” non-technical needs into an Action Sheet, using selected quotations from participants to illustrate their wishes and needs of the technology. However, these were of little use to the technology developers without further explanation. This presented a dilemma: should the so-called user story (which is very helpful in developing relevant scenarios) be reformulated to also take account of the context of the quotations? However, this does not substantially contribute to a more detailed presentation of the actual demands without bearing the risk of introducing the “translator’s” own bias. The problem was exacerbated by the lack of meetings between technology developers and workshop participants.

Comparative findings

Summarizing the above arguments, it can be postulated that Action Sheets seem to be an effective tool for integrating user needs in different kinds of technology development projects. It has to be underlined though that Action Sheets – to our knowledge – were only used in those two cases and therefore our conclusions drawn from those two case studies need to be interpreted cautiously.

The main purpose of using Action Sheets is to make a new or existing development process more tangible and convertible. Nevertheless, the comparison between the two projects shows that context-sensitive adjustments are necessary to achieve this because the working method provides a rough guideline rather than a defined methodology. In the following, we will outline the lessons learned from comparing the two projects in order to support decisions on whether Action Sheets are suitable for other development projects. The lessons learned are subdivided into six categories: (1) organization of interdisciplinary cooperation, (2) resources, (3) content and structure of Action Sheets, (4) application type, (5) achievement of consensus, and (6) development process.

Organization of interdisciplinary cooperation

A crucial factor for successful implementation of Action Sheets is the underlying construct of cooperation. In general, persons from different departments or organizations and with heterogeneous expertise have to pull together within the development process. As the two examples show, it can be difficult to identify clear action steps and priorities for the development process from the initial requirements catalog. A lack of common language is a common problem in technology development projects. Therefore, a basic prerequisite for using this procedure is that all parties involved commit themselves to implement Action Sheets with all the associated effort, e.g. for ballot meetings or evaluation of different process steps. This requires a high degree of openness toward other disciplines and viewpoints, which is not always easy because of a lack of understanding of discipline-specific approaches. In the INFOPAT-PEPA case the social scientist working within the implementation project for example were not familiar with the Scrum working manner of the development team in the first place which made conversations about upcoming development steps quite difficult before AS were implemented. In order to overcome this lack of understanding it may be helpful to have a neutral person in the project that has expertise in different fields and acts as a moderator. Furthermore, this person could also be responsible for formulating common project goals and promoting them in a comprehensible manner.

The QuartrBack project shows that another challenge may arise if project partners live or work far away from each other. Even though modern information technology simplifies communication over long distances it can still be disadvantageous if personal meetings are not or only rarely possible.

Resources

When thinking about using Action Sheets for a certain project, one should keep in mind that this approach is resource consuming. In the two projects presented here, the implementation of Action Sheets took quite some time. This time effort can possibly be reduced in future development processes because the cornerstones of the technique have meanwhile been identified (see subchapter 2 “Objectives”). However, investing more time and effort can also have positive effects as it may lead to a more appropriate development. In both sample projects, Action Sheets were not used right from the beginning – if this had been the case, the process might have been less time-consuming.

In addition, human resources required for project meetings and for identifying, (re-) organizing and (re-)formulating user needs should also be considered.

However, when using the Action Sheet method right from the beginning and not in an already running process, it can be expected that the resources needed are not higher than those in other project management approaches.

Content and structure of action sheets

With regard to content and structure, the question arises of how detailed the information provided in the Action Sheets should be. While INFOPAT-PEPA used a very in-depth set of Action Sheets, QuartrBack rather concentrated on the quotations and kept the other categories more concise. Using quotations in the same way as in QuartrBack offers the advantage that biased presentations can be largely avoided. However, since it turned out that some of the quotations are not understandable for the developers, the user needs expressed therein were reformulated instead of using exact quotes from the focus groups.

Furthermore, it is important to decide which parts of the Action Sheets should be filled in in direct collaboration between those who determine user needs and those who put these requirements into practice. Used in this way, Action Sheets ensure a mutual understanding between the two groups, and help translate user needs into requirements in a continuous refinement process.

Application type

As already mentioned in Subsection 3.3.2, it seems appropriate to use the Action Sheet tool before the development process actually starts. While the INFOPAT-PEPA project developed and applied Action Sheets in an ongoing project, QuartrBack had the opportunity to work with Action Sheets from the outset. It should be mentioned that this difference in the application of the tool might compromise the comparability of the two projects.

Achievement of consensus

In both projects, it was not possible to achieve complete consensus on the way of including requirements into Action Sheets. However, this leads to the question of whether there is a need to overcome dissent or whether it is not a precious strength of the approach to take “all” requirements seriously into account: no requirement or stimulus of potential users should be disregarded by the project team. Only technical limitations or other restrictions should lead to the exclusion of an identified requirement.

An important aspect in this context is also the question how to involve future users more frequently into the development process. In both presented cases patients, citizens living with and without dementia and other stakeholders could only have been integrated selectively due to different reasons, such as burden of disease, time effort.

Development process

Generally, it is essential that the decision to use Action Sheets and the discussion about the type of application take place before the development process starts. Furthermore, the kickoff of the development process should be after reaching an agreement on the first set of Action Sheets between the team members responsible for clarifying user needs and the developers. Unfortunately, in many development projects only one part of the team – for example social scientists in the INFOPAT-PEPA case – get in contact with the potential future users via focus groups, interviews or the like. Especially in those cases where IT-developers do not take part in the survey uncovering requirements of patients, citizens or others it is really important to define how the user requirements can be integrated into the development process without distortion.

Therefore, depending on the particular context, a decision has to be made regarding the role of different players. In QuartrBack, for example, the development steps were prioritized by the developers based on Action Sheets. This might lead to deviating priorities compared to the users’ needs. In INFOPAT-PEPA, on the contrary, the split product owner role sometimes led to situations where it was not clear who had the final decision-making power. These two examples reveal that, so far, no way has been found to ensure completely transparent and democratic use of Action Sheets within an overall project consortium. Nevertheless, experiences from INFOPAT-PEPA, in particular, show that continued interprofessional dialog on the development status in sprint meetings contribute to the project’s success.

Implications for practice

Despite the expertise in Action Sheets gained in the two sample projects, the above mentioned challenges could not yet be solved. The experiences show that all persons involved in future projects based on Action Sheets should be asked for their opinion on which method should be adopted. Structured user evaluations during and after development projects will help minimize uncertainties and difficulties related to this new instrument and procedure.

Conclusions and outlook

User needs must be considered from the very beginning of the development process. However, it is not always obvious how to reconcile them with IT know-how and contextual knowledge of the health care system. Action Sheets seem to be an effective tool for different types of projects. The general aim of using Action Sheets is to make a planned or existing development process more tangible, understandable and convertible.

However, despite the experiences from the two-way user needs analyses and development processes, the question remains whether feedback rounds among (potential) users and other stakeholders in the development process are an essential prerequisite for high acceptance and, consequently, high market demand. Besides, it seems advisable to ask all persons involved for their opinion on which Action Sheet method should be adopted, e.g. by conducting a structured user evaluation during and after the development project. Furthermore, there is still no format for the transparent use and further development of the Action Sheets throughout the entire process. In addition, the findings from the two projects, at least from the QuartrBack-project, leave open whether the user needs can be prioritized by the technology developers alone or whether this should be done by an interdisciplinary team with comprehensive knowledge also of the socio-technical context. Moreover, further research on Action Sheets might include an evaluation of the actual integration of user needs in the final technical solution.

Nevertheless, it can be outlined that the Action Sheet method is transferable and adaptable to different development processes and their products/objectives, irrespective of the application type selected. Both types, application in the running process or from the beginning, can be justified depending on the context. However, some adjustments are necessary. In particular, greater account must be taken of the required time resources. In the authors’ view, it might be possible to shorten the period of demand analysis in order to streamline the process, while achieving comparable results. Finally, it can be stated that the use of Action Sheet can save time in the development process as it allows identifying and presenting user needs in a more structured way. Therefore, Action Sheets seem to be a very good starting point in technology development processes.

Still, a number of questions remains unanswered so far: How do team members evaluate the use of Action Sheets? Were they useful from their perspective and why (or why not)? Does this approach reduce the number of errors, developer effort (working hours), project costs and implementation time? Does the method provide higher quality results? How do respondents feel that using action sheets improves communication, meetings, number of conflicts or error correction? Therefore, in order to systematically evaluate Action Sheets, interviews would have to be conducted with all managers, business analytics, Scrum masters, team members, product owners and users who participated in the presented projects.

Conflicts of interest

The authors declare no conflict of interest. The funders had no role in the design of the study; in the collection, analyses, or interpretation of data; in the writing of the manuscript, or in the decision to publish the results.

Protection of human subjects

The studies were performed in compliance with the World Medical Association Declaration of Helsinki on Ethical Principles for Medical Research Involving Human Subjects, and were reviewed by the Ethics Committee at the German Society for Care Science and the Ethics Committee of the University Hospital Heidelberg (S-497-2012).

Acknowledgments

The authors wish to thank the entire consortia of the projects INFOPAT and QuartrBack in which the results presented here were gathered. At QuartrBack, special thanks are due to Johannes Hirsch for his dedicated commitment. Above all, we would like to thank the citizens, patients and other participants for their commitment in the projects. Without them, transdisciplinary research would not have been possible; everyone has therefore made a decisive contribution to the success of the project to date. Thanks also go to the German Federal Ministry of Education and Research (BMBF) for promoting our research and innovation.

Additional information

Funding

This work was supported by the German Federal Ministry of Education and Research, grant numbers [01KQ1003B (INFOPAT)] and [16SV7611 (QuartrBack)].

Notes

¹ Scrum is used for agile development projects and systemizes the development process by applying special roles and methods. So called sprint phases subdivide the whole development process into short periods that should end up with a functioning intermediate product. The whole process is monitored and discussed closely within different periodical meetings such as sprint planning or review.

² We did not collect or use existing data on cognitive status (e.g. the MMSE or similar), because the cognitive status was not decisive for participation.in the project (QuartrBack). All people with dementia should be involved as long as they could give their informed consent. Due to the effects of dementia, in the end only people in the early to middle stages were interested in participating in the project. However, this selection was not a methodological limitation of the people involved.

³ While no people with dementia explicitly participated in the workshops, the project did include people with mild to moderate dementia as well as their informal caregivers in two ways: 1) through the participation of a person with dementia and his wife in an expert advisory board, acting as representatives of the targeted user group. 2) Through the involvement of a small group of people with dementia as well as their informal caregivers in the field tests carried out toward the end of the project period. People with dementia were involved in this later phase of the project with an already mature technology prototype in order to avoid frustrations caused by technical failures etc. However, interviews were conducted with people living with dementia before and after the test phase with regard to the requirements of the technology and usability (user design).

⁴ The four leading questions were:

1. What basic conditions must be fulfilled for me to become a helper?

2. How must the ideal helper network be designed for me as a potential user?

3 What do I expect from the technology as a potential user? What do I fear?

4 What possibilities must the helper app offer me (as a helper)?

⁵ These included ensuring general functionality (1), cleanability (2) ease of use of the device (“easy to carry”) (3), usage of the correct data (4), including an energy-saving mode for indoors (5) and planning extrinsic and intrinsic motivation mechanisms (6).

⁶ For more details, see Kunz et al. (2016).³¹