Product (inc. Service) Design Resources

https://servicedesigntools.org/about

The Service Design Tools site is a wonderfully detailed collection of resources suited to evaluating user contexts, for helping you adopt a `design attitude'. The resource is supported by an on-going project aimed at bridging education, academic research and professional practices.

https://www.designmethodsfinder.com/how-it-works

The design methods finder offers another possible source of inspiration for identifying research (and design) methods to apply to your own design research project.

https://www.nngroup.com/

The Nielsen Norman Group (Jakob Nielsen, Donald A. Norman, Bruce "Tog" Tognazzini) has been behind a sustained drive to professionalise high tech design by defining a new kind of occupation; Interaction Design.

https://useit.com

This is Jakob Nielsen's site for sharing thoughts on the principles of interaction design, events and ID community material.

https://asktog.com

Bruce Tognazzini's site and his take on design principles.

The Guindon Design Experiment

This experiment is an adaptation of the Spaghetti Cantilever Teambuilding Exercise. Organise into large and small groups (from 4 or 5 people to 8 or 9 people).
• Each group will employ a ‘thinking aloud’ protocol as they run the experiment.
• The cantilever designers should highlight key transitions or changes in their thinking about the problem.
One person will act as the researcher, capturing a time-record of the designers’ abstraction level and time at any moment. The researcher will make judgements about the abstraction level. The researcher is not allowed to take part in the design and construction.
• Change the person in the researcher role every 5 minutes to give all team members an opportunity to contribute to the cantilever design and construction.

Resources for 10 groups

Include the following observations on the ‘Design Activity Graph.’
• Scenario thinking
• Requirement thinking
• High level solution thinking/building
• Medium level solution thinking/building
• Low level solution thinking/building
• Key ideas.
• Testing or Review.

Example of one group's design-construction activity chart

Spaghetti Cantilever Exercise
An exercise in design and coordination (adapted from Patrick Stacey’s boundary object seminar). This exercise resonates with Peter Skillman's 'Marshmallow Challenge.'

Allocate at approximately 1 hour to run this exercise. 10" setup and briefing. 30" experiment. 5" extra time. 15" debriefing.

You will need a large space with scattered desks to accommodate the exercise. Tiered lecture theaters are not suitable environments for this activity.

Aims
Practical Aim: Construct a cantilever extending from a surface, such as a table top.
Knowledge Aim: To assess the different activities people engage in open-ended problem solving.

Material
For construction each group is given a pack of spaghetti, a roll of tape, 2 sheets of A4 paper. Pens are for writing and not to be used in the structure!
Each group to be given a sheet of graph paper to capture the team's Guindon graph.
The tutor will need a timer and tape measure.

Competitive dimension/evaluation: Which group will construct the longest cantilever, - it must not touch the floor!
The tutor will need a measuring tape to measure and compare the length of the cantilevers.

Reflection
Ask each group to classify the activities they underwent (perhaps over 4 or 6 distinct kinds of activity)
Ask each group to estimate how much time they spent on each activity.
Ask the groups to reflect on how they won (or lost!) and to reflect on the contributions their different experience, backgrounds, disciplines made to the solution.
Were there collaboration problems? What boundary objects used to make sense of the challenge?
What evidence of design work is available (diagrams, prototypes, experimental trials)?

Class of 2019/20

Group ID	Test 1	Final Span (cm)
NinjaTurtles	OK	86cm
Rogue1	OK	51cm
Rogue2	OK	43cm
DontDrive	OK	78cm
TeamTape	OK	109cm
Waterslide	OK	75cm
FishingRod	OK	108cm

Class of 2013/14

Group ID	Test 1	Final Span (cm)
a	OK	72cm
b	OK	44cm
c	OK	64cm
e	OK	91cm
f	OK	64cm
g	OK	20cm
h	OK	52cm
x	OK	71cm

Class of 2013/14 FT

Group ID	Test 1	Final Span (cm)
a	OK	13cm
b	OK	10cm
c	OK	70cm
e	OK	46cm
f	OK	58cm
g	OK	67cm
h	OK	59cm
i	OK	62cm
j	OK	18cm, 18cm

Class of 2012/13 

Group ID	Test 1	Final Height
a	3/4	56cm
b	OK	71cm
c	1/2	nil
e	1/2	52cm
f	1/4	81cm
g	3/4	46cm (74cm)
h	OK	83cm
i	1/4	83cm
j	3/4	51cm

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.