Inhuman Factors–Producing Virtuoso Users

July 16th, 2009

Add to Technorati Favorites

by Jim Bradford, MediCHI Consulting

For many years universities have taught computer science students more than they ever wanted to know about Human Factors (Human Factors is the art and science of creating software that is intuitive and easy-to-use). Inevitably or in some cases, eventually, these students graduate and go to work for companies that create “feature driven” products in preference to “usability driven” products. Most computer science graduates have the knowledge they need to do good design work but they are rarely asked to apply this knowledge.

So, after a quarter century as a usability evangelist, I am throwing in the towel. If you can’t beat ‘em, join ‘em as my grandfather used to say. In the next paragraph or two I am going to define a new discipline that I am calling “Inhuman Factors.” Inhuman Factors acknowledges that many products are complex, hard to understand, and never reach the point of being fully debugged. Inhuman Factors takes the view that difficult to use products will be the norm for the foreseeable future.

To illustrate the argument let’s pick on Microsoft for a moment. The Microsoft Office suite had humble beginnings. Their word processor was originally intended to replace the typewriter. Their presentation system (PowerPoint) was offered as a replacement for transparencies and overhead projectors. Their spreadsheet application was built to replace the bookkeeper’s humble ledger. In just a little over a decade these applications have grown to such monstrous feature-driven complexity that the company now oversees a certification process to identify those hardy souls who have actually managed to figure things out. Talk about making a virtue of necessity! This is the most brazen spin for bad design since Heinz claimed that their ketchup was hard to pour because it was “rich.”

One of the classic signs of a poorly designed user interface is a wide disparity between experts (power users) and the rest of the user population. Many years ago I worked in the R&D division of a large telecommunications company (now bankrupt – not my fault). I was part of a department that developed a very complicated in-house computer aided design tool. We did an after-the-fact usability assessment for this system and discovered that the most productive user was nearly 20 times as productive as the least productive user (a 2,000% difference – the least productive user took nearly a month to do what the most productive user managed in a day).

This is where Inhuman Factors comes in. Through a process of task and workflow analysis, through the development of meaningful cognitive models, and through the creation of useful exemplars, Inhuman Factors will do formally what that high performing user did intuitively. Inhuman Factors will deploy many of the same tools as traditional Human Factors but with a contrarian goal – the creation of virtuoso users who can take existing software applications to the heights of productivity that the sales force originally promised.

Please check back in the coming months as I elaborate on the theme of Inhuman Factors. Comments and suggestions are welcome.

Tags: ,
Posted in General Human Factors, Interface Design, Usability | No Comments »

What Is Usability and How to Recognize It

January 27th, 2009

Add to Technorati Favorites

by Jim Bradford, MediCHI Consulting

This article was originally published on the prominent healthcare blog, HIStalk

From time to time when I use a new application I seem to develop a kind of Tourette’s Syndrome characterized by teeth grinding, fist clenching, and dark mutterings. As I struggle through yet another badly designed, user-unfriendly system, I find myself wishing fervently that Bill Gates had finished college.

Technically, the user friendliness of a system is known as “usability.” There is an entire academic discipline (variously called “Human Factors” or “Ergonomics”) that is devoted to the study of usability. But if you don’t happen to have a Ph.D. in Ergonomics how do you recognize a well designed, highly usable system?

Mental Models and the Psychology of Geeks

The human brain constantly monitors the environment and creates models about it. This allows us to think about our environment and make predictions about what will happen next. We carry over this natural tendency to model things into our interaction with computers.

Not all models are created equal however. I have a friend who believes that if you set a thermostat as high as it will go, it will warm up the house faster. It is not an unreasonable model-it just doesn’t happen to be right.

The best system designers work hard to give you many clues about how a system works. This allows your brain to make a good model that produces accurate predictions about system behavior. When you encounter such a system you begin to feel that the system is natural, intuitive and easy to use.

