When User Experience really a matter of life and death
The NY Times reports that the Department of Defense created Joint Patient Tracking Application so that military doctors around the world can access patient medical histories -- and while it's used in Iraq and Afghanistan, it is mostly not used in the US (Disuse of System Is Cited Gaps in Soldiers' Care). The net in the US is that the military medical community is not aware of the patient history, and ends up covering the same ground with patients over again -- re-ordering tests, re-making diagnoses, and wasting time. Back in Afghanistan and Iraq, the problem is slightly different -- because the system is not often used in the US, the feedback loop overseas medical personnel need to improve their quality of care is broken. Without access to ongoing care and progress of patients, they struggle to evaluate how treatments on the battlefield can be improved.
According to the times, "Lapses in using a digital medical record system for tracking wounded soldiers have led to medical mistakes and delays in care, and have kept thousands of injured troops from getting benefits".
The article goes on to cite a number of sources claiming the patient tracking system functions just fine -- and yet it's still only used by 13 of 70 military medical treatment centers in the US, depsite being mandated by DoD 2 years ago. According to Steve Robinson, whom the NY Times identifies as a ventrans' advocate,
"Virtually all military doctors agreed that the digital system was effective in tracking patients. But he added that he had participated in seven Congressional hearings, most recently last week, that focused on problems with how the defense and veterans departments track medical information.
“We don’t really have time to wait for another system to come online when we have one ready now that the D.O.D. approved,” Mr. Robinson said. “The tools are there, but we just keep having meetings about whether to use them.”
Failure to adopt a technically functional system -- despite being mandated -- is a classic symptom of usability design failure. There's nothing in the article to suggest that there is any specifically wrong with the Joint Patient Tracking Application from either a technical or functional perspective. And I haven't seen any screen shots or seen the navigation flow, so I can't comment on whether it's "pretty" or easy to use by itself. The reality is that I don't need to see those things to suspect there may be a User Experience problem here.
In this case, UX is not about being pretty or having an appropriate internal interaction model. No -- the evidence suggest that this is what some might call a "capital D" Design failure. That is, the Joint Patient Tracking Application doesn't fit into what medical personnel do. It doesn't make their work sufficiently easier to make them *demand* to use it. Seriously, with the benefits desribed in the NY Times, why aren't medical personnel up in arms that they don't have this application?
I admit I'm completely in the realm of speculation here, but I suspect it has something to do with a lack of integration into all of their other work processes. There are actually many examples of this type of failure in industry. Common ones include packaged ERP and CRM systems, but lots of LOB applications have the same issues. If an application makes a person enter information twice, or pull it from one system and enter it into another, or stop a well-designed process to do something in another system, then the application that is perceived to be less crucial -- or maybe just less familiar -- will probably have issues with user adoption.
When this happens, managers and executives often resort to a variety of "carrrot and stick" strategies to get people to use the offensive system, but the result is often insincere compliance and sometimes malicious compliance -- the worst form of insubordination. Either of these outcomes will create friction for employees that hurts morale and productivity.
A better approach is to make sure business processes are well understood and that applications are Designed to improve them from the perspective of the users -- that is, the consumers of the application... the people who need to decide everyday that they will use the app. BTW, I'm not just talking about understanding the highly structured business processes (the standard stuff folks usally harp on), but also unstructured and semi-structured business processes, too.
It's simply not enough to have the right functions and the right information and even the right internal interaction model in a system. Applications must enable what we, as human beings, are trying to accomplish. When more than one application is in play, how those applications work together and how they work with our core information tools (often Excel, Outlook, a browser, and a mobile phone) will determine whether users see the applications as enabling to them or disabling to them.
So what do you do if you have apps that people don't want to use? The first thing is genchi gembutsu -- go and see what's actually going on. How are people using the app (or not)? How are they accomplishing their work (or not)? What do they think is important? What do the upstream and downstream people think is important? In some cases, there could be entire sections of an app that the enterprise doesn't even need people to use. Or that the company might be asking the wrong people to use at the wrong time.
In other cases, having people use all parts of a system may be really important to the enterprise. The good news is that, even in these cases, you often don't need to re-write an app's functionality. Instead, you can choose to expose functionality and information in ways that are more productive for your people.
For example, imagine that people are rebelling against using a "new" system that would require them to login to the system, read patient history, read test results and past intervention results, enter additional interventions, and then enter patient outcomes by hand. Might be ok by itelf, but now imagine that medical personnel already have a different system that they log into and that is supposed to fill all these roles -- it's just that the data is monitored and analyzed by different people. Moreover, imagine the "other" system is also the execution system for ordering tests, transfering histories to specialists and other personnel, and also for reading test results and specialist observations/diagnoses from others. In this scenario, the "new" system would, very predictably, face serious issues with adoption.
Assuming there really are good reasons to use the new system, a reasonable approach might include:
- Identify what data and functionality are common between the two systems
- Identify what functionality can be shut off altogether
- For each common data element, declare a master data source
- For each redundant function, declare a master functional service
- Determine whether or not the unique functionality and data should be added to one of the applications or whether it's better to have them remain separate.
- Using either one of the existing applications or a new one, create a unifying interface for the data and services that are important enough to keep.
- Leverage the valuable existing data and services behind the unifying UI.
- Leverage workflow between applications to monitor and manage both human-centric and machine-centric processes
- For unstructured and semi-structured processes, provide the ability to execute those steps within the context of the total human process and extend the workflow management to those semi-structured environment.
For example, if a doctor needs to go look up drug interactions before completing a prescription, potential channels for looking up that information could include going to a website, reading a Word document, querying a database, contacting another person, etc. It's possible to enable any or all of these methods to accomplish the task of verifying drug interactions before writing a prescription within the context of entering the prescription order. Preserving the context is important, because frequent context switching limits productivity.
It's also possible to create and preserve status of a prescription order. If a doctor wants to speak with an expert before completing the prescription order, the prescription information entered can be preserved with a status of "not yet issued", so that information does not need to be re-entered when the doc is ready to finalize the prescription. Moreover, having information on the status of the prescription order can enable a variety of other capabilities that can help drive user adoption. For example, a "reminder" service that sends an email to a doctor's smartphone about prescription orders that have been in "not yet issued" status for more than 30 minutes (or whatever time threshold you might want to configure). If the doc has just learned it's ok to order the prescription but is now away from the computer, workflow can enable the doc to complete the prescription order right from their smartphone by responding to the reminder and changing the prescription status on the smartphone itself. Workflow can also enable the new system to receive the prescription status update and log the order appropriately. This can minimize human delays in prescription ordering, and make doctors more productive when away from a computer. This example scenario also enables new intelligence on the prescription decision and execution process -- for example, what prescriptions are pending, what's been issued, what's been filled, what started with one drug but were changed to another, etc.
I hope I've made it clear that I don't really know much about specific details of the DoD's Joint Patient Tracking Application, but the NY Times article presents a story with some very common plot elements. The application might be just fine in a vaccuum, but a fundamental part of design is making sure that applications really enable people -- human beings -- to be more effective at what's important to them. If it's not enabling key users - so that people demand to use it - then there's a good chance there's a design problem. People (usally ;-) ) live in the real world of incomplete information, conflicting priorities, interruptions, distractions, and different people communicating similar (but yet not quite the same) information... good IT applications should help people manage these difficulties, not contribute to them.
John Mullinax is a Platform Strategy Advisor with Microsoft's DPE Team. Before joining Microsoft in 2006, John held a vartiety of positions at Ford Motor Company, most recently leading IT services strategy to support explosive business growth in China. Other positions included: Enterprise Architect, Application Portfolio Management, Technology Governance, and Product Manager. Prior to joining Ford, John earned his MBA at the University of Washington. Before that, he was Director of Elections for Douglas County, Washington, where he conducted the first Federal mail-ballot election in the USA. Subsequently, he joined the Secretary of State's office as a consultant working with county election officials in Washington state to improve operational effectiveness, integrity, and security (aka, to prevent the kind of debacle we saw in Florida in 2000).
