User Tools
Site Tools
Sidebar
Table of Contents
Design Strawman
These are working notes, toward a general strawman design process.
To Do
- Check the process at http://blog.ponoko.com/2008/11/28/design-process-the-maker-way/
- In [Ale64], constraints (requirements) are developed without preconceiving organized categories for them to fit within. Then, relationships between them are established.
- This is essentially backwards of the standard way of doing things.
- The benefit is that the resulting structure is (presumably) better suited to the specific problem.
- The cost is that there is no “template” that can be generalized to help solve future problems.
- It is important to carefully consider this. It's a big change from the way things are, but it may make more sense.
- Re-read [ACC00] and see what, if anything warrants inclusion in the strawman.
- [ACP92] develops an artificial system to expand design spaces. There may be some underlying process that can be helpful here, or at least provide a new ideation technique for courseware. Review it again.
Nomenclature
Product: the item being designed; e.g. “product characteristics” are characteristics of the actual product.
Design: the collection of information describing the product; e.g. “design characteristics” are characteristics of the design, not of the product.
- There is no overlap between design characteristics and product characteristics.
- We could have had design characteristics be a superset of product characteristics, but we believe that would be too confusing.
Overview
There are many attempts to describe product development processes in strange, nearly vacuous ways. Examples include Quality For Business.
The strawman should be better than this.
SDS covers all stages of product life-cycle (LC):
- pre-design (strategic planning)
- design
- fabrication
- distribution
- operation/maintenance
- end-of-life
SDS covers all phases of the product development process (PDP):
- requirements analysis and specification
- functional analysis and design
- conceptual design
- concept evaluation and refinement
- systems design
- detailed design
SDS takes into consideration other aspects of the engineering endeavor that affect or are affected by design:
- teamwork
- project management
- concurrent engineering
SDS uses grammatical parsing & analysis to extract meaningful information from natural language statements. For example,
- Product characteristics are written as things a product must “be” or properties a product must “have”.
- Product functions are written as things a product must “do”.
- A modal distinction is made between things a product “should” do or be (possibility or preference), and things a product “must” do or be (necessity or obligation).
- The six interrogative forms (who, what, where, when, how, and why) are used as exploratory tools for reasoning.
SDS takes advantage of principles of systems engineering.
- A product is a system, i.e. set of interacting components, that provides a defined set of functions, and that is distinguished from its environment (the supersystem).
- See also products as transformers.
SDS distinguishes kinds of information according to the following criteria:
- behavioral: arising from reactions to stimuli arising from each LC stage (operational stimuli - e.g. physical loading during use - being most important, but also, distribution stimuli such as vibrations during transport, etc)
- functional: arising from the intended role of the product in a larger system (supersystem)
- environmental: arising from impact of product on other components of the supersystem (e.g. safety)
SDS is based on pattern languages.
- A pattern language can capture procedural know how in small flexible chunks, that can be arranged in hierarchies or networks.
SDS evolves in time.
- The SDS is not constant; it adapts and grows. This is more easily done thanks to the use of pattern languages.
Open Research Questions
Concept Evaluation: When evaluating a concept with respect to a criterion, the good and bad characteristics of the concept are conflated. Try to devise a way of rating the good and bad characteristics separately. The analogy is to doing a cost/benefit analysis of each concept with respect to each criterion – rate the cost and benefit separately in the table, then combine them in some algebraic way. Cf [MZ96].
Problems are defined in situations/contexts. Problem analysis happens with respect to the situation. Need to capture situational analysis/understanding/awareness as a part of problem analysis, or something that even happens before problem analysis.
Add the attribute types of Kano models (cf Daryl Caswell's unit on Kano Models for his CDEN module) to my product characteristics work.
What do other authors have to say about the phases? Can other phase categorizations be unified?
[CTT94] consider a multimodeling approach to be appropriate because they see reasoning about systems as a cooperative activity. This meshes with the idea of multiple agents in ADPM. Check the paper, verify, and try to incorporate their results in some way.
[CJ96] stress that function descriptions must not make commitments (must not refer to) product structure. How does does this relate to levels of granularity, and Dym's objectives/functions?
[Hym98], the phrase “client's dissatisfaction with a current situation” is used to describe the as-is world into which a new product is introduced. Can this be fit into ALX3d?
Is a FR a constraint on functionality, whereas a plain constraint is a constraint on non-functional aspects of products? This may help distinguish between constraints, FRs, etc.
If synthesis is a mapping from function to form, then is analysis the inverse mapping, or is it the mapping from form to performance? (Where performance is not equal to function.)
What does it mean for a function to have a property? What kinds of properties do functions have that structures do not?
parametric design is intimately tied to an object-oriented perspective.
Sources to check:
Product characteristics
A product characteristic is an essential quality of a product typically represented in adjectival form.
Product constraints
A product constraint, per [DL00], is a limit on the product that identifies what is not acceptable, whereas a product characteristic defines the minimum acceptable value of a design parameter and an indication of the direction in which better values are found.
To facilitate this distinction, constraints are written as negative statements about the product. E.g. “the product's weight cannot exceed 10kg” is a constraint, whereas “the product must be as light as possible” is an objective.
A method for problem analysis
Two alternative methods:
- use the ontology to address each kind of information (product characteristic, function, constraint, etc.) in turn, or
- brainstorm NL statements about the problem, then analyze the statements to rewrite them within the SDS structure.
Method 2 is preferred, because it clearly distinguishes between the creative/synthetic cognitive tasks and the reductive/analytic cognitive tasks. This provides a more intuitive framework - designers know “This is the time for innovative thinking”.
Is there some sort of experiment that can be done to check this? For example, have 2 small teams working on the same problem, each using a different method; then have the teams exchange their final design specs and comment on them. Does each team admire the other's work? Do both teams think one result is better than the other?
The method has the following basic stages:
- brainstorm exploratory statements regarding the problem definition
- classify/categorize those statements according to the ontology, noting open issues or follow-up statements separately.
- revisit the open issues and follow-ups to extend the problem structure.
- revisit the entire problem structure to verify consistency.
Stages 1 and 3 are those where innovative ideas and free thinking are encouraged; stages 2 and 4 are those where analytic thinking is encouraged. However, each stage may contain a little of both kinds of thinking.
- Brainstorm exploratory statements
- Create initial design specification structure
- Revisit open issues and follow-ups
- Verify entire design specification structure
An example
The example is drawn from [DL00] (p 55): Design a new ladder for electricians or other maintenance and construction workers for use on conventional job sites.
Similarities Between Design Disciplines
Every kind of design has certain common features, activities, and attributes. What exactly are they?
Validation
An interesting notion regarding validation: [ACC00] reads “This approach to product design has been validated on more than 100 real industrial cases.” The method described there is, however, surprisingly generic: set requirements, conceptualize, architect a system. If it's really generic, then can any similar approach recycle the same “proof”? Does the validation they performed also apply (at least generally) to any similar process model?
Successful Meetings
Many facilitators use process models to promote “creativity” that are essentially design processes. Here's one example.
| Step | In Facilitation | In Design |
|---|---|---|
| 1 | Focus - ask a question, don't pose an issue | Requirements elicitation and engineering |
| 2 | Divergent thinking | Concept design |
| 3 | Convergent thinking | Concept evaluation and systems design |
| 4 | Keep it fresh | Coevolution and detail design |
Human Computer Interaction
HCI has been a discipline that has adopted a strong design orientation. There is probably alot to be learned from HCI in working towards any reasonable “universal” design.
Some HCI links of interest include:
Danish HCI Research Symposia:
See Also
References
