The annoying part about not being able to talk to users is that even though you can design from forms, it’s nice to watch someone fill out the form so that you can put things in the proper order. Most people jump around forms, and if you can determine a pattern or fill out part of the form for them, people are much happier.

Then you have the mouse versus keyboard considerations [I’m a keyboard partisan], which are never easy.

Designing for yourself is the easiest path, Аня, but the “ergonomics” are more important if people are going to be happy.

Of course, I was not, ultimately, the sole user of my system, so I designed with that in mind. The company for which I created my database continued to use it for several years after I left — until the company finally folded (due to bad business decisions).

My proudest achievement was that I made the data entry forms “ergonomic” — I could enter that damned data all day long without getting a cramp.

As I have mentioned, I’ve had hardware thrown at me.

the design document i got for this project was a walk through the office:
–get those [points to wall full of filing cabinets] off of paper and into the computer.
–put those [points to boxes on top of filing cabinets] into the system if they’ll go.
–those [points to opposite wall full of filing cabinets] will be put into xyz system, will your system talk to their system?
–make it all as user-friendly as possible, but you can ignore suggestions from the users in department x. if this makes them all take early retirement, we’ll give you a bonus.

well, ok, that last one is a bit of hyperbole, but not by much.

I’m going to take a wild guess and assume that most of these systems were designed with billing in mind, not medical records.

Over the last 30 years I have learned that the last two groups of people consulted on any major IT project are those who are tasked with creating it, and those who will be tasked with using it. I have never seen a real, authentic systems design document, normally you are provided with a wish list that doesn’t even specify input and output.

My default procedure is to get copies of a company’s forms, and, wherever possible, design the screens to look like the existing forms.

The problem with doctors doing input is that they generally use a form that has three blocks: patient’s name, date, and text. There may be other boxes on the form, but those are the only ones that get filled in, and the name and date are filled in by someone else. It is disconcerting when halfway through an office visit you determine that the doctor thinks you are someone else.

With the minor alteration of putting medication names in an appropriate box, they could be checked against a database. And if the diagnosis is put in an appropriate box, more information could be provided from other databases. When everything is dumped in a text box, searches are made more difficult and the system is less useful.

Maybe. Or maybe the bad decisions about what is and is not included in those systems are made long before IT professionals get their hands on them.

Most such software is specified by committee, with the result one expects from committee work. In my experience, the software design team has at most one member on that committee, and when I’ve been that member, I’ve found I have very little influence over what the “suits” ultimately choose to do. They have their agendas, and they often don’t much care about your convenience.

I do not mean to excuse bad interface design or implementation, which is an IT professional’s problem… only to say that the higher-ups can be very insistent about functionality that is or is not included, and they often do not consult people in my shoes any more than people in yours, Anya.

Regarding doctors, it’s been probably 15 years since I’ve worked for an MD as such, and I can’t say I miss the work. Many of them are quite certain that an MD confers godlike knowledge on them. And one MD newly employed by an institution I worked for actually went into my desk space, rearranged everything and threw away my coffee cup (the china kind, not the Styrofoam kind). That’s not the way to get good work out of your programmer!

One thing I’ve learned designing and using databases (limited though my experience is) is that record-keeping systems should be designed around the way people are going to use them — not the other way around. It really cuts down on the learning curve if the machine is the tool of the user, and not some inexplicable video game.

I’ve been in too many places where a system was plopped down front of an operator who was told “You will use this” only to find that half their data was not accounted for and their previously functional procedures totally ignored. Why would anyone ask the peons how the system would/should be used? The human part of the system breaks down — and that why medical professionals resist.

Maybe it’s the attitude of the software designers that needs changing.