A User Journey: Development of a Drone-Based Medication Delivery – Meeting Developers and Co-Developers Expectations

1. Introduction

While demographic trends are leading to an increase in the need for care throughout Germany, rural regions are already more affected than others. In addition, factors such as decreasing staff shortages in the healthcare sector and rural exodus are having an unfavorable impact on the situation, especially under crisis or pandemic challenges, such as COVID 19 [1]. The need for new logistical delivery routes became clear and delivery drones for medications were listed as the most frequently mentioned application in the healthcare sector [1]. Despite the benefits of drones in healthcare, lack of user´s skills and competence as well as negative perception of drones affect the success in the introduction of such technologies [1,2,3]. Thus, we designed a study - the pharmacy-drone-study (Apotheken-Drohnen-App; ADApp) - that aimed to investigate factors of user acceptance of a drone-based medication delivery in a co-creative user-centered design. The peculiarity of the ADApp study was that partners from economy, science and different social strata were equally involved and able to contribute their ideas and wishes on an equal footing, thus playing a key role in the development process. The study took place from February 2021 to January 2024 and represents the entire development process of the ADApp project, from the first prototypes of the app to the entire ordering and delivery process with app and drone over populated areas of Dessau (Germany). This process comprised four development steps, three under experimental and one under real conditions [4,5,6]. The ADApp study focused on the one hand on the iterative, participatory development of developers and co-developers using the methodic guidelines of co-creative design according to Farao et al. [7] and on the other hand on the derivation of practice-relevant orientation points for participatory technology development (app and drone). In this evidence-based approach, users are involved in the development of technologies at an early stage and their needs are prioritized [7,8]. An introduction without user involvement can therefore lead to the results being changed, which in turn can change and distort the defined objectives [7,9,10]. Since the users of the core group accompany the entire development process, it is all the more important to acquire a naive control group (called “ad-hoc” groups) for each development step in order to level expectations and learning effects of the core group [11]. By integrating an adhoc group for each development step, the assumptions of the core group are to be checked and, if necessary, made transferable to a broader population group.

After the first ADApp studies initially examined the factors that predicted the intention to use and looked at possible group differences in usability and usefulness between the core group and the adhoc groups [6], the quintessence’s of the technical work goals, improvements and achievements that emerged over the entire development process and which were described by the core group and the adhoc groups across all iterations will be described in conclusion in the present study (Study 1).

Secondly, the focus will be placed on the development journey of the co-developers (core group) across all development steps and the participatory collaboration with the developers will be considered. How did the core group participants become co-developers in the course of the project? How was participatory cooperation successful and what opportunities and obstacles were there along the way? The quintessences of participatory cooperation will be examined in more detail in the present study (Study 2).

2. Study 1

The focus of the monocentric ADApp study was the iterative, co-creative development of a pharmacy drone app with multiple measurement points. After the interaction between humans and drones in the delivery of medication and defibrillators had already been investigated in a previous scoping review [4] in order to identify research gaps, the next step was to identify problems, needs and requirements of users and outline concrete scenarios that were necessary for the implementation of a first demonstrator of the app [5]. Furthermore, factors that predicted the intention to use were determined and group differences between the core group and the adhoc groups with regard to the usability and usefulness of the process were considered [6]. What has not yet been discussed is the development of the technical maturity of the app and the resulting insights into the technical work objectives.

Therefore, study 1 of the present study, primarily refers to the technical development of the pharmacy drone app and is based on the Technology Readiness Level (TRL) to describe the maturity level of the app [12]. In TRL 2, the application was first described in the context of focus groups. In TRL 3 (iteration 1), the functionality was already demonstrated (initial feasibility in the laboratory). TRL 4 showed the test setup in the laboratory using a complex task (iteration 2). In TRL 5, the test setup was tested for the first time in the operational environment (iteration 3). In TRL 6, the app and drone were tested for the first time in a relevant environment with realistic complex problems (iteration 4). The TRL levels run along the iterations of the whole ADApp study.

The quintessence of the technical work objectives is presented in Study 1 on the basis of recurring core statements that were defined by the core group and the respective adhoc groups across all four iterations. The aim of these core statements is to derive practical orientation points for participatory technology development for future research and development projects. Thus, the present study 1 aimed at identifying superordinate categories (called “core statements”) over all four iteration loops within the ADApp study to generate general topics of the participatory technology processes.

