talk given at the faculty of informatics PhD school, vienna university of technology, about my research background and methodology.

1. peter purgathofer
purg@igw.tuwien.ac.at
@peterpur

2. designerly ways of research

3. design?

6. designerly ways of research

7. sciences
design? humanities
arts

8. ...design is essentially prescriptive whereas science is
predominantly descriptive. Designers do not aim to deal
with questions of what is, how and why, but, rather,
with what might be, could be and should be.
Bryan Lawson, 1980

9. »Software design is the process of translating a set of
task requirements (functional specifications) into a
structured description of a computer program that will
perform the task.«
r. jeffries et al.
»The optimum solution to the sum of true needs of a
particular set of circumstances.«
e. machett

10. 1. In most cases the people who commission the
building of a software system do not know exactly what
they want and are unable to tell us all that they know.
2....Many of the details only become known to us as we
progress in the implementation. (p.251)
Parnas & Clements, 1986

11. 1. In most cases the people who commission the
building of a software system do not know exactly what
they want and are unable to tell us all that they know.
2....Many of the details only become known to us as we
progress in the implementation. (p.251)
Parnas & Clements, 1986

12. Hence, ideally problem solving theory would be correct,
but in reality, producing the problem is work that the
designer must do.
Gedenryd, 1998

13. …that you cannot understand the problem without having
a concept of the solution in mind; and that you cannot
gather information meaningfully unless you have
understood the problem but that you cannot understand
the problem without information about it.
Horst Rittel, 1968
Wenn also Software-Engineering von der
Möglichkeit träumt, eine vollständige Definition
des Problems an den Beginn des Prozesses zu
stellen, dann steht es damit in direktem
Widerspruch zur Theoire des Designs. Es
braucht also niemand zu wundern, wenn man
damit scheitern muss. Damit wird das
Pflichtenheft zum potentiellen Stolperstein der
Software-Entwicklung.

14. Evidence suggests that usability practice is more craft
than engineering, but we sell it as an engineering
practice.
Jared Spool

15. what informs design?

16. artefact

17. requirements artefact

18. problem is »given«
requirements artefact

19. It is clear from our analysis of the nature of
design problems that the designer must
bryan lawson
inevitably expend considerable energy in
identifying the problems. It is central to modern
thinking about design that problems and
solutions are seen as emerging together, rather
than one following logically upon the other….
[B]oth problem and solution become clearer as
the process goes on.

20. ✘
requirements artefact
this is an illusion

21. artefact

22. requirements artefact

23. ideals, ethics, morals regulations, laws
requirements artefact aesthetics, style
technological constraints hopes, projections

24. Usability
Utility Likeability

26. source designer
client
user
legislator
symbolic function
domain internal formal
practical
external radical

27. what informs design?

28. › three generations of design models
»thinking«
»talking«
»doing«

29. »thinking«

30. »thinking«
central assumption: design is a problem solving activity
problem analysis definition synthesis result
»design methods movement«

34. »thinking«
central assumption: design is a problem solving activity
problem analysis definition synthesis result
»design methods movement«

35. »thinking«
central assumption: design is a problem solving activity
christopher alexander: »notes on the synthesis of form«
problem analysis definition synthesis result
given deduction plan

36. »thinking«
central assumption: design is a problem solving activity
john christopher jones: »design methods«

37. »thinking«
a little later: alexander and jones desert
There is so little in what is called ›design methods‹ that has anything useful to say
about how to design buildings that I never even read the literature anymore [...] I
would say forget it, forget the whole thing.
christopher alexander
If you wish for certainty you might as well leave this subject alone
Because design is to do with uncertainty
As far as I can see
But a lot of people who do wish for certainty do dabble in it
And I fear they are wrecking the subject
j. christopher jones

38. »thinking«

39. › three generations of design models
»thinking«
»talking«
»doing«

40. »talking«

41. »talking« - horst rittel: »wicked problems«
1 Wicked problems have no definitive formulation, but every formulation of a wicked problem corresponds to the
formulation of a solution.
2 Wicked problems have no stopping rules.
3 Solutions to wicked problems cannot be true or false, only good or bad.
4 In solving wicked problems there is no exhaustive list of admissible operations.
5 For every wicked problem there is always more than one possible solution, with explanations depending on the
Weltanschauung of the designer
6 Every wicked problem is a symptom of another, ›higher level,‹ problem.
7 No formulation and solution of a wicked problem has a definitive test.
8 Solving a wicked problem is a ›one shot‹ operation, with no room for trial and error.
9 Every wicked problem is unique.
10 The wicked problem solver has no right to be wrong—they are fully responsible for their actions.

42. »talking« - horst rittel: »wicked problems«
-› …that the design process is not considered to be a sequence of activities
that are pretty well defined and that are carried through one after the
other like ›understand the problem, collect information, analyze
information, synthesize, decide‹, and so on.
-› …that you cannot understand the problem without having a concept of the
solution in mind; and that you cannot gather information meaningfully
unless you have understood the problem but that you cannot understand
the problem without information about it.
horst rittel

43. »talking« - horst rittel: »wicked problems«
IBIS - »issue-based information system«
a counterplay of raising issues and dealing with them,
which in turn raises new issues and so on.
analysis and synthesis are not seperate activities, but
must be seen as together: »analysis thru synthesis«

44. »talking«

45. › three generations of design models
»thinking«
»talking«
»doing«

46. »doing«

47. »doing« – based on theory of »interactive cognition«

48. »doing« – based on theory of »interactive cognition«

49. »doing« – based on theory of »interactive cognition«
core concepts: »problem setting«
»doing for the sake of knowing«
»inquiring materials«
–› »design instruments«

50. »doing« – based on theory of »interactive cognition«
core concepts: »problem setting«
»doing for the sake of knowing«
»inquiring materials«
–› »design instruments« sketching
szenario writing
personas
»probes« prototyping

51. »doing« – based on theory of »interactive cognition«
core concepts: »problem setting«
»doing for the sake of knowing«
»inquiring materials«
–› »design instruments«

52. »doing« – based on theory of »interactive cognition«
»having a conversation with his drawing«
»Such a drawing is done by the designer not to communicate
with others but rather as part of the very thinking process
itself which we call design.«
»seeing-moving-seeing«
»my thinking pen« sketching
»whenever we have a design session or crit review in the office
I cannot say anything until I've got a pencil in my hand«

58. as we converge on the final design.
sketching
prototyping
Figure 34: Overlapping Funnels
The reduction that results from decision making is balanced by the

59. sketching
not obvious
attend invite
suggest suggest
refine explore
obvious
test evoke
answer question
resolve provoke
specific tentative
prototyping

62. the start, these can be surprisingly simple.
Figure 27: Reproduction of 3D “Sketch” of the PalmPilot

63. designerly ways of research!

66. http://chrisrust.wordpress.com/2000/12/31/whiteleythesis/#more-130
http://mikepress.wordpress.com/2010/07/15/arty-fartys-contribution-to-science-and-technology-research/

67. designerly ways of research!

68. »doing for the sake of knowing«
»analysis through synthesis«
»oneness of analysis and synthesis«
»explorative design«

74. some further questions for design theory
research
› role of design in software development
› methods & strategies for design
› how to teach design
› what not to do in design

75. designer als »auftraggeber«
design
implementierung
entwickler als »nutzer«
workshop
»light weight« »heavy weight«

78. designerly ways of research
peter purgathofer
purg@igw.tuwien.ac.at
@peterpur

79. william buxton
sketching user experiences
getting the design
right and the right
design