You can see a lot by looking.
So said the inimitable Yogi Berra. Unfortunately, too few systems analysts do enough
looking. The rest hold meetings where the users chant, This is what we need.
Dutiful note-takers, the analysts design a software application that meets the stated
requirements but is rejected by end users as incompatible with reality.
Decades ago, I left data processing, now called information technology, for a brief
sojourn as a government economist. Before that, as a programmer I had diligently crafted
applications to user specifications only to see the applications sit on the shelf. The
users seemed truly interested in automated tools. So why, I wondered, did they act like
pathological liarsnever telling us what they really needed?
I decided this bizarre behavior required closer observation. My first assignment as a
newly minted economist was in an office that was having a product licensing application
developed by my old DP shop. As I sorted and filed product licenses by hand, I gradually
realized that, contrary to the systems analysts understanding, the new system would
not replace the paper process of issuing, filing and debiting licenses.
Instead, the new applications were destined to operate in parallel. The only value
added would be the annual summary reports. Rather than creating a paperless office, the
programmers were actually adding to the paper burden. Every number would have to be
entered on both paper license tally sheets and computer data entry screens. As a user, my
workload would double.
I shared these insights with my former DP colleagues, who were aghast that they were
churning out such a retrograde effort. This bit of intelligence blew the bottom out of
their cost-benefit analysis, revealing the project to be a waste of scarce DP personnel.
After a series of high-level meetings, the project was canceled. I was removed from the
license officelargely for my own safetyand told to develop commodity
databases. This was the IT equivalent of the witness protection program.
In my new position I worked with the economists who needed the database. As a result, I
got excellent support and experience watching them locate and manipulate data in their
day-to-day analytical assignments. Using a commercial report writer, I generated output in
a fraction of the time and cost it took my Cobol-coding colleagues.
As the new kid, I received detailed instructions about the work process and its
relationship to the contributions of co-workers. My job was to understand how the current
application worked, not solve any automation challenges.
The report writer was quite flexible, allowing us to tailor report content and format
to the needs of the assignment, something Cobol, with its overhead and documentation
requirements, could never keep up with. Users minor change requests usually just
added to the growing developers backlog.
Traditional systems analysis is conducted via group interviews, dominated by management
and expert users. Novice users, if permitted to attend at all, rarely speak. As a result,
system analysts get a distorted view of the desired outcome. The conversations tend to
focus on functionality, not usability.
The resulting applications may perform the requested functions, but theyre full
of problems. The user interface may be a poor fit for the typical user. Even the
users physical or social environment may be incompatible with the applications
design. For example, gregarious help desk technicians will resist going off alone to study
the new computer-based training package.
After many days of total immersion in working for those economists, the automation
requirements revealed themselves as obvious. I learned a lot by looking.
JoAnn Hackos and Janice Redish describe these problems and how to overcome them in
their excellent book, User and Task Analysis for Interface Design. They lay out a
methodology of observation and analysis and provide many excellent examples.
In part because they applied their own methods in writing it, the volume is
well-organized and easy to read. Systems analysts and programmers who follow the guidance
of Hackos and Redish will save much time and money by seeing what users really need.
Walter R. Houser, who has more than two decades of experience in federal
information management, is webmaster for a Cabinet agency. His own Web home page is at http://www.cpcug.org/user/houser.