A naive adhoc group was recruited for each of the four development steps in order to prevent possible bias effects due to response shifts caused by repeated interviews with the core group. This approach of using adhoc groups as control groups makes it possible to generalize the core statements determined in the development process [13].

2.1 Materials and Methods

2.1.1 Setting and Participants

After the first iteration loop (March/April 2022) initially tested the usability of the app (TRL3) and an initial app demonstrator was adapted according to user feedback, the second iteration loop (June/July 2022) was dedicated to the design of the prototype and its technical development and evaluation (TRL4). In the third iteration (October 2022), the entire process has already been tested under experimental conditions at the test site in Cochstedt, starting with registration, determining the delivery location, submitting a prescription and receiving the medication (TRL5). Finally, the fourth and last iteration step took place under real conditions in a populated area in Germany, Dessau (TRL6). For the first time, the entire ordering and delivery process, from the submission of the e-prescription to the delivery of the order by drone, could take place on sight over populated areas. The test subjects in the core and adhoc groups initiated an order by transmitting the electronic prescription via the ADApp to a fictitious patient apartment. After all data had been fully recorded and the delivery location confirmed, the drone could be loaded at the pharmacy and deliver the order. It was dropped from a height of around 10 m above the defined landing point.

Participants were selected as representatives of the potential users of the drone-based medication delivery service and the supply chain according to the role characteristics: physicians, nurses, pharmacists, and interested users, especially SARS-Cov2 infected-patients, and relatives of palliative care patients. All participants gave their written informed consent before inclusion in the study and were informed in detail about the aims and reasons for the study and the procedure in advance. The ADApp study was approved by the Ethics Committee of the Martin Luther University Halle-Wittenberg (protocol code 2021-069 and date of approval May 6, 2021).

2.1.2 Data Analyses

All iteration loops were audiotaped, transcribed and coded following the content analysis method from Elo and Kyngäs [14]. using deductive approach moving from specific to general [15]. Data Analyses were described in more detail in Fink et al. [6]. After all transcripts over all iterations were coded according this scheme, two researchers (IV, FF) summarized independently all coded categories used in Fink et al. [6] to inductive derived superordinate categories (called “core statements”) [16]. For this purpose, all categories were grouped under higher order headings to reduce the number of categories by classifying the before defined categories to more general categories. In case of disagreement between IK and FF, discussions were held between the two examiners until a consensus was reached.

2.2 Results

2.2.1 Participants

Data was collected from a total of 23 participants (age range 22-65 years, average age 41.76 ± 12.34 years; two pharmacists, two nurses, one general practitioner and one SARS-Cov2-infected patient) for the four iteration loops, which took place between March 2021 and September 2024. In order to level out biases such as existing learning effects or preconceived expectations of the core group, a naive adhoc group was recruited for each iteration step. In each of the first three adhoc groups, four subjects participated, with iteration one consisting of two SARS-Cov2-infected patients, one general practitioner and one nurse, iteration two and three consisting of three SARS-Cov2-infected patients and one nurse, and iteration four, where five SARS-Cov2-infected patients took part in the adhoc group. Although we tried to achieve a balance between the two groups, it was not always possible to distribute the core and adhoc groups equally.

2.2.2 Core Statements

In total eight superordinate categories (core statements) were formed and are listed in Table 1.

Users stated that automation processes simplify many things for them and prefer quick and easy use in order to avoid redundancies. For example, they stated that an automatic address suggestion when entering the zip code would be desirable. Automatic push notifications and the automatic opening of the camera when uploading e.g. an e-prescription were also suggestions from users. The users of the core group and the adhoc groups were also keen to minimize both the language control and the design. Only as much information as necessary should be used to guide and design the app so as not to overload it and avoid misleading users. Symbols should be limited to the essentials and texts should be formulated as briefly and concisely as possible. Furthermore, clear information is required that enables precise differentiation between the individual steps, such as differentiating between the delivery address and the billing address. Users also placed particular importance on functions that allowed for control and autonomy in order to take into account important safety-relevant factors, such as tracking the delivery by drone, previewing the successfully uploaded e-prescription and at the same time taking into account the autonomy of the user and thus leaving options open, such as the type and frequency of contact. Guidance through the individual steps within the app was also important to the test subjects in the core group and the adhoc groups. The guidance should be short, concise and easy to understand and a short tutorial video should be available for more complex processes. Users also preferred to scroll through the individual pages click by click rather than one-page scrolling. In the area of conceptualization, simple and precise language should be used. Here it was important to the users that no technical terms and no English terms were used. In addition, attention should generally be paid to barrier-free design and consistency between different steps. Visualizations should be intuitive and the guidance through the individual pages should be well structured and clearly delineated. For example, users wanted the mailbox to be clearly highlighted as soon as a new message arrived. Above all, there should always be a transparent approach, e. g. to the way in which information is provided and obtained, and all information should be openly accessible in order to create trust and acceptance.

