HUMAN-CENTERED PRODUCT PLANNING AND DESIGN:ENGINEERING PHASE

1. ENGINEERING PHASE

The purpose of the engineering phase is developing a final design of the product or system. Much of the effort in this phase involves using various design methods and tools in the process of evolving a conceptual design to a final design. In addition to synthesis of a final design, planning and execution of measurements associated with evaluation, demonstration, verification, and testing are pursued.

Four-Step Process

In this section, a four-step process for directing the activities of the engineering phase and docu- menting the results of these activities is discussed. The essence of this process is a structured approach to producing a series of design documents. These documents need not be formal documents. They might, for example, only be a set of presentation materials.

Beyond the value of this approach for creating a human-centered design, documentation produced in this manner can be particularly valuable for tracing design decisions back to the requirements and objectives that motivated the decisions. For example, suggested design changes are much easier to evaluate and integrate into an existing design when one can efficiently determine why the existing design is as it is.

It is important to note that the results of the naturalist and marketing phases should provide a strong head start on this documentation process. In particular, much of the objectives document can be based on the results of these phases. Further, and equally important, the naturalist and marketing phases will have identified the stakeholders in the design effort, and are likely to have initiated relationships with many of them.

Objectives Document

The first step in the process is developing the objectives document. This document contains three attributes of the product or system to be designed: goals, functions, and objectives.

Goals are characteristics of the product or system that designers, users, and customers would like the product or system to have. Goals are often philosophical choices, frequently very qualitative in nature. There are usually multiple ways of achieving goals. Goals are particularly useful for providing guidance for later choices.

Functions define what the product or system should do, but not how it should be done. Conse- quently, there are usually multiple ways to provide each function. The definition of functions sub- sequently leads to analysis of objectives.

Objectives define the activities that must be accomplished by the product or system in order to provide functions. Each function has at least 1, and often 5 to 10, objectives associated with it. Objectives are typically phrased as imperative sentences beginning with a verb.

There are two purposes for writing a formal document listing goals, functions, and objectives. First, as noted earlier, written documents provide an audit trail from initial analyses to the ‘‘as-built’’ product or system. The objectives document provides the foundation for all subsequent documents in the audit trail for the engineering phase. The second purpose of the objectives document is that it provides the framework—in fact, the outline—for the requirements document.

All stakeholders should be involved in the development of the objectives document. This includes at least one representative from each type of stakeholder group. This is important because this doc- ument defines what the eventual product or system will and will not do. All subsequent development

assumes that the functions and objectives in the objectives document form a necessary and complete set.

The contents of the objectives document can be based on interviews with subject-matter experts, including operators, maintainers, managers, and trainers. Baseline and analogous systems can also be valuable, particularly for determining objectives that have proven to be necessary for providing specific functions.

Much of the needed information will have emerged from the marketing phase. At the very least, one should have learned from the marketing phase what questions to ask and who to ask. All the stakeholders in the process should have been identified and their views and preferences assessed.

The level of detail in the objectives document should be such that generality is emphasized and specifics are avoided. The activities and resulting document should concentrate on what is desirable. Discussion of constraints should be delayed; budgets, schedules, people, and technology can be considered later.

Requirements Document

Once all the stakeholders agree that the objectives document accurately describes the desired functions and objectives for the product or system, the next step is to develop the requirements document. The purpose of this document is to identify all information and control requirements associated with each objective in the objectives document.

For evolutionary designs, baseline and analogous systems can be studied to determine require- ments. However, if the product or system being designed has no antecedent, subject-matter expertise can be very difficult to find. In this case, answers to the above questions have to come from engi- neering analysis and, if necessary, validated empirically.

The requirements document should be reviewed and approved by all stakeholders in the design effort. This approval should occur prior to beginning development of the conceptual design. This document can also be very useful for determining the functional significance of future design changes. In fact, the requirements document is often used to answer downstream questions that arise concerning why particular system features exist at all.

Conceptual Design Document

The conceptual design of a product or system should accommodate all information and control requirements as parsimoniously as feasible within the state of the art. The conceptual design, as embodied in the conceptual design document, is the first step in defining how the final system will meet the requirements of the requirements document. The conceptual design document should de- scribe a complete, workable system that meets all design objectives.

Realistically, one should expect considerable disagreement as the conceptual design evolves. How- ever, the conceptual design document should not reflect these disagreements. Instead, this document should be iteratively revised until a consensus is reached. At that point, all stakeholders should agree that the resulting conceptual design is a desirable and appropriate product or system.

Detailed Design Document

The fourth and final step in the design process involves synthesizing a detailed design. Associated with the detailed design is the detailed design document. This document describes the production version of the product or system, including block diagrams, engineering drawings, parts lists, and manufacturing processes.

The detailed design document links elements of the detailed design to the functionality within the conceptual design document, which are in turn linked to the information and control requirements in the requirements document, which are in turn linked to the objectives within the objectives doc- ument. These linkages provide powerful means for efficiently revising the design when, as is quite often the case, one or more stakeholders in the design process do not like the implications of their earlier choices. With the audit trail provided by the four-step design process, evaluating and inte- grating changes is much more straightforward. As a result, good changes are readily and appropriately incorporated and bad changes are expeditiously rejected.

Summary

In this section, the engineering phase has been described in terms of a documentation process, including the relationships among documents. As noted earlier, this documentation need not be overly formal. For instance, documents may be simply sets of presentation materials. The key is to make intentions, assumptions, and so on explicit and to ensure that key stakeholders, or their representatives, understand, agree with, and will support the emerging design solution.

Obviously, much of the engineering phase concerns creating the contents of the documents de- scribed here. Many of the other chapters in this Handbook provide detailed guidance on these en-

gineering activities. Human-centered design is primarily concerned with ensuring that the plethora of engineering methods and tools discussed in this Handbook are focused on creating viable, ac- ceptable, and valid design solutions.