Changes for page f. Test CFT3: Two Detailed Use Cases

Summary

• Page properties (1 modified, 0 added, 0 removed)

Details

Page properties

Content

...	...	@@ -35,16 +35,42 @@
35	35
36	36	Across the three sessions, participants expressed strong interest in the potential of both technologies, while also identifying critical usability and integration challenges.
37	37
38		-In the **first session** (Use Case 2), participants emphasized the importance of minimal setup time, discreet personal alerts, and role-based interfaces. Firefighters preferred default configurations and automation, while USAR personnel were more open to detailed monitoring. The traffic-light status concept and a two-stage escalation model for critical alerts were well received, balancing the need for timely warnings with human oversight. Participants also supported the idea of a dedicated tech or medic role to manage sensor readiness and monitoring.
	38	+**Use Case 1 (Autonomous indoor drones):**
39	39
40		-In the **second and third sessions** (Use Case 1), feedback centered on the need for rapid drone deployment, minimal interference with human responders, and reliable victim detection. First responders highlighted the importance of parallel deployment protocols and geofencing to avoid human-drone conflicts. Drone pilots emphasized the value of having dedicated operators and analysts, and supported the integration of friend-or-foe identification to improve AI recognition. Trust in the system was closely tied to familiarity with the operator and the ability to override autonomy when needed.
	40	+* Feedback centered on the need for **rapid drone deployment**, **minimal interference with human responders**, and **reliable victim detection**. First responders highlighted the importance of **parallel deployment protocols** and **geofencing** to avoid human-drone conflicts. Drone pilots emphasized the value of having **dedicated operators and analysts**, and supported the integration of **friend-or-foe identification** to improve AI recognition.
	41	+* Participants agreed that drones are a valuable **additional tool**, but (currently) not a replacement for dogs or human responders. Deployment timing depends on the situation: in urgent cases, responders may enter without waiting for a drone; in international USAR missions, there may be more time to prepare and deploy drones.
	42	+* Regulations is also something to take into consideration—drones are not allowed to fly near personnel, requiring coordination and certification.
	43	+* Participants noted that **drone teams are often separate from firefighting teams** and may not fit into standard vehicle deployments. In USAR, drone operation could be an **additional role** for technical search specialists. There was consensus that drones should **continue scanning after detecting a victim**, unless they can provide direct aid.
	44	+* Drone pilots highlighted technical preferences, such as combining **RGB and LIDAR feeds**, and noted that **indoor noise and sensor interference** are real concerns.
	45	+* Trust in the drone team varied, especially among participants unfamiliar with previous CFTs or without experience with these technologies in the field. Some responders were initially skeptical but acknowledged that **standard operating procedures (SOPs)** could help integrate drone teams more effectively.
	46	+* Participants also emphasized the need for **flexible information filtering**, allowing HQ to suppress irrelevant data and team leaders to focus on their operational area.
41	41
	48	+**Use Case 2 (Physiological and environmental sensors):**
	49	+
	50	+* Participants emphasized the importance of **minimal setup time**, especially for firefighters who need to deploy immediately. USAR personnel, operating in longer shifts, were more tolerant of a 10–15 minute setup window.
	51	+* There was strong support for **default configurations**, **discreet personal alerts**, and **role-based interfaces**. Firefighters preferred simple, glanceable indicators (e.g., traffic-light status), while USAR medics wanted access to more detailed data.
	52	+* Participants stressed that **not everyone needs to see everything**—information should be filtered based on role and task. For example, a smoke director or safety officer might monitor vitals instead of the team leader. The system should provide **yes/no answers** to task-relevant questions rather than raw data.
	53	+* There was consensus that **team leaders must retain control**, including the ability to mute alerts when needed to maintain situational awareness.
	54	+* Views on escalation varied: some participants preferred **automatic escalation to HQ**, while others particpants favored **team leader confirmation first**.
	55	+* Participants also supported the idea of a **dedicated tech or medic role** to manage sensor readiness and monitoring.
	56	+* The system was seen as a way to **increase resilience**, but participants warned against over-reliance or information overload.
	57	+
42	42	= 4. Discussion =
43	43
44		-The feedback underscores a central theme: technology must adapt to the tempo and structure of emergency response, not the other way around. Both systems were seen as valuable additions, but only if they respect the cognitive and operational constraints of their users. For drones, this means fast, autonomous reconnaissance that complements rather than delays human action. For sensors, it means providing actionable insights without overwhelming users or requiring excessive configuration.
	60	+The evaluation sessions highlighted the importance of aligning technological innovation with the operational logic and tempo of emergency response teams. Rather than focusing solely on functionality, participants repeatedly emphasized the need for systems to respect the **division of roles**, (**national) protocols**, and **mission-specific constraints**.
45	45
46		-Trust emerged as a critical factor in both cases. For drones, trust was built through consistent team assignments and the ability to intervene in autonomous behavior. For sensors, trust depended on discreet, accurate alerts and the assurance that human judgment remained central. The feedback also highlighted the importance of role clarity—who monitors what, when, and how—and the need for flexible system configurations to match different team structures and national protocols.
	62	+One key insight was the **diversity of expectations across countries and roles**. For example, Dutch and Polish participants had different views on escalation authority—some preferring centralized confirmation, others favoring automatic escalation. Similarly, firefighters and USAR personnel differed in their tolerance for setup time and information density. These differences underscore that **designing a solution that satisfies everyone is inherently difficult**. Different roles (Firefighters, USAR teams, medics, drone pilots, and team leaders) each brought distinct expectations shaped by their mission profiles, team sizes, and regulatory environments.
47	47
	64	+Another recurring theme was the **importance of trust—not just in the technology, but in the people operating it**. For drones, this meant that responders were more likely to accept the system if they had worked with the same drone operator before, because when first responders know the operator’s style and competence, they are more likely to trust the drone’s data and integrate it into their decision-making without hesitation. For sensors, trust was tied to the system’s ability to deliver relevant alerts without overwhelming users or bypassing human judgment, because a subtle vibration or visual cue, paired with a clear explanation visible to the team leader or medic, was seen as more trustworthy. In both cases, participants valued **human-in-the-loop designs** that preserved decision-making authority while leveraging automation for speed and coverage.
	65	+
	66	+The sessions also revealed subtle but important tensions: between **autonomy and oversight**, **data richness and cognitive load**, and **technical capability and field practicality**. For example, while drone pilots advocated for layered sensor views and AI-enhanced detection, responders were more concerned with whether the drone could be deployed quickly and without disrupting operations. Similarly, while medics appreciated detailed vitals, team leaders wanted only the most essential alerts—preferably in a format that could be understood at a glance, even in low-light or high-stress conditions.
	67	+
48	48	= 5. Conclusions =
49	49
50		-Stakeholders view autonomous drones and health sensor systems as promising tools to enhance safety, speed, and situational awareness in emergency response. However, their success hinges on thoughtful integration into existing workflows, minimal disruption to frontline operations, and clear human oversight. Design priorities should include rapid deployment, intuitive interfaces, role-based alerting, and mechanisms that reinforce trust and coordination. By aligning system behavior with user expectations and operational realities, these technologies can become trusted assets in high-stakes environments.
	70	+The stakeholder evaluations confirmed that both the autonomous drone and health sensor systems have strong potential to enhance emergency response—but only if they are **deeply embedded in the operational culture** of the teams that use them.
	71	+
	72	+For the **sensor system**, success depends on delivering **relevant, role-specific insights** with minimal friction. Systems must be **plug-and-play**, with clear escalation logic and the ability to adapt to different team structures. The value lies not in showing more data, but in showing the **right data to the right person at the right time**.
	73	+
	74	+For the **drone system**, the challenge is to balance **technical sophistication with field usability**. Drones must be fast to deploy, easy to coordinate with human teams, and capable of operating independently without becoming a burden. Their integration into standard operating procedures—and the trust placed in their operators—will be critical to their acceptance.
	75	+
	76	+Ultimately, both systems must be designed not just for functionality, but for **fit**: fit with the mission, the team, the environment, and the moment. When that fit is achieved, these technologies can move from being experimental tools to **trusted tools **in the field.