2.3 Discussion

Study 1 aimed to generalize specific statements of a drone-based app development in such a way that they can also be applied to future participatory projects in order to generate technology-specific factors that are necessary for technology development. In total eight factors have been identified that can form the basis for successful app development for future research in this field. Automatization, minimization, differentiation, autonomy, conceptualization, transparency, and barrier-free design are identified as key factors for an app-based technology development and should be part of further studies to investigate its reaction to user acceptance measures. A former study within the ADApp project identified four main factors for user acceptance: 1) the duration to perform a task with the technology were negatively correlated with the usability; 2) usability and usefulness were the strongest predictor for the intention to use the technology; 3) skeptism and curiosity were also predictors for the intention to use; 4) increasing competence led to an increase of usability and the intention to use [6]. These main factors come along with the statements during think-aloud approach, it can therefore be assumed that the technology-specific factors of the core statements increase user acceptance if these criteria are met. In other words, these eight core statements are part of the usability, i.e. when these are met, usability increase.

2.3.1 Automation and User Convenience

Users emphasized the simplification of tasks through automation, indicating a preference for features such as automatic address suggestions and push notifications. This aligns with broader trends in user experience (UX) design, where automation is leveraged to reduce cognitive load and streamline user interactions [17]. By automating repetitive tasks, applications can enhance efficiency and user satisfaction [18]. For instance, automatic address suggestions based on zip codes and integration with mapping services for delivery location determination can significantly improve the user experience by minimizing manual input and potential errors.

2.3.2 Minimizing Redundancies and Simplifying Interaction

The preference for minimal language control and simplified design reflects a desire to avoid information overload. Users favor applications that provide only necessary information and use concise, clear text and essential symbols. This approach is consistent with the principles of minimalism in UX design, which advocate for eliminating unnecessary elements to focus on core functionalities [19]. A minimalist design helps prevent user frustration and enhances navigability, particularly for novice users [20].

2.3.3 Control and Autonomy

Users' emphasis on maintaining control and autonomy highlights the importance of trust and security in application design. Features such as tracking delivery by drone and previewing uploaded e-prescriptions allow users to monitor and verify critical steps, thereby enhancing their sense of control. This aligns with the findings of Constantine [21], who underscores the significance of user control in fostering trust and reliability in digital systems. Providing users with options regarding contact type and frequency also respects their autonomy and personal preferences, which is crucial for user satisfaction and long-term engagement. The basic human needs for autonomy, competence and connectedness [22] according to the Basic Psychological Need Theory (BPNT) [23], also influence the interaction of users with a system and create mediating variables between a technical product and the well-being of the users. This was also demonstrated in a former study in which increasing autonomy led to an increase in commitment, and increasing competence led to an increase in user motivation and, as a result of the bond created, an increase in the well-being of all users [6].

2.3.4 Guidance and Usability

The need for concise, easy-to-understand guidance through app processes is a recurring theme. Users value clear instructions and the availability of tutorial videos for complex tasks. This suggests that while users appreciate automation, they also require supportive elements to navigate the application effectively. Research by Lazar et al. [24] supports the use of multimedia tutorials to enhance learning and usability, particularly for complex or unfamiliar tasks. Additionally, the preference for click-by-click navigation over one-page scrolling suggests that users find discrete steps more manageable, which can be attributed to better cognitive segmentation and reduced task complexity [25].

2.3.5 Language and Accessibility

The insistence on simple, non-technical, and non-English terminology underscores the need for accessibility and inclusivity in design. Avoiding jargon ensures that the application is usable by a broader audience, including those with limited technical proficiency [26]. Furthermore, the emphasis on barrier-free design aligns with universal design principles that advocate for accessibility for all users, including those with disabilities [27]. Consistency in language and design across different steps further contributes to a seamless user experience, reducing the learning curve and potential confusion.

2.3.6 Transparency and Trust

