designerly ways of research

peter purgathoferpurg@igw.tuwien.ac.at

@peterpur

designerly ways of research

design?

designerly ways of research

sciences

humanities

arts

design?

...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

»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. je!ries et al.

»The optimum solution to the sum of true needs of a particular set of circumstances.«

e. machett

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

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

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

Gedenryd, 1998

…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, 1968Wenn 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.

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

Jared Spool

what informs design?

artefact

artefactrequirements

artefactrequirements

problem is »given«

It is clear from our analysis of the nature of design problems that the designer must 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.

bryan lawson

artefactrequirements✘this is an illusion

artefact

artefactrequirements

technological constraints

aesthetics, style

hopes, projections

regulations, laws

artefactrequirements

technological constraints

ideals, ethics, morals regulations, laws

aesthetics, style

hopes, projections

Usability

Utility Likeability

42

designer

client

user

legislator

internal

external radical

practical

formal

symbolic

source

domain

function

what informs design?

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

»thinking«

»thinking«

central assumption: design is a problem solving activity

»design methods movement«

problem definition resultanalysis synthesis

»thinking«

central assumption: design is a problem solving activity

»design methods movement«

problem definition resultanalysis synthesis

»thinking«

central assumption: design is a problem solving activitychristopher alexander: »notes on the synthesis of form«

problem definition resultanalysis synthesis

given deduction plan

»thinking«

central assumption: design is a problem solving activityjohn christopher jones: »design methods«

»thinking«

a little later: alexander and jones desertThere 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 aloneBecause design is to do with uncertaintyAs far as I can seeBut a lot of people who do wish for certainty do dabble in itAnd I fear they are wrecking the subject

j. christopher jones

»thinking«

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

»talking«

»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.

»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

»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«

»talking«

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

»doing«

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

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

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

core concepts: »problem setting« »doing for the sake of knowing« »inquiring materials«

–› »design instruments«

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

core concepts: »problem setting« »doing for the sake of knowing« »inquiring materials«

–› »design instruments«sketching

prototypingszenario writing

personas »probes«

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

core concepts: »problem setting« »doing for the sake of knowing« »inquiring materials«

–› »design instruments«

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

sketching

»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«

»whenever we have a design session or crit review in the o"ce I cannot say anything until I've got a pencil in my hand«

something that I earlier said that I would not do, namely, namely give you one of

my definitions of design. So here goes:

Design is choice, and there are two places where there is room for creativity: (1) the creativity that you bring to enumerating meaningfully distinct options from which to choose, and (2) the creativity that you bring to choosing the criteria, or heuristics, according to which you make your choices.

This formulation of the process makes explicit the fundamental importance of

both the generative and reductive aspects of the design process. Each

corresponds to one of Laseau’s funnels. The expanding funnel represents the

generation of the possible opportunities, or options from which one can select.

The converging one represents the making of choices from among those options,

and the gradual convergence onto the final design.

I like this figure for what it adds. And yet, it has its own weaknesses. While it

graphically highlights that the generation of new ideas is ongoing throughout the

process, it doesn’t reflect how the range of things that we can consider narrows

as we converge on the final design.

Figure 34: Overlapping Funnels The reduction that results from decision making is balanced by the constant generation of new ideas and creativity that open up new opportunities to improve the design. (Laseau, 1980, p. 91)

The other thing that it doesn’t show, but that is important to keep in mind, is that

for the process to work, we must generate and discard much more than we keep.

This is what Pugh (1990) has called controlled convergence. This leads us to yet

another representation, that seen in Figure 35. The key take-away from this

figure is how it illustrates the design funnel as alternating between adding and

eliminating concepts – concept creation (CC), which expands the scope of the

funnel, and concept convergence, which narrows the funnel.

/ 76

s k e t ch ingprototyping

not obvioussketching

prototypinginvitesuggestexploreevokequestionprovoketentative

attendsuggest

refinetest

answerresolvespecificob

vious

These things are really subtle. As we pointed out at the time, this is a wonderful example of both the strength and subtleties of the physical affordances of devices. Consequently, ideally we want to be able to explore these types of relations – in order to find the pitfalls as well as the sweet-spots – as early in the design process as we can. Yet, we don’t want to get into detailed model building at this stage, any more than we want to get into serious code writing.

What we really want is something that is to model building what paper prototyping is to dialogue design. That is, we need to develop techniques that have all of the properties of a sketch: fast, cheap, timely, etc.

At the start, these can be surprisingly simple.

Figure 27: Reproduction of 3D “Sketch” of the PalmPilot Very early on, Jeff Hawkins carved up a piece of wood to get a sense of the size that the device must be. It needed to fit into a shirt pocket, as well as sit comfortably in the palm of the hand. (Photo: Elizabeth Russ)

One of my favourite examples is what Jeff Hawkins did in the early stages of designing the PalmPilot. As recounted by Rob Haitani, one of the designers on the project:

Jeff believed we had to make the product considerably smaller than current PDAs. He carved up a piece of wood in his garage and said this is the size I like. I would print up some screenshots ans we were develping UI, and he’d hold it and pretend he was entering things, and people thought he was weird. He’d be in a meeting furiously scribbling on this mockup, and people would say, “Uh, Jeff, that’s a piece of wood.” (Bergman & Haitani, 1990, p.83)

To help put this in context, in 3 minutes I made a reproduction of Jeff’s “sketch” in my basement, using a piece of scrap wood. It took only another 2 minutes to test

/ 59

designerly ways of research!

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

designerly ways of research!

»doing for the sake of knowing«

»analysis through synthesis«

»oneness of analysis and synthesis«

»explorative design«

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

320

design

entwickler als »nutzer«

designer als »auftraggeber«

implementierung

workshop

»light weight« »heavy weight«

peter purgathoferpurg@igw.tuwien.ac.at

@peterpur

designerly ways of research

william buxtonsketching user experiencesgetting the design right and the right design