2015 / improving drone use in search and rescue missions

Search and rescue

The problem (opportunity)

Drones have an increasing presence in search-and-rescue (SAR) events.

However, their use is haphazard, because field commanders have no direct visualization of where the drones are or what they are recording.

Rather, that information reaches them indirectly via radio from the drone operators out on scene.

 

The idea

Provide a system for first responders in SAR efforts to locate, direct, and monitor the feeds of different drones being operated on scene.

My role

I led the design of the system’s UX and UI. The focus was on needs identification, requirements generation, human-factors considerations, wireframing, and evaluation.

 

The approach

My team followed the typical user-centered design process shown here. It was a multi-year effort divided roughly into two stages: research and iterative design.

End users were involved throughout the process, providing input through interviews, workshops, participatory design sessions, and usability tests.

 

The research stage

The research stage began with an analysis of the SAR domain. We reviewed previous projects and research, studied existing systems in the area, talked with experts in the field, and had a workshop with SAR stakeholders.

We also used a SAR operations manual to create a mind map showing the interactions between different roles in SAR efforts.

The result was a set of user requirements for the system interface.

 

The design stage

Design proceeded over several iterations separated by workshops with users. It produced:

  • Usage scenarios (to focus the design efforts)

  • Wireframes (created in PowerPoint for easier collaboration with remote teams, and easier transfer to Word for final delivery)

  • Mockups (also PowerPoint)

  • Storyboards (PowerPoint)

  • Paper prototypes (…paper)

  • Working prototypes (built in C# by front-end developers on the team)

Challenges, strategies, and lessons

The companies handled this by arranging a number of meetings throughout the year. However, the different groups still operated within their own silos. One consequence is that early in the project, we discovered that the actual implementation of the system interface had diverged from my team’s designs. That required some extra effort to get us aligned, which was a valuable demonstration of the need to set up good communication channels in any distributed project team.

The project team included a dozen different partners (a mix of academic, corporate, SME, and research organizations) scattered across Europe, making coordination difficult. The situation was complicated in that the partners all had different work models and short-term goals.

We had to be both strategic and opportunistic with our user testing and research. On the one hand, we had to be ready to gather input whenever the chance presented itself. On the other, we had to look ahead for events (e.g., product demonstrations, first-responder training exercises) that would give us access to end users. We also had to work at extending our professional networks to get access to the right people.

SAR events occurred infrequently and irregularly, so observing them and testing solutions in the wild was unlikely.