As disaster managers, technology is one our tools of the trade that enhance our operational abilities.  They are not the end all be all of solutions, but they significantly help enhance critical activities for success.  In recent years, the number of technology solutions have exploded in both number and capability.  But what has often taken a back seat is the usability of programs that often require high degrees of training and business practices.  I can't say we will ever be free of this, but the level at which we operate is simply too inefficient and costly.  Technology must be intuitive and solve complex process-oriented problems in order to realize its true value.  

But are we really at the mercy of companies developing these solutions?  I take a different approach...we must not only ask, but demand that disaster technologies developed today (largely applications) meet my six pillars of usable software technology: Process-Oriented, Intuitive, Flexible, Secure, Available, and Integrated.  

Process-Oriented

This is a no-brainer.  All technology should help solve a process-oriented problem such as communicating with the public, exercise design and development, managing response resources, or maintaining situational awareness.  Sometimes though, we get caught up in the sales pitch or all the features it has.  

Regardless, the solution must help solve YOUR problem!  Defining these can be sometimes tricky, but good thought and effort must be put into identifying these areas for improvement.  In fact, use your technology procurement cycles as an opportunity to improve process by using tools such as SixSigma.    

Usable

Again, this is something we always hope for, but never fully attain.  From navigation to work flow, applications should be developed as simply and intuitively as possibly.  Can any steps be removed?  What steps are unnecessary or legacy?  Does the application match the flow of the process?  the job?  the mission?  Are buttons and icons easy read and understand?  

These questions are critical to understanding usability and should be expanded as necessary.  The point of this is to reduce costs by reducing the need for application training and complicated business practices.  User dashboards are becoming more common as a usability tool.  User interfaces should be intuitive for someone who knows their job well.  

Flexible

Customization is a long running issue in any of our organizations.  In fact, we go as far to purchase a tool, then pay for more customizations despite common behaviors in the industry!  Our costs end up rising significantly as we realize we need X or Y or Z to help complete our missions.  The truth is, vendors have a tough job balancing what customizations should be in the hands of its customers and what should be retained due their specialized nature.  Many of their revenue models also depend on these customizations.

However, we need to push away from specialized customizations as they have a negative affect on our bottom line.  For example, once you have customized your software, updates, patches, and new features become very hard to deploy.  More problems are encountered, costing more to fix through your maintenance contract or service level agreement (btw, I really think these, as individual agreements, should go away completely; one master should suffice...probably a topic for another post.  This also limits the pace of innovation as many customers are using different versions.  

As mentioned above during the technology procurement process, carefully decide on YOUR needs ahead of time to help avoid this.  Heck, develop a technology strategy if need be.  Your administrative panel should ALWAYS have easy-to-use and flexible customization options that do not require "coding."  And vendors should understand that a strong and robust administrative panel is an absolute necessity!  

Secure

Security is always on my mind (and yours as well).  It reminds me of the song "Always on my Mind" by Willie Nelson.  While I am not talking about a lost love, I am talking about the constant threat of data and information compromise whether it be internal, external or a simple corruption.  We must recognize our threats and vulnerabilities in this area, but also recognize the issue with designing systems so secure it is hard to use and manage for its intended function.  

For example, the HSEEP Toolkit requires a very secure/hard to remember password that has to be renewed every 90 days.  Once more, if you account is moved to "inactive" status or your simply forgot your password, it requires a phone call instead of a simple and automated "Forgot My Password" process that can validate the same information.  I can go on and on about tools that don't balance security with usability very well.  And it truly is a balance.  We are all busy people who need to know that the tools we use are secure, but usable.  

Available

We are all emergency managers, responders and continuity professional with critical roles during emergencies.  As a result, our systems are critical as well.  Downtime is not an option.  Much has been written about business continuity and disaster recovery strategies.  But moves to internet-based solutions is growing significantly and challenging existing strategies to maintain critical operations.  Vendors are working hard to ensure their data centers have 99.9% uptime and availability.  Applications stand a better chance of uptime when they are not in the disaster impact zone.  Additionally, when you use separate applications from different providers in different locations, you significantly decrease your downtime risk.  

I should note that the availability that I speak of heavily relies on internet access and is a critical failure point.  But when you know where you need to devote your money and resources, such as mainly ensuring reliable access to the Internet, continuity strategies become more cost effective and easier to maintain and implement.  Now you are not worried about dedicating IT staff to managing your servers during high load times, addressing network failure or VPN issues, or constantly trying to keep up with software updates and server requirements.   You are dedicating and devoting your time to one important mission, Internet access.

Integrated

This is my bread and butter and where it will be at in the next five years.  Integration represents the many inter-dependencies that we have been trying to manage and coordinate for years.  Technology can make this easier, but if currently fails with all the customizations taking place.  Integrations should be a non-technical/non-coding activity based on the idea that you are simply connected to another platform that serves a complimentary need.  Revenue models need to shift from expensive customizations to standardized customer access.  I am not saying don't charge for this, but there is a middle ground that enables most of the customizations emergency managers are looking in a cost-effective manner that empowers the customer to modify the tool according to its needs.  

Integration still serves a greater purpose, though.  We no longer own ALL the data we work with and it is important that we can shift to an access control model no matter what platform you are using.  I was at a recent exercise where users of the emergency management software were hand posting information from their local status board to the Regional board and vice versa.  This SHOULD BE AUTOMATIC AND THE BOARDS SHOULD BE INTEGRATED!  OASIS is developing many standards to support this, but vendors need to step outside their silos and work in conjunction with their competitors by developing Application Programming Interfaces and pre-configured integrations with other applications.  We are an inter-dependent field that needs inter-dependent technology.  

Simple LDAP (a widely-used IT solution for managing organizational users) integration is a great start to support user provisioning.  Next up..the top five emergency management solution providers should develop integrations to each other's solutions.  

Conclusion

Well, as I write this post, I am realizing how big this issue is and perhaps I need to write a lot more about my pillars.  But I want to make sure I have stressed the one important overarching principle...the software we use today must be intuitive and reflective of our operating conditions.  Vendors have a long way to go to change their business model, get on constant and consistent innovative update cycles, and collaborate with their customers.  However, customers, the people who use this software every day must begin demanding these changes.  Cool features and capabilities mean little unless they are developed with our real-world needs in mind.  

I have hopefully provided some food for thought.  What are your thoughts and experiences?  What would you do differently?

​