Guindon Design Experiment

Based on designing and building a cantilever beam using spaghetti and sticky tape.

Detailed protocol available at:

https://managingdesignanddevelopment.blogspot.com/2010/09/guindon-design-activities.html

Goal:

Develop an understanding of empirical design and development work as it unfolds over time.

Method:

The experiment will run for ~30 minutes.
At 1 minute marks check one or more activities you underwent in the last period from the following list:

5. "Scenario level"
4. "Requirement level"
3. "High level solution"
2. "Medium level solution"
1. "Low level solution"
0. "Key ideas (lightbulb moments)"

 Results:

At the end of the experiment take a photo of your cantilever experiment and post it to your socials. Potential tags...

"#designing #designprocess #designcollaboration #softwaredesign #digitalinnovation #guindondesignchallenge #thinking-aloud #researchmethods"

Discussion:

Reflect on your graph. Can you relate your findings to Raccoon's Chaos Model?

Guindon Design Notes:

In the late 1980s Raymonde Guindon designed an experiment to observe software designers at work while they were engaged in the process of creating a solution to a set problem. The software engineers, working individually, adopted a ‘thinking-aloud’ protocol and were observed directly by the researcher and videotaped for analysis.
As a consequence of these studies Guindon developed an understanding of design and development work as it unfolds over time; it is in fact a chaotic process of learning and reflection through trial and error. In essence the process of creating a solution to an ill-structured problem is itself un-structured, at least in the simplistic sense of being a planned, logical process moving from high level design to low level implementation in a smooth orderly manner. In fact the observations lead Guindon to the conclusion that software design work is largely underdetermined (Guindon, 1990).

“opportunistic decomposition is better suited to handle the ill-structuredness of design problems… top-down decomposition appears to be a special case for well-structured problems when the designer already knows the correct decomposition. .” (Guindon, 1990)

Guindon’s study demonstrated empirically that top-down design doesn’t occur as such in design work, or at least it doesn’t occur in a linear sequence from top to bottom. This has implications for lifecycles and frameworks that impose linear or staged phase structures based on the concept of top-down design-to-development processes.

Reference: Guindon, R. (1990) Designing the Design Process: Exploiting Opportunistic Thoughts. Human-Computer Interaction, 5, 305-344.