Develop Tools for the End Users not for problems

I guess it falls somewhere under teaching an old dog new tricks. But, my current project has forced me to re-evaluate some of the tactical decisions we have made in previous projects.

A bit of background: We are currently working on development of a software system to help fix some of the process problems in hospitals. And believe me, hospitals are target rich environments for process improvement.

The unique twist here is that we have to allow non-technical hospital employees to build and maintain fairly complex process rules. This forced us to start thinking of the tool from the real end users capabilities and work backwards to the actual system. The net effect is that the system is modeled after every day, commonly understood abstraction that help to minimize training. We have been very diligent at eliminating complexity where it was not needed, and especially at avoiding anything that even smelled of "programming".

I know this sounds like a common sense thing to do, but it doesn't normally happen that way, at least not around here. In the past, our approach would have been to build a tool to match the problem first, and then back in to administrative capabilities and training necessary to allow our customers to do their jobs. The result was almost always heavily dependant on the idea that our target audiences would want to solve the problem badly enough to "stretch themselves" a bit to learn how to manage the new system. While this was sometimes true, in retrospect, it limited our customer audience to those few who were willing to do so. The rest of our prospects would tune us out, when our sales pitch started to look complicated.

This time around, the target administrators were so different; we had to keep the end user in mind every step of the way. To accomplish this, we tried to picture nurses using each new feature before it was put into the tool set. We don't know if nurses will actually be maintaining these rules, but we have designed the system so that nurses could maintain them with minimal to no training.

While it is still early days, the result of this approach to the problem is very promising. The software module in question is not a hurdle, and in fact nurses attending some of our presentations have specifically said: "I could do that!".

Also, the clean, simple abstraction we followed, has allowed us to pick up this new software and plug it into an existing, well established Call Center technology that our company also sells.

Lesson Learned: In the future, I will try to design all of my systems with the end user foremost in my mind and will strive to eliminate any complexity that that audience would not already be prepared to deal with. I know that will not always be possible, but it should be the rule, not the exception.

Tags: engineering, software