Developing Information

All things exist in time. They are not unchanging, and they cannot be designed without regard for the way they operate and are used over time. Any product can be viewed as a system operating with a user or users in different ways that are appropriate for its modes of existence. To plan effectively, a planning team must recognize these Modes, identify Activities that occur in them, and isolate the Functions that the system must perform (or the user must perform for it) within each Activity (Figure 3).

Typical Modes through which familiar hardware systems pass include: manufacture, distribution, transportation, storage, use, maintenance, repair, and retirement. For any given system, these may be replaced, augmented or supplemented with others; and major Modes may be subdivided into Submodes specialized for the individual case. In this project, the Modes were Diagnosis, Preparation to Initiate Proceedings, Alternative Dispute Resolution (ADR), Hearing, and Enforcement. Listing the Modes is generally not difficult, and the stage then is set to identify Activities that take place within them.

By definition, an Activity is a set of purposeful actions taken by users and system in an environmental setting. The actions of an Activity, thus, should be cohesive enough in purpose to be thought about collectively. Two difficulties make it hard to assign titles to Activities. First, the general complexity of real-life systems tends to make it difficult to bound Activities neatly. Second, the multiplicity of word choices available makes it difficult to find the right set of titles to achieve an intellectually satisfying balance. By trial and error, however, it is usually possible to name a set of Activities satisfactorily to cover the actions of a Mode neatly.

As a way to begin an analysis, it is helpful to think of Activities as scenes in a play. The analogy is completed by thinking of the set on which the play takes place as having props that are actively used in scenes (the system components) and others which provide background (environmental components). From scene to scene, new props may move into the center of attention, while ones of previous interest become background. Users, in the analogy, are the actors. The roles they assume reveal the special characteristics of users’ interests.

Setting the stage for an Activity and playing out the scene enable the planning team to see the Functions that are involved in the “performance”. It is these that must be identified, since these are, ultimately, what the system must do well (or help the user to do well). Each Activity entails the performance of a number of Functions, either by the system or by its users. Whether these Functions are retained in their original user or system categories in the final design is unimportant; Functions can be assigned and reassigned fluidly between user and system to obtain the best resolution of the problem within the set of Defining Statements. What is important is that a good coverage of the Functions is obtained.

Half of the purpose of the foregoing process is the enumeration of Functions. The other half is the development of information about these Functions that will shed insight on what happens as they are performed.

Treating the system to be designed as a user/system model allows it to be analyzed from the perspective of the system or of the user. From the system standpoint, classic systems analysis observes operations and determines relationships among components – toward the creation of a system model with features that can be described and processes that can be simulated. The analysis of Activities scrutinizes users’ actions for the purpose of building an organization of Activities describing user behavior. Both kinds of analysis are useful for producing hard data and constructing a model. In fact, the process model just discussed draws from both. But the hard data is not enough to guarantee a good conceptual design.

What is necessary is insight; information as distinguished from data. Information has surprise – it reveals something not known before, or not thought of in the same way before. In the search for patterns, data may lead to information; when it does, a considerable amount of data may be distilled into a much smaller (and more manageable) amount of information, producing what is most useful to the conceptual planner: real insight into the nature of a problem. This frequently can only be expressed in soft or qualitative terms, a form difficult to deal with by quantitative means – but most valuable for the generation of ideas.

In the Action Analysis process, Functions are associated with insights – about why things go wrong in performing the Functions, or about how special factors combine to allow other Functions to be performed well. These insights are documented as Design Factors and become part of a qualitative information file along with the Functions.

Activity Analysis forms (left in Figure 4) record information at the Activity level. Design Factor forms (right in the figure) document insightful observations and ideas associated with the Functions of an Activity.

The Activity Analysis form is divided into three sections. In the first section, at the top, the scene is set. Users are listed by roles or types, and system and environmental components are identified. In the sections below, Functions are listed either as actions taken by the system or actions performed with the system by users. As they are developed, Design Factors listed to the right of the Functions to which they pertain.

Formats for naming Functions and Design Factors are fixed. Since a Function is essentially an action or maintenance of a condition, the most natural way to describe it is with a verb phrase. Design Factors are about problems and insights. To make titles for them most useful, they should capture in a concise phrase the essence of the insight the analyst has realized. In that way it is most likely to remind planners accurately of the problem (or opportunity) when they see it.

The Design Factor document contains a number of entries. Its primary purpose, however, is the provision of information of two kinds: information about the problem (or opportunity) detected, and information about what might be done about it. The fact that problem and solution are both covered in the same document is not accidental. It is important that when insights are recognized, ideas be sought for how to use them. These ideas may not be used in a final concept for the system, but they are important as progenitors and are used in structuring the information file later in the process.

The Observation section is the first of two sections dealing with the problem. An Observation is a sentence in which an insight about the performance of a Function is recorded. As much as possible, it should distill the essence from the observed phenomenon. Frequently it is helpful to express the sentence in a condition/occurrence format. In this format, a condition is defined in a dependent clause; and an occurrence that takes place when this condition is present is described in a following independent clause. If this format is used, the conjunctions “if”, “when”, “while”, “because”, “where” or others may be helpful in introducing the condition. It is important, however, not to overstate (or overrate) the certainty of the relationship between condition and occurrence – the term Observation is meant to indicate that a phenomenon is observable, nothing more. A cause/effect relationship should not be inferred when, in fact, that strong a relationship cannot be justified (more than one cause may be required for the effect; the effect may be one of many and not justifiably isolated; the effect may not always follow from the cause; etc.).

Associated with the Observation section is a section labeled Extension. In this section, explanatory material is placed to extend or develop the information of the Observation. No matter how thoughtfully worded, the single sentence of the Observation seldom is enough to convey the insight adequately. The whys and what-do-you-means? that inevitably are asked are addressed in the Extension. Supplementary material from other sources may be discussed; examples may be cited; contributing phenomena other than those mentioned in the Observation may be introduced; side effects may be considered. After examining the Extension section, readers should have a good understanding of the insight of the Design Factor. They should be able to appreciate its value and, perhaps, even anticipate the directions for using it that will be suggested in the next sections.

The first of two sections dealing with ideas is the Design Strategies section. Design Strategies are, by definition, generalized suggestions for how to react to the information of the Observation and its Extension. They express the implications that this information has for design. For a format, they take an imperative verb phrase, carefully crafted to prescribe an approach without specifically describing a solution. Typically, Design Strategies are specialized for the situation from general strategies for problem solving such as: confront the problem, remove the cause of the problem, avoid the problem, block the problem, divert the problem, break up the problem, reduce the problem, etc.

The Solution Elements section is the second solution section. Specific ideas go into this section. Solution Elements are ideas well enough described to be evaluated as useful to the system being developed. They do not have to be original; in fact, they are distinguished as being existing, modified or speculative, depending on the level of innovation that the planning team feels that it has contributed. They are important for determining interaction among Functions (as shall be discussed) and may actually be used in the overall solution, but they should not be overly valued at the time they are written. For a name format, they take a noun phrase. Noun phrases express concepts well and are easy to remember – especially if they include colorful phraseology. A good name for a Solution Element has an adjective and a noun chosen to create an evocative title. Such a title, once explained, is readily retained in memory, and a wealth of detail associated with the concept is usually recalled with it.

Other sections on the Design Factor form serve administrative needs. The Originator section records the author of the Design Factor. The Associated Functions section ties the Design Factor to the Functions

for which it was written (the title should appear as it does on the Activity Analysis forms). The Title block names the Design Factor and is the name found on the Activity Analysis form as the Associated Design Factor for a given Function. For Source/s, an entry following standard bibliography format is used (with footnote entries in the text to locate specific reference pages). If the information is derived from the Originator’s direct observation or personal experience, the Source entry may read “Personal observation”.

Solution Element documents (Figure 5) detail the ideas noted on Design Factors. These documents are one-page, short forms designed to capture enough detail about ideas to give them substance when they are needed later. Besides the same kinds of reference blocks used on Design Factors and Defining Statements, they have three important sections. The first, Description, is for a short, one or two phrase explanation of what the Solution Element is. This is expressed at a general level and should be just enough to identify what it is and what it does at a high level. The other two sections, Properties and Features, isolate the specific aspects of the idea that give it its identity.

Properties are what it is. Expressed in noun phrases, a series of bullet lines establish what functional entities need to be present to make the concept work. Features are what it does. Verb phrase bullet lines do the same thing for its benefits. Essentially, the Properties are what the design and/or engineering teams will want to know (what has to be developed), and Features are what the communications, and/or marketing teams will need (why someone will appreciate it).

The simplicity of the Solution Element form and the directness that it requires for description give it its value. In the press of analysis, observation and search for understanding, many insights unfold and many ideas emerge almost unbidden. In conventional processes, these are mostly lost for lack of any systematic way to capture them. In Structured Planning, the Solution Element form is the tool for capture.

The results of the Action Analysis process are collected in a Function Structure (Figure 6). The Function Structure reveals the what must be accounted for by the project in both breadth and depth, and provides a visually convenient means for judging the coverage of the analysis process. The product of the Action Analysis process is actually much more, of course. Three sets of critical information have been obtained: a set of Functions, a set of insights and a set of ideas – the latter two described in Design Factor and Solution Element documents.

Paradoxically, as useful as the Function Structure is for establishing coverage, it is not the best form of organization for developing concepts. Organizing information for use in concept development is the job of two computer programs, RELATN and VTCON. These programs incorporate specialized theory for how information should be structured for the synthesizing phase of planning.