Unfortunately geek psychology doesn’t often lead to this kind of design process. In 1971 Gerald Weinberg published his (now classic) book, The Psychology of Computer Programming. To boil a long tome down to its essence, the kind of person attracted to computer programming is frequently the type of person the media would characterize as a “troubled loner.”  Unfortunately the design of usable systems requires a well developed ability to understand how people think, feel and react when confronted with a complex system. As a rule, troubled loners are not good at this.

As a consequence, human factors experts are often drawn from the “touchy feely” disciplines (i.e., anything other than engineering or computer science). They are often brought in to fix computer systems that are so horribly hard to use that almost no one can make them work. This strategy is akin to bringing in a doctor only after the patient has died. The usability specialist does what he or she can but the result is usually a system that has evolved from being impossible to use to the point where it is merely frustrating to use.

The traditional approach to developing computer software (design-code-fix) is pretty well entrenched. Thirty years of preaching from academia has not noticeably improved the usability of computer systems. The key to usability, I believe, is an informed and demanding consumer. This is rooted in a fundamental property of a free market economy-if people stop buying poorly designed products, companies will eventually stop making them.

The Informed Consumer-How to Recognize Usability

Affordance: This design principle dictates that the appearance of things should provide a strong hint about how they are used. A hammer looks like it would be good for driving nails. A screw driver suggests how screws should be managed. An espresso machine, .. well . . not so much. Hammers and screw drivers have good affordance and espresso machines have poor affordance. When you look at the user interface of a new piece of software, do the commands, buttons, menus and other gizmos give you a good idea of how to use the system? If they don’t, it’s strike one against the designer.

Prescriptive Feedback: When using complex systems people will make mistakes and this provides the acid test for usability. Have you ever encountered an error message that says something like, “Illegal command or filename”? Good grief! Which is it, the command I just used or the file I just named? What law did I break? What makes a command illegal? Why can’t I call a file anything I want?

Can you imagine if other products were designed like software? Can you imagine a dashboard trouble indicator saying, “Illegal battery voltage or engine temperature”? If software doesn’t help you fix mistakes then it is strike two against the designer.

Task Fit: Software is a tool. Some software is a tool for creating documents, other software helps manage your finances and still other software exists purely to entertain you. Well designed software should focus on doing a small number of distinct tasks (a half dozen at most) and it should be obvious how the controls of the user interface help you do each task. Unfortunately many software companies prefer a “one size fits all” approach to development and end up creating a “one size fits nobody” product. If it’s not obvious how a software application’s capabilities relate to the task you have in mind, then it is strike three against the designer.

The Bottom Line

In recent years the nature of our daily lives has changed to such an extent that many of us spend the majority of our working and private lives sitting at a keyboard. Usability has become an important determiner of the quality of life for citizens of the twenty-first century. If the software you use is not intuitive, if it is not helpful, and if it doesn’t fit the tasks you want to do then walk away .. just walk away.

Tags:
Posted in General Human Factors, Usability | 3 Comments »


Making Medical Device Interfaces More User-Friendly

January 2nd, 2009

Add to Technorati Favorites

by Jim Bradford, MediCHI Consulting

Bradford says: Some surprisingly simple changes can often make large improvements to medical device interfaces.

~~~~~~~~~~~~~~~~~~~~~~~~~~

Citation: “Making Medical Device Interfaces More User-Friendly,” by Michael E. Wiklund, Medical Device & Diagnostic Industry Magazine, 1988, pp 177–182.

People who should read this: (1) the engineers and computer programmers who design medical devices, and (2) administrators responsible for buying new medical devices.

The Context: Medical devices are often designed by people with little understanding of human factors and user interface design principles.

Review:  At first I hesitated to review this article because it is two decades old. As I read it however, I realized that some advice is timeless.

Michael Wiklund has written extensively on medical human factors including three books on the topic:

  • Handbook of Human Factors in Medical Device Design (available, 2009)
  • Designing Usability Into Medical Products (2004)
  • Medical Device and Equipment Design: Usability Engineering and Ergonomics (1995)

In this article Wiklund revisits many of the standard best practices in user interface design but adapts them to the specific context of medical device design. He provides advice on:

  • Crowded display screens
  • Navigation issues (i.e., how a user moves from screen to screen)
  • Layout and hierarchies
  • Aesthetics
  • Typography and descriptive language
  • Effective use of icons
  • Consistency (one of the golden rules of interface design)

Even nontechnical readers (and perhaps nontechnical readers in particular!) will get a great deal of value from this article.

Human Factors has been an active discipline since the mid 1940′s [1]. During most of that time it has been an uphill battle to convince developers of the importance of human factors. After 65 years of experience many technical people still consider good interface design an optional, value-added feature. In my opinion we will only see developers taking human factors (and usability) seriously when customers become informed about the many benefits of a well-designed interface. Wiklund’s article serves as a model of the kind of writing human factors evangelists should be producing.

- – - – - – -
[1] The History of Human Factors and Ergonomics, by David Meister, CRC, 1999, 400 pg.

The bottom line: Physicians and medical administrators need to know that some comparatively simple design practices can make all the difference between a good and bad medical user interface.

Tags: , ,
Posted in Interface Design, Medical Human Factors | No Comments »

The Relationship of Usability to Medical Error

November 20th, 2008

Add to Technorati Favorites

by Jim Bradford, MediCHI Consulting

Posted: November 20, 2008

Bradford says: Devices with very small screens such as PDA’s and smartphones should not be considered as an input device for prescriptions or other medical note-taking.

~~~~~~~~~~~~~~~~~~~~~~~~~~

Citation: “The Relationship of Usability to Medical Error: An Evaluation of Errors Associated with Usability Problems in the Use of a Handheld Application for Prescribing Medications,” by Andre Kushniruk, Mark Triola, Ben Stein, Elizabeth Borycki, and Joseph Kannry, Medinfo 2004, pp 1073-1076.

People who should read this: (1) Physicians considering using handheld terminals, and (2) medical administrators concerned with the safety implications of handheld terminals

The Context: Using Personal Digital Assistants (PDA’s & smartphones) for writing prescriptions.

Review: Illegible handwritten prescriptions have produced safety concerns for over a century. As we enter the twenty-first century sophisticated new handheld devices hold the promise addressing this problem while simultaneously streamlining the way prescriptions are managed and monitored.

This paper evaluates a prescription writing system that replaces the traditional prescription pad with a Handspring Visor Pro personal digital assistant (PDA). The researchers recruited a group of ten volunteers all of whom were Internal Medicine physicians from the Mount Sinai School of Medicine. Each physician was given several medical scenarios and was asked to prescribe the appropriate medication and dosage using the handheld device.  The doctors were asked to verbalize the diagnostics thinking leading to a particular prescription.

The physicians were videotaped as they used the device. In addition, a record was made of the actual interaction with the PDA. A list of slips and errors were compiled across all ten physicians (a slip is a small mistake-equivalent to a typo; an error is a larger mistake-generally based on a misunderstanding of device operation).

A subsequent analysis of the video revealed a number of usability errors in the design of the prescription software. The researchers then used a tabular method based on a timeline to correlate user slips and errors with usability problems. They reached the (not unreasonable) conclusion that the usability problems contributed to the medical errors. Most of the time, these errors involved dosage problems rather than the prescription of the wrong medicine.

The experiment revealed two problems that were common to almost all of the participants.  The first related to the extremely small display area available on a handheld device.  When a significant part of the available screen “real estate” was given over to the menu system needed to operate the device, insufficient space was left to show all of the actual prescription. The researchers believed that many of the dosage errors that occurred derived from the fact that the physicians could not see the entire prescription at a glance.

The second major usability problem contributing to the observed medical errors, was the fact that many of the default values for the prescriptions were wrong from the physicians point of view.

Conclusions: The problem with the small screen size is a serious issue. It is something that is not easily corrected by changing the user interface design. It became very clear during the experiment that physicians (with many demands on their attention) needed to review their notes (in their entirety) at a glance. This is something that physicians and administrators need to consider before adopting handheld devices. A careful tradeoff needs to be made between portability and usability.

Fortunately, the second major usability problem relating to dosage defaults can be corrected fairly easily by ensuring that developers consult with physicians when setting up the system defaults.

The bottom line: Devices with very small screens such as PDA’s and smartphones should not be considered as an input device for prescriptions or other medical note-taking.

Tags: , ,
Posted in Medical Human Factors, Usability and Medical Error | 2 Comments »

5 Exceptional Things about Medical I.T.

November 15th, 2008

Add to Technorati Favorites

by Jim Bradford, MediCHI Consulting

Posted: November 15, 2008

The goal of human factors is to make complex computer systems easy to understand and simple to use. Unfortunately, computer systems are usually created by engineers and computer programmers. Throughout the development cycle, those who create computer systems tend to use themselves as a model for the user population. The result is often a system that is frustratingly difficult to use.

Computer systems fall into two broad categories. Many systems are developed for the general population (for example: word processors and spreadsheets). Other systems are developed to support particular industries (for example: banking, the airline industry or the medical profession). Each industry has its own special requirements and the medical profession is no exception. The following lists five major reasons why the human factors associated with medical information systems are a special case.

#1. Do No Harm: If someone makes a mistake while using a word processor it can be annoying but a mistake using a medical information system could cost someone their life. The design of a user interface can either increase or decrease the likelihood of error. The human factors expert must use what is known about human performance to minimize the risk of medical mistakes.

#2. Doctors are Always Busy: Programmers create medical information systems in the quiet of their cubicles, but physicians use these systems in environments that are anything but quiet. From the assembly line environment of a busy medical practice to the controlled chaos of an emergency room, physicians must retrieve information, make decisions, and update records with an absolute minimum of time and attention available for system interaction. A skilled human factors practitioner uses workflow analysis to create or select a user interface that meets the demands of a busy doctor or nurse.

#3. Adapt the Interface, Not the Physician: Organizations and professions frequently have a set way of doing things. This is often called “business process” or “professional protocol.” Software designers usually have little knowledge of the business processes their software serves. The skillfully designed user interface must ask the right question at the right time and must provide the correct information just when it is needed. The human factors expert is responsible for analyzing the business processes of a user population to make sure that the software serves the processes and not the other way around.

#4. When in Rome, Speak as the Romans Do: Few professions have such a distinct professional vocabulary as does medicine. Medical information systems must use the language of medicine and not require medical staff to learn a new set of terms specific to the software. It is the responsibility of the human factors expert to devise and conduct field studies with an actual user population to ensure that the medical information system uses the correct terms in the correct way.

#5. A House Divided Cannot Function: the issue of “cognitive load” is frequently important in the design of information systems. Can a person drive a car down a busy freeway while simultaneously talking on a mobile phone? Not everybody can. When a person’s attention is divided between several tasks, the possibility of catastrophic error can arise. There are few application areas where this is more critical than in the case of medical information systems. The concepts of “simple and intuitive” are most important when a medical practitioner should be devoting most of his or her attention to medical issues. The human factors expert must identify these critical areas of high cognitive load during the “requirements specification” phase of a system’s development and confirm that the designers succeeded in addressing these issues during the post-development field testing phase.

At a time when many medical practices are replacing paper-based record keeping with electronic medical records systems, the art and science of medical human factors has never been more important.

We are entering an era when hospitals, clinics, laboratories, insurers, and individual medical practices will need to communicate seamlessly with one another through computerized medical information systems. If the human factors is done right, we can expect to see physician productivity go up and the frequency of medical error go down. If the human factors are not done right, we will see productivity go down and the frequency of medical errors go up.

The key to realizing the potential of medical systems is to include human factors in the development cycle and to make extensive use of human factors when medical information systems are selected. Indeed the latter guarantees the former.

Tags: , ,
Posted in Medical Human Factors | 1 Comment »

Newer Entries »