Wednesday, August 3, 2011

Work With the System

Most systems have intent. They - courtesy of their creators - have workflows, expected usage patterns, etc. At their core, the creators of the system had one or more ideas of how the system would be used, and they optimized the system for those uses and those ideas.

For example, an archive storage system I worked on was designed specifically for archiving data. This intended use had several manifestations: it was highly optimized for writing and not for reading; and data integrity was paramount, even at the cost of speed or price.

As another example, I worked on an electronic medical record system. It was designed to be very friendly for physician use and to be a "one stop shop" for patient medical data. This intended use meant that physician workflows (ordering prescriptions, for example), could be accomplished faster and withe fewer clicks than insurance workflows (reviewing payment data); we had optimized the system for physician use. The intended use also meant that we had many interfaces to other systems, but almost all of them were other clinical systems (labs, or radiology systems) and not to insurance payment systems.

Now, could you use the system for something outside its intended purpose? Yes, absolutely. To continue the example of the medical record system, it's entirely possible to deploy it in a medical billing office. It'll just be harder to use.

And that's today's lesson:

Work with your system, not against it.

Yes, it's frequently possible to use the system in ways the creators didn't intend. Most of the time it'll even mostly work. But it will be harder than it should be. You'll run across non-intuitive workflows. Performance will be a slower. You'll find odd bugs in things that most users will never see but that are important to your workflow. You'll get frustrated.

So before you go making a system do things that the creators didn't mean for it to do, try finding something that actually is intended to do what you want. If you can work with the system, you'll have a much easier time.

1 comment:

  1. This rings true for me not only when speaking about systems, but also testing tools and methodologies. This is also why I try to maintain a varied skill set. Many tools and methodologies are designed with a specific intent and when you try to force them into an area for which they're not designed, you end up blowing your project scope or working long hours. Square peg, round hole?

    - Chad