Designing for Change: Dynamic Communications Using a Logical Model
The Human Factors Engineer is often called upon to perform tasks requiring a substantial amount of interviewing for workflow data gathering. This is certainly the case when a new EDP system is being investigated/restructured or when the manual workflow of an organization is being investigated. The Human Factors objective, in this sort of workflow analysis is to maximize the efficiency of any change and minimize the disruption (during and after the investigation) to the personnel involved. A careful task and workflow analysis must be performed since simply replacing manual tasks with a computer will not necessarily result in efficient workflow or task performance. The analysis must include the entire universe of tasks that are or could be performed in order to determine the information flow, when to remove from or insert the human in the mechanized system loop, etc. The present paper describes a methodology for building what we refer to as a logical model of both the user and system environments. Often, the only certainty facing system designers and Human Factors Engineers is change in the work environment and in the use of the EDP systems supporting that work. It makes sense then to build into the design of the work environment and EDP systems the greatest flexibility and modularity possible. The present paper describes how, by using the proposed logical model methodology, the Human Factors Engineer becomes the “agent of change” on any development team. The improved analysis and design methodology contains five major activity steps which lead to the creation of a working logical model. These activity steps are: 1) Identification of the working environment; 2) Establishment of the organization and system scope: 3) Development of a functional hierarchy; 4) creation of work and data flows; and 5) Documentation of each identified work and system module. Each step is illustrated and described in detail in the paper. Also, how each step, by its and in coordination with the other steps, is used to build the working logical model is discussed. The paper describes the methodology in an instructive manner. Drawing from experience gained by utilizing the methodology, the advantages and disadvantages are highlighted. Any design methodology, however useful, is dependent on the willingness and commitment of all team members to implement it. The steps taken to gain broad acceptance of the methodology are discussed within the paper. In essence, the logical model can be used by the Human Factors Engineer as a dynamic communication device providing two way communication between designers, implementors, and user organizations. As design options in system development become available the Human Factors Engineer can demonstrate the impact of the options. Also, newly discovered user requirements can be added to the model and communicated to the designers.