Responder Maps: Week 6

Accomplishments

In preparation for more formal user interviews, I’ve restructured the context scenario depicted in the Responder Maps demo video to reference established workflow sequences involving the pre-plan site inspection, alarm call dispatching, and situation awareness in the field. By examining the context, needs, goals, artifacts, and transitions of each, I hope to elicit input that will inform future iterations of the product.

A recent presentation to the Geocam group by Mark Micire (NASA IRG/CMU Robotics, FEMA California Urban Search and Rescue) reinforced design thinking integral to problem solving in emergency response. Key takeaways included:

A. Empathize / Define
• Understand the customer by becoming the customer (a variation on “eat your own dog food”).
• Workflow is everything. Start with what exists. If you come up with solutions that don’t integrate well into existing workflows, they will take longer to adopt (if ever).
• Emphasize learnability (different from usability). Lower the learning curve — end users are not rocket scientists nor necessarily technically-inclined. In the field, where training and instinct take over, certain solutions can be more difficult to use, e.g., one that requires sovereign posture.
• Don’t assume internet connectivity or reach back. For complete survivability, consider what happens when systems go down (if app no longer available, articulate why persistent functionality not important to your tradespace.)

B. Ideate / Prototype / Test
• Involve users in ideation — let them scribble, mold, sculpt, etc.
• Find the right person to talk to. Many have introduced/built their own solutions.
• Look to the center of the bell curve for validation (not just the early adopters).
• Design for your parents, not your peers. Many firefighters come from a generation ahead of you, possibly two. (Avoid UI patterns from videogames.)

Additional comments pointed out the importance of understanding the firefighting culture and how best to fit in, useful pointers to heed as one conducts contextual inquiry.

Challenges

In light of the foregoing, getting the most out of the stakeholders we’ve engaged thus far will require soft skills to encourage dialog, ideate solutions, and manage change (as important as hard skills in design or workflow analysis.) Observations drawn in the Design of Everyday Things by Donald Norman seem particularly relevant (sharing research on higher productivity gains from the building design of the FAA’s Seattle offices, where users were heavily involved in the design process.)

Goals

Polish the context scenario/demo video storyboards for further contextual inquiry involving key stakeholder/end user input and activities.

Enhanced by Zemanta