Performance, Data Pixels, Location, and Preattentive Attributes

This entry is part 8 of 12 in the series Medical Computing
Dueling Whiteboards courtesy Dr. R.L. Wears

Dueling Whiteboards courtesy Dr. R.L. Wears

A good principle for medical software is to design for the ED as a worst-case scenario. If it works there, it will work anywhere.No clinicians are as time-pressured as those in a busy Emergency Department. There, distractions – even seemingly minor ones like presenting a complete CBC instead of an abstract – slow the clinician down, and may distract from something more important.

Quoting from a recent presentation at  HIMSS:

Emergency physicians are majorly stressed and working at max capacity already. Darwinian selection means that ED staff (this is from the Critical Incident Stress Management literature):

  • have obsessive/compulsive personality traits
  • they like to be in control
  • they are risk oriented
  • they are action-oriented
  • they “need to be needed” and
  • they are dedicated

Emergency physicians are interrupted far more frequently than other physicians, and the same is true of ED nurses, techs, and certainly clinical secretaries. So, those in the ED are intolerant of anything that wastes their time. (Look at the “Dueling whiteboards” picture at the beginning of this post; note the number of users of the handwritten whiteboard vs. the computer-based one.) This is why the IT department (Information Technology = “the computer nerds”) traditionally hates the ED, and why IT projects fail in the ED more than in other units. Nonetheless, making things work in the ED is a path to success throughout the hospital. Read the rest of this entry »

Share

Information Design

This entry is part 7 of 12 in the series Medical Computing

Wikipedia says: Information Design is the art and science of preparing information so that it can be used by human beings with efficiency and effectiveness. It goes on: the term has come to be used specifically for graphic design that has the purpose of displaying information effectively, rather than just attractively, or for the purpose of self expression by the designer as artist.

Action-Oriented Information Design drives actions, such as care of a stroke or MI. It aims to decrease error, to remind us to do those things that we know to do but might forget, and to improve our compliance with established guidelines, while not forcing us into rigid protocols. Action-oriented information design also encapsulates domain expertise to teach us better ways to perform our tasks. Those who write standing orders for a hospital, know it or not, are practicing action-oriented information design.

Information design evolved long before computers or the Internet, focusing on the printed page and graphic design. The following topics constitute a basic study guide for information design practitioners or critics:

Share

Goals vs. Tasks

This entry is part 6 of 12 in the series Medical Computing

In past articles, we discussed human-illiterate computers, usability, memorability, learnability, Tognazzini’s Paradox, design integrity, simplicity, abstraction, discount usability testing, and personas. Now, we will discuss goals and tasks. These are similar terms, and sometimes used almost interchangeably. But using the terms task and goal sloppily is, according to expert software designers, an error that leads to disastrous software design. So it behooves us to understand the differences between tasks and goals in solid detail.

This is written as if I’m writing to someone who’s developing software; and though it is certainly my intent to get people writing software for Emergency Departments to pay attention, it’s just as much to for those of use who use ED software – or someone who is doing something homebrew using Excel or Microsoft Word macros.

The difference between tasks and goals relates to our previous discussion of personas in the last article. First, let’s look at some excerpts from a nice online overview of UML, the Uniform Modeling Language. UML, which is a couple of decades old, was a breakthrough in its day. It allows you to specify how a computer program should interact with people, not in ambiguous English, but using a grammar that allows a more precise specification. Key ideas incorporated in UML include actors: Read the rest of this entry »

Share

Personas

This entry is part 5 of 12 in the series Medical Computing

In past articles, we discussed human-illiterate computers, and we discussed usability, memorability, learnability and Tognazzini’s Paradox: how  changing a single word can make big differences in usability. We also discussed design integrity, simplicity, abstraction, and discount usability testing. Now, we’ll talk about personas.

It seems to me that personas are a bit like Critical Incident Stress Debriefing (CISD). Both have generated a lot of heated discussion: does it work? And, despite solid evidence that definitively answers the question, heated discussion continues.

<Sideline>There is good evidence that CISD doesn’t work, but there is a large national network of people strongly committed to providing CISD sessions for victims of disaster. Now don’t get me wrongCritical Incident Stress Management (CISM), of which CISD is just one part, is important. Psychologically stressful incidents may result in acute stress reactions which, if unrecognized and untreated, can lead to full-blown post-traumatic stress disorder (PTSD). CISD, which is a group debriefing session, a limited one-time psychological intervention, is promoted as a way to control acute stress reactions and prevent PTSD. But it’s been conclusively shown that CISD sessions are at best useless and at worse harmful. I am medical director for a multistate search and rescue organization. As such, I have had to review the literature and make a medical direction decision that, despite the strong feelings of CISD teams, our organization should never participate in CISD group debriefing sessions. This not to say that CISM isn’t needed; it is. But the “management” should not include group debriefing. </Sideline>

The evidence shows that CISD does not work. But the evidence shows that personas do work. There is certainly an air of “Cooper-worship” in the literature on personas, which excites some opposition (and “Cooper-hate”), but the underlying engineering strategy of using personas is solidly established.

OK, so what is a “persona” and why should you care? Read the rest of this entry »

Share

Discount Usability Testing

This entry is part 4 of 12 in the series Medical Computing

In the first of this series, I tried to persuade you that your computer was human-illiterate, and we defined and discussed usability, memorability, and learnability. In the second, we discussed Tognazzini’s Paradox: how the hardest part of designing an effective program is often what seems the most trivial—sometimes simply a matter of changing a single word. In the third, we talked about design integrity, simplicity and abstraction. Now, let’s address “discount usability testing.”

When we talk about “usability testing” most of us think about expensive consultants, fancy labs with one-way mirrors and video recorders, and the like. Yes, usability testing can be done in such labs. Yes, companies like Microsoft have permanent million-dollar user testing labs.

But if you design, program or provide feedback on any portion of an ED information system – learn how to do some discount usability engineering. Usability guru Jakob Nielsen says: “I advise clients to avoid design agencies that are too arrogant to include user testing in their project plans.” For that matter, if you are a user: do some quick and dirty usability testing to document on how bad (or how good) your system is – either to demand a better system, or to demand that the vendor provide usability updates! Read the rest of this entry »

Share
//commented out L sidebar 7/26/11 //