D3D Design Methodology
Overview
The design process within the designers mind is inherently hard to capture within rigorous formalism without killing it. It should treated like a wild animal with an enormous home range within the designers thoughts, behaving with a certain degree of arbitrariness. Despite this, there are some things that the designer can do (besides hosting the process in his/her head):
- Observe it
- Describe it
- Measure its outputs (validation)
- Moderately change its environment (goals, requirements, inspiration, knowledge)
- Help it if it gets stuck
This methodology is intended to help designers do those things in a systematically in order to get the most out of mechanical design processes.
Search and Reinforcement Learning Analogy
All creative processes can be seen as searches in spaces of thinkable outcomes (See for example Mike Bostock presentation for more on search analogy). We'll view design processes as searches trying to arrive at the highest quality design with the least amount of effort. The guide during the search is a continuously updated estimate of what quality we're heading towards. Success is determined by both how accurate the estimates are and how the estimates are used. Within Reinforcement Learning, acting to improve estimate accuracy is called exploration and acting as if current estimation is good enough is called exploitation.
In mechanical design, a case of exploration would for example be to build something that you know will fail in order to learn from watching how it fails.
Before Starting a Design Process
The designer should know how the quality of the machine will be measured. The estimate of what quality we're heading towards is the designer's compass in the vast space of thinkable designs and the design process gets confused without it.
Functional requirements and goals are good, a firm understanding of intended usage is better, direct feedback from actual usage is best.
The design process traverses a vast decision tree while exploring design space.
The parts of design space that it ends up in gets limited by choices of
- Which inputs it is designing to handle
- Which primitive design elements it includes in the design
- What language, concepts and higher order design elements it forms and uses
The choice of concepts determines what kind of movements the process can take within design space. For example the concepts "left half of machine" and "right half of machine" can be combined in a single step to arrive at a complete machine.
Its the designers job to systematically describe and validate these choices when they are made.
Prototype design candidates need to be buildable as well as thinkable.
The decision nodes are of the following basic types
- ...
The Search Algorithm/Design Procedure
Our search will use three sub-procedures:
Stepwise Definition: | Heavily inspired by DE's six steps[1]. Used to describe how we've understood the design (sub)problem at hand. |
Input Decision: | Used shrink design space by narrowing the range of accepted inputs. |
Concept Creation: | Designing things that might be useful for whatever reason. Used to define paths named through design space. |
These will be applied to modules and sub-modules recursively, searching the design space in a best-first manner. That is, when we find a promising sub-design, we continue working on that sub-design and its sub-sub-designs until either it is complete or until we meet difficulties.
The calling process is always re-entered at an earlier point than where
Stepwise Definition
1. | Problem Analysis: | Give the thing we're going to design and build a name and describe the types of input and output (a "signature" or "contract"). |
2. | Purpose Statement: | Reformulate eventual problem statements into a couple of sentences explaining the purpose of the thing we're designing. |
3. | Examples: | Illustrate the purpose statement by listing some example usages of the soon-to-be designed thing. Serve as criteria of success and are used as tests later. |
4. | Sketches: | Some basic shape and logic of the design is already given at this stage. Write it down. |
5. | Being creative: | Put together parts in ways that will solve the problem. If there's need for further specification of input go to Input Decision. sub-modules. |
6. | Testing: | The creation of a test suite from examples ensuring small inputs work as expected. |
Input Decision
- List available choices (that we can think of and express, and in reasonable detail)
- If list seems unfinished: Go into Concept Creation
- Explicitly reason around what's known, what's unknown and general pros and cons related to all the different choices
- Make a decision
- Be very explicit about how this limits the design space
- Validate that the chosen limitation doesn't violate requirements in any obvious way.
Concept Creation
Whenever language gets too formal, or design progress is so slow that we loose track it can be a good idea to jump out of the loop and define some higher order concepts to build upon later. If the defined concept aren't readily definable/manufacturable from already known concepts in a single step, then the design becomes "abstract" or "lazy" and might prove to be impossible to manufacture.
1. | Dive into the space of potentially useful (for whatever reason) concepts. |
2. | Do basic validation that the concept should be completely definable/manufacturable. Actually defining/manufacturing it is recommended. |
3. | If concept shows a lot of promise, line up all things that can be considered a sub-module and define them with the Stepwise Definition procedure. |
4. | Review previous design process and re-enter it from where you estimate the best overall probability to arrive at a good design. The re-entrance is what makes the algorithm best-first. |
Design Algorithm
- Start Stepwise Definition at the highest possible level
- Keep a log of how you traverse the different steps
References
- ↑ 1.0 1.1 FELLEISEN, Matthias. How to Design Programs: an introduction to programming and computing. MIT Press, 2001.