Putting a bad system on a computer doesn't necessarily improve it

Over 35 years ago

The first computer system I ever worked on started out as a disaster. The developers had put all their effort into the computer system logic and programming, and in those distant times with programming in machine language and data entry by manually punched cards, errors were expensive to correct. But the developers overlooked the most important factor in their system—the people. But that was not the only computer disaster. As the years wore on, I experienced failure after failure as computer 'professionals' continued to put the machine ahead of people. As unbelievable as it may sound to many modern IT people, I've seen more system failures than successes in a wide range of organisations, both private and government, and the same problem continues as I write.

Am I knocking computers and modern technology and IT people in general? NO! I think modern technology is wonderful and I love what we can do today compared to what was available even five years ago. But there's both GOOD and BAD practice, and unfortunately, my experience over 40 years has been that there's a lot more bad practice than there is good.

In 1976, British author and IT lecturer Keith London, described computer systems in his book The People Side of Systems.

“Programmers often see an organisation in black and white: the nuts and bolts of document flow, clearly defined file data element characteristics, precise logical program branches, rigid computer operations schedules. The very nature of the computer itself requires that a program be specified in precise, formal terms. He is, in his everyday work, seeing only the formalized tip of an iceberg. If such a programmer becomes a systems analyst, he would now investigate and analyse. If he were to maintain his mechanistic perception of a system, his work would be doomed to failure. For he would still see only the tip of the iceberg of the formal procedures and data. The bulk of the iceberg in systems terms is the people, their jobs and their attitudes."

Today!

Even now, over 30 years after Keith London wrote, analysts and system developers still make the same mistakes, failing to consider the people and the way they work with the business system. I wish this was an isolated case, but long and continuing experience has proven otherwise.

An important lesson

When I was being introduced to business systems, I learned a very important lesson—FIX THE BUSINESS PROCESSES FIRST and then add the computer. Michael Hammer and James Champy, in their book Reengineering the Corporation, give the example of IBM Credit who “in trying to automate its operations…managed only to immortalize a bad process by committing it to computer software, making it even more difficult to alter in the future.” You’ll find more about reengineering business forms in a longer paper on our web site.

If you computerise a bad system, all you do is make the problems occur faster.

My first involvement in GOOD computer input form design was in 1979 when I was asked to work with one of our state police departments. Their approach was radically different to what I had previously encountered. Instead of being given an input layout prepared by a programmer and told to get on with the design, I was handed a copy of the draft specifications. The result was that I was able to point out where some of the input requirements were going to cause problems for the users. This led to the development of a new data entry concept for the project followed by the design of the draft forms and procedures before the real programming took place. Once the designs were worked out and checked with potential users, the programming commenced and the system was implemented very smoothly. I'm told that those forms are still in operation today.

The future

As we move further into the 21st Century we need to remember these lessons as more and more of our forms become electronic. If many software developers had their way, paper forms wouldn't exist. Even from administrators, there's an ongoing push to place ALL forms on the Internet, especially from government, but with no thought about whether that's the best way to go; no thought about the limitations of current Internet technology or even whether people are prepared to use forms that way. We're getting an increasing number of reports from government sources that many members of the public are objecting to electronic forms. I'm not suggesting that electronic forms are bad—after all, our company sells electronic forms software—but I am suggesting that we need to use them wisely. We need to put people first, and that includes internal staff as well as the public. We need an holistic approach, taking all factors into consideration—human psychological needs, user literacy, ergonomics, efficiency and corporate productivity, work flow (both paper and electronic), reliability of captured data, information accessibility, and much more.

Many managers throw technology at their problems like a person giving aspirin to someone with a brain tumour. To solve business problems you need to know what the REAL problem is and then find the CAUSE. Then, maybe—just MAYBE—technology might help to provide an optimum solution.

Usability News

Here's another good source of information on usability: Usability News.
Once you're there it's worth doing a search on "Caroline's Corner", where you'll find lots of articles by Caroline Jarrett on usability, some of which deal with forms.

Usability Professionals' Association - UPA

I have now joined the Usability Professionals' Association (UPA). It will make a valuable addition to my source of knowledge and I can highly recommend it.
The Association can be found at: http://www.upassoc.org/.

Boinx FotoMagico a great Macintosh Application

I've just installed and started using Boinx FotoMagico on the Mac.
What a great application! We'll be using it to create video training courses with presentations out of Apple Keynote with a recorded commentary. I can highly recommend it.

