What Makes a Good Design Factor?

General
Design Factors are the most important documents of the Structured Planning process. In one place a Design Factor captures insight about the subtleties of good and bad performance-and ideas for what might be done to improve. It is qualified rather than quantified information, and it contains clues to the elusive why questions that underly design and planning decisions. It is the information most difficult to obtain and most easily lost.

A good Design Factor is not quickly developed-not because it is difficult to write, but because it requires thoughtful probing on the writer's part to discover relationships and insights. Done well, it is the basis for the most creative and sensitive concept development; it can make the difference between good design and great design.

Originator, Contributors and Dates
Names and dates must accurately reflect the development of the Design Factor's content, and the last date should agree with the version date at the bottom of the form. The Date of First Version at the bottom of the form should be the date when the form was originated.

Sources
Not all Design Factors require Sources, but many will benefit from the rigor of good scholarship. Relevant authority should be used wherever possible to back up assertions in the Extension section. Useful reference can come from many sources including, most obviously, pertinent literature, but also users and experts consulted in interview. If no other source is listed, the entry Personal observation will alert the reader to the analyst's own observation, knowledge or experience as the information source.

A coherent referencing system is essential, and needs to be uniform across the project, employed by all writing Design Factors and other documents requiring source information. The Chicago Manual of Style from the University of Chicago Press is an excellent choice as a style guide for bibliographic entries in the Source/s section and the way to reference sources from the Extension section. For the latter, the endnotes model is a good choice.

Associated Functions
Associated Functions are those for which the insights and ideas of the Design Factor are relevant. They originate on the Activity Analysis worksheets and become part of the full Function Structure. On the Design Factor document, Associated Functions originally are only those from the Activity Analysis form that generated the Design Factor. When the Action Analysis process is complete, all Functions should be considered for additional associations with each Design Factor.

Titles of Associated Functions should be exactly as appear elsewhere in the system--on Activity Analysis forms, the Function Structure and on Solution and System Elements.

Observation
The Observation and Extension sections are both about insight. The Observation should be a succinct sentence that distills the insight as well as possible into a single statement. A direct statement as a declarative sentence may be appropriate or, when some precipitating cause or event is known, a two clause statement with dependent and independent clauses. A variety of forms exist for this, among them if __, then __; because __, x __; when __, x __; while __, x __, etc. If a strong relationship is known to exist, the relationship between causes may be cause/effect, but such a certain relationship is not necessary, and a softer "force/tendency" relationship or even just the presumed association of correlation can suffice to reveal insight.

Extension
Rarely is a single statement (the Observation) enough to satisfy those who wish or need to understand an insight. The inevitable "whys" and requests for elaboration lead to the Extension section that exists as a repository for all the information germane to understanding the full potential of the summarized Observation.

A good Extension section should make full use of the space allotted to add detail to the Observation. The goal is answers to the why? or what do you mean? questions as well as contextual information, authoritative confirmation and enough detail to enable the analyst to formulate ideas for how to use the insight. Where authority or credible reference is available, it should be listed bibliographically in the Source/s section and footnoted in the Extension.

Design Strategies
This section and the Solution Element section are included on the Design Factor form to deal immediately with ideas inspired by the insight/s of the previous two sections. When insights are fresh, it is important to take advantage of the heightened awareness of the moment to get down any ideas that occur.

Design Strategies exist in the interim between insight and idea, there to spotlight promising directions to search for ideas. If a specific idea with a special name is the goal (and an entry for the next section, Solution Elements), a Design Strategy is a level of abstraction higher. Design Strategies are at the middle level of a three-level abstraction ladder that starts at the top with general strategies such as confront the problem, avoid the problem, reduce the problem, etc., continues at a topical level where general strategies give way to specific direction relevant to the Design Factor's insight, and ends with a specific idea described in a Solution Element.

Good Design Strategies should be imperative verb phrases suggesting some course of action. The question that follows, "how can I do that?" leads to a Solution Element--or more than one. A good Design Factor should have at least two Design Strategies.

Solution Elements
Proper entries for the Solution Elements section are ideas detailed enough to be discussed, evaluated and written up. They should be named with noun phrases. Nouns (as opposed to verbs) conjure up images well and are best for naming ideas. An effective method for naming Solution Elements is to create an "evocative" title with an adjective or adjectival phrase and a noun. Combinations that suggest a paradox are advocated by Synectics users as being most readily recalled. Memorable names are easy for team members to recollect and often carry over to final System Element names at the conclusion of the project, even continuing to product names when the product enters the market.

Solution Elements need not be wholly new inventions. Frequently, existing ideas or ideas modified from existing ones fit nicely into a system solution. To distinguish between what is new and what is existing, each Solution Element should be marked with an E for existing, M for modified, or S for speculative (wholly new). Sources for existing and modified ideas are given in the Solution Element document.

Generated from Design Strategies, Solution Elements also may be used in reverse to suggest new Design Strategies in a creative see-saw between the specific and the general. What other Solution Element could this strategy produce? What other strategy might produce this or a different kind of solution? There is no limit to the number of Solution Elements for a Design Factor, but common practice suggests two to four good ones are more than sufficient. It is not uncommon to have more than 300 for a project of 150 Functions.