Transparency in information provision and access is crucial for building user trust and acceptance. Users desire clear, openly accessible information regarding how their data is used and processed. This transparency is fundamental in mitigating privacy concerns and fostering a trustworthy relationship between the application and its users [28]. Highlighting new messages in the mailbox, for instance, exemplifies how clear visual cues can enhance transparency and user awareness, thereby improving the overall experience.

3. Study 2

During the whole ADApp project developers (software and drone developers) and co-developers (participants of core group) worked closely together within an iterative participatory research design to involve users (co-developers) at an early developing stage for prioritizes their needs [7]. However, little attention was paid to the perception of the collaboration between developers and co-developers so far. Thus, to determine how the developers and co-developers perceived the participatory collaboration over the entire duration of the project, what their expectations were and to what extent these were met, a final workshop took place. This is important to derive implementation recommendations for future projects in order to assess the impact of cooperation between developers and co-developers and to how it can be improved.

3.1 Materials and Methods

3.1.1 Setting and Participants

Two tandem groups, consisting of a developer and a co-developer, were created and used as a qualitative method within the framework of participatory research. The paired discussions among participants, serve as an innovative approach to fostering deeper engagement and more nuanced understanding of participant experiences, perspectives, and insights. This method is particularly beneficial in participatory research as it promotes active dialogue and reflexivity among participants, thereby enhancing the richness and reliability of the data collected. The decision to use tandem groups was guided by the need to create an interactive and dynamic environment where participants could freely exchange ideas and experiences. Traditional focus groups can sometimes inhibit individual expression due to the presence of dominant voices or groupthink dynamics. In contrast, tandem groups, by facilitating one-on-one interactions, allow for more balanced and in-depth discussions. This method aligns well with the principles of participatory research, which emphasize inclusivity, co-creation of knowledge, and empowerment of participants [29,30]. Each tandem group discussed various topics as listed in Table 2.

Three groups were formed, with one group consisting of two developers and one co-developer. An external role is assigned to the project coordinator, who was also involved in a tandem group and is identified separately in the anchor quotations. Due to the particular affinity of men for technology, it was unfortunately not possible for us to represent both genders equally.

After the tandem rounds, all questions were discussed again together in order to be able to respond to the comments of the other participants. All of the participants statements were audio-recorded and then transcribed and coded with the help of Maxqda software 2022. The most important statements for each set of questions are listed below, along with anchor quotations from fictitious personas that represent the respective groups [31]. A tabular overview of the personas used can be found in Table 3.

In the present study two, the use of personas as a qualitative method within the framework of participatory research was employed. Personas, fictional characters based on empirical data, serve as a powerful tool to encapsulate diverse participant experiences, needs, and behaviors. This method is particularly effective in participatory research and design thinking as it facilitates deeper engagement and understanding among stakeholders [31]. Table 3 shows an overview of the fictitious personas used for the developers and co-developers.

3.1.2 Data Analyses

The data analysis was carried out according to the content analysis method from Elo and Kyngäs [14]. Transcripts were analyzed according to Berelson's event sampling method and coded using deductive approach moving from specific to general [15]. The categories were formed along the guideline-based question complexes A – E (see Supplementary Materials S1) and coded for all transcripts using Maxqda software. Here, each utterance represents an event, whereby a complete sentence, a sentence fragment or a temporally (e.g. a pause of 2 seconds) or semantically (e.g. a change in content) separated speech sequence is defined as such. The analysis is then carried out using reference phrase analysis [32,33]. To validate the concept, randomly selected parts of the transcripts (20%) were coded by a second researcher (IK) familiar with the analyses and checked for matches. In case of discrepancies, discussions were held between the two reviewers until a consensus was reached. Cohen [34] was computed with MAXQDA for all variables. The interrater reliability was _K = 0.84, p < .001 with an almost strong agreement [35].

3.2 Results

3.2.1 Initial Motivation and Aims

The initial motivations of the developers and co-developers initially differed. The developers stated “(…) that nobody is really looking into the topic of transporting medication by drone. (...) or, above all, not to the end customer”. (Developer 1). To this end, particular attention was paid to the last mile: “(...) the main point of the whole thing is, of course, that the nurse suddenly has time to look after the patient again. If you assume that at the moment they drive from the patient to the doctor, pick up the prescription at the pharmacy, fill it and then return to the patient. And they have their one and a half hours or two and a half hours of care time per day, per patient (...) then the patient simply hasn't had any of it. (...) There's just a bit of an idea that you can really help there.” (Developer 1).

