Suppose you're a company like Memex, in the business of providing software to police departments. Given the nature of the work, almost any electronic assistance might be preferable to the alternative. Would you rather do a quick search on all information about a suspect whom you're interviewing, or dig through file cabinets and desk drawers for information that might not even be there?
The temptation of lazy design
Law enforcement's need for electronic assistance might tempt software developers to be lazy. As anyone who has built an application for a specialized purpose (tracking donations, handling equipment requests, pooling notes about patients, etc.) knows, it's easy to create a bare-bones UI and the underlying database. It's a lot harder to make it usable, and to build in the application logic that the real world demands. And then there are the inevitable customizations...
A quick analogy: I decided to put in a drip watering system for some plants in the back yard. Someone could have handed me a box full of random hoses, PVC pipe, and connectors, and left me to figure out how to make use of it all. While some of the hoses might have been good for someone else's garden, they don't match the layout of my plants. If I don't have the right tools--for example, a wrench to tighten some of the couplings--basic aspects of this household project will be a lot more challenging.
Instead, I bought a kit. It wasn't perfect for my needs, but it got me started a lot faster and more successfully than the approach I was tempted to take, buy the components that, in my earnest newbie ignorance, I thought would work together.
The benefits of starting with the use case
Let's leave the peonies and get back to the felonies. Again, you might throw together a UI that lets you enter incident reports, search on related crimes, and report on the closure rate of investigations. However, making the application usable takes real work, including paying careful attention to how people in law enforcement actually work.
That's what made me very interested in finding out all I could about Memex's applications. The UK-based company hired Peter Ship, a former investigator in the murder unit of London's Metropolitan Police, to advise them on their product design. The company also worked with local police departments to provide further information and validation of how to fit the technology to police work.
Whenever you take this kind of use case work seriously, you wind up emphasizing features that you might not have been expecting to be as important as turn out to be. For example, the decision to design the application around the needs of an inexperienced investigator, potentially the weakest link in the chain leading to prosecution and conviction, prompted Memex to invest in a "Validate With Advice" capability. Based on the police department's own guidelines for how to handle particular situations, the system makes important suggestions to the investigator. For example, if the incident report falls into a category of crimes (smash-and-grab thefts, domestic violence, etc.) that the department is giving special attention, the Memex application can tell the investigator how to prioritize this investigation, and what next steps to take.
This particular example also shows how use case analysis can help development organizations make tough decisions. To make the Validate With Advice feature work, you need a rules engine that's flexible enough to accommodate a lot of departmental guidelines, and simple enough so that the non-technical users who best understand these rules can define them in the application. On top of that, to get people started, the application needs some canned rules that resemble the sort of guidelines that most departments will enforce. That triple combo of capable rules engine, interface for business users, and pre-defined rules is a big development effort, frought with potential pitfalls--exactly the kind of project that many development teams would try desperately to avoid.
Room for creativity and coolness
Sometimes, people in the tech industry grumble that a too-slavish dedication to use cases reduces their creativity. However, Memex's design team shows how the use case can be the springboard to very useful features with a high coolness factor.
Many investigators use a link chart to depict a web of relationships among the facts of a crime. Witness A saw Suspect B in location C. However, we know that 10 minutes earlier, Suspect B was across town using an ATM. So how did he get to C in time to commit the crime.
Memex's tools build this kind of link chart on the fly. Autochart is pretty cool to see on its own, but it's especially cool to see how it works in conjunction with search. An investigator who has doubts about Witness A might search across repositories to find more information about that person. As pertinent facts emerge--for example, all the other times this person provided an eyewitness account of a crime--that the investigator might add to the link chart. Over time, the picture that emerges isn't a machine-generated set of pointers between bits of data, but a carefully-constructed narrative, based on the facts and the investigator's judgement.
Someone who hasn't taken use case analysis seriously might still create a link chart, but it's more likely than not to be a half-assed attempt, designed more for demos than actual use. The connection between the link chart and search is exactly the sort of capability that would be missing in the marketware version of the feature.
I have a gut feeling that people building vertical-specific applications like Memex's might be doing a better job of use case analysis than many "horizontal" technology built for a general audience. No matter how horizontal or vertical your product might be, the Memex case shows how very, very specific use cases can lead development teams to resist lazy design and make the right design choices.
What a wonderful post! Having helped introduce the use case mentality into Memex' services organization in the US, I can attest to the fact that the concept is just as important in the field as it is in product development. We were able to short circuit the implementation of the Memex Intelligence Management suite from 9-12 months to less than 3 months by embracing use cases.
Of course we've now embraced the concept at my new venture, but please don't tell anyone...it's our secret weapon :-)
Thanks again for a great post.
Sam Bayer
www.b2b2dot0.com
Posted by: Sam Bayer | 07/11/2009 at 01:15 PM