Questions From ANOTHER Interaction Designer

Another anonymous PACS designer chimes in:

I'm an interaction designer/programmer as well. And I find Cooper & Reimann's book Interaction Design 2.0 to be useful in educating programmers about generic user expectations and behavior. It also introduces some important concepts which we use in our design guidance documents.

As much as I agree about the importance of good interaction design, market forces are such that what people pay for (from among what is offered) is what the market will provide more of. So I have some questions related to that.

1) When purchasing a PACS, how do radiologists evaluate the software interaction? To what extent are they willing to try out unfamiliar(but possibly better) interaction models, and how much time are they willing to give to that process?

2) Does anyone evaluate the ease of use of anything besides the radiologist's workstation? If so, what?

3) How much is usability weighted in the purchase decision? And how much of a premium (in purchase price) is a superior design worth?

Very good questions, all. Here, we really get to the crux of the matter, whether a more usable product is a sales advantage, and worth more than Brand X.


Now, I can answer all of these according to my own, biased, radiologist-centric viewpoint, which might not be accurate for all involved. Based on my experience and research and observation, it is probably rare for the radiologists to actually decide which PACS to buy. As often as not, the choice lies in the hands of bean-counters, and/or the IT folks, who may or may not pay attention to the needs, wants, desires, and whines of the radiologists.


So, how do radiologists evaluate the software interaction from a 10-minute demo? Very poorly. It is impossible to see how a complex piece of software will behave in your hands in that short a time. In most cases, the sales or apps person is "driving" anyway, and we poor rads get no hands-on time at all. From this brief exposure, we are supposed to make a million-dollar decision. I have long advocated prolonged web-based demos, and I still think they represent the best approach.


When I'm looking at new software, I try to use it as if I were actually in a production environment. This isn't easy, especially in a 10-minute demo, but it can and should be done. Now, trying new processes is a problem. I, for one, am willing to do so, but some are not. If the keys to the "new process" are not immediately obvious, if it is not intuitive, it will be bypassed.


Let me go off on a tangent for a moment. I received a disk from St. Elsewhere over the weekend with a client program from a smaller PACS company. The damn thing loaded VERY slowly, and the GUI was esoteric. I was actually in the middle of writing a hatchet-piece about the program in between call cases. However, the more I worked with the viewer in the process of digging up dirt on it, the more I found it useful, or put another way, the less I hated it. Thus, unfamiliarity in this business breeds contempt. Now, this particular program will never reach the level of Dalai-usability, but it wasn't quite as bad as I first thought. There is a balance, a threshold of what works well for all immediately, and what will eventually work better than you think it will initially.


How much time will we give to checking out something new? Probably not enough. Again, we need to see quickly that your new process is better than the old way.

Hopefully, PACS admins and IT types are allowed to look at the back-end of the system as well as the front. The best GUI in the world is useless if its underpinnings don't work well. The support folks need to be checking out the administrative tools, ease of fixing studies, and ten dozen other things that I couldn't even begin to name. Yes, I do indeed acknowledge their importance!

The part usability plays in the purchase goes right back to who is really in charge. If the rads ignore the job of selection, and just depend on the proverbial "someone else" to do the picking, then it probably doesn't matter at all. The same is true if the rads are excluded from the decision altogether. (It happens, trust me.)

And it needs to be stated that usability is in the eyes (and mouse) of the beholder. One of my senior partners proclaimed for the first time yesterday that he vastly prefers Agfa Impax 6 to Amicas LightBeam. Why? Because with Impax, you can access the ruler tool via the right-click menu, and with LightBeam, you have to scoot the mouse up to the tool-bar. The other features (no matter how well or poorly done) don't matter to him one bit, at least they didn't yesterday. Now, my other 27 partners think just the opposite, but you see the dilemma. Whom should the designers target? Why me, of course!

How much is a good design worth? That's somewhat of a trick question. In the PACS business, there is a significant disconnect between price and design. I don't have to go there again, do I? Designing a program that actually works properly in the hands of real users might well cost more that just letting the engineers/designers/programmers run loose. There should be numerous iterations of redesign and retesting with real live radiologists, especially those who do not already use the company's product. That's a hard process to quantify and deciding what it's really worth is even harder.

I've been preaching about GUI design for years and years. It's nice to see the concept finally get some attention, and I really appreciate hearing from the guys on the front lines in this effort. Will their hard work pay off? It should! The better, more usable PACS should sell better than the clunker, but that may not work so well in the real world, where IT may decide to purchase from the company that "no one ever gets fired for chosing," whichever that might be this week. But keep up the good work guys; sooner or later someone WILL be fired for picking an unusable system. Someday. I promise.