Defensive Buying - Your Key to Selecting the Best Medical Software

The ancient concept of "buyer beware" is important in the field of medical software. Modern medicine is a complex discipline and the software that serves the needs of medical professionals is equally complex. In an ideal world informed consumers would insist on software that is easy to understand and easy to use. Unfortunately becoming a fully informed consumer is a lengthy and difficult process.

Is there a better way? The answer is yes! The discipline of Defensive Buying equips medical professionals with just enough knowledge to recognize good design. Companies that do a good job on design spend a lot of time working to understand the needs of their users. If the hallmarks of good design are present then you can be confident you have found a quality product.

The key indicators of superior design all relate to the human factors of the user interface. Human factors combine the disciplines of psychology and computer science to produce software that works effectively with the way people think and solve problems.

Let's stand the problem on its head. Here are ten signs of badly designed software. If you see more than two or three of these in a system, it is time to look elsewhere.

1. A disconnect between tasks and functionality - a task is something you want to do and a function is a capability of the system. Tasks and functions should match up well. If they don't then the system designers have not done their homework.

2. Constantly searching screens for the information you really want - a system's screens should provide you just the information you need and nothing more. Medical information systems tend to provide every possible piece of information just in case a user might need it. This greatly increases the mental load on the user.

3. Froozle the Catlob (commands seem to be written in a foreign language) - every discipline has its unique terminology. Does the software use yours?

4. The most frequently used commands are deep in the menu hierarchy. The most frequently used commands should be the most accessible. How does a designer know what the most frequently used commands will be? By studying the user population and the way they work!

5. Proliferation of workarounds - a workaround is a kind of trick to make software do something it doesn't do easily. If many workarounds are required to make a system do what you want then this product is not for you.

6. Too many special cases - why can’t I have a ‘/’ in my filename? In the software business we have an acronym for everything. One of my favorites is LPS (lazy programmer syndrome). LPS accounts for a lot of bad design. If you find that you have to memorize many special cases and arbitrary restrictions then you can be certain that your software was designed by lazy programmers.

7. Descriptive rather than prescriptive error messages. Descriptive error messages tell you what went wrong; prescriptive messages tell you what to do. Well designed systems provide the latter. If a software system EVER produces descriptive system messages (Java exception errors, array bounds errors, etc) then it qualifies as the worst of the worst. Buying such a system guarantees a life of constant frustration.

8. The summer intern wrote the help system. Programmers like to program. They do not like to write help systems, user guides, and tutorials. In poorly managed companies, the low man (or woman) on the totem pole gets to write the system documentation. In most cases the result is terrible. Before making a buying decision, spend 20 minutes browsing through the help system and the documentation. If you can't make any sense of it, you can be certain this software was written by a poorly managed company.

9. You Google your question and find 237,000 hits. Google has become a wonderful resource for user communities. If you are having trouble understanding something about a system then use Google to do a search based on your question. If you discover a huge number of people asking similar questions, it suggests that the system developers did a poor job understanding the needs of their users.

10. Your local college offers a course on using your application. If a system is so confusing, complex, and poorly documented that somebody is offering a course on it, avoid this system at all costs!

A few hours of your time and the 10 indicators of poorly designed software should protect you from the worst purchasing mistakes. This small investment of time will free up countless hours that would have been devoted to fighting with poorly designed software—hours that can now be spent practicing medicine!

Jim Bradford, is a former college dean who has more than 25 years of academic, industrial, and consulting experience. He offers a workshop on Defensive Buying for medical professionals, see: www.medichi-workshop-nv09b.com.