The developers of the pharmacy drone app further stated that “(…) the goal was that it would actually end up being a product that could be used.” (Coordinator) and implemented “(…) in a real environment.” (Developer 1), i.e. “(…) to implement this project in such a way that there really is a drone that can transport and deliver medicines.” (Developer 2) and the customer should be able to trigger the order in advance using the associated app. In addition, the system should also aim to be cost-effective, where “(…) it would be nice if we could get the whole thing to the point where it really beats the pill cab, and significantly so.” (Developer 2).

Moreover, the motivation to establish new supply structures in order to link app and drone logistics, which is linked to the pharmacies' merchandise management system and integrates the e-prescription, was very high from the outset.

The co-developers, i.e. the participants in the core group, gave very different reasons for their motivation. A general interest and the importance “(…) to be able to make a contribution.” (Co-Developer 2) to success were mentioned several times.

In addition, the desire was also expressed to be involved from the outset and to engage in exchange “(…) and also get into discussions with people who are interested themselves.” (Co-Developer 1).

However, in the course of the project the “(…) basic motivation has already dropped somewhat due to the external circumstances.” (Developer 2) such as to many regulatory hurdles, both on the part of the aviation authority and the Chamber of Pharmacists, which slowed down the processes. Nevertheless, the initiator and coordinator of the project said: “(…) for me as the initiator, motivation is of course at the top and it hasn't diminished so far. (...) and that hasn't changed either, so I'm still motivated.”

Despite these obstacles, “(…) you already know what the regulations are, how development takes time, where we stand. Internationally, just as it always goes hand in hand with bureaucracy here in Germany. There is also a great deal more knowledge involved in any case.” (Co-developer 1).

In addition to the increase of knowledge about some obstacles, another motivator was “(…) when the app develops further (…) and longer flights are possible with the drone.” (Developer 2).

Among the co-developers, the basic motivation has changed in the sense that a sense of belonging has developed over the course of the project and the test subjects wanted to actively “(…) see how things are going.” (Co-Developer 3).

The participants in the core group stated that the desire for belonging and meaning played an important role for them and that they wanted to “(…) contribute something meaningful.” (Co-Developer 3) to the success of the project and to “(…) simply contributing my opinion was my goal. (...) And you have the feeling that the feedback has also made a difference and is being incorporated.” (Co-Developer 3).

3.2.2 Perception of the Participatory Cooperation

Both the developers and the participants in the core group as co-developers found the participatory collaboration very enriching and successful. For developers “(…) the open exchange is also very, very important.” (Developer 1) whereas co-developers stated that “communicating face to face with the developers is basically the exciting thing about it. It was actually very enriching that it was set up like that.” (Co-Developer 1). Both parties felt heard and the co-developers were able to iteratively express their wishes and ideas, which were taken into account by the developers wherever possible. “(…) there were changes from one meeting to the next, some of which came from us with the ideas and that surprised me positively.” (Co-Developer 2). The sense of community and togetherness that arose from the participatory work was also described as positive. The participants in the core group reported that they were able to identify themselves as co-developers over the course of the project and felt equal to the developers.

Both groups noticed that the participatory collaboration led to suggestions for changes that might otherwise not have been considered and that contributed significantly to improving the app and the process, such as the operator determining the delivery location.” (…) I wanted to be involved because it's really interesting when you're involved and not just presented with a finished product.” (Co-Developer 3). Participatory processes are learning processes in which developers were “(…) surprised by the things that other people criticize. Of course there's also a justification, but I just didn't expect it and that's why it's positive overall.” (Developer 2). In addition, the co-developers noted that it would be nice if co-developers were given an insight into the developers' work from the outset. “(...) As a tester, it might be good to get a better insight into the developer's point of view to see whether your ideas are realizable or not.” (Co-Developer 2). The regular meetings in presence were also perceived as enriching, although it was unanimously reported that dual events in presence or digitally can vary depending on the situation. Another learning effect was the scientific setting of integrating control groups (adhoc groups) as a newly approach within the participatory process: “So I definitely think it was a good approach with the two separate groups, the core, the adhoc group, because you really had a good comparison. You also saw from the evaluations that the adhoc groups lasted longer, but that was all logical, they didn't know the app, looked at it for the first time and it was an interesting approach, which I think also gave us interesting results.” (Developer 3).

3.2.3 Experiences of the 4th Iteration - The Flights over Populated Areas in Dessau

The developers and co-developers were very satisfied with the 4th iteration, the flights over the populated area of the city of Dessau Roßlau (Germany). Both groups found the preparations, the review of the previous iterations and the final test flights with the linked app ordering process to be successful: “I thought it was a great concept, a bit like seeing what conditions you have to have there, how it works, how the goal setting works, that you don't have to do anything, it was also interesting to see. No, it actually informed me, as it should be, I would say.” (Co-Developer 1). Both groups reported that they found it very nice to receive a summary of all development steps and changes. This enabled them to track all the changes once again.

When asked in which contexts drone-based deliveries can still be implemented and what is needed for this, both groups agreed that “(…) it would make sense wherever you can fly effectively. This means that only densely populated areas, full of hospitals and airports, such as the Ruhr area, would be excluded and anything that somehow falls within the rural area would make sense.” (Developer 2). “(...) but of course also emergency medicine, a point that would make sense from my point of view.” (Developer 3). In addition to scheduled drug deliveries, the developers also see the use of emergency deliveries as useful, as well as the rapid transportation of laboratory and blood samples. It was also discussed whether threat-based medication deliveries could provide added value in palliative care. “(...) so SAPV, emergency interventions always, in any case, if you need something new somewhere, for example on a highway, very quickly at the scene of an accident.” (Co-Developer 1). “(...) and we are currently optimizing this, it has to be a certified delivery process and I think it will then be recognized by all chambers and authorities.” (Coordinator).

3.2.4 Optimization Suggestions

When asked what adjustments could still be made to the app and drone process, both groups responded that it should contain as much information as necessary and as little as possible as well as be self-explanatory throughout, so that it is quick and easy to use, even without having had any previous contact with it. However, the user-friendliness has so far been indicated by the co-developers as capable of improvement. One reason for that was the “(…) balancing act between user requirements on the one hand and which of these you implement and how and how do you manage this without overloading the product. That's a tough act to follow.” (Developer 2). Co-Developers would like to see better handling and ease of use as well as “(…) push notifications integrated into the normal operating system.” (Co-Developer 2. The developers see great potential above all in optimizing “(…) flight range, i.e., battery range.” (Dveloper 3) as well as “(…) safety-relevant changes.” (Developer 3) such as “(…) a camera in the drone to document the handover process.” (Developer 2)

3.2.5 Lessons Learned from the Project

Both the core group and the group of developers reported that they perceived the entire development process as more complex as they thought before: “(...) so it's incredibly small steps. Even small thoughts where you think, that's a quick improvement. (...) Everything is incredibly time-consuming, small steps, um the test subjects have a great idea and then it takes a really long time until it's started and implemented. (...) There is an incredible amount of work involved in all the adaptations. (...) but it's very, very time-consuming.” (Co-developer 3). This results implies the importance of the insight into each other´s work and understanding between developers and co-developers because it increase the mutual understanding: “We also learned a lot about medication, including how a pharmacy works. How they earn their money, etc. These are topics that we hadn't dealt with that much before, of course, but we realized that it's a very, very exciting market environment and something that could definitely have potential.” (Developer 1). Moreover, the developers have the opportunity to “(…) see it from a developer's point of view.” (Coordinator). Despite these insights “(…) the balancing act between the customer's wishes on the one hand and the simplest possible design of the app on the other particularly [was] exciting, so that you really have a product that can be used quickly, which really contains all the core functions without being overloaded.” (Developer 2).

3.3. Discussion

Study 2 aimed to determine the perceived participatory collaboration between developers (software and drone developers) and co-developers (participants of core group) from the beginning to the end of the ADApp project to generate participatory-specific factors for further implementations. The present study determined five factors of participatory collaboration: initial motivation, basic psychology needs (autonomy, competence, relatedness), iterative feedback, iterative review as well as technology-/user-specific factors.First, motivation is a driver for a sustained collaboration, scientific productivity as well as the inclusion of different perspectives. The initial motivations of the developers and co-developers of the drug delivery drone project illustrate the different drivers behind technological innovation and participatory research. The developers were primarily motivated by a desire to close existing research gaps and improve logistical efficiency, with a focus on the 'last mile' of drug delivery. These statements are also confirmed by the research of Eskandaripour et al. who have demonstrated the efficiency and environmental benefits of using drones for small deliveries such as medical products [36]. Among other things, the importance of accessibility to remote areas is mentioned, where drones can provide a solution for supplying remote, infrastructurally weak areas. The importance for rural areas is the research field of the investigations of the ADApp Project, too. In addition, drones enable significantly faster delivery of medicines, especially in urban areas with heavy traffic or rural regions that are difficult to access, as it is described here. Furthermore, a possible cost efficiency is discussed as well, as drones cause lower operating costs and do not require a driver compared to conventional pharmacy delivery services.

For example, potential time and cost savings also make it possible to reallocate staff resources to more patient-centered activities. This underlines the potential of technological innovations for healthcare. This view is in line with recent reports and research highlighting the potential benefits of healthcare automation in reducing the non-clinical workload of medical staff [37,38].The research-driven motivation of the developers, which aims to develop new solutions in healthcare logistics, is in line with Rogers' innovation diffusion theory, which states that new ideas and technologies often arise from recognized gaps or unmet needs [39].

However, while the motivation of developers was research-driven, the motivation of co-developers was primarily characterized by curiosity, the excitement of working with innovative technology and the desire to make a meaningful contribution to the success of the project. This is also in line with the findings of Deci and Ryan's self-determination theory [23] and fits with the results of the latest studies by Fink et al [6] in which the basic psychological needs for competence, autonomy and relatedness correlate positively with curiosity. These motivations reflect an intrinsic interest in new technologies and a participatory desire to be part of pioneering work. This suggest that participatory research should always be accompanied by non-participatory test subjects in order to rule out the effects of familiarity and involvement. At the same time, co-developers are important in order to determine and integrate the needs anew in each development step. Participatory design methods often use such motivations to encourage user engagement and gather diverse contributions [40].

Second, basic psychology needs such as competence and relatedness are important factors in feeling involved and feeling engaged especially when challenges arise [24]. Challenges over the course of projects might affect initial motivation and should be considered during the project of developers and co-developers. Within the ADApp project, the initial enthusiasm was weakened primarily by regulatory hurdles on the part of the developers. The difficulties in navigating the bureaucratic and regulatory landscape were a major demotivating factor for some developers, which is also described in the studies by Hiebert et al. 2020 [1] and Rejeb et al. 2021 [2] using the environmental TOE barriers. However, the improved knowledge and understanding of the regulatory environment helped to maintain a certain level of motivation among the developers (competence). Furthermore, relatedness plays an important role for improving and maintaining co-developer´s motivation. Moreover, they feel more engaged and connected to each other and the project with increasing duration of the project and effort put into the technology. This reflects the dynamic nature of motivation in participatory projects, where external challenges can both hinder and enhance engagement, depending on participants' learning and adaptation experiences [41].

There are some practical implications that can be derived from these two factors. Developers and co-developers should be aware of each other's motivation at the beginning and during the course of a project in order to be able to create common goals and visions for the project. This is the only way to ensure the focus and direction of the project is sustainable and long-term. Developers should therefore be aware of the needs-oriented motivation of the co-developers in order to align the technology with their basic psychological needs and integrate their requirements into the technology-supported research and development. Questions that should be asked: how can the technology be designed to meet the needs of users? It also shows the importance of basic psychological needs in motivating users to participate in participatory projects and should therefore not be ignored: how can the needs of users be integrated into the entire process in such a way that they feel autonomous, competent and involved? For example, co-developers felt engaged through relatedness and meaning. This imply the importance of incorporating their feedback in technologies because it gives them a feeling of being seen and taken seriously. Moreover, it implies that structures must be created that promote exchange among each other and with the developers. On the other hand, co-developers should be aware that developers are often motivated by knowledge and research gaps and also of economic interests. Developers want to have a technology that work in reality, what is only possible with users from reality, and work efficient. At the same time, these need-driven and research-driven motivations are interdependent, because without development and research gaps there would be no technical mission and without the motivation to want to contribute something, there would be no participative-collaborative users.

Third, iterative feedback is essential for participatory processes. The iterative nature of participatory design enabled the co-developers to continuously express their wishes and ideas, which led to a sense of community and mutual respect [10]. Both the developers and the co-developers found the participatory collaboration enriching and successful. This collaborative approach is consistent with the principles of participatory design, which emphasize co-design and iterative feedback to ensure that the final product meets users' needs and expectations [7,42]. This implies, that the integration of co-developers´ feedback from one meeting to the next is an important step to not only involve co-developers actively in the process but also that they feel integrated. On the other side, developers have changed points that they would never have noticed before because they have a different perspective. But also, co-developers have the possibility to see it from a developer´s perspective. Additionally, the ADApp project was not only a technical development project but also a scientific one. Both, developers and co-developers learn about scientific approach within participatory processes. For example, it turned out that the integration of a control group (adhoc group) was essential in order to be able to identify further weaknesses in the technology, which were no longer relevant due to the co-developers' familiarity with the technology [6].

Fourth, thorough preparation and iterative review of the development steps are important for transparency and continuous feedback in participatory projects. It is essential to receive summary of all developmental steps so that developers and co-developers can understand what needs to be changed and what has already changed. Moreover, it makes sense to increase complexity of technology and its context in order to be able to reflect reality more and more. One possible measurement for this is the Technology Readiness Level (TRL) which assess the maturity of a particular technology. Within this systematic metric a particular technology can classified according to nine levels from basic principles to laboratory environment to relevant environment to successful mission operations [12].

Fifth, participatory collaboration also depends on a successful implementation of the particular technology. The balance between user needs and the simplicity of the app design was a recurring theme. This underlines the challenge of integrating comprehensive functions while maintaining user-friendliness, an important aspect of user-centered design [43,44]. The importance of simplicity for user-friendliness is in line with usability research, which indicates that intuitive and user-friendly design are essential factors for the success of a product [17,44]. Simplicity and clarity in the user interface are crucial for a good user experience. Thus, to ensure participatory collaboration, the particular technology should go along with technology-specific factors (see study 1) and user-specific factors [6].

In conclusion, participatory approaches often require more communication, coordination processes and iterative feedback loops between the groups involved. This can make the process appear more complex, as described by the developer and co-developer groups, as more stakeholders are involved and their perspectives and requirements must be taken into account, making the development process more differentiated and comprehensive [45,46]. When different groups work together, especially in interdisciplinary or cross-sectoral teams, this can lead to a better understanding of the respective challenges, methods and goals, as experienced by our developers and co-developers. This advantage of participatory research projects not only has an impact on improving the technical components of the app, but also improves the relationship between the two groups in the long term [29,47] and can also facilitate acceptance and implementation, as potential conflicts can be identified and resolved at an early stage. However, it is also important to consider the challenges of such approaches, such as the increased coordination effort and the need to manage conflicts and power imbalances within the group [30].

4. Limitations

Studies 1 and 2 show, on the one hand, the technical quintessence of all development steps that were developed by the core group and the respective adhoc groups (study one) and, on the other hand, they shed light on the quintessence of participatory collaboration beyond the development process (study two).

There are some methodological limitations that must be taken into account when interpreting the present results.

In study two in particular, it is noticeable that the group of developers is made up exclusively of men, as is the group of co-developers, in which only one woman was represented. This can be attributed to the particular affinity for technology and interest in innovation of the men in our study. Moreover, correlational analyses of Fink et al. [6] showed that female participants are more anxious about technology than men while men are more interested in technology than women. Nevertheless, there is a basic tendency towards a clear effect, which is evident despite the unequal gender distribution.

Although the risk of "positive selection" cannot be completely ruled out, it is considered unlikely. This is due to the fact that the topic of drone-assisted drug delivery was largely unknown. The perspectives of participants who fundamentally reject technical systems in the care and supply sector were just as little represented as those of people who did not take part in the surveys for other reasons. Possible reasons for this could be a general reluctance to take on additional work due to a lack of time, high workload or other thematic priorities.

However, it can be stated that the results of the present studies have shown important aspects of the technical development as well as the participatory cooperation. Similarities to surveys for other target groups in the healthcare sector can also be seen here.

5. Conclusions

The project’s development journey illustrates the complexities and dynamics of participatory design in healthcare technology. Both studies contribute to a better understanding of essential factors that lead to successful participatory processes between developers and co-developers with the aim to increase usability and the intention to use. Study 1 identified eight technology-specific factors that go along with factors of user acceptance [6] and participatory collaboration (study 2). Usability, as predictor for the intention to use a technology, is a result of technology-specific factors that should be considered during technology development. Moreover, these technology-specific factors are essential for participatory collaboration, because without integrating these factors during iterative collaboration process, co-developers would not feel integrated into the developmental steps. This means, to ensure user-friendliness as well as participatory integration, technology-specific factors are necessary. In special, study 2 identified five factors of a participatory development process and the insights gained from this project can inform future participatory research and development efforts, emphasizing the importance of transparency of motivation, basic psychological needs in engagement, iterative feedback, and iterative review in achieving successful technological innovations.