D3D Design Methodology
- 1 What this is
- 2 The Designers' Job
- 3 References
What this is
In this document Tobben is scratching his own methodology itch. For methodologies more tightly knit to OSE see GVCS_Methodology, Development_Methodology. For OSE templates and more on OSE development, see Development_Spreadsheet_Template, Development.
Also note that this document does not cover how to handle teams and similar aspects. It focuses on one designer with one design problem. It is an interpretation and extension of the programming golden standard methodology developed by the ProgramByDesign initiative. The gist of this document is in the #Stepwise_Definition section.
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, making unspoken and implicit design decisions and in general behaving in arbitrary ways. 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 (exploring consequences, 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 finished and unfinished results (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 finished design with the least amount of effort.
The design process' guide during the search is a continuously updated estimate of what design quality it is heading towards. Probability for a successful search is determined by both how accurate the estimates are and how the process makes use of them. Within Reinforcement Learning, acting to improve estimate accuracy is called exploration and acting as if current estimation is good enough is called exploitation. Excluding one of them leads to random design decisions.
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.
The Designer and the Process
Design decisions are made continuously and are made based on ideas that arrive at seemingly random times. We therefore separate The Design Process and The Designer. The Process is a source of randomness continuously making an unknown number of small and big decisions. The designers' work and responsibility is to:
- Identify decisions and ideas
- Describe decisions and ideas
- Work out consequences and validate decisions and ideas
- Try to guide and help the process from a distance
- Help the process loose if it gets stuck
This way of externalizing seemingly unpredictable aspects of creative work has roots in ancient Greek and Roman tradition (see from min 6 of ).
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.
Movements in Design Space
The design process traverses a vast decision tree while exploring the thinkable design space. That is, the design process steps through design space by making decisions.
The choice of concepts and design elements 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" lets the process take a giant single step to complete machine. (Exploring "machines with two halves" might be a worthwhile exploration, but might not lead to good design quality in itself...)
The designer should help the design process is by making it aware of the current designs surroundings. For example, available design space 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 designer should describe such decisions. The designer also has to care about questions like "do we need validation?" and "is it buildable?".
The Designers' Job
The following is practical advice for helping the design processes and getting the most out of it in a systematic way.
Keep A Log
All thoughts, identified decisions, reasoning around them, lessons learned and similar should be logged in chronological order to help debugging the process. Note what steps are exploration and what are exploitation.
The Designer Routine
The following practical routine is intended to cover all the aspects of the designers' job. It should help the designer keep a systematic approach both in
- Keeping documentation creation up to speed when the process moves quickly
- Helping a derailed process get back on its feet
Our designer routine will use three sub-routines:
|Stepwise Definition:||Heavily inspired by DE's six steps. Used to describe how we've understood the design (sub)problem at hand.|
|Input Definition:||Used to shrink design space by narrowing the range of accepted inputs.|
|Concept Creation:||Designing things that might be useful for whatever reason. Makes new paths through design space accessible.|
These sub-routines recursively call each other, so the designers' systematic logging work will branch out according to how the process explores branches of the decision tree.
A design process is preferably started out by entering Stepwise Definition at the highest possible level of abstraction. If the process has already done progress in other directions, the designer should calm it down and describe what has already been done in terms of the sub-routine that is found to be most suitable. What direction to guide the process next is described in the sub-routine.
If sub-routines may be applied to modules and sub-modules recursively. That is, when a promising sub-design is found, we may allow the process to explore necessary sub-design and its sub-sub-designs.
When the search has to be rewinded, it is preferred to re-enter the decision tree and calling designer sub-routine in a best-first manner. That is, consider the log of several previously run sub-routines before resuming the design process, and take note of what branch is being continued on/explored.
Helping a Derailed or Halting Process
Try jumping out of Stepwise Definition and into Concept Creation whenever
- Language gets too formal to think clearly
- Design progress is so slow that we loose track
Designing unused concepts that can potentially be better defined and built upon later is fine.
Try jumping out of Concept Creation and run under-defined concepts through Stepwise Definition whenever
- Concepts become too random/har to think and reason about
- The design starts to fail tests
Making tests more specific and reviewing previous validations carefully can also be of help.
|1.||Problem Analysis:||Give the thing we're going to design 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. Identify new sub-modules and list them for later stepwise definition.|
|6.||Testing:||The creation of a test suite from examples ensuring small inputs work as expected.|
- 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
- Write down the decision to explore
- Write down how this limits the design space
- Unless design step is purely exploratory: Validate that limitations doesn't violate requirements in any obvious way.
|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.|
- FELLEISEN, Matthias. How to Design Programs: an introduction to programming and computing. MIT Press, 2001.