Emergency management has existed for decades, but the strong push to professionalize and standardize the industry largely began with the passage of Post-Katrina Emergency Management Reform Act (PKEMRA) more than a decade ago. This push yielded a number of benefits including increased unity of effort, consistent training, and stakeholder interoperability. However, it’s possible that for all we’ve gained in standardization, we may have lost some in the way of innovation. For an over-worked emergency manager, reaching for an existing time-tested, industry-approved solution can be easier than designing a new one, even if there’s room for improvement. But that doesn’t have to be the case.
During the recent International Association of Emergency Managers (IAEM) Region 3 Symposium in Fairfax, VA, a presenter from the District of Columbia Homeland Security and Emergency Management Agency (DC HSEMA) described the concept of “design thinking” and encouraged its use to spur innovation in emergency management.
Design thinking is more than just a thought process, it is a system of innovation that is
“powered by a thorough understanding … of what people want and need in their lives, and what they like or dislike about the way particular products are made, packaged, marketed, sold, and supported.”
Here are five design thinking steps emergency managers can follow to invigorate their work with creativity and innovation:
Talk to the desired end users, customers, or clients.
Whether you are creating a product, writing a policy, or designing a form, it will be ineffective if it doesn’t meet the needs and expectations of the end user in a way they understand. Empathize with the solution’s intended audience and ask questions such as “what do you want this to do?”, or “what specific information are you looking for?” to gain a deep understanding of their desires. This is easier said than done in a complex and layered emergency management arena that encourages interaction among the whole community: stakeholders in the Federal, state, local, tribal, territorial, non-profit, and private sectors. For example, a continuity document for a Federal agency may look very different than one for a Tribal government, and those may both differ from one for a private business. Try to define your solution’s intended audience as narrowly as possible, and consider creating multiple solutions which are tailored to the needs of smaller audiences instead of a single “one size fits all” solution.
Translate your understanding of end user needs into a defined problem statement or scope.
At HWC, this often takes the form of a scoping document shared between us and our clients that distills our understanding into a tangible form. This scoping document serves as a guidepost throughout product development and keeps the needs of the users at the forefront. To follow the continuity example from the previous step, a scoping document may state that the client wants the product to be comprehensive, or that they want it to be no more than a few pages of bullet points. Goals and objectives that bound the project but leave enough flexibility for new ideas are best.
Think outside of the box.
In an industry where we have codified ICS forms and doctrine for everything from training exercises to risk assessment, we have to challenge common beliefs and existing practices. Brainstorming is a no-fault environment where the simplest idea can drive innovation. Standard practice may suggest that a comprehensive, multi-scenario continuity procedure is best practice, but a short continuity checklist can be more effective if none of the clients have the time to read the procedure. While debate, discussion, and differing ideas are fundamental to brainstorming, it’s important to reach consensus on a path forward for the product or process. In some design thinking approaches, generating a large number of ideas or definitions of the problem is called divergence, while reaching consensus on a single one is called convergence.
Quickly create a version of your solution.
Use the scoping document in tandem with the product definition to create the product according to the results of your brainstorm. The resulting prototype can be an “inexpensive, scaled down” version of the product, or it can even just be “specific features found within the product” to start. In keeping with the continuity example, the initial prototype could just be a list of steps or actions to take, or it could be a more thorough, formatted list of successors, mission-essential or primary business functions, and alternative work sites. The key outcome of this phase is to produce some version of your product or solution to test and improve.
Test and Repeat
Test the prototype with end users.
Make sure end users understand the prototype and that meets their needs. Solicit their feedback by asking questions and use that feedback to improve upon your prototype(s). Perhaps the client is happy with the information, but it is organized in a way that is inconsistent with their expectations. Or perhaps the prototype was a good start, but the client wants more functionality. Maybe the prototype checklist was threat/hazard agnostic and broadly applicable, but it’s possible that the client now wants one tailored to hurricanes. The entire design thinking process is iterative and can and should be repeated until both the designers and the end users are happy with the product.
Applying design thinking to emergency management can result in innovative processes and products that better suit the needs of unique stakeholders. However, innovation should be balanced against interoperability to ensure that the whole community can benefit from new products and processes. Additionally, major innovations may be better suited to the “preparedness” phase of the emergency management cycle, when life-saving operations will not be impacted. Measured but innovative thinking will continue to progress the emergency management profession, and will enable us to better prevent, protect, mitigate, respond to, and recover from all hazards.
Graphics by Parul Agarwal