Failure to Learn - Anthony Hopkins - Lessons for forms management

On Thursday I commented about IT people failing to learn lessons over the past 40 years. Then yesterday I received a copy of the book "Failure To Learn" by Prof. Anthony Hopkins of the Australian National University. The book deals with the BP Texas City Refinery disaster in 2005. It follows on from an earlier book "Lessons from Longford" which dealt with a similar disaster at the Exxon Gas Plant in Melbourne Australia in 1998. BP had known all about the Exxon disaster but failed to learn the lesson.

When I read the Longford book, I was struck by the relevance of the issues raised by Anthony Hopkins to management in general and to forms management in particular. The result was a class delivered at the Business Forms Symposium in Phoenix in 2006. The associated paper is available for download from our web site.

As I thought about the issues further, It became startlingly evident to me that it wasn't only forms management that was relevant to forms professionals, but also form design. Why are so many form designers around the world still designing forms as if they live in the 1950's. I and others have written and lectured numerous times about how the old fashioned ideas of the mid 20th Century just don't work for public-use forms. Yet designers fail to learn the lessons. They continue with old ideas such as tiny boxes with "upper left corner captions" instead of questionnaires, no lines on the ends of boxes, cryptic box labels instead of plain language, "tramline" delimiters for data entry fields, etc.

The problem is heightened in the USA with antiquated legislation such as the Paperwork Reduction Act which only exacerbates the problem by reducing the amount of paper but increasing the work. Administrators wonder why so many people have trouble filling out the forms. Organizations complain about the amount of time it takes to deal with the errors people make and provide expensive help desks for form fillers. Yet with modern approaches they could reduce all this to minimal amounts.

For example, between 80% and 100% of public-use forms typically have one or more errors in the data collected, yet with best practice design this can be dramatically reduced to as low as 5%. I know of one case in Australia where it was costing $10 million per year just to correct the errors form fillers make—and that's with a country of only around 20 million people. What is the cost in places such as the USA or India with a much larger population?

So while I was castigating the IT profession for failure to learn, forms designers and forms analysts need to learn some lessons as well.

Label field alignment and eye-tracking for online forms

I've just finished reading a paper by Das, McEwan and Douglas on a report of eye-tracking for label alignment in online forms. While it didn't really say anything new, I found it interesting that it confirmed what we'd already learned over the past 25 years through observational studies and usability testing. That is, it is faster for users to have labels for lists of ballot boxes right aligned to the boxes rather than left aligned with a gap between the label and the box.  It is effectively no different to what should generally happen with paper forms.

The paper title is "Using Eye-tracking to Evaluate Label Alignment in Online Forms".

It can be purchased here.

Why do IT people make forms and procedures an after thought?

After forty plus years in the business I'm still amazed at how many IT people think forms and procedures are unimportant.

Go to a meeting and talk to analysts and as soon as the subject comes up their eyes glaze over as if it is too childish to discuss. When we tell them we design forms and write procedures they generally aren't the slightest bit interested.

Sometimes I come across someone who understands as I did recently at a meeting at IBM, but that is rare indeed.

Yet how many systems have you come across that don't do what they are supposed to do because the data collection part of the system doesn't work properly. Most systems start and often finish with forms. They often need forms during the process as well. The trouble is that IT people tend to think that because it is on a computer screen, the form is no longer a form. Yet the same general principles apply as for paper forms. Even worse are the forms often created by web designers who think that they are different again. There are some technical differences due to the way people use the screens over paper entry, but these are only minor compared to issues such as getting the language and data entry sequence right.

I often tell such people that if they don't think forms analysis is a big subject then why does it take a 500 page text book to tell people how to do it?

You'd think that after nearly 50 years of business computing and having systems fail over and over again, that they'd learn some lessons.

When will they ever learn that if they want their computer system to work properly for the end users, then they should get the forms and procedures right FIRST—before they start writing code?

When will they ever learn that forms analysis and procedures analysis are specialised professions?

Managing email

Came across this great information today. It's well worth watching.
Click here to see it.

It comes from Merlin Mann at:
http://www.43folders.com.

In it he talks aboout a tickler system.  I've started using MailTags (Mac only - maybe something similar for Windows) and it is terrific.

It does so many great things, I'd hate to be without it now.

See the following URL:
http://www.indev.ca/MailTags.html