Designing for the intelligence professional

We have witnessed the explosive growth of just about every new technology under the sun, all claiming to support (or even entirely automate) intelligence analysis tasks, emerging in the years of the increased Long War budgets. We have even taken part in the design and development of a number of systems – some of which have endured, others of which we have gladly put out of their misery.

We have come to a number of conclusions regarding what works and what doesn’t based on those experiences. We have learned some interesting lessons from the usability crowd, and even more from the evolving body of standards and practices which comprise the whole Web 2.0 phenomena. But a recent article regarding the proliferation of features in various techno-toys, driven by consumers who may not really know what the need or want, calls for additional contemplation.

For us, the gold standard of design is and always will be the Avtomat Kalashnikov. It is designed to do one thing, and one thing well – under any conditions, with nearly any level of maintenance (or lack thereof). (There is a reason why it is among the most frequent weapons encountered worldwide.) No feature creep there – and a reason why we keep (at least) one at home, in addition to having carried one in many locations overseas over the years.

Unfortunately, the venerable AK is also the product of nearly seven hundred years of firearms evolution. The tools used by the intelligence community can claim nowhere near such a distinguished lineage. (The sole exception perhaps may be found in the world of the cryptographer, where automation has simply advanced mathematical tools once done by hand with pen or abacus. However, one could argue that the munitions of the cryptologic world are among the most refined tools of the intelligence community, certainly so far bypassing their counterparts in the analytic environment as to be an entirely different order of beast.)

In part, we suffer from tools we do not truly need because most those tools are designed by engineers and technologists working in isolation from their users. Indeed, in most systems development processes we are familiar with, the user is simply at best an afterthought, or at worst an annoyance to be conferenced with in order to ensure “buy-in” as one of the “stakeholders”. It is a wonderful thing for a developer to be able to code in splendid isolation, and hand-off a system they themselves certify to meet the user population needs – even though only a handful of actually users may have ever seen the damn thing before it goes live, and opportunities for comment and change are restricted to such a narrow window their input may as well not have even been obtained.

We might call for a similar approach to tool development as we have seen in the development of analytic methodology – embedded design professionals, working alongside their analyst counterparts, and embedded analysts, working to bridge between the two worlds as translator, native guide, and Sherpa. We are aware of initial attempts at making this happen, but much more needs to be done at resolving some of the difficulties such efforts face both within the walls and within outside partners.

In this, we would also second the call by Haft of the Spear for the introduction of lightweight development environments to permit rapid deployment of small scale, situated software for specific applications. Likewise, the introduction of lightweight processes (and supporting information sharing options) to capture analysts’ needs, desires, and frustrations with their toolsets would go a long way to helping codify that which is absolutely vital versus that which is merely part of the ever growing list of bells and whistles – especially if this is done within a larger framework of lessons learned and tradecraft capture and transmission efforts.


h/t Boing Boing