i The fragility of human-centred design Marc Steen ii iii The fragility of human-centred design Proefschrift ter verkrijging van de graad van doctor aan de Technische Universiteit Delft, op gezag van de Rector Magnificus Prof. dr. ir. J.T. Fokkema, voorzitter van het College voor Promoties, in het openbaar te verdedigen op vrijdag 28 november 2008 om 10.00 uur door Marc Gerard Daniël STEEN ingenieur industrieel ontwerpen, geboren te Haarlemmermeer. iv Dit proefschrift is goedgekeurd door de promotoren: Prof. dr. ir. J. A. Buijs Prof. dr. H. Letiche Samenstelling promotiecommissie: Rector Magnificus, voorzitter Prof. dr. ir. J. A. Buijs, Technische Universiteit Delft, promotor Prof. dr. H. Letiche, Universiteit voor Humanistiek, promotor Prof. dr. C. J. P. M. de Bont, Technische Universiteit Delft Prof. dr. S. D. Brown, University of Leicester Prof. dr. P. Case, University of the West of England Prof. dr. V. A. J. Frissen, Erasmus Universiteit Rotterdam Prof. dr. J.-L. Moriceau, Telecom & Management SudParis Prof. dr. P. J. Stappers, Technische Universiteit Delft (reservelid) Dit proefschrift is tot stand gekomen dankzij steun van TNO. TNO.NL © 2008 Marc Steen and IOS Press All rights reserved. No part of this book may be reproduced, stored in a retrieval system, or transmitted, in any form or by any means, without prior permission from the publisher. ISBN 978-1-58603-941-7 Keywords: design, innovation, human-centred design; telecom; police; informal care, science and technology studies; organization studies; ethics; Levinas; Derrida. Published and distributed by IOS Press under the imprint Delft University Press Publisher & Distributor Distributor in the USA and Canada IOS Press IOS Press, Inc. Nieuwe Hemweg 6b 4502 Rachael Manor Drive 1013 BG Amsterdam Fairfax, VA 22032 Netherlands USA fax:+31-20-687 0019 fax: +1-703-323 3668 email: info@iospress.nl e-mail: sales@iospress.com LEGAL NOTICE The publisher is not responsible for the use which might be made of the following information. PRINTED IN THE NETHERLANDS v Table of contents To the reader.......................................................................................1 1. Introduction ............................................................................................3 INTERIOR, CONFERENCE ROOM, DAYTIME...........................3 INTERIOR, SMALL OFFICE, DAYTIME.....................................10 Summary and overview of chapters .............................................16 About form (1)..................................................................................18 2. Human-centred design .......................................................................19 Positioning ........................................................................................19 Human-centred design ...................................................................22 Terminology .....................................................................................23 Involving users.................................................................................24 Tensions and approaches ...............................................................29 Focusing ............................................................................................35 Participatory design ........................................................................36 Applied ethnography......................................................................37 Lead user approach .........................................................................39 Contextual design............................................................................40 Co-design ..........................................................................................41 Empathic design ..............................................................................42 Probes ................................................................................................43 Personas and storylines ..................................................................44 Summary...........................................................................................45 3. Research approach...............................................................................49 Science and technology studies .....................................................50 A social constructionist approach .................................................52 Involvement – and an attempt at deconstruction .......................53 Generating theory – about design and ethics ..............................55 Studying one project – combining practice and analysis...........59 Fieldwork..........................................................................................61 Local knowledge..............................................................................63 Falsification.......................................................................................65 Summary...........................................................................................66 Combining the roles of practitioner and analyst.........................66 Reflexivity (1) ...................................................................................70 Traditions of reflexivity ..................................................................73 Introduction to the project studied and to Chapters 4 and 5.....79 vi 4. Designing with/for police officers ...................................................85 Starting with an idea .......................................................................85 Focusing on a single topic (workshop 1) ......................................88 Neglecting other topics ...................................................................89 Conducting observations................................................................92 Leaving out observations................................................................95 Validating our observations (workshop 2) ..................................96 A police officer's manager talks back ...........................................98 Reading an article and developing sympathy...........................101 Making sketches and recycling ideas..........................................102 Evaluating and developing the concept (workshop 3).............104 Evaluating and developing the concept (workshop 4).............107 Creating and evaluating a prototype..........................................109 Reflecting on the project ...............................................................112 Summary.........................................................................................117 5. Designing with/for informal carers................................................121 Starting with an idea .....................................................................122 A kick-off meeting .........................................................................125 A literature study and survey......................................................125 Formulating a problem to address ..............................................129 Additional observations and interviews ....................................131 Making design decisions and sketches.......................................132 Further defining a problem and a solution ................................133 Attempts to improve cooperation ...............................................136 Interview rounds 1 and 2..............................................................139 A creative session...........................................................................141 Interview round 3 ..........................................................................143 Reflecting on the project ...............................................................147 Creating and evaluating a prototype..........................................152 Summary.........................................................................................155 6. Interpretation and discussion..........................................................159 Human-centred design as a socio-cultural process ..................160 Human-centred design as a political process ............................162 Ethical qualities of human-centred design practice..................165 Other and self...................................................................................169 Grasping and desire ......................................................................171 Openness and closure ......................................................................175 Iterations .........................................................................................178 Design thinking..............................................................................181 Decision and invention .................................................................183 vii Other interpretations.....................................................................185 Reflexivity (2) .................................................................................188 Reflexive practice ...........................................................................191 Fragility ...........................................................................................195 Topics and perspectives outside the scope of my study ..........197 7. Conclusions and recommendations ...............................................201 About form (2)................................................................................201 Conclusions ....................................................................................202 Legitimacy ......................................................................................205 Recommendations .........................................................................206 Realism ............................................................................................209 A checklist.......................................................................................211 Bibliography ...................................................................................213 Summary.........................................................................................225 Samenvatting..................................................................................233 Acknowledgements.......................................................................241 About the author............................................................................243 viii 1 To the reader This book is full of essays (cf. To the reader in the Essays of Michel De Montaigne 1877 [original 1588]). I attempted to practise humancentred design and I attempted to write about that. I wrote this book for mainly personal reasons – not to serve a wide audience or for my own fame. I am not enough of a scholar or a writer to accomplish such goals. Moreover, if I had wished to become famous, it would probably have been wiser to portray myself in a more favourable light. Instead, I pictured myself as 'naked' as possible, including my many shortcomings. This book is intended for other people who try to practise human-centred design; for people who try to provide a voice or a role for so-called users in their research and design efforts. I provide an account of how we, a group of researchers and designers, tried, together with 'users', to learn and create innovations. I combined practitioner and analyst roles in order to learn through experience, and I found that our HCD practice differs from HCD principles and theory. My message is twofold: I think that, in many cases, I would encourage people to do practise HCD and at the same time I argue that HCD is more difficult than people tend to think at first glance. Lastly, I would like to point out that I am the main character in this book and I see it more as a personal diary than a research report. If you wish to read about such a 'frivolous and vain' subject as my personal observations and reflections, then allow me to invite you to do so: Please, be my guest. 2 3 1. Introduction I wrote this book with a specific audience in mind: people who, like me, attempt to organize or conduct human-centred design (HCD). As a practitioner of HCD, I feel attracted to its goals of providing users a voice or a role in my research and design processes. And as an analyst of HCD practice, I see several issues that can put those goals at risk. In this chapter I will introduce my research themes in the form of scripts of two meetings: a meeting with people within the organization where I work and a meeting with the two people who supervised the research that I am reporting in this book. INTERIOR, CONFERENCE ROOM, DAYTIME A conference room at TNO Information and Communication Technology, a research organization. The walls are light grey, the carpet is dark grey. There is a poster that reads: 'TNO: Knowledge for business'. Seven people are sitting at tables arranged in a U-shaped rectangle: ERIK, VALERIE, RIEN, JAN, ANGELIEN, LAURENS and ME. We are sitting in groups of two or three along the sides of the 'U'. ME: Welcome. I am glad you could make it despite your busy agendas. What I propose to do. I sent you all my research proposal and asked you to read it as a preparation. Did you receive it and did you find a chance to read it or browse through it? Yes? Great. What I propose to do is first to talk about what I wish to study, why I think it is relevant and how I wish to conduct my research. After that, you are invited to make comments or ask questions. Is that okay with you? Fine. Together with a number of colleagues we try to apply human-centred design [cf. ISO 1999] approaches in our innovation projects. The idea is to talk with users about their practices, needs and preferences, and to jointly envision, create 4 and evaluate future products with them and for them. The idea is to organize such user involvement as early as possible in a project, and throughout its iterative phases of design and evaluation, in order to be able to apply what we learn from such interactions as early as possible, so that users' contributions can help to steer the project. Now comes a difficult part for me. I will try to explain how my research interest emerged from feelings of frustration and irritation. I felt frustrated about the place of human-centred design in our projects. Ideally, the findings from human-centred design efforts steer a project, but in practice they are often overruled by technological considerations, for example when we make a priori choices for or against a certain technology which then tend to steer the project, or by economic considerations, for example when solutions are evaluated in short-term financial terms which overrule other concerns. We may do field studies, interviews and workshops together with users to create a design that we expect people to like and use, but if the project's client or commissioning party wishes to do something else, he or she can just do that. Human-centred design is only one of the forces influencing the project, and often a weak one. Furthermore, when we do humancentred design, I sometimes feel irritated. That is to say. Er. We call our approach participatory, as in participatory design, but how much user participation do we actually allow? I mean, if I set the agenda in a workshop with users then they participate only within my agenda and the chances are that I do not listen to what really matters to them. And how much empathy'– as in empathic design, do I actually have with users? If, in an interview, I ask only questions within the scope of what I am interested in, and if I focus on the interviewee's role as the user of one specific product, I will tend to neglect this person's other roles and experiences. Those are the reasons why I became interested in studying the practice of humancentred design; to see how that practice differs from the theory and principles of human-centred design. My goal is to describe what researchers and designers do when they interact with users and within their project-team, and how they make decisions in order to make progress in their research and design. My empirical study will be based on participant observation in one project in which I am involved, and of which I coordinate one part. People from different organizations participate in this project and we follow various human-centred design approaches. We work on the design and evaluation of two telecom applications together with 5 and for two groups of users: one with/for police officers and one with/for informal carers [Chapters 4 and 5 respectively]. ERIK: I am a senior consultant and Marc asked me to participate in this meeting because I have a constructive approach. I find it interesting that you focus on researchers' and designers' attempts to cooperate with users. What I would like to see as a result of your research are recommendations for practice. For example: if you follow approach X in your project, then this will happen. And if you follow approach Y, then something else will happen. So that you don't end-up with a general statement such as: 'It's a good idea to cooperate with users'. ME: I understand your suggestion. You would like me to provide recommendations for human-centred design practice. I did consider formulating hypotheses and evaluating them empirically, but I decided not to do that. I will not be doing experiments or evaluations. I will 'simply' try to describe human-centred design practices in one project. I am putting quotation marks around 'simply' to indicate that 'merely' describing interactions between people and decision-making processes can be enough of a challenge. My goal is to provide descriptions, rather than prescriptions. However, as a more constructive reply to your suggestion, and because I share the concern about making my research relevant for practice, I plan to articulate and discuss several tentative recommendations. But I guess it would require a follow-up project, or a project carried out by someone else, to actually try out or evaluate these recommendations. VALERIE: I am a senior researcher and part-time professor of science and technology studies, or STS, and that is one of the reasons why Marc asked me to participate. In response to the suggestion to articulate recommendations for practical applications, I would encourage you to not think about applications too soon. Instead, I would suggest that you define what you wish to contribute to the field of STS. You are going to study empirically what researchers and designers do, which would fit perfectly within STS. I suggest that you take several concepts from STS and then formulate a research question and draw up a research approach. ME: I appreciate your suggestion. In my research proposal I refer to two concepts from STS. One relates to 'configuring' [Woolgar 6 1991a] the user, which is about how researchers or designers articulate – sometimes explicitly but more often implicitly – an image of a user and then design a product for that person. Another is 'scripts' [Akrich 1992], which is about how researchers or designers incorporate their ideas about what a user looks like and does – or more precisely: what they think a user should be like and should do – into the product they are developing. In addition, I borrow several ideas from texts of the philosophers Levinas and Derrida in order to talk about other and self and about openness and closure. I am interested in what happens when researchers and designers interact with others and in their attempts to be open towards others – towards users and towards fellow project-team members – and to other people's ideas. I am interested in how they balance those attempts with their tendency to stay within their frames of thinking and acting and with their tendency to create closure, the need to draw conclusions and create results. VALERIE: You are trying to combine two very different approaches: an active approach of doing human-centred design and a reflective approach of science and technology studies. These are very different. If I were you, I would make it very clear how these relate to each other and how your thesis is oriented towards these two approaches. ME: My plan is to study one human-centred design project from an STS perspective. So the substantive topic of my research is humancentred design [chapter 2] and the research approach is positioned in science and technology studies [chapter 3]. That is how I try to keep these domains apart. I mean, this is how I try to connect these two domains. My thesis is intended to connect these two different approaches. RIEN: I am human resources manager in our organization and Marc and I share an interest in organizational culture. I am not an expert on your topic or on research methodology, but it seems to me that you will have difficulties with such a dual role. You will be working in this project and you will be studying this project simultaneously. ME: I am aware of the dual role. I have also experienced ambiguity because I work in human-centred design projects with colleagues and I provide consultancy to clients about human-centred design, 7 and these roles contrast with my current attempt to critically study human-centred design. But, returning to your question: I hope to find a way of making that dual role work to my advantage so that it allows me access to what I wish to study and, at the same time, allows me to maintain some distance from what I wish to study. JAN: Marc and I share an interest in knowledge creation and innovation management, which is one of the reasons I am here. Another reason is that the project which he is studying is part of a research programme that I coordinate. One of the things that I like in your proposal is your observation that researchers and designers very often take themselves as examples when they envision users and what users will do with their products. They create fictional personas and storylines that look just like them, with highly-educated, reasonably well-off people of around 30 years old. You rarely see storylines featuring 60 year-old ladies, for example. ME: That's right. I once made a small collection of personas and storylines [e.g. http://www.itu.int/osg/spu/ni/futuremobile/ Broadbandmobile.pdf] and it occurred to me that the main characters are 20 to 30 year-old men who rush from meeting to meeting, hop in and out of taxis and airplanes, and bark orders in their mobile phones. This set me thinking. Do these people represent users, or are they models for the researchers and designers themselves? Here, there is a relationship between human-centred design and STS. In many human-centred design projects, researchers and designers create fictional personas and storylines: descriptions of potential users of the product on which they are working and short narratives in which they use the products. I see these practices as instances of configuring or scripting users. ANGELIEN: Marc asked me to participate because I am the manager of the business unit in which he works. What I like about your research is your alternative perspective: your other perspective on innovation, your references to Levinas and Derrida. I think it is valuable to explore and articulate such alternative perspectives on innovation because sometimes I get the mistaken impression that innovation is only about technology or only about money. My advice is to clarify the added value of the other perspective and 8 define how it stimulates a different process or delivers different results. I would like to see that added value more clearly. ME: Thank you, Angelien. I would like to relate your comments to a question about how I can make my research relevant. I expect that I will have two different audiences who will be looking for different kinds of relevance. I hope that my thesis will help practitioners – such as my colleagues – to look differently at their human-centred design practice and to organize and conduct it differently. And I hope that scholars, from organization or management studies, from design studies and from STS, will appreciate a practitioner's account of human-centred design; the practice is not easily accessible to social science because of the practical difficulties of studying a project intimately for a longer period of time. Put differently, I hope to create relevance by combining practitioner and analyst roles. ANGELIEN: Marc, I do have two more suggestions. First, I would like to see how your thesis fits in a wider discussion about the role of users in innovation processes. Second, I would like to see some kind of evaluation by users of the products that you design. What do they think about what you created for them? Ask the police officers and informal carers to talk about whether they recognize themselves in your conclusions and whether they appreciate the products that you create for them. ME: Thanks for your suggestions. I hope to position my study in a debate about the relationship between people and technology. The currently accepted idea in academia is that people and technology are in a complex and reciprocal relationship and exert a mutual influence on each other. This idea of 'co-construction' [Oudshoorn and Pinch 2003a] is intended to replace the (often optimistic) idea that people can use technology as a neutral instrument or unproblematic tool ['determinism'] and to replace the (often pessimistic) idea that technology is autonomous and that it can threaten people and what being human is about ['essentialism'] [cf. MacKenzie and Wajcman 1999]. Related to this debate about the relationship between people and technology is a debate about the relationship between design and ethics [e.g. Van de Poel and Verbeek 2006], to which I hope to contribute. The texts of Levinas and Derrida enable me to write about their particular ideas on ethics. With regard to your second question about asking users to 9 evaluate the products we created together with and for them: well, in many projects I am interested in users and in their perspectives, needs and preferences, but in the context of this thesis my primary objective is to study what researchers and designers do. Several COLLEAGUES and FELLOW PROJECT-TEAM MEMBERS open the door. They look surprised and ask, almost in unison: You are not interested in users? ME: No, I'm afraid not. In the project I'm studying we are interested in what users do. But in this study of the project, I am primarily interested in what researchers and designers do, including how they interact with users, how they speak and write about users, and how they represent users in their decision-making at project meetings. Users only appear in so far as researchers and designers interact with them and talk and write about them. This is different from how I normally work and from what I am normally interested in. I did consider the option of interviewing the police officers and the informal carers whom we interviewed or did workshops together with in order to learn about their perspectives. But I decided not to do this because it would suggest that I follow a positivist approach – as if there is a 'real' reality outthere that I can study objectively – and I don't want to follow such a paradigm. Instead, I chose to follow a social constructionist approach and focus on what happens within the project-team [see Chapter 3]. Within that approach I hope to be able to study, amongst other things, the way in which project-team members discuss how users evaluate our ideas, concepts and prototypes. We will involve users in such evaluations, for example via workshops or trials. However, I will focus on what the projectteam do and I will not make any truth claims about what users out-there 'really' think of our products. LAURENS: I am scientific director and I coordinate the budgets for PhD research in our organization. I am enthusiastic about your topic, which I think fits in with our current research themes of open innovation and social innovation, and about the prize you were awarded for your essay [Steen 2006a]. I will recommend granting you a budget at the next management team meeting. In addition, I have a question for you. I understand that you plan to study one project in which you yourself are working. I can imagine that 10 people will ask you why you are studying only one case. What does this one case tell us about other cases? ME: Thank you very much Laurens. I think your question is about generalizability. Many people probably associate generalizability with statistics. When you decide to study a sample of certain phenomena, the sample must be of a certain size in order to be statistically representative for a larger population. But there is another kind of generalizability that is more appropriate for my type of research. That generalizability is about attempting to study one case in such detail that you can talk about concepts that have 'relevance to other settings' [Easterby-Smith et al. 2002, p. 53]. I plan to study one project in detail, from an inside perspective and over an extended period of time, and I hope to find concepts that are relevant for other cases as well. Furthermore, I hope to create added value by choosing an innovative angle to look at design and innovation by applying several ideas from philosophy – other-self and openness-closure. I hope to provide an alternative account of human-centred design and uncover some of the qualities of human-centred design that normally remain hidden. I look at my watch. ME: I see it's almost time, so let me summarize my research theme and approach. I am interested in human-centred design practice and in how it differs from human-centred design theory and principles. I will study one project in which I work and in which we attempt to practise human-centred design. I am interested in what happens within the project-team: how researchers and designers interact with each other and with users; and how they make decisions during their research and design efforts. Thank you for your attention and your time. I appreciated your questions and suggestions. Over the next few months I will conduct further desk research into human-centred design and into research methodology, and at the same time I will conduct participant observation in this project and write about it. INTERIOR, SMALL OFFICE, DAYTIME One or two years later. A small office at Delft University of Technology or at the University for Humanistics. Large, colourful posters are on the walls or there are piles of books laying around. 11 Three people enter the room, HUGO, JAN and I, carrying plastic cups with coffee. We sit down at a table with four places. JAN also brought several packets of sugar-free sweetener for the coffee. JAN: So, now we have our coffee. How are you, Marc? ME: Fine. I would like to talk with you about my research. JAN: Right. Well, if you'd like to go straight to business, that's fine with me. I've read your texts, but somehow I am still missing what you are interested in. I mean, could you say simply and straightforwardly what you are curious about? ME: Well, I am critical of the way we practise human-centred design. I would like to provide an account of human-centred design practice in a single project. My goal is to open the 'black box' [Latour 1987; Winner 1993; Ashmore 1989, p. 4] of human-centred design and to show what normally remains hidden. Expressed differently, my goal is to 'deconstruct' [Derrida 1991; Critchley 1999; Letiche 1998] human-centred design; to provide an alternative reading of it and draw attention to its ethical qualities. With ethical I do not mean to evaluate or prescribe what would be morally good or bad in a human-centred design project. But I am interested in a form of ethics that Levinas and Derrida wrote about – in a form of ethics that happens between people: in movements between other and self and between openness and closure; and in qualities of human-centred design that are usually marginalized. My plan is to conduct participant observation in one project in which I am involved, and write about that. JAN: I like your approach of studying a project from within, while it happens, because it fits with a trend in the research that is being conducted within our department [Industrial Design Engineering of Delft University of Technology]. We gradually moved towards studying realistic design practices. We began by studying design students in experimental settings, then we studied design professionals in experimental settings [e.g. Cross et al. 1996; Dorst 1997] and then we studied students outside the lab [e.g. Valkenburg 2000]. More recently, we studied professional designers in their natural contexts [e.g. Smulders 2006; Kleinsman 2006]. I think your project would fit in with this shift. However, I wonder whether... It seems as if writing about your personal 12 experiences of working in one project brings the risk of writing a diary that is mainly of interest to you yourself. Why would I be interested in reading about what you did and what you thought and felt? How would that become relevant for others? These others may be academics in design studies, in sociology or in philosophy, or they may be practitioners, people who work in research or design projects. ME: Concerning your question about relevance, it is my hope that my texts can help practitioners to look differently at their humancentred design practices. I borrow concepts such as other and self and openness and closure from Levinas and Derrida in order to look at such practices in a different way than is usually the case. I believe that researchers and designers who try to conduct humancentred design are already moving between other and self and between openness and closure, but that they are not very aware and not very explicit or articulate about these moves. Practitioners rarely discuss these movements or take them into account when they organize and conduct their projects. A human-centred design project is often organized as if it is an engineering project or a scientific study: as a linear project through which one proceeds via analytic procedures. Alternatively, I think that human-centred design is an 'interpretive' [Lester and Piore 2004] process that happens between people, that it has ethical qualities and that we can organize it more in accordance with those ethical qualities. I like the idea of being a kind of social worker who tries to emancipate researchers and designers who attempt to do humancentred design. I hope to help some of my colleagues, partners and clients to become more aware and more articulate about the hidden and marginalized ethical qualities of human-centred design and to organize and conduct human-centred design in a different way. HUGO: You say you wish to write about self-other relationships. But in the texts you have written so far, you never talk about self-other. You write about project goals and the professional roles of projectteam members. You never write about people's identities or about how they establish and negotiate their identities and their relationships with each other. Another thing that strikes me is this: the users are never there! You talk about them, but they are never actually present. 13 ME: Er, yes. Well, I feel puzzled and insecure about your remark. Are you criticizing the way in which I organize and conduct the project? That we don't allow users to participate? Or are you criticizing how I am conducting my this study? Is it that I don't pay proper attention to self-other? Or that I don't write properly about self-other? Or do we have a different conceptualization of what human-centred design is about? That would be in line with my main argument, namely that human-centred design practice can be puzzlingly different from human-centred design principles, and that researchers and designers indeed find it difficult to give users a voice or role in their projects. Or are you providing me not with a critique but with a suggestion? Let me begin with a simple reply: I do agree with your observation that users were not present in our project most of the time, and that most often we represented them. What was your other question again? HUGO: So far – and I am referring to drafts of your Chapters 3 [Steen 2006b] and 4 [Steen 2006c] – you don't write about self-other. For example, if you were writing about self-other, then you would be writing about your own role, about your relations to others, and about how you position yourself towards the people you work with. You would need to write reflexively! Or you could decide not to address self-other and not to write reflexively. That would also be fine with me. I tend to say 'Don't write a fully reflexive text', because then you would need to rewrite all your material and analyses, which would involve a great deal of work. Alternatively, you can write about project goals and about professional roles, which will be interesting enough. ME: I guess that you are suggesting that reflexive writing would need to take social constructionism further than I currently do; that I attempt to do something like 'critical relational constructionism' [Hosking 2002] or take into account that social constructionist 'research is both about socially constructed events and objects and [also] a specific instance of the social construction of events and objects' [Pearce 1992]. Now, I guess that is indeed not what I am trying to do. However, I do wish do something with concepts such as other and self, and openness and closure. HUGO: Well, what you can do, is a sort of compromise: you can write the main part of your thesis about human-centred design and 14 focus on project goals and on professional roles, then add several pieces of reflexive writing to these texts. JAN: What I noticed in our previous conversations is that, when you speak with us, you can sometimes be open and personal and, for example, speak reflexively about how you feel, what you are interested in, what you find important, what kind of frictions you experience. But somehow it seems to me that, as soon as you start to write, the warmth disappears and ice cubes are added to your words, so to speak. Your writing seems so much colder than the way you sometimes speak. ME: I do recognize what you say and I don't feel happy about that. I wish I was able to write about what I think and feel in the same way that I can sometimes speak about what I think and feel. Levinas wrote about the difference between the 'Saying' – what one is able to say and what can sometimes happen between people – and the 'Said', the written text about what happened between people [Critchley 1999, p. 7]. What I write is always a reduction, a 'residue' [ibidem, p. 8], of what happened between people, between other and self. HUGO: I am worried about your two roles. You are working on this project, you actively intervene in it, and you are studying the project and writing about it. I think you must acknowledge the different roles; 'there is a difference, but the actor and the reflective roles really should never be allowed to be opposed or separate! This separation is the cause of many problems ...' [e-mail, 26 September 2006]. JAN: I am not sure how I can help you with this, Marc. In most research in which I am involved, the researcher is in a more detached position: outside the object of study. You are participating in the project that you are studying. It's as if you have two I's – the project coordinator and the thesis writer – on the psychiatrist's couch together, and we are the shrinks who ask questions to both I's. I can imagine that would make you feel uncomfortable. HUGO: If you mention Levinas, then you must realize that for Levinas your relationship to the other is not a matter of choice. The other and the relation between other and self are ontological. You 15 cannot choose. You write about the possibility to do humancentred design, the choice to give the other a role in your project. But for Levinas, the other is already there. You cannot choose. The whole assumption behind human-centred design and the way the other is approached seem to be very superficial and very instrumental. Now that would be interesting to write about. ME: I think I understand what you say. As I mentioned before, I think that human-centred design already has ethical qualities. I agree with you that I cannot choose to do human-centred design ethically or not; when one does human-centred design, one finds oneself in ethical relations to others. However, I think that I can and must make decisions about how I want to try to act in these relationships. Levinas wrote about the other who puts me in a position of responsibility – I have to respond – and about how this responsibility enables me and forces me to choose how to act; this responsibility constitutes my freedom [e.g. Duyndam and Poorthuis 2003]. HUGO: Well, sort of. JAN: I would like to discuss another assumption of human-centred design. We seem to assume that we can constructively talk with users about their future needs and about future products; design is always about the future. However, approaching such questions, I think, requires skills and knowledge which designers typically have to some extent. But how can you expect a user to talk reliably about his or her future needs and about future products? ME: I am sorry if I failed to make that clear. My understanding of human-centred design is that it is not a method to study people's needs so that we can design something for them. I would not, for example, bluntly ask someone to sum up his or her needs. Instead, we would attempt to engage in a dialogue in which we can learn from each other, and jointly explore and articulate ideas about needs we can try to solve. Additionally, I would not ask someone directly to invent some new product for me. Instead, we would attempt to create a setting in which different people contribute their skills and ideas so that we can jointly explore, envision and evaluate ideas, concepts and new products. 16 HUGO: Practitioners of human-centred design currently seem to have assumptions about how to approach the other and your attempt is to clarify that they have not yet thoroughly thought about these assumptions and about how these assumptions are problematic in the practice of doing projects. As I see it now, they can either continue their practice but become more modest and not call it 'human-centred' design, or they can decide that it is worthwhile to rethink their practice and to try to make their practice more humane. ME: I wish to show what happens in human-centred design and I would be happy if some practitioners start to think differently about their practice and attempt to organize or conduct their practice differently; more towards what human-centred design can be about. JAN: Your goal will be to help them to become more confused; confused on another level. Summary and overview of chapters In many projects in the ICT industry there is little room for users. However, in some projects researchers and designers attempt to practise human-centred design (HCD): they attempt to step outside their ivory tower and meet and interact with users. However, based on my own and my colleagues' day-to-day experiences of attempting to do HCD, it seems that this is not an easy task and that good intentions do not simply become practice. In this study, I wish to critically reflect on HCD practice. By 'critically' I mean that I wish to identify how HCD theory, principles and best intentions differ from HCD practices. (The word 'critical' comes from the Greek krinein, which means something like 'to differentiate, to separate'.) I will not be concerned with evaluating or improving HCD practice, but I will be concerned with revealing and discussing some of its qualities that normally remain hidden. My research question is: What happens in human-centred design practice and how does this differ from the theory and principles of human-centred design? 17 Chapter 2 contains a review of several HCD approaches. In this review, I draw attention to two tensions which I think are inherent in HCD practice, namely a tension between the roles and agencies of researchers/designers versus users' roles and agencies, and a tension between concerns for understanding current situations or practices (is) versus for envisioning future situations or practices (ought). In Chapter 3, I discuss my research approach and decision to study one project, in which I myself am working, over a period of four years. This approach allows me to study from within how people interact with each other, to study the roles and agencies of projectteam members as opposed to users, and to study how project-team members make decisions over a period of time during their research and design efforts. Furthermore, I introduce reflexivity as a means of coping constructively with combining practitioner and analyst roles. Chapters 4 and 5 contain my accounts of the project activities. We attempted to design two telecom applications: one with and for police officers, and one with and for informal carers. In my accounts of these two cases, I describe and reflect on what we did and combine this with attempts to write reflexively about my own role(s) in the project. In Chapter 6, I interpret the two cases and discuss how HCD can be understood as a socio-cultural process, as a political process, and as a process with ethical qualities. I focus on the ethical qualities of HCD practice and interpret the two tensions (from Chapter 2). I interpret the tension between researchers/designers and users in terms of movements between other and self, and I interpret the tension between concerns for is and ought in terms of movements between openness and closure. Chapter 7 contains conclusions and recommendations. I argue that HCD has ethical qualities and that these qualities are marginalized in HCD practices. I present HCD as fragile: I think that it can be beautiful and that it can break easily. Furthermore, I recommend that practitioners bear this in mind when they organize or conduct HCD. I recommend reflexive practice as a way for practitioners to be (more) aware of and (more) articulate about their own role and agency in their HCD practices. This would help practitioners to align their practice more closely with their intentions and with what HCD can be about. 18 About form (1) The form of fictional dialogue (above) was inspired by Malcolm Ashmore's The reflexive thesis (1989). This book contains The fiction of the lecturer, a lecture in which a narrator delivers a lecture and an audience reacts, and The fiction of the candidate, an examination in which a narrator is questioned by two examiners. One reason for applying such 'new literary forms' is that it allows an author to write about situations in which he or she was involved. The dialogues above are fiction and are based on real situations with real people. The scripted actors' lines are paraphrases of what the real people said at various meetings (on 8 November 2005 and on 26 June 2006 for the first scene, and at various, almost bi-monthly meetings throughout 2006 and 2007 for the second scene). Moreover, the real people read the scripts and gave their kind permission to be represented in this form. The form of scripted dialogue enabled me to order and present people's utterances to suit my own purposes. My 'authorial power' allowed me to 'entirely control what [people] are allowed to say' (Woolgar 1993, p. 523). For example, in the first scene, I present myself as being relatively in control, whereas in the second scene I present myself as less in control. Furthermore, these scripts can be understood as creating a second chance. I was not always able give satisfactory answers to the questions asked during the meetings on which the dialogues are based because I was in the middle of finding out what to study and how to study it. Now, looking back, I can create improved versions of these meetings. I prefer to regard this first chapter not as an opening chapter but as a closing chapter, because it is meant to help me to create closure. I chose certain directions and closed-off other directions in order to focus and proceed with my research and my writing. 19 2. Human-centred design This chapter is about human-centred design (HCD), which I see as an attempt by researchers and designers to open their research and design efforts to users; an attempt to step outside their ivory tower and interact constructively with people out-there for whom they are developing a product. For people who have never been involved in research and design, such user involvement – which I use as a synonym for HCD – may seem obvious: to talk with the people for whom you are creating something and to learn about their needs or preferences before you start the creation process. However, this is not common practice in the information and communication technology (ICT) industry. Many ICT innovations are driven by the development of new technologies. I see HCD as an alternative to this type of 'technology push'. Positioning There are some paradoxes in my position. I work in the ICT industry and I would like to continue doing so. At the same time, I tend to be critical of an unquestioning belief in progress through the application of more and more ICT. Moreover, I work in research and design roles in HCD projects and would like to continue doing that, while at the same time, I would like to conduct a critical study of HCD practice. The belief in progress through science and technology is often traced back to the beginnings of western modernity in the seventeenth century and, more specifically (e.g. Achterhuis 2006), to Francis Bacon's The New Atlantis (1627), in which he described an utopian island where people lived happily thanks to the development and application of all sorts of science and technology. I was exposed to this belief in progress as a student of industrial design engineering, and in my current work context. This belief in progress is obvious in 20 the ICT industry, with its promises to improve people's life and work. However, many innovations in the ICT industry are driven by technology push and separated from people's needs and preferences. Many ICT innovations have become self-referential. Here is an illustrative quote from Neil Postman's Technopoly, a critique on the excessively dominant role of technology in our society (1993: p. 61): Attend any conference on telecommunications or computer technology, and you will be attending a celebration of innovative machinery that generates, stores, and distributes more information, more conveniently, at greater speeds than ever before. To the question "What problem does the information solve?" the answer is usually "How to generate, store, and distribute more information, more conveniently, at greater speeds than ever before". I am not against this belief in progress. (How can a fish be against water?) But I would like to explore HCD as an alternative to technology push and to the Baconian dogma that holds that we can and should observe, model, predict, manipulate, monitor and control the world around us, including other people. There have always been people with a critical stance towards the development or application of technology: farmers who objected to railways being built on their land, or workers in the textile industry who burned machines that were meant to replace them. I am not going to set fire to anything, but I would like to critically study my own practice of designing ICT applications. Victor Papanek, in Design for the Real World, critiqued the practice of developing and marketing products that serve no 'real' needs (1991, p. ix): There are professions more harmful than industrial design, but only a very few of them. [...] industrial design has put murder on a mass-production basis. By designing criminally unsafe automobiles that kill or maim nearly one million people around the world each year, by creating whole new species of permanent garbage to clutter up the landscape, and by choosing materials and processes that pollute the air we breathe, designers have become a dangerous breed. 21 John Thackara (2006) wrote with a similar goal – but without the 'blaming and shaming' (p. 7) designers – about how technology has evolved from a collection of tools used for doing things into a selfperpetuating system (p. 2). He also argued that (p. 189): We've constructed ourselves an industrial system that is brilliant on means, but pretty hopeless when it comes to ends. We can deliver amazing performance, but we are increasingly at a loss to understand what to make and why. Thackara advocated seeing design not only as part of the problem but also as part of the solution: 'If we can design our way into difficulty, we can design our way out' (p. 1): 'A conscious effort is needed – a design effort – to connect the properties of the myriad materials and processes available – whether natural or man-made – to the needs we have as people in our daily lives' (p. 189). I feel similarly optimistic about HCD and I think it can be an alternative – or even a counterforce – to technology push and a way to provide a voice or a role to users. At the same time, I am aware that people versus technology is a false dichotomy (Latour 1987; 1996) and that the idea that people can control technology is naive (Berg 1998). Nevertheless, I like to believe that HCD can help people to exerr influence on the shaping of technology and to develop a more reciprocal relationship towards technology, rather than being passive and at the receiving end. My attempt is to further our understanding of HCD and I am aware of an implicit idea of progress in this attempt, which seems to surround me in the way that water surrounds a fish. The idea of progress also appears when HCD is positioned as a subsequent and progressive step in the way that ICT products and services are designed. A similar positioning is apparent in Liam Bannon's (1991) paper From human factors to human actors, in which he described shifts from individual users of ICT to groups of people using ICT, from laboratory research to workplace interventions, from analysis to design, from user-centred design to user-involved design. This shift is related to the introduction of ICT in the workplace and to the emergence of the field of computer supported cooperative work (CSCW): the study of how people use ICT for communication and cooperation and the design of ICT that match the social and cultural aspects of people's work. Other trends related to this positioning of 22 HCD as a next step are: the shift from ICT used in the workplace to ICT used in everyday life and leisure (Bødker 2006), enabled by the convergence of telecom, IT and media and the adoption of ICT in people's everyday lives; the move from a focus on cognition and usability to a focus on users' experiences (Pine and Gilmore 1999; Buchenau and Fulton Suri 2000); and on the design of 'pleasurable products' (Jordan 2000). Furthermore, there are parallels between HCD and 'open innovation' (Chesbrough 2003), 'co-creation' (Prahalad and Ramaswamy 2004) and 'outside innovation' (Seybold 2006), which can be understood as attempts to open up innovation processes in ways that enable users to participate and contribute. Currently, companies such as Philips are aiming to develop an understanding of people's needs as a basis for creating innovative products (Marzano 2005) and design agencies like IDEO explore design ideas and develop and evaluate prototypes together with users (Fulton Suri 2003b). The interests of researchers and designers zoomed out from looking at one person using one ICT product for one task, often information retrieval or editing, to looking at groups of people who use multiple ICT products and services in different contexts, often for communication and cooperation. The involvement of users shifted from asking questions about usability at the end of a project to all manner of interaction, from the start of a project and during its iterative phases. Human-centred design I will focus on the attempts of researchers and designers to interact constructively with users during research and design activities. I use the term human-centred design to cover a wide range of approaches. The International Organization for Standardization, in their ISO 13407 standard, characterized HCD with four principles (ISO 1999): 1) The active involvement of users and a clear understanding of user and task requirements; 2) An appropriate allocation of function between users and technology; 3) Iteration of design solutions; 4) Multi-disciplinary design. The first principle is of interest, although I would rephrase 'user and task requirements' into something like 'people, their needs and 23 preferences and how they want to use technology' in order to indicate a shift from 'users' to 'people' (cf. Bannon 1991). Furthermore, principles 3 (iterations of designing and evaluating solutions) and 4 (multi-disciplinary teamwork) are of interest because I am interested in how HCD projects are organized and conducted. Principle 2 (allocation of functions between users and technology) applies mainly on the content level of design decision-making and, since I am focusing on the process, I will pay only indirect attention to it. My focus is on the activities of researchers and designers. However, I recognize that their work is only half of the innovation process; the other half is done by people who adopt, domesticate or appropriate innovations. 'Users' can perform all sorts of active and creative roles and influence the shaping of an innovation (e.g. Oudshoorn and Pinch 2003b; Mante-Meijer and Klamer 2004; Haddon et al. 2005). Another way of putting this is to say that both designers and users shape an innovation. Nevertheless, my focus is on what researchers and designers do within an HCD project, on how they think and talk about users and 'construct' users 'out there' (Latour and Woolgar 1986), rather than focusing on any 'real' users or their 'real' properties. Terminology There are some terms which I would like to comment upon. I use the word 'users' as shorthand for 'future, potential or putative users'. The latter draws attention to the fact that the product or service which is being developed is not yet finished and that there are not yet any end-users (Redstrom 2005). Furthermore, I use the term 'users' in order to refer to people for whom a product or service is primarily or ultimately intended and not, for example, to maintenance staff who also use the product. I could have chosen the term 'end-user', which would be more accurate to describe this role, but I chose 'user' instead because 'end-user' is easily associated with a passive role of a person at the receiving end, a person at the end of chain of events, whereas I would like evoke the more active and creative roles of users. Moreover, I write 'users' rather than 'customers' in order to refer to people who actually use the product or service and not, for example, to people who decide to buy it or who pay for it. Of course, a user can also be a customer, as is the case for many consumer 24 products and services: the one who uses it is also the one who buys it and pays for it. Then there are the terms 'human-centred design' and 'user involvement'. I use the word human-centred design to distinguish it from user-centred design, which I associate with approaches that confine a person to his or her role as a user and which emphasise usability rather than how a person experiences a product or service and its usefulness. My preference for using the term human-centred design instead of user-centred design concurs with that of Patrick Jordan (2002, p. 12): The problem with usability based approaches is that they encourage a limited view of the person using the product. This is – by implication if not by intention – dehumanizing. Furthermore, my preference for human over user is inconsistent with my usage of the term user involvement. I could have chosen to use a term such as people involvement, which would more appropriately suggest that I see people not only in their role of user, and also that a range of people, with different and blurring roles can participate in research and design. However, I decided to use the term user involvement to conform with other authors; only few people use the term people involvement. Additionally, I use the words researcher and designer to denote roles or activities rather than people or occupations. One person can at one time do research, that is 'study something carefully and try to discover new facts about it', and at another time he or she can design, that is 'decide how something will look, work, etc. especially by drawing plans or making models' (Oxford Advanced Learner's Dictionary, 7th ed.). Moreover, I am keen not to use the term R&D (research and development), because it is often associated with an organizational function or department and sometimes with a tendency to be concerned with internal matters and to focus on technology, which would be quite different from what HCD tries to achieve. Involving users Many organizations, both private/commercial and public/not-forprofit, need or want to innovate (Tidd et al. 2001, p. 17). Not for the 25 sake of innovation itself, but in order to create new products or services or processes that will, in turn, create added value for the people who use the products or services. Developing innovations that match users' needs or wishes is especially (but not exclusively) problematic in high-tech industry, where many innovations are driven by technology push. A risk inherent in technology push is that researchers and designers create a product or service that people do not want or cannot use. There seems to be a gap between the world of researchers and designers on the one hand, and the world of users on the other hand (Muller 2002). HCD can be thought of as an attempt to bridge this gap, by involving users in research and design and bringing about constructive cooperation between researchers, designers and users. This can solve a key problem in innovation, namely that too many projects suffer from 'insufficient market input, a failure to build in the voice of the customer, and a lack of understanding of the market place' (Cooper 1999b). Furthermore, it has been noted that a lack of adequate understanding of users and their needs and preferences is a key factor in the failure of innovations (Panne et al. 2003). User involvement is seen as a way to obtain valuable contributions from users. In the field of designing and evaluating ICT products and services, Jacob Nielsen (1993, p. 74; quoted in Kujala 2003) observed that: It is amazing how much time is wasted on certain development projects by arguing over what users might be like or what they may want to do. Instead of discussing such issues in a vacuum, it is much better (and actually less time-consuming) to get hard facts from the users themselves. Sari Kujala did a review of the 'benefits and challenges' of 'early user involvement' approaches and projects in the in the ICT industry, and concluded that (2003, p. 11): User involvement is clearly useful and it has positive effects on both system success and user satisfaction. She also argued that: Involving users is not an easy task for designers. Early involvement of users appears to be promising, on the condition 26 that user involvement methods are developed further and the roles of users and designers are carefully considered. Designers should take an active role in user involvement. Users are experts in their own field, but they do not need to be experts in design. Furthermore, studies in the domain of service development suggest that users can help to create innovations (e.g. Alam 2005). A review of customer involvement in new service development advises managers to 'adopt a proactive approach and involve customers early in the innovation process', to 'focus [...] on capturing latent needs', to carefully 'consider the techniques and ways of working' to that end, and not to leave innovation 'solely to engineers' (Sandén et al. 2006, p. 122). One experiment may serve as an example (described in Kristensson et al. 2002; Magnusson et al. 2003; Magnusson 2003; Kristensson and Magnusson 2005; Magnusson 2006; Kristensson 2006). In this experiment 'ordinary users' and 'professional service developers' were invited to develop ideas for mobile telecom services, which were evaluated using three criteria: user value, originality and producability. Analyses showed that 'ordinary users' came up with ideas that were relatively more original and relatively more valuable for users, but their ideas scored relatively low on producability. This lower score for producability need not be a problem because there are all manner of methods to enable and facilitate researchers, designers and users to cooperate creatively and constructively. For example, users and designer can engage in 'mutual learning' so that they can jointly design a system that works (see: Participatory design, p. 36), 'lead users' can be provided with 'toolkits' (see: Lead user approach, p. 39), or 'everyday people' can use 'generative tools' to help them to envision and create ideas that can actually be produced (see: Co-design, p. 41). I would like to point out that I consider HCD not as a tool for studying and understanding people's needs, or as a tool for controlling and getting a grip on product development. For me, HCD is about trying to jointly learn and to jointly create; it is about letting users influence research and design processes. This is more like an exercise in trying to be open towards others and towards new ideas, which can be thought of as the opposite of trying to obtain a firm grip on things. This standpoint is similar to viewing innovation as an 'interpretive process', a view put forward by Richard Lester and Michael Piore (2004, p. 76) as an alternative to the currently dominant view on innovation as an analytical process: 27 In the analytical view, the customer has preexisting needs, and the job of the developer is to identify those needs and then to create products that meet them in an optimal way. [...] In the interpretive view, the customer has no needs until they are articulated, and this articulation is what the interaction between designer and customer is all about. In this view, innovation occurs if people meet and exchange ideas and meanings and jointly create new ideas and new meanings. They suggest facilitating 'conversations' between people, both inside and outside the organization, which are more about exploring and exchanging knowledge than about making decisions and creating closure. They suggested managing this process by acting like a hostess at a cocktail party (ibidem, p. 174-5). Advocates of user involvement have suggested that users are ideally involved from the start of a project and throughout its iterative cycles. This is because, at the 'fuzzy front end of innovation' (Koen et al. 2002) – the early stages of a project in which problems and opportunities, ideas and concepts are explored, which can be rather different from the later stages of development and implementation – many decisions need to be made, and are ideally made together with users or based upon their input. Early user involvement is intended to help to steer a project in such a way that it delivers products and services that match users' needs and preferences. The potential of user involvement cannot be fully realized if users are only involved at the end, for example in testing a finished product. Some critics of HCD would tend to make such remarks as: users cannot help you with developing new products or services because they do not have the necessary knowledge about technology. Or: users cannot tell you about their needs, especially not about their latent needs or their future needs because they are not aware of these. I tend to partly agree with this. Not all users have extensive knowledge about technology and cannot simply sum-up their latent or future needs. However, this need not be a problem. HCD does not necessarily imply that users perform research or design roles (although some can and do), but that they contribute to research or design processes, as experts on their own daily lives and on their own experiences with products and services. The idea is not simply to ask them about their needs ('Please, can you explain what your needs 28 are?') or to invent something ('Will you invent something new, please?'), but to organize a context and setting in which users can express themselves and envision new ideas in cooperation with researchers and designers. For me, the question is not whether users can contribute to research and design, but whether researchers and designers can organize and conduct their project in such a way that users can indeed contribute. This draws attention to the advice to carefully consider the 'roles of users and designers' (Kujala 2003) and the 'techniques and ways of working' (Sandén et al. 2006) cited above. Several authors have voiced objections or warnings to keep in mind when organizing HCD. These relate to whether researchers and designers should simply believe what users tell them and simply follow-up on what users say. For example, Van Kleef et al. (2005) mentioned three reasons to be cautious about relying on users' utterances: users may not be aware of their needs; they may be unable to articulate their needs; and they may be unwilling to speak about their needs with an interviewer. Furthermore, Panne et al. (2003) argued that researchers or designers can become prejudiced about customers' needs when they involve customers more regularly, and Stewart and Williams (2005) warned against over-emphasizing the findings from a study with a few users because such a study may result in an over-customized product that will interest only a few. Moreover, Hekkert and Van Dijk (2001) argued that paying too much attention to users may erode the role of the designer, whose vision and creativity are essential for the innovation process. I would like to place these objections and warnings in the context of what I have written above. In HCD, interacting and talking with users is not intended to extract information about their needs or ideas for new products. Rather, HCD is about facilitating communication and cooperation and jointly learning and creating new things. Recently, the guest editors of a special issue of CoDesign (Binder et al. 2008) observed that involving users in design at present would raise fewer questions than not involving them would: The claim often heard in the debate of the 1990s that users are unable to contribute to the design of new technologies with which they are not familiar seems now widely to be turned on its head. Today many companies and researchers question how successful design can be made without exploring people's everyday practices and aspirations and, ultimately, involving the people for whom designs are intended. 29 Finally, I would like to point out that I will not be concerned with discussing the success of products or services that result from human-centred design or user-involvement approaches. I can imagine that such evaluative studies would require a comparison between approaches, for example Project A with HCD versus Project P without HCD, and some measurement of success. Moreover, one would have to address questions such as: Successful for whom and successful in what ways? However, I will not address such questions and will focus instead on describing research and design processes. Tensions and approaches There are many different approaches to organizing and conducting HCD and they come from diverse traditions. In the following sections I will identify and discuss six HCD approaches. My purpose with this review is twofold: I wish to show how these approaches differ, and also how they are similar. I will do this by drawing attention to two tensions that occur in all HCD approaches and by proposing that these different approaches are different ways of dealing with these tensions. One form of tension is due to the differences between the world of researchers and designers, and the world of users (cf. Spinuzzi 2005). Michael Muller (2002) described this tension as follows: Each world has its own knowledges and practices; each world has well-defined boundaries. Movement from one world to the other is known to be difficult. We can see this difficulty manifested in our elaborate methods for requirements analysis, design, and evaluation – and in the frequent failures to achieve products and services that meet users' needs and/or are successful in the market place. HCD is an attempt to bring these worlds together and different HCD approaches attempt to do that in different ways: in some approaches researchers and designers attempt to move towards users, their worlds and their experiences; and in other approaches researchers and designers attempt to let users participate in and contribute to research and design. This tension can also be thought of in terms of designing for users versus designing with users, or one can envision a continuum between 'proactive user involvement' and 'reactive user involvement' (Limonard and de Koning 2005). 30 Another tension occurs because of conflicting concerns. In HCD one has to be concerned with understanding users' current situations or practices and with envisioning future or alternative situations or practices. In other words, one has to be concerned with what is and with what ought to be – with understanding the present and with designing for the future (e.g. Ehn 1988). This tension was also observed by sociologist Leslie Haddon and designer Kari-Hans Kommonen (2003). They wrote about the difficulties of multidisciplinary teamwork and focused on the differences between the tradition of social science, which is about studying, understanding and representing a current situation, and the tradition of design, which is about imagining and visualizing alternative or future situations. A social scientist typically 'spends some considerable effort in thoroughly documenting reality' whereas the 'primary emphasis of the designer is often about [...] changing that reality'. They remarked that designers tend to 'make "intuitive" decisions quickly based on experience as they try to develop ideas and arrive at a personal sense of what is happening', whereas academic sociologists are typically concerned with 'fully being able to justify' their interpretations, evaluations and decisions. They concluded that: The approach of social scientists requires them to do thorough work which might sometimes seem too deep to the designer and which may not address the designer's central questions. The converse is, of course, that the social scientists see the designer as being too superficial. A project may start with ideas about a current situation, often depicted as a problem, a 'present socio-technical context of use', or with ideas about a future or alternative situation, often depicted as an opportunity, a 'future use of a technology in context' (Limonard and de Koning 2005). In HCD, one cannot be concerned only with the is (as many social scientists are) or only with the ought (as some designers are); these concerns must be combined. Moreover, one has to perform 'the juggling act between the traditional researcher's role of collecting and analyzing data versus the activist's role of initiating and sustaining significant change at the research site' (Spinuzzi 2005). This tension can also be thought of in terms of a human-centred versus a design attitude. 31 I propose to use these two tensions as two axes and to plot six different HCD approaches in this space – see Figure 1: • Participatory design; • Applied ethnography; • Lead user approach; • Contextual design; • Co-design; • Empathic design. Figure 1: Different human-centred design approaches The horizontal dimension of the proposed overview plots a movement of users towards researchers and designers and their participation in research and design activities versus a movement of researchers and designers towards users and towards their worlds and experiences. This axis is similar to the (vertical) axis that Michael Muller and Sara Kuhn (1993) drew in their overview of participatory design approaches: 'Who participates with whom in what', going from 'Users directly participate in design activities' to 'Designers participate in users' world(s)' – see Figure 2. It is also similar to the A concern for current situations ('is'); a research orientation A concern for future or alternative situations ('ought'); a design orientation A move of users towards researchers and designers A move of researchers and designers towards users Participatory design Applied ethnography Lead user approach Contextual design Co-design Empathic design 32 (vertical) axis that Matti Kaulio (1998) drew in his review of approaches for customer involvement in product development: 'Type of customer involvement', going from 'Design by' via 'Design with' to 'Design for' – see Figure 3. Figure 2: Participatory design approaches (source: Muller and Kuhn 1993) Figure 3: Customer involvement approaches (source: Kaulio 1998) The vertical axis of the proposed overview plots a concern for understanding a current situation ('is') and research orientation versus a concern for envisioning future or alternative situations 33 ('ought') and a design orientation. This axis is similar to the (horizontal) axis 'User centred vs. Designer-centred' of the Methods Lab (Aldersey-Williams et al. 1999), an overview of various approaches in user research for design, ranging from methods designed to help study and understand users to methods designed to help envision and create innovations – see Figure 4. It is also similar to the (horizontal) axis that Ilpo Koskinen and Katja Battarbee (2003) drew in their overview of design research methods, which ranges from 'designer-centred design (imagined users in imagined situations)' to 'user-centred design (real users in real situations)' – see Figure 5. Figure 4: User research for design (source: Aldersey-Williams et al. 1999) Figure 5: Design research approaches (source: Koskinen and Battarbee 2003) 34 It may be noted that some authors use an axis to represent a timeline, for example 'Position of activity in the development cycle or iteration' (Muller and Kuhn 1993) or 'Phase of the design process' (Kaulio 1998). However, I chose not to do that for two reasons: my focus is on the early stages of research and design, so that implementation (prototyping and final product) is outside the scope of my study; and I like the idea of product development as an iterative and circular process (Buijs 2003), in which a chronology of distinctly ordered phases would be less relevant or less desirable. After creating and presenting the proposed model (Steen et al. 2007), I came across an overview by Elizabeth Sanders (2006b; cf. Sanders and Stappers 2008) of design research approaches. She drew a twodimensional space with two axes: a vertical axis that contrasts 'Design-led' with 'Research-led' and a horizontal axis that contrasts an 'Expert mindset, that sees "users" as subjects (reactive informers)', with a 'Participatory mindset' that sees '"users" as partners (active co-creators)' – see Figure 6. These axes and some of the approaches plotted are very similar to the axes and approaches that I have proposed in Figure 1. Figure 6: Design research approaches (source: Sanders 2006b) Furthermore, the model I propose resembles a model that Kanstrup and Cristiansen (2005) developed in order to help designers discuss power relations. In the model they distinguish between a focus on understanding the present versus designing the future and whether design activities take place on the users' location version in the 35 designers' lab. Finally, one may wonder why I did not harmonize my axes with other authors' axes. I could have drawn the researchers/designers versus users axis vertically as Muller and Kuhn and Kaulio have done, and the is versus ought axis horizontally as AlderseyWilliams et al. and Koskinen and Battarbee have done, or I could have rotated my axes 180 degrees to match those of Sanders. However, I have adhered to my model because I believe it aptly visualizes the chasm between researchers/designers and users, and their attempt to cross this chasm. Focusing I this section I describe the foci that I used to select and focus on six HCD approaches (participatory design, applied ethnography, lead user approach, contextual design, co-design and empathic design). A first focus is on approaches that are typically used in projects in which ICT products are designed or evaluated. Many of the approaches discussed originated in the ICT industry, although they can, of course, also be applied outside the ICT industry. A second focus is on the involvement of users in research or design activities. I choose not to focus on the participation of users in the generation of content, for example when people write or edit articles on the Internet (user-generated content), or their participation in the configuration of products or in the production of services, for example when people select and combine (physical or digital) modules to create their own product or service (personalization or mass customization). Another focus is on HCD approaches where researchers and designers interact face-to-face with users and in a relatively openended manner. In a literature review of user involvement in new service development, Ian Alam (2002), discussed different modes of user involvement. Using Alam's terminology, I focus on approaches where researchers and designers interact with users via face-to-face interviews, user visits and meetings, brainstorming, users' observation and feedback or focus group discussions. As a consequence, I have excluded approaches such as surveys or conjoint analyses, in which end-users are typically studied via questionnaires, and I excluded approaches such as Quality Function Deployment or Value Sensitive Design (Friedman and Kahn 2002), in which end-users are typically represented by experts. My focus is on face-to-face interactions with users and on the direct participation of users. 36 Because my study focuses on the early phases of an innovation project, I have excluded approaches such as usability engineering or usability testing (Norman 1988; Nielsen 1993), beta-testing and market trials (e.g. in Kaulio 1998), because these are typically applied in the later phases of innovation. In the next six sections I will describe six different HCD approaches as moves to illustrate the dynamics and tensions that I described above. Furthermore, I will describe them as separate from each other, although they are often combined within projects, and as typical, although they are often adapted to the context of a project. Moreover, I am aware that some of these terms, especially participatory design and the lead user approach, are sometimes used to include a range of other approaches that I choose to see as separate. Alternatively, I chose to use the term human-centred design as the umbrella term. Finally, I would like to emphasize that I see all six approaches as attempts to bridge the gap between researchers/designers and users, and to combine the concerns for 'is' and 'ought'. I propose that the six approaches address this gap and concerns in different ways by choosing different starting points and different areas of emphasis. Participatory design Participatory design (PD) has its roots in the 1970s in Scandinavia and it was initiated by academics who cooperated with people from trade unions. They saw offices becoming automated by computers and strived for more democratic values in the workplace and for worker emancipation (Greenbaum and Kyng 1991; Spinuzzi 2005; Törpel 2005). PD can be defined as 'an approach towards computer systems design in which the people destined to use the system play a critical role in designing it' (Schuler and Namioka 1993, p. xi). In PD one attempts to give the people who will be using a system a voice or a role in the design, evaluation and implementation of the system. It attempts to involve users in research and design. Joan Greenbaum (1993) advocated PD, drawing from three perspectives: from a pragmatic perspective, it helps to get 'the job done better'; from a theoretical perspective, it is needed in order to facilitate communication and cooperation between people with diverse backgrounds during the research and design processes; and from a political perspective, it is desirable that 'people have the right to influence their own workplace, including the use of computer technology'. 37 In PD, users are treated as experts, and it is attempted to bring their (tacit) knowledge and skills to the research and design process. The goal is to let users, researchers and designers work together to create a tool that will enable the user to do his or her work better. 'The tool perspective allowed researchers to recognize and leverage the workers' craft knowledge' (Spinuzzi 2005). A classic example of participatory design is the UTOPIA project (Ehn 1993), initiated in 1981 as a cooperation between the Nordic Graphic Workers' Union and researchers in Sweden and Denmark. In this project, workers were invited to workshops in which they could jointly explore problems and develop solutions, together with researchers and designers. In this project, the Future Workshop (Bødker et al. 1993) format was developed, which consists of three phases: Critique, a form of brainstorming in which participants are invited to speak up; Fantasy, in which themes from the Critique-phase are inverted to positive guiding themes and elaborated into 'utopian outlines'; and Implementation, in which plans are formulated for action in the immediate future. The Future Workshop format may illustrate that, although PD typically starts with an existing situation involving a specific group of people, it is also concerned with envisioning alternative or future situations. Pelle Ehn (1993), in a study of the UTOPIA project, wrote about 'mutual learning': graphic workers learned about the technical possibilities and constraints of computer technology, while designers learned about the craft and profession of the graphic workers. If this sounds idealistic or simplistic, then one can keep in mind that PD 'raises questions of democracy, power, and control at the workplace. In this sense it is a deeply controversial issue, especially from a management point of view' (Ehn 1993). The ambition of participatory PD to protect people from their work being delegated to machines is related to the second principle of HCD of creating an 'appropriate allocation of function between users and technology' (ISO 1999). Applied ethnography Another long-standing tradition is applied ethnography, a form of applied social science that draws from anthropology, sociology and ethnomethodology. Lucy Suchman pioneered this approach in the ICT industry when she studied and reported how people use Xerox copiers. She showed movies of people struggling with these machines to the engineers at Xerox, which helped them to redesign and 38 improve their copiers. Applied ethnography is about researchers and designers going into-the-field to study and understand how people use (current or future) products or products. Kujala (2003) remarked that such 'field studies are a particularly promising approach for understanding users' implicit and non-verbal needs'. I call this approach applied ethnography, because one would typically be concerned with studying and understanding people only to a certain extent and to a specific end, namely to apply findings to inform or inspire product development. In applied ethnography one attempts to look at naturally occurring situations and to look at them holistically and from a member's point of view (Blomberg et al. 1993). In this context, 'holistically' means that the researcher/designer looks at how people and their actions are embedded in social and cultural contexts, and the 'members' point of view' refers to an interest in how people create meaning and in their descriptive categories. One would, for example, describe a photocopier as the 'only copier that will handle my oversized originals', rather than as a 'Canon NP9800 copier' (Blomberg et al. 1993). It is not difficult to imagine that understanding other people's social and cultural contexts and sense-making processes can be a challenge for researchers and designers who are designing or evaluating a product. Applied ethnography is especially relevant for the (re)design and evaluation of ICT applications for computer supported cooperative work (CSCW) (Button 2000; Crabtree 2003) because it draws attention to social and cultural aspects of communication and cooperation between people. CSCW can be seen as a reaction to studies that focus on people as individuals and on people's individual cognitive functions. Furthermore, it is interesting to see that ethnography and participatory design can be combined (Kensing and Blomberg 1998), for example, by combining observations, interviews and workshops. Applied ethnography seems to be increasingly popular in commercial settings of market research and product development. An article in BusinessWeek (Ante 2006) stated that: 'Anthropological research can be a potent tool – or a waste of time and money. Here's how to get the most bang for your buck'. In contrast to this commercial enthusiasm, there are also critical voices about applying some sort of ethnography in design projects. For example, Paul Dourish (2006) argued that legitimizing applied ethnography only in terms of how it contributes to the design process – the well-known 'implications for 39 design' section in a report or presentation of an applied ethnography project – is too narrow and fails 'to do justice to the kinds of insights that [ethnographic inquiries] can provide'. Similarly, but from the field of organization studies, Peter Case (2000) wrote an article in which he ridiculed 'rapid results ethnography', a way of carrying out fieldwork rapidly, commercially and without depth. Lead user approach The lead user approach is based on the observation that many ideas for improved or new products or services originate in the minds and hands of innovative users (Von Hippel 1988; Von Hippel et al. 1999; Von Hippel 2005) and do not always come from professional researchers or designers. Eric Von Hippel (2005, p. 22) defined lead users as people who have 'two distinguishing characteristics: (1) They are at the leading edge of an important market trend(s), and so are currently experiencing needs that will later be experienced by many users in that market; (2) They anticipate relatively high benefits from obtaining a solution to their needs, and so may innovate'. Lead users experience a problem or need that they cannot fulfil with a current product or service and create innovative solutions, applications or modifications. An organization can invite such lead users to help researchers and designers to jointly develop improved or new products or services. An important difference from participatory design is that the lead user approach is oriented towards commercial goals rather than towards democracy or emancipation. Interestingly and not surprisingly, many examples of successfully involving lead users in product development relate to outdoor or extreme sports equipment (e.g. Lüthje and Herstatt 2004; Lüthje et al. 2005; Hamm 2006; Franke et al. 2006). There are people who are so passionate about their sport that they improve their equipment or develop superior equipment. Sometimes such lead users are hired by a firm for product development or marketing roles. Within the tradition of cooperating with lead users, it has been suggested that people can be provided with 'toolkits' to improve the development process: 'manufacturers actually abandon the attempt to understand user needs in detail in favor of transferring needrelated aspects of product and service development to users' (Von Hippel and Katz 2002). Users are provided with a space in which they can design using 'libraries of commonly used modules' and progress through cycles of trial-and-error learning so that the 40 products and services they design will actually be producible (Von Hippel 2005, pp. 147-164). Contextual design Contextual design (Beyer and Holzblatt 1998) – which used to be called contextual enquiry (Holzblatt and Jones 1993) or contextual techniques (Beyer and Holzblatt 1996) and is currently marketed as rapid contextual design (Holzblatt et al. 2005) – is a relatively specific approach, almost a technique. It can be considered a further application of applied ethnography in that it helps researchers and designers to observe people in a natural context (often a work context), to discuss and interpret their observations in a multidisciplinary project-team setting, and to directly apply their findings for formulating recommendations and requirements for an improved or new ICT application. The method prescribes several perspectives along which observations and interpretations can be organized, such as: what users do; how they communicate; the roles that power and culture play; the artefacts which they use; and their physical environment (Beyer and Holzblatt 1998). In a contextual design, knowledge about users is gathered by the project-team members and brought into the development process and transformed into product requirements. Because of this transfer and the concern with creating an ICT application, there can be a risk that project-team members foreground their own knowledge about users (which would, of course, be based on interactions with users) over knowledge from users. Contextual design is, for example, practised by Incontext (www.incent.com). On their website they present several cases, such as the development of a system for LANDesk. LANDesk provides security management solutions and wished to gather reliable customer data quickly (within four weeks) in order to improve their product and increase market share. By observing and interviewing different users performing a variety of tasks, the design team was better able to understand the needs. This delivered a market characterization and recommendations and opportunities to improve the product. 41 Co-design I use the term co-design to refer to the work of Elizabeth Sanders and people she works with (e.g. Sanders and Dandavate 1999; Sanders 2000; 2002; Sanders and Stappers 2008). Co-design is an attempt to let users, researchers and designers – or stated in less prejudiced terms: people with various backgrounds and skills – cooperate creatively, so that they can jointly explore ideas and concepts, make and evaluate sketches, and tinker with mock-ups or prototypes. Co-design can be thought of as a kind of participatory design, with additions from art and design traditions. Additionally, it seems that, in a participatory design, one would typically involve a group of people who work together in professional tasks (in their role as workers) and design a product with which they will actually be working, whereas in codesign one can also invite people who do not yet know each other (in their role as consumers) and design a product for a mass market or for non-work contexts. Key ideas behind co-design are that 'everyday people' can become participants and co-creators rather than customers and users (Sanders 2006a), and that users can contribute as 'experts of their experiences' (Sleeswijk Visser et al. 2005) to research and design processes. Sanders (2000) argued that in traditional market research one typically tries to capture 'what people say' via focus groups or interviews, and that in traditional ethnography one typically captures 'what people do' via observation. Alternatively, she advocates focusing on 'what people make' and facilitating users, researchers and designers to jointly create things and proposed using 'generative tools', which are meant to establish 'a shared design language' and to enable people to 'communicate visually and directly with each other. The design language is generative in the sense that with it, people can express an infinite number of ideas (for example, dreams, insights, opportunities, etc.) through a limited set of stimulus items' (Sanders 2006b). Examples of generative tools are 'tools for remembering', such as diary-style cards on which people can answer questions like 'What is your typical weekday evening like?'; 'tools for thinking', which are meant to help brainstorming about questions such as 'How do you expect your work to change in the future?'; 'tools for visioning' to facilitate creatively addressing questions or themes; or 'tools for feeling', which are intended to come into contact with and express one's emotions (Sanders 2000). 42 Empathic design In empathic design, researchers and designers attempt to move towards users, towards their lives and their work, and attempt to empathize with them and with their experiences and emotions. There are different versions of empathic design. For example, Dorothy Leonard and Jeffrey Rayport (1997) advocated observing customers carefully in order to discover their latent needs and proposed the following procedure to do that: observe; capture data; reflect and analyse; brainstorm for solutions; and develop prototypes and possible solutions. Ilpo Koskinen and Katja Battarbee (2003, p. 47) described empathic design as a range of 'empirical research techniques that provide designers access to how users experience their material surroundings and the people in it', as a range of approaches through which designers can empathize with other people's experiences in different physical, social and cultural contexts. One key issue that emerged in discussions with practitioners and seems to be as yet undecided in this relatively recent approach is how one can achieve empathy: 'the ability to understand another person's feelings experience, etc.' (Oxford Advanced Learner's Dictionary, 7th ed.). Should a designer try to exclude his own experiences, and focus and connect to the other person's experiences? Or should a designer try to connect with his or her own experiences, inspired or informed by what s/he sees and hears from another person? (cf. Sleeswijk Visser and Kouprie 2008). This question seems to be similar to questions about how an actor can prepare for playing a role. There are different approaches to doing this: some actors study the character's background and, for example, visit places where this character would go, whereas other actors search within their own memories for feelings similar to those the character would have. Furthermore, there is a broad range of empathic design techniques available, which are often combinations of observing users, roleplaying and playing with prototypes – all of which can be done together with or without users participating. For example: designers can 'shadow' people with limited or no vision and do exercises while they themselves are blindfolded, in order to empathize with these people (Fulton Suri et al. 2005); designers and users can jointly participate in role-playing to create or evaluate ideas for new products and use a 'magic thing', a simple non-functioning mock-up 43 of the future product to which one can attribute imaginary functions (Iacucci et al. 2000; Iacucci and Kuutti 2002); designers can go to a location where the innovation they are working on will be used and perform 'bodystorming' techniques to become acquainted with the location (Oulasvirta et al. 2003), or designers can observe people who use 'low-fi' prototypes while improvising current and future tasks, as a way to learn about usage and to further develop their prototypes (Svanaes and Seland 2004). Empathic design is similar to applied ethnography, but I would like to characterize applied ethnography as being concerned with understanding and representing current situations, and empathic design as being concerned with envisioning and experiencing alternative or future situations. Furthermore, I would argue that empathic design is different from participatory design and co-design: the latter are attempts to make users move towards researchers' and designers' activities and participate in these, whereas the former is an attempt by researchers and designers to move towards users' activities and engage with users' experiences. Probes In addition to these six approaches, researchers and designers can use 'cultural probes' or 'design probes' (Gaver et al. 1999; Hofmeester and De Charon de Saint Germain 1999 Hemmings et al. 2002; Hutchinson et al. 2003; Hulkko et al. 2004; Mattelmäki 2006). Probes are designed to enable people to report on their daily lives and experiences, so that these inform or inspire research or design processes. They often comprise a package of materials or tools for documenting experiences or for conducting small assignments, for example diaries or short questionnaires to capture experiences or ideas, or visual materials or (digital) photo cameras to visualize ideas. Probes can be applied in different ways: one can invite the people who filled in the probes to discuss these with the researchers and designers, in which case it would fit into a co-design approach; or these people do not directly participate in the interpretation of the filled-in probes, in which case it would fit into an empathic design approach. Tuuli Mattelmäki (2006, p. 63) distinguished four different motivations for using design probes: to inspire designers to envision new concepts; to interpret descriptive information about users; to empower users to participate in the design process; or to facilitate 44 dialogue with stakeholders (of the project) about users' perspectives. Related to this issue, Froukje Sleeswijk Visser et al. (2007) studied the use of probes as tools for 'supporting inspiration, empathy and engagement' with users and advocated using information from and about users in a relatively raw and as yet uninterpreted form, so that designers can actively and creatively engage with it and discuss it within the design team ('participatory communication'), rather than provide them with the results of interpretation and ready-made conclusions. Personas and storylines Finally, there is a method that is widely advocated and practised in product design, service design and interaction design (e.g. Carroll 1995; Carroll and Go 2004; Cooper 1999b; Cooper and Reimann 2003; Pruitt and Grudin 2003; Crisler et al. 2004) (and in market research, marketing and advertising), namely the construction of personas and storylines. Personas are descriptions of fictional people that are meant to represent current or future users of a product or service. Storylines are descriptions – in text or with pictures, photos or videos – of fictional situations in which people, for example the personas, use a product or service, which are meant to represent current or future situations of product or service usage. Note that I prefer to use the term storyline rather than use case, which is associated with a focus on technical functionality, or rather than scenario, which is associated with the creation and assessment of scenarios for higher-level or strategic options (Alexander and Maiden 2004). Personas and storylines are typically used to summarize findings from observations, interviews or workshops and to apply these in research and design processes. The rationale of constructing personas is to create a point of reference for project-team members. If projectteam members have no specific person or persons in mind during a discussion, their decision-making is likely to go in any direction. If, on the other hand, a persona is available to represent a specific (type of) user, then project-team members can refer to that persona and create a shared understanding of the needs and preferences of this persona – or, preferably of real users – and make consistent and effective design decisions. Similarly, the aim of constructing storylines is to aid research and design processes. Storylines can provide a context for understanding or envisioning people's needs or preferences. A storyline featuring someone sitting at home at night 45 watching television would provide a different context to a storyline featuring someone running to catch the train. Storylines are meant to help reflect on the use of a product or a service in a specific and concrete (fictional) situation. Personas and storylines can be used in different ways. Some people argue that personas should be based on sound and quantitative market research (e.g. Grudin and Pruitt 2002), while others argue that personas do not have to be based on research so long as they help to steer the design process (e.g. Cooper 1999a). The use of storylines is also diverse: some create storylines that are intended to represent people's current situations, while others create storylines designed to envision alternative or future situations. Summary I have argued that human-centred design (HCD) is about involving users in research and design and about stimulating constructive cooperation between researchers, designers and users. The idea is to do this from the start of a project and throughout its iterative cycles. Moreover, I have argued that there are two tensions inherent to HCD and that different HCD approaches try to resolve these in different ways. One tension occurs between the roles of researchers/designers and the roles of users – see the horizontal axis of Figure 1. This tension can also be thought of in terms of the agency of researchers and designers versus the agency of users, or as a question about whether the knowledge of researchers and designers or the knowledge of users is foregrounded. In participatory design, the lead user approach and co-design, users are invited to move towards research and design processes and attempts are made to foreground their knowledge. Conversely, in applied ethnography, contextual design and empathic design, researchers and designers attempt to move towards the worlds of users, and researchers' and designers' knowledge – about users – can play a dominant role. Below, I will interpret this tension in terms of other and self (p. 169). Another tension occurs between the concern with understanding current situations or practices (is), a research orientation, versus the concern with envisioning alternative or future situations or practices (ought), a design orientation – see the vertical axis of Figure 1. This 46 tension can also be thought of in terms of foregrounding knowledge about a current situation versus ideas about alternative or future situations. Applied ethnography and participatory design typically have specific current situations or practices as starting points, for example when a specific existing group of people doing specific tasks is involved in a project, when a current problem is focused upon and studied, or when attempts are made to jointly develop solutions for that specific situation or problem. Conversely, co-design and empathic design may well start with ideas for alternative or future situations or practices, often formulated as an opportunity, or with ideas for a new product or service. Finally, contextual design and the lead user approach can be thought of as attempts to pragmatically combine these concerns for is and ought: in contextual design, researchers/designers aim to understand a current situation and to apply their findings directly to the design of a future product, and in the lead user approach, people who developed ideas or products based on their current practice contribute to the development of a future product. Below, I will interpret this tension in terms of openness and closure (p. 175). If I allow myself some radical simplifications, I can approximately plot the different HCD approaches in time and space. Participatory design and applied ethnography have their roots in research and academia and in Northern Europe. The lead user approach and contextual design are applications of such methods in in-company product development in the USA, and co-design and empathic design are recent developments in which researchers and designers, from academia and businesses and from Europe and the USA, cooperate. (It may be noted that I did not discuss HCD in Asia, Africa, Latin America or Australia.) Furthermore, participatory design and applied ethnography often have political drivers, such as workplace democracy, users' emancipation and users' perspective. The lead user approach and contextual design are associated with commercial motives and the need to produce results efficiently, and co-design and empathic design tend towards creativity and art, focusing on stimulating inspiration together with users. The purpose of articulating the tensions in these terms – Whose knowledge is foregrounded? What kind of knowledge is foregrounded? – is to facilitate an interpretation and discussion of HCD as a sociocultural process in which people create and share meanings, as a political process in which people exercise power via their knowledge 47 claims, and as a process with ethical qualities that will be developed in terms of other and self and openness and closure, in Chapter 6. In this interpretation and discussion I will be concerned with how researchers and designers have their own knowledges and skills and how they are balanced with other people's knowledges and skills. Based on this chapter, I can further articulate my research question – What happens in human-centred design practice and how does this differ from the theory and principles of human-centred design? – and focus on how two tensions are played out in practice, namely the tension between the roles and agencies of researchers/designers versus users, and the tension between a concern with understanding what currently is versus a concern with envisioning what ought to be. 48 49 3. Research approach This study is an attempt to make a twofold gesture: I practise HCD in my day-to-day work and, at the same time, I talk about the difficulties of doing HCD. I was looking for a way to study humancentred design (HCD) in practice, from within, in real-time, while it happens, and to study how the practice of HCD differs from its theory and principles. Put succinctly, my research approach would be: In order to study HCD practice, I decided to study one HCD project in which I am working. I can imagine that fellow researchers or designers or HCD practitioners, who often have backgrounds in engineering or psychology, will wonder how studying only one project can be relevant, and will want to read about generalizability. I can also imagine that scholars with social-science backgrounds will want to read about how I studied a project in which I was involved myself. I will first position my study in the field of science and technology studies (STS) and opt for a social constructionist research approach. On that basis, I proceed to make a series of choices to discuss my research approach: about an independent or involved researcher role; about sample size and unit of analysis; about testing or generating theories; about experiments or studying natural settings; about developing universal or local knowledge; and about verification or falsification. It will look like building a neat structure. I will than tear down some of that structure and provide an account of how I struggled with my role as participant observer – or observant practitioner, because I often felt that my practitioner role was more important than my observer role – and with combining practitioner and analyst roles. How can I analyse situations in which I am an active participant? And how can my analyses become relevant for other practitioners? I will explain the role of reflexivity in order to address such questions. Reflexivity occurs, whether I like it or not, 50 because I am studying a research and design project with the goal of formulating suggestions for doing research and design differently: I am trying to re-research research and to re-design design. Near the end of this chapter, I will try to see reflexivity not as a bug, but as a feature. Science and technology studies My study can be positioned in the field of science and technology studies (STS). STS is a multidisciplinary field with diverse ancestors, such as the 'sociology of scientific knowledge', the 'social study of science' or 'science, technology and society', in which social scientists, historians, philosophers and others study, amongst other topics, what people who produce science or technology actually do. This can be understood as the 'empirical turn' (e.g. Rip 2000) in the philosophy of science and technology. The attempt is to open the 'black box' and to show the processes through which science and technology are constructed (Latour 1987). STS scholars study how scientists, researchers, engineers, designers and the like construct 'scientific facts' or 'working artefacts', and how they interact and negotiate with each other while constructing these facts and artefacts (e.g. Latour 1987; Pinch and Bijker 1987; Rip et al. 1995). I put quotation marks around 'scientific facts' and 'working artefacts' because people may decide, at a certain time and in a certain place, that a certain fact is true, while at another time and in another place people may decide that the same fact is false – and similarly for a working artefact or malfunctioning artefact. Bruno Latour and Steve Woolgar (1986) pioneered the field 'laboratory studies' (Knorr Cetina 1995) when they studied what people in a life science laboratory actually did in practical terms – rather than studying the outcomes of what these people do, as is commonly done. They approached the people in this laboratory similarly to how an ethnographer would approach people of a tropical tribe: they did participant observation, tried to understand the rituals, and made notes. Their conclusion was that people in a lab construct facts through all sorts of practices. The people in that lab ran tests, read print-outs of the tests, made notes, published papers and referenced other people's articles, and in this process they constructed 'scientific facts' through all manner of discussions and negotiations. Such studies seek to unravel the social processes that occur before people decide that a fact is true so that it becomes true, 51 or before people decide that a technology works so that it works. Latour argued that a fact is not true because of some external law of nature, but that it can become true if enough people become convinced that it is true – 'if things persist, they start to become true', instead of 'if things are true, they persist' – and that a technology works not because of the technology itself, but because people become convinced that it works – 'the machine works, if all the people involved are convinced', instead of 'once the machine works, people will be convinced' (1987). For people with a background in natural science or engineering, this may sound bizarre. But they will be aware that people centuries ago 'knew' that the world is flat and that the Sun orbits the Earth, and that we currently 'know' that the Earth is a sphere and that it orbits the Sun. The idea that facts are socially constructed is probably more controversial than the idea that artefacts are socially constructed (cf. Knorr Cetina 1995, pp. 149-150). It is relatively easy to imagine a group of researchers and designers in a project-team who interact, discuss and negotiate with each other and that, through this social process, they construct sketches, prototypes and artefacts. The focus of STS has now widened. Currently, some STS scholars are becoming interested in applying their approaches to study what people in commercial businesses do (Coopmans et al. 2004; Woolgar et al. 2005), moving away from an interest in knowledge production in universities or labs, where STS has its roots. Other scholars in STS are interested in users' roles in innovation processes (e.g. Oudshoorn and Pinch 2003a; Haddon et al. 2005) and in ways to involve users in innovation processes (e.g. Rohracher 2005b). My study would fit within these trends, since I am interested in what researchers and designers do in a project involving various organizations, and in how they interact with users during the project. However, my focus is on what researchers and designers do and not on what users do; users only feature when researchers and designers interact with them or represent them within their project. In terms of content, my study relates to the field of design studies. Moreover, it fits within a trend in that field to move from studying designers in laboratory settings, for example Analysing design activity (Cross et al. 1996), Describing design (Dorst 1997), to studying designers 'in the field', where and while design processes are taking place, for example The reflective practice in product design teams 52 (Valkenburg 2000), Ethical issues in engineering design (Van Gorp 2005), Get synchronized (Smulders 2006) and Understanding collaborative design (Kleinsman 2006) (examples from Delft University of Technology). Furthermore, I am interested in how research and design processes are organized and conducted, which means that my study also relates to the field of management research (AlderseyWilliams et al. 1999). Moreover, since I am interested in other and self, openness and closure and follow an 'essayist' approach, my study could also fit in the category of humanist organizational studies (Letiche 2008). A social constructionist approach In the field of management research, a key distinction can be made between positivist approaches and social constructionist approaches (Easterby-Smith et al. 2002, pp. 30-31): positivist approaches are based on the assumptions that 'the social world exists externally' and that a researcher's task is to measure its properties, whereas social constructionist approaches are based on the idea that '"reality" is determined by people rather than by objective or external factors' and that a researcher should be concerned with 'what people, individually and collectively, are thinking and feeling, and attention should be paid to the ways they communicate with each other'. A schematic characterization is provided in Table 1. Table 1: Positivism and social constructionism (source: EasterbySmith et al. 2002, p. 30) Positivism Social constructionism The observer must be independent is part of what is being observed Human interests should be irrelevant are the main drivers of science Explanations must demonstrate causality aim to increase general understanding of the situation Research progresses through hypotheses and deductions gathering rich data from which ideas are induced Concepts need to be operationalized so that they can be measured should incorporate stakeholder perspectives Units of analysis should be reduced to simplest terms may include the complexity of 'whole' situations Generalization through statistical probability theoretical abstraction Sampling requires large numbers selected randomly small numbers of cases chosen for specific reasons 53 From the positioning of my study within STS, it almost necessarily follows that I choose for a social constructionist research approach. In the next six sections, I will articulate and discuss my research approach by addressing six key choices (Easterby-Smith et al. 2002, pp. 43-52): • Independence or involvement; • Testing or generating theories; • Sample size and unit of analysis; • Experimental design or fieldwork; • Universal theory or local knowledge; • Verification or falsification. Involvement – and an attempt at deconstruction Within a social constructionist approach, researchers are likely to opt for an involved research role and to engage with what they study, whereas researchers who work within a positivist approach are likely to choose a more independent research role and to create distance from their object of study. Choosing to study a project in which I am actually involved gives me the opportunity to conduct my study as 'participant observer' (Easterby-Smith et al. 2002, p. 110). Moreover, I would be a 'complete member' (Ellis and Bochner 2000, p. 740) since I am studying a group of people of which I am already a member. The advantage of this insider perspective is that it solves 'the researcher's number one challenge' (Gummeson 2000, p. 14) of obtaining access to situations that I wish to study. However, my insider perspective can also be a blessing in disguise as it can coincide with too much involvement. I experienced difficulties in maintaining distance from what I am studying – a requirement for analysing and interpreting the practice in which I am participating. Although I plan to do observation only, and not to conduct any explicit interventions, my active role in the projects will undoubtedly influence many of the situations I attempt to study. In order to establish some kind of distance from what I am studying, I feel attracted to Jacques Derrida's approach of 'deconstruction' (e.g. 1991), a way of reading texts carefully, uncovering what is not said, and providing alternative readings of these texts. Deconstruction can be understood as a 'radical form of questioning text(s)' (Letiche 1998). Here, the word text is not restricted to written texts, but can also refer to situations occurring within a project and to what people say or do in a project, especially when what people say or do is written down, 54 so these texts can be read and reread in the process of deconstruction. Derrida is reluctant to define what deconstruction is, and prefers to say what it is not: 'deconstruction is neither analysis nor a critique, [it] is not a method and cannot be transformed into one' (1991, p. 273). Steering away from defining what deconstruction is would be consistent with a key goal of deconstruction, namely offering an alternative to making statements in the form of a 'third person present indicative: S is P' (p. 275) (where S refers to subject and P to predicate and an example of such an indicative would be: 'Project X is successful'). Deconstruction occurs when one attempts to open up a text for alternative readings, to read between the lines and to write these alternative readings in the margins of the text, as a supplement. In deconstruction, one attempts to escape one's tendency towards logocentrism, which is – pun intended – the tendency to seek, create and privilege order and hierarchies and the tendency to marginalize what falls outside this order or what falls on the lower side of these hierarchies. Simon Critchley described deconstruction as follows (1999, p. 23): What takes place in deconstruction is reading; and [...] what distinguishes deconstruction as a textual practice is double reading – that is to say, a reading that interlaces at least two motifs or layers of reading, most often by first repeating what Derrida calls 'the dominant interpretation' of a text in the guise of a commentary and second, within and through this repetition, leaving the order of the commentary and opening a text up to the blind spots or ellipses within the dominant interpretation. I have attempted to follow a modest form of deconstruction. I attempted to apply a first voice to describe what happened during the project, based on participant observation and on documents, and then to apply a second voice to reflect on what happened and to provide alternative readings and interpretations of what happened, in order to supplement or destabilize the first descriptions. I describe my approach as modest, because I did not attempt to create a text that escapes logocentrism. The paradox of attempting to conduct deconstruction in writing is that one must use written language, which tends towards logocentrism, as a means of trying to escape logocentrism. This paradox has been described as a 'tightrope act', as an attempt to 'take up a position exterior to logocentrism, if such a thing were possible' (Critchley 1999, p. 29). 55 My involvement in the project and my research approach may give rise to questions about validity, reliability and generalizability. The meaning of such concepts differs in positivist and social constructionist paradigms. In a positivist paradigm, validity refers to how closely the measures correspond with reality, reliability refers to whether the measures yield the same results on other occasions, and generalizability refers to whether the study confirms or contradicts existing findings. In a social constructionist paradigm, validity refers to whether access is gained to the experiences of the people studied, reliability refers to transparency in the process of making sense from the data, and generalizability refers to whether concepts from one study are relevant to other settings (Easterby-Smith et al. 2002, p. 53). I attempted to learn about other people's experiences through my involved role and approach, I attempted to provide transparency in my research process by writing reflexively about my role in the project and about my role in researching this project, and I attempted to study one project in detail and over an extended period of time, so that I could go behind-the-scenes and find concepts that are relevant for other settings and write about the concepts in a way that is interesting for others. Generating theory – about design and ethics Another choice is about where to start: with theory or with data. One can start with theory and then go about testing it by collecting data. Or one can start with data and then try to generate a theory based on the data. In practice, this choice is less clear cut. One can start with a theory, carry out some observation and then discuss or develop the theory. Or one can start with observation, turn to theory and then conduct more observation to evaluate or develop the theory. A researcher often has prior practical experiences or 'preunderstanding' (Gummeson 2000) or uses theories that 'direct attention', 'organize experience', 'enable useful responses' (Alvesson and Deetz 2000, pp. 39-46) and guide how one looks at the world. In order to approach the paradox of theory first versus data first, we can speak of a validation function or an explorative function of research. The validation function is about a focus on evaluating an existing theory via research, whereas the explorative function is about starting research with a theme, direction or interest, and then collecting data to generate theory. 56 This explorative function is appropriate for my study because I wish to look critically at HCD practice. By critically, I mean the attempt to differentiate, to make distinctions – in my case: the attempt to look for differences between HCD theory and principles and HCD practice. I would argue that there are not many critical texts about HCD. Many texts about HCD are prescriptive or in the form of guidelines, setting out how to do HCD, and if they are descriptive, they are often case studies in the form of success stories to show the added value of HCD. Not many texts look critically at what happens behind-the-scenes. Sari Kujala's (2003) review of early userinvolvement practices is an exception in that she does go below the surface, as do the edited volumes with case studies from which she draws: Participatory Design: Principles and Practices (Schuler and Namioka 1993) and Field Methods casebook for software design (Wixon and Ramey 1996). Furthermore, there are several behind-the-scenes accounts of user involvment in innovation processes (e.g. Oudshoorn and Pinch 2003a; Rohracher 2005b) and of customer involvement in service development (e.g. Edvardsson et al. 2006). Many texts about HCD seem to cover up what happened in practice – for example the tension between researchers/designers and users, and between the concerns with what is and what ought to be. One often reads phrases such as: 'After the observation, it was decided to prioritize problem X and make it central in the design process', or 'During the workshop, solution Y was chosen and then further developed'. Such phrases conceal what happened between people and how decisions were made; the process of HCD is presented as a 'black box' (Latour 1987), a closed container that shows only what goes in and what comes out. I consulted several experts in my search for behind-the–scenes studies and critical texts. Ilpo Koskinen (e-mail, 15 February 2007), an expert in empathic design, observed that 'design is a young field of research in which internal criticism is largely lacking' and that such critique, if it exists, is for example about the problem in empathic design of having too much empathy for users, of 'going native' and not maintaining the distance required for design, and not about whether it is possible to have empathy. Sari Kujala (e-mail, 22 March 2007) could think of a paper by Juhani Iivari and Netta Iivari (2006) in which four different meanings of 'user-centredness' are discussed, namely a way to focus on users, a way to focus on people's work, a way to let users participate in a project, or a way to let users 57 personalize a system. Such distinctions illustrate that not all practitioners who claim to work in a user-centred way actually involve users in their project. Furthermore, Susanne Bødker (e-mail, 15 March 2007), an expert in participatory design (PD) at Aarhus University, remarked that she knew of only a few critical texts and pointed me to texts by Randi Markussen (1994), Eevi Beck (2002) and Clay Spinuzzi (2005). Markussen, in Dilemmas in cooperative design (1994; see 1996 for an extended version), observed that people who do PD often do not speak about their own roles in the politics of PD and how they relate to power and empowerment, and she recommended that they discuss these. Furthermore, she suggested that practitioners make themselves accountable about how they 'handle the power delegated to them through the processes of design' and that they 'refine their reflections on how the relations in cooperative design projects are constituted'. Similarly, Beck (2002; see 2001 for an extended version), advocated paying attention to the 'societal/political/ethical consequences of ICT development, management, adoption, or use' and bringing the politics of PD to the fore: 'We could do well to bring out the politics in our own roles in contributing to constructing computing technology'. She argued that 'forms of participation exist [...] that do not question, but further, dominant power patterns around the development of IT' – hence the title of her paper: P for political – Participation is not enough. Recently, Bødker (2006) noted that user involvement is often treated as unproblematic, which 'leads to a lack of reflection or reflexivity on behalf of designers as regards their own ways of working'. There are examples of such reflections, for example in a report of a workshop that was held at the Participatory Design Conference 1998 (Gulliksen et al. 1999a; Gulliksen et al. 1999b), which contains behindthe-scenes discussions by practitioners of how to involve users and let them participate, how to manage a project and deal with conflicts and power, how to take cultural contexts into account, and how to organize communication between different stakeholders and facilitate shared understanding. Furthermore, a paper by Netta Iivari (2006) critically discusses the rhetoric of user involvement in terms of how different people discuss user involvement and how discourses on user involvement can threaten user involvement, and effectively silence users instead of giving them a voice. Despite the referenced texts, I would argue that there are not many behind-the-scenes studies or critical texts, and I therefore suggest that my study can 58 have an exploratory function and contribute to the generation of theory. Concerning my research approach, my primary entrance is participant observation. In addition, I have borrowed several concepts from the French philosophers Emmanuel Levinas (19061995) and Jacques Derrida (1930-2004). (They are known as French, but they were born in Lithuania and Algeria respectively). Borrowing ideas from these philosophers is not uncommon in the field of organizational studies, especially if one wishes to write about ethics (e.g. Letiche 1998; Jones 2003; Conference 'Levinas, Business, Ethics' at University of Leicester, 27-29 October 2005; Conference 'Derrida, Business, Ethics' at University of Leicester, 14-15 May 2008). During my research, I felt attracted to several of their ideas and decided to apply these as a means of looking at HCD practice from a different perspective and discussing and interpreting my observations (see Chapter 6). I did not engage in a philosophical treatment of their texts, nor did I read the sources from which Levinas and Derrida drew: from Heidegger, Husserl, Nietzsche and Bergson via Hegel, Kant and Descartes to Aristotle and Plato. Rather, I made use of several relatively accessible texts by Levinas and Derrida in order to help me to write about other and self and about openness and closure. My ambition is to generate theory, to develop new ideas about HCD and to contribute to a debate about design and ethics. One starting point for this debate is Langdon Winner's (1993) critique on social constructivist studies of technology (what we would currently refer to as 'STS') for not discussing ethics sufficiently. He criticized STS for their lack of attention 'and, indeed, apparent disdain' for moral questions. He described such studies as 'opening a black box and finding it empty'. More recently, Keulartz et al. (2004) argued that 'the most influential approaches within STS show a 'normative deficit' and display an agnostic or even antagonistic attitude toward ethics'. Moreover, Ibo van de Poel and Peter-Paul Verbeek (2006) encouraged a debate between STS and engineering ethics and argued that, traditionally, engineering ethics has been concerned with studying the ethical consequences of developing or applying technology, and they suggested that STS can help to conduct more situated studies of what people involved in engineering or design actually do: STS insights can help make engineering ethics open the black box of technology and help discern ethical issues in engineering 59 design. Engineering ethics, on the other hand, might help STS to overcome its normative sterility. [...] The STS perspective makes it possible to perform a context-sensitive form of ethics, in which normative questions are seen as intrinsically connected to the context out of which they emerge. My hope is that my study can contribute to this debate about design and ethics by providing a 'context sensitive' account of HCD, from the inside, as a participant observer. Studying one project – combining practice and analysis One can choose to study a relatively large number of cases, for example to obtain a broad overview or compare cases. Alternatively, one can choose to focus on one or a relatively small number of cases, for example to obtain a more detailed or in-depth view. I choose to study one project from within, over a period of four years (2004 to 2007). This choice, to carry out a 'single case study' can be justified by different arguments: because it is a critical case that helps to test a well-formulated theory, like a critical experiment; because it is an extreme or unique case, as sometimes happens in clinical psychology; or because it can function as a revelatory case, a study of a situation where the researcher has 'an opportunity to observe and interpret a phenomenon previously inaccessible to scientific investigation' (Yin 1994, pp. 38-40). My study can be thought of as a revelatory case, because it rarely happens that people who conduct HCD write about their practice (from an STS perspective), or that (STS) scholars participate on a day-to-day basis in a HCD project that they are studying. Jurgen Ganzevles (2005) remarked that '"Keep practice and analyses separated" still seems to be the guiding principle for good scholarship", and characterized the gap between theory and practice as a 'no-man's land between "STS theory" and "what to do"' and advocated exploring this area. I wish to remark that there are studies by people who work in design or engineering and who have written about their practice from social-science or philosophy perspectives, such as The existential pleasures of engineering (Florman 1994), Everyday engineering (Vinck 2003), User involvement in innovation processes (Rohracher 2005b) and examples from Delft University of Technology (Cross et al. 1996; Dorst 1997; Valkenburg 2000; Van Gorp 2005; Smulders 2006; Kleinsman 2006), and there are texts by social 60 scientists or philosophers who studied design or engineering practices and wrote about these, such as Configuring the user (Woolgar 1991a), Reconfiguring the user (Mackay et al. 2000), The de-scription of technical objects (Akrich 1992), User representations (Akrich 1995), Engineering culture (Kunda 1992), Designing engineers (Bucciarelli 1994), Aramis, or the love of technology (Latour 1996) and How users matter (Oudshoorn and Pinch 2003a). I checked this list of texts with Wiebe Bijker (4 April 2007), Jurgen Ganzevles (6 April 2007) and Harald Rohracher (3 April 2007), and they were surprised that I had found so many and could not think of other examples. I like the idea of my study as an exploration of this 'no-man's land' between practice and theory. A propos, and in order to avoid misunderstandings, I wish to remark that I consider the application of social science in research and design projects as a separate topic. People in the fields of HCD, human-computer interaction (HCI) or computer-supported cooperative work (CSCW) apply all manner of social-science methods to better understand users and develop ICT products or services for them (e.g. Suchman 1987; Kensing and Blomberg 1998; Button 2000; Frascara 2002; Crabtree 2003). My concern, however, is with studying researchers and designers who work in such projects. Related to questions about sample size are questions about unit of analysis: What phenomena will I focus on? How large or small will these phenomena be? I found it hard to determine the unit of analysis beforehand, but this became clearer during the process of studying and writing. I became interested in what researchers and designers do when they practise HCD, in how they interact with users, in how they make decisions in their project, and in the relationship between these interactions and decisions. I focused on how project-team members interacted with each other, for example in project meetings how they dealt with the results of their interactions with users, for example interviews or workshops, and on how project-team members made decisions, for example about which problem to address or neglect and about which solution to pursue or reject. This interaction and decision-making happens over the course of time, which I was able to study longitudinally, from 2004 to 2007. In Robert Yin's vocabulary, I studied 'embedded' units of analysis (1994, pp. 41-44). I studied one project, and within this project I studied two cases (Chapters 4 and 5). Within each case, I paid attention to how people interacted, discussed and negotiated with each other during meetings and I studied what they wrote in notes, memos or articles. 61 Such a case study can best be conducted from a relatively broad perspective since a narrow perspective would bring the risk of failing to see the relationship between the phenomena in which one is interested. Fieldwork A fourth choice related to the kind of empirical work one chooses to do. Experiments are typically associated with a positivist approach, with natural sciences and with some branches of psychology. In an experiment, one typically attempts to isolate a phenomenon, to control the context, to manipulate inputs and to measure outputs, which can be done with non-living materials or with people in a role of subject in an experiment. Fieldwork, on the other hand, is associated with a social constructionist approach and with many forms of social science. A typical goal of much fieldwork is to study people and their actions and interactions in naturally occurring situations. Given my earlier choices, it will not come as a surprise that I chose to do fieldwork. Furthermore, I chose to follow an ethnographic approach and conduct participant observation. This decision still leaves open a wide range of possible perspectives for looking at people and situations. One could – and I will mention only several perspectives with which I am a little bit familiar – be interested in how people interact with each other, for example in how people present themselves and play roles (Goffman 1959) or in how people negotiate and experience social reality through their interactions (Garfinkel 1967). Or one could be interested in people's inner lives, for example in how people's experiences are shaped through their usage of language (Shotter 1993) or in how people experience their identity (Deetz 1994). Or one could be interested in cultures or structures, for example in how organizational culture influences what people can and cannot do (Kunda 1992) or in how a dominant discourse influences people and disciplines them (Foucault 1992). Or one could be interested in relations between people and technologies, for example in how people and things create networks and exert influence upon each other (Latour 1987) or in how people and technologies mutually shape each other via practices of design and usage (Oudshoorn and Pinch 2003b). Another way of illustrating the diversity of perspectives, one can look at the collection of twenty different analyses of the same empirical 62 data in Analysing Design Activity (Cross et al. 1996). An experiment was conducted in which teams of three designers and individual designers conducted a specific design task for two hours. Video recordings, transcripts and copies of drawings and notes from these sessions were sent to different (groups of) researchers, who analysed the same data from different perspectives and focused on different topics: for example on decision-making and design and evaluation processes; on individual versus team problem solving; on the structure of design problems and design strategies; on the use of knowledge and information management; on the use of objects and drawings; and on social processes and collaboration. I am mostly interested in the design process and – because a process is not visible – in what happens between people and in what I can observe of people's actions and interactions. Additionally, I draw attention to the documents and artefacts they produce. Consequently, I cannot, in the current study, be very concerned with other people's individual inner lives (except my own, when I engage in reflection or reflexivity) or with overarching structures that would exist outside people's interactions. I find it difficult to characterize my study but I think it resembles ethnomethodology (Garfinkel 1967) in the sense that I focus on what happens between people and on how people create, negotiate and experience social reality. However, I am not very concerned with how people use and experience language in how they create and negotiate categories, relations and memberships, which one would typically do in ethnomethodology. My study would also fit in the category of 'semiotic' approaches to studying the relationship between people and technology because I focus on how people attribute meanings to technology when they attempt to shape it (Oudshoorn and Pinch 2003b, pp. 9-11); for example on how researchers and designers attempt to 'configure' (Woolgar 1991a) users or create 'scripts' (Akrich 1992) about users (see: Conducting observations, p. 92; Interview rounds 1 and 2, p. 139). Below, I will also relate my approach to ethnography and autoethnography (see: Traditions of reflexivity, p. 73). Participant observation is often accompanied by collecting and studying documents and by conducting interviews. I gathered and interpreted texts produced by team members within the project, such as meeting minutes, memos, reports and articles. With regard to interviews, I decided not to conduct any. The typical functions of conducting interviews, such as obtaining information from people or 63 validating observations or interpretations, would not work for me because of my involvement in the project. I speculated that interviewing my fellow project-team members would generate awkward data. In a social constructionist research approach a research interview is not a neutral fact-finding activity but an 'encounter' (Moriceau 2004) between people; an interaction in which experiences and meanings are created. Suppose that I observed something in a project-team meeting (an encounter) and organized an interview (another encounter) in which I wish to validate my interpretation of what I observed. I can imagine that in the interview we would create entirely new experiences and meanings so that the interview cannot be used to validate the preceding observation or that we could sort of re-produce what happened in the preceding meeting. In both cases, the interview cannot be used to validate the preceding observations or interpretations. Conducting a second interview to check whether the first interview had produced entirely new meanings or similar meanings would not work for the same reason – and would only bring a risk of infinite regress. Moreover, it would not be difficult to imagine mechanisms that would render interviews inappropriate for fact-finding in my case: project-team members will tell me only what they think I wish to hear and I will only ask questions that I already am interested in and focusing upon. What I can do within a social constructionist approach is to organize project-team meetings in which I discuss my research with my fellow team members. This will create new encounters, which I can observe and interpret. Experiences and meanings do not happen within isolated people, but between people, so that it seems fair to give a say to the people I am studying and writing about. I organized two such meetings in which my fellow project-team members and I reflected on the project together (see: Reflecting on the project, p. 112; Reflecting on the project, p. 147). Local knowledge A researcher can attempt to create a theory with universal validity: a theory is valid regardless of context, for example the law of gravity that describes gravity in any place and at any time. This aim is associated with a positivist paradigm and with the natural sciences. In contrast, a researcher who follows a social constructionist paradigm can attempt to study and describe phenomena in their unique, distinctive and local contexts. Within the field of organization 64 research, especially in Europe, it is legitimate to conduct a study in order to generate local knowledge. A key argument in favour of this approach is that 'practical knowledge used by managers when going about their work is essentially contextually bound, and that it is learnt through engaging in practice' (Easterby-Smith et al. 2002, p. 51). My approach of studying one unique project is in line with this approach of generating local knowledge. Mats Alvesson and Stanley Deetz (2000, pp. 24-31) proposed to distinguish between four different possible research programmes in the field of critical management research – see Figure 7. They drew a grid with two axes: they distinguished 'local/emergent' or 'elite/a priori' as two possible origins for concepts and problems, and they distinguished 'dissensus' or 'consensus' as two possible relationships to the dominant discourse. These two axes create a space with four possible research programmes. In my study, I will be concerned with generating local knowledge because it is based on local experiences in one project, and I will be looking for alternative ways of looking at HCD and for alternative HCD practices (dissensus). My study would fit in the local/emergent-dissensus corner of their grid (top left). Figure 7: Different research programmes in management research (source: Alvesson and Deetz 2000, p. 24) Elite/ a priori Origin of concepts and problems Local/ emergent Dissensus Consensus Dialogic studies (postmodern, deconstructionist) Critical studies (later modern, reformist) Interpretive studies (premodern, traditional) Normative studies (modern, progressive) Relation to dominant social discourse 65 Falsification A final choice regarding the research approach is between verification and falsification. This choice is especially relevant within positivist approaches. A familiar example of this choice is that of different possible approaches to a hypothesis such as 'all swans are white' (Easterby-Smith et al. 2002, p. 52): in order to verify that hypothesis you would look at swans and see whether they are white; and in order to falsify that hypothesis you would look for non-white swans and head for the zoo or travel to Australia in order to find contradictions to the hypothesis. The choice between verification and falsification is less clear cut in social constructionist approaches because there one can do research without hypotheses. However, Alvesson and Deetz (2000) proposed applying a falsification strategy for organizational research within social constructionist approaches too, because it can help to produce knowledge that is of practical use: Most managers are strongly tempted to look for evidence which supports the currently held views of the world. This is not surprising if they are responsible for formulating strategies and policies within a context that is very uncertain, [...] even if disconfirmatory evidence is unpopular, it is certainly both more efficient and more informative than confirmatory evidence. What I take from this, is to give falsification some role in my research approach, for example by questioning my tentative interpretations; I did that by organizing meetings with my fellow project-team members in which we reflected on the project and on my interpretations of what happened (see: Reflecting on the project, p. 112; Reflecting on the project, p. 147). Furthermore, I attempted to write reflexively, which can be understood as an attempt to examine my own experiences, thoughts and feelings (see: A police officer's manager talks back, p. 98; Attempts to improve cooperation, p. 136). Moreover, my entire study can be thought of as an attempt to falsify the theory of HCD and the dominant discourse of HCD, in that I am looking for differences between HCD principles and HCD practice: for situations from practice that do not match HCD theory. In my observations, interpretations and discussions I was looking for aspects that did not go as planned. I also applied this way of looking for analyzing the various transcripts of discussions during projectteam meetings; I 'looked for trouble' (Steven D. Brown, personal 66 communication 2006), for example, points in a discussion where people interrupt or misunderstand each other, or points where one person talks at length. Summary I will now summarize the research approach that I have constructed so far. I became interested in HCD practice and in how it differs from HCD theory or principles, and in what happens between project-team members (and to some extent to what happens between project-team members and users) and how they make decisions in their project. My research goals are to understand what happens in HCD practice and to explore alternative ways of practising HCD. I positioned my study in the field of science and technology studies (STS) and within a social constructionist research tradition. I chose to study one project ('single case') in which I myself work ('participant observer') and in which we tried to practise human-centred design (HCD), so that I can study what happens between people from within and how decisions are made over an extended period of time. I proposed to cope with the possible drawback of too much involvement by trying to maintain distance by means of a modest form of 'deconstruction'. I have justified my research approach by observing that there are only a few research texts that combine HCD practice and STS analysis, or are about HCD projects from an insider's perspective. In the tradition of participatory design, I will pay attention to politics and ethics and my goal is to contribute to a debate about design and ethics. Furthermore, I chose to take my observations as a starting point (data first), to borrow several concepts from ethics, to try to generate local knowledge, and to falsify my own interpretations by organizing joint reflection and by attempting to write reflexively. Combining the roles of practitioner and analyst I will now provide an account of how my research approach actually developed: how I struggled with combining the roles of practitioner and analyst, and how that sometimes made me feel puzzled or confused – for example, when I expressed criticisms of HCD in our project on which I worked, and received criticism on my role in the project. Or when I expressed criticisms of HCD at one moment and 67 found myself working as a consultant and having to sell HCD at another moment. During my study, I made several shifts, which I can plot in a diagram with two axes: a horizontal axis that plots positivist versus social constructionist approaches; and a vertical axis that plots detached versus involved researcher's roles – see Figure 8. Figure 8: Alternative approaches to conduct research (the axes are from Easterby-Smith et al. 2002, p. 57; the action, description and reflection and reflexivity labels are mine) I started my research from the context of working as a practitioner: from a position of action, see Figure 8 (1). I saw HCD as a method through which people could reclaim power over technology that has gone out of control. I imagined a dystopia in which people use e-mail, telephone and MSN to communicate instead of talking with each other face-to-face, or in which people spend all their time in virtual worlds, rather than being concerned with the real world or with real problems. Furthermore and probably fuelled by my engineering background, I had the ambition to improve our methods for HCD. In that time, I came across 'classical' philosophers of technology, such as Detached researcher roles Social constructionist approaches Positivist approaches action description and reflection reflexivity 1 2 3 Involved researcher roles 68 Jacques Ellul and Lewis Mumford (Achterhuis 1992), which made me think in terms of dichotomies, in terms of people versus technology and in terms of good versus bad. I imagined experiments, in which we would develop, try out, evaluate and improve our HCD methods. Such research would be based on a positivist idea of studying phenomena that are external to me, and such research would require an involved researcher role. In such a paradigm, a researcher could conduct experiments and manipulate an experiment's settings. But I soon realized that such experiments would not work for me. I would have to treat my fellow project-team members as lab rats in my experiments and I would find it that hard to combine this with continuing to work together in our project. Alternatively, a researcher could conduct action research, which is a delicate mixture of researching a situation, intervening in it and researching what happens. This happens in iterative cycles and in close cooperation between all participants and requires a high level of engagement. But I realized that this would not work either, because if I were to conduct action research properly, I would have to give my fellow project-team members agency in my research process and I do not want to do this. An action position would not work for me, so I had to look for another research approach. Then I moved towards description and reflection, see Figure 8 (2), as an attempt to (temporarily) detach myself from the situations that I want to study. This kind of research can be done within a social constructionist approach and requires a detached researcher role: a researcher goes into-the-field and studies the people out-there. I tried out this approach and described several situations in the project which I studied and I tried to reflect on those situations. For example, I discussed transcripts from project meetings in which I participated actively with fellow PhD students and with my supervisors. In these transcripts, I had disguised my identity by changing my name to Alex, and I altered the names of my fellow team members. However, my fellow PhD students and my supervisors easily guessed that Alex was me, and asked me all sorts of critical questions about my role in the project. This often made me feel confused and sometimes very uncomfortable. For example, they criticized how little we understood about the users with whom we cooperated (the police officers or the informal carers) and how little we allowed them (especially the informal carers) to participate. Those were precisely the points I wished to make as an author. I thought that there was no need to 69 emphasize this in relation to my role of project coordinator. I thought that they would treat me as an outsider writing about this project, but treated me as an insider with an active role in this project. I found myself switching awkwardly between describing the project (as a participant), defending my role in the project (as coordinator of part of the project), criticizing the project (as an analyst), and writing about the project (as the author of this text). I was asked critical questions, not only on the level of content, but also about my role in the project and my competences as a coordinator or a host of project meetings. This description and reflection approach did not help me to combine practice and analysis in a constructive way. Moreover, I felt unhappy about describing situations from an outsider's perspective. I negatively associated such an approach with a detached style of writing from a supposedly superior position. One way to make such an approach work is to play with the relationship between 'reality' and providing an 'account' of that reality, and it has been suggested to use irony for that purpose (Woolgar 1983). Although I tried to apply irony on some occasions, I was unable to make this work properly. This happened, for example, when I spoke about how I experienced observing police officers' work, at CHI Nederland Conference (21 June 2007). I told about how one police officer took a man from his flat into custody while the man's children were playing on the street, and I remarked that 'this is, of course, a good way of dealing with this situation'. Afterwards, I learned from people from the audience that I failed to imply that I thought that police work is complex and that it is not always possible to straightforwardly judge their work in terms of good or bad. Then I moved towards reflexivity, a combination of a social constructionist approach and an involved researcher role, see Figure 8 (3). I came to see reflexivity as a way to constructively combine practice and analysis and to be honest about my dual role of working in as well as studying the project. Additionally, my goal is to move back from reflexivity to action. I wish to discuss my study with my fellow project-team members and bring the findings of my study to other practitioners. When I finish this study, I plan to go 'back to work'. In summary, I can describe these moves chronologically, as logical and successive steps: 70 1) In 2004 and 2005 I conducted participant observation in the project in which I was working, and of which I coordinated one part. During workshops with users and during project meetings I made notes and audio and video recordings, and I transcribed and interpreted several of the workshops and project meetings. 2) In 2006 I wrote two papers (Steen 2006b; Steen 2006c) about the project and I discussed these with my fellow project-team members to hear their views. I recorded and interpreted these meetings, together with a student of science and innovation management, as a modest form of researcher triangulation. 3) In 2007 I attempted to write reflexively about combining the practitioner and analyst roles, for example in several 'awkward' situations with users (A police officer's manager talks back, p. 98), with fellow project-team members (Attempts to improve cooperation, p. 136) and with my supervisors (next section). Reflexivity (1) I understand reflexivity as something that occurs when the methods that one applies in some form of practice (e.g. an HCD project) are similar to the methods that one applies to study this project (e.g. a study of an HCD project). HCD, the topic of my study, is about understanding current (users') practices and envisioning alternative (users') practices and my study of HCD is about understanding a current (HCD) practice and envisioning alternative (HCD) practices. I had a research and design approach to this research and design project. In the project, we observed users and represented them via storylines, and in my study of the project I observed the project-team members and represented them in this text. I attempted to re-research and re-design research and design. I understand reflexivity and reflection as different concepts. To reflect or to be reflective would mean something like 'to think carefully and deeply about something' (Oxford Advanced Learner's Dictionary, 7th ed.). However, terms such as reflexive and reflexivity are harder to pinpoint. Their usage 'in social science discourse tends to be subject to unsystematic variation' (Ashmore 1989, p. 31). Looking at their etymology, they would mean something like 'to bend again' or 'to bend back' (op. cit., p. 30). Reflexivity happens when I apply a method that I would normally apply to somebody else or to something else, the other way around, to myself. This meaning is reflected in the meaning of reflexive as a term in grammar: 'a reflexive word or form 71 of a word shows that the action of the verb affects the person who performs the action: "He cut himself''' (Oxford Advanced Learner's Dictionary, 7th ed.). Reflexivity used to be considered necessary for obtaining or maintaining 'scientific objectivity' when studying situations in which one participates (Alvesson et al. 2004, p. 2). In such cases, researchers treat their involvement as a bug in their research and need to engage with reflexivity in order to cope with this bug. Another way of understanding reflexivity is concerned with the risk of becoming too reflexive. Trevor Pinch argued that 'a continual obsession with one's own intellectual production leads to introspection and ultimately it becomes impossible to write anything because one is continually aware that one's own writing is arbitrary and that there is always more to say' (1988, p. 180). In the same volume, Latour described reflexivity as 'sawing the branch upon which [you] sit' and cautioned that reflexivity can lead into 'indefinite navelgazing, dangerous solipsism, insanity and probably death' (1988, p. 155-6). Possibly in reaction to such negative connotations, Malcolm Ashmore and Steve Woolgar (e.g. Ashmore 1989; Woolgar and Ashmore 1988) suggested exploring, engaging with and celebrating reflexivity. Woolgar (1991b) suggested exploring the 'the self-in-the-text, the voice of the analyst/writer/author as it appears (or rather, as it conceals itself) in the course of argument (writing, speaking, representing)', and argued that a reflexive move will not be regressive but 'thoroughly regenerative' – that it may lead towards new and interesting and relevant insights. Woolgar also described this kind of reflexivity, which starts with studying the role of 'analyst/writer/author', as the 'hardest possible case'. In other words, I can try to see reflexivity not as a bug, but as a feature. This would be in line with the advice of my supervisor Hugo (e-mail, 26 September 2006), namely to regard reflexivity as an opportunity: this issue of yourself as researcher, actor and author is the crux to the project – you shouldn't feel badly about discovering how complex the relations are – that is exactly why there is a thesis – because the relationships are so complex and little understood ... See the problem also as your opportunity! 72 Reflexivity, if it happens, happens in consciousness. I understand consciousness not as happening only within myself but as being (re)created and experienced in interactions between people, including myself. This makes it even more difficult to put consciousness into words and onto paper. What I write about reflexivity is not the same as the reflexivity I write about. Writing about interactions with others and how I experienced these interactions can be a way of expressing some of my reflexivity. My supervisor once suggested writing a 'stream of consciousness' to try to capture reflexivity. I assume that advice was meant to counteract my tendencies to think in separate elements rather than about the whole, to manipulate and control concepts and my eagerness to improve things and create results. I guess that I do these things at least partly because of my fear of introspection. So, let's try a stream of consciousness for one minute. Well, then. I was trained in industrial design engineering and I am not ashamed of that. Sometimes I felt embarrassed. Especially when I moved between my role in the project and my role of writing about it. When my supervisors questioned me about this. Or students of organization. Some of them conveniently chose to write about others in such a detached and clever manner that I do not dare to ask them about their practice of studying and writing and about the relevance of their work. Or my peers: techies and designers. Some of them can so easily justify their work: if the technology works, it is good; if the product makes money, it is good. Why would they reflect on their practice? What is the use of navel-gazing? Yes, I did feel irritated on occasions. But if I look at writing my research text as creating a design, I can feel more comfortable. I created neat boxes to put different texts in: literature review goes here; methodology goes there; description in that chapter; and discussion in the other. I did my best to make it look nice for my peers. I maybe forgot about the social science audiences. I mean, I can imagine a social scientist browsing through this text and being critical about my lack of attention for culture, about not properly keeping a diary, about not labelling and categorizing concepts – about not doing ethnography properly. Well, that's because of my tendency to envision alternative practices, to create a bricolage of science and technology studies, management studies, design studies and philosophy, towards 'applying' such difficult philosophers like Levinas and Derrida to such a mundane activity as designing products. 73 Traditions of reflexivity It can be argued that reflexivity occurs in all social science: 'if [social science] is about humans and their social arrangements then it is (also) about those humans in those social arrangements who are responsible for the production of social science' (Ashmore 1989, p. 32). Therefore, it is not surprising that there are various forms of reflexivity in different traditions. I will briefly review four of these: • Ethnography and autoethnography; • Ethnomethodology; • Science and technology studies; • Essay writing. In ethnography, which means something like 'writing about people', one goes into-the-field and describes what one sees and hears. Ethnographers make field notes and transform these into texts about other people. Some ethnographers also write about their own thoughts, feelings and experiences during the research, but many confine these to a personal diary and do not include these in their published texts. Here are, however, some field notes by the classic ethnographer Malinowski (1967; quoted in Denzin and Lincoln 2000, p. 12): On the whole the village struck me rather unfavorably ... the rowdiness and persistence of the people who laugh and stare and lie discouraged me somewhat. ... Went to the village hoping to photograph a few stages of the bora dance. I handed out half-sticks of tobacco, then watched a few dances; then took pictures – but the results were poor ... they would not pose long enough for time exposures. At moments I was furious at them, particularly because after I gave them their portions of tobacco they all went away. I think this is an example of writing about writing about other people. This kind of reflexive ethnography has become popular since the 'crisis of representation' (Denzin and Lincoln 2000, pp. 16-17), that is: the realization that one cannot write about the other objectively, that one brings one's own preoccupation, and that this profoundly influences one's perception, interpretation and writing. Contemporary ethnographers are likely to mix both sources of knowledge: what they see and hear from others, and what they think and feel themselves. One version of such reflexive ethnography is autoethnography 'an autobiographical genre of writing and research 74 that displays multiple layers of consciousness, connecting the personal to the cultural' (Ellis and Bochner 2000, p. 739). At first sight this may appear to be simple – simply writing about what you heard and saw and about how you experienced that – but it is said to be 'extremely difficult' (p. 738): Oh, it's amazingly difficult. It's certainly not something that most people can do well. Most social scientists don't write well enough to carry it off. Or they're not sufficiently introspective about their feelings or motives, or the contradictions they experience. Ironically, many aren't observant enough of the world around them. The self-questioning autoethnography demands is extremely difficult. So is confronting things about yourself that are less than flattering. [...] Then there's the vulnerability of revealing yourself, not being able to take back what you've written or having any control over how readers interpret it. It's hard not to feel your life is being critiqued as well as your work. In my case, I understand these 'multiple layers of consciousness' as writing about what people did in the project, what I did in the project, what happened between people, including myself, how I look back on the project, what I tried to do and how I could have acted differently, and what could have happened alternatively. I realize that this is not an easy task for me. Even normal ethnography (without the 'auto' element) would be difficult for me, being trained as an industrial design engineer, to create new products rather than study people. Moreover, ethnography typically requires penmanship and the ability to provide 'thick description', in which one pays attention to non-verbal communication, to the material surroundings, to culture and couleur locale, and in which one conveys these meanings via evocative writing. Examples of such writing would be John Van Maanen's (1998) or Ton Bruining's (2005) descriptions of police work, in which they describe vividly and convincingly both what police officers do and their experiences as researchers. Another tradition in which reflexivity occurs is ethnomethodology (Garfinkel 1967). (This section is partly based on a presentation of Steven D. Brown on 11 December 2006 in the PhD programme of the University for Humanistics.) An ethnomethodologist is interested in how people create, re-create and experience social reality through their interactions. The assumption is that there is nothing like culture or structure that pre-exists or exists outside these interactions 75 between people. Social reality is what happens between people and one studies social reality by observing people interacting with each other. As a consequence, roles of people or relationships between people do not exist beforehand and are not fixed, but are negotiated during each interaction through all manner of procedures. An ethnomethodologist observes people, talks with them and thus creates knowledge. Reflexivity occurs when she realizes that her study of people's procedures happens via her own procedure. She can, for example, try to blend in with the procedures of the people she studies in order to get to know them better. Or she can create and introduce new procedures that do not fit in with people's current procedures and observe what happens. This would be called a breaching experiment. When she realizes that her research is also a procedure, that there is no alternative or superior route to knowledge, she must provide a reflexive account about her own research procedures, about her roles and relations, about her contributions to the social event that she researched, and about her procedures for interpreting this event. A form of this reflexivity is necessary for my study because my procedure for studying the project by observing project-team meetings is intertwined with the procedures of the people working in the project. Furthermore, it is necessary because my procedures for studying the project – observation and creating texts – are very similar to the procedures we follow in our project to study users' procedures – observation and creating texts. In retrospect, it occurred to me that some situations I experienced as awkward and unpleasant – see: A police officer's manager talks back (p. 98); Attempts to improve cooperation (p. 136) – can be characterized as unintentional breaching experiments: I acted counter to some people's expectations and practices and people reacted in an irked or angry way. Reflexivity also happens in science and technology studies (STS). An STS scholar can go to a biology lab to study how people in that lab construct (biological) facts, and in his research report he must write about how he constructed his (sociological) facts about how they constructed their (biological) facts. He must write about his own process of observing and drawing conclusions and about the other people's process of observing and drawing conclusions. Reflexivity becomes especially relevant and interesting if the domain being studied and the perspective from which it is studied are very close to each other. This happened in Ashmore's The reflexive thesis (1989). 76 Ashmore, as a sociologist (practising meta-meta-science), studied other sociologists (practising meta-science), who studied other scientists (practising science) who are studying a phenomenon. Ashmore (1989, p. 108-9) explained the need participation and observation: on the one hand, 'the participant knows best' about what is studied, and on the other hand, the 'outsider stance' is necessary to conduct science. He argued that 'in the study of science (and knowledge practices generally) one cannot avoid being inside and outside at the same time' and described 'participant observation' as a 'balancing act': 'Too much insiderness and one risks going native; too much outsiderness and one is in danger of mis-Verstehen-ing the situation'. In addition, Ashmore and Woolgar argued that there is a range of varieties of reflexivity: from self-reference, a kind of reflexivity based on the idea that one who does social science is part of the same social world that one studies; via self-awareness, a kind of reflexivity where one thinks about one's actions ('benign introspection'); to constitutive reflexivity (which comes from ethnomethodology), which starts with the realization that 'in any act of representation, there is an intimate interdependence between the surface appearance (document) and the associated underlying reality (object)' (Woolgar 1988, p. 21, paraphrasing Garfinkel 1967). This constitutive reflexivity is needed because of 'the mutually constitutive nature of accounts and reality': there is a reciprocal relationship between something out-there and an account, a story someone provides, about that something: 'In order to make sense of an account one must, in a sense, already know what it is that the account refers to; and in order to know that, one must have already made sense of the account' (Ashmore 1989, p. 32). What I take from the STS tradition is the need for reflexivity because I will be making knowledge claims about a project in which we make knowledge claims. Moreover, I feel attracted to some form of constitutive reflexivity, in the sense that I will not only pay attention to the project which I am studying, but also to various 'accounting practices': what others say about this project, what I say and write about this project, and what others say about what I say and write about this project. Some form of reflexivity also has a place in essay writing. I take the example of Michel de Montaigne (1533-1592), who coined this genre's name when he wrote his Essais (first published in 1588). Montaigne 77 wrote about his own thoughts, feelings and experiences and treated these as sources of knowledge and as material for further study. He was one of the first to write as an author with a self. Montaigne painted a self-portrait as honestly as possible and from a very personal perspective, and he did that in a way that is interesting for a wider audience (Dobbelaar 2005, p. 18). He was not looking for universal truth or for fixed facts, as was usual in his time – and still is, in some places. He wrote about what he personally thought was of value, rather than about universal truth and about his changing thoughts and feelings, rather than looking for fixed facts. Montaigne took his own experiences seriously as a way of learning about himself and to create an opportunity for others – his readers – to learn about themselves. He did not find this an easy task, but a worthwhile task nevertheless. There is no desire more natural than that of knowledge. We try all ways that can lead us to it; where reason is wanting, we therein employ experience (Of Experience) There is no description so difficult, nor doubtless of so great utility, as that of a man's self (Of Exercise) These quotes could function as mottos for my research approach. I found it difficult, but worthwhile, to study my own role in the project and in the studying of it. I think that practical experience, introspection and reflexivity can be sources of learning. What attracts me in essay writing is the creating of a text which originates from my experiences in practice, the attempt to connect with my thoughts and feelings and treat them as sources of knowledge and material for further study, and the attempt to write accessible and interesting texts (in English, which is not my first language). Additionally, Alvesson et al. (2004) argued that, in the field of (critical) organization and management research, reflexivity can be interpreted as an attempt to understand how people create knowledge and to draw attention to the linguistic, institutional, social and political influences on and mechanisms of knowledge production. They identified four traditions of reflexive practices – destabilizing practices; multi-perspective practices; multi-voicing practices; and positioning practices – and advised combining these. In my approach, I draw from three of these: from reflexivity as a destabilizing 78 practices (which they associate with an outsider perspective), in that I attempt to conduct a deconstruction of HCD practice; from multivoicing practices (which they associate with an insider perspective), although my text contains only a small number of transcripts of what other people said; and from positioning practices, in that I pay attention to social and political forces, as is done in 'laboratory studies'. On various occasions, my supervisors Jan and Hugo asked me questions about my role in the project, about my role in project-team meetings, about how I conducted my study, about how I interpreted my observations and about how I wrote about this. What I took from these discussions is that I cannot separate my practitioner and analyst roles. Hugo once wrote to me (e-mail, 26 September 2006): 'you tried a sort of realism and it failed'. He called it a paradox that my attempt for realism – my attempt to develop a detached position and write about my role in a detached manner – produced data that forced us into a more reflexive approach: 'the data (realism) buried realism (object assumed to be outside the author)'. On another occasion, Hugo summarized my role and said: 'You are a rat'. I looked at him and asked 'Excuse me?', because I had heard him say 'rat'. He then explained: 'I mean a lab rat. You are your own lab rat'. I am the subject as well as the object – the lab rat – being studied. And that did not always feel pleasant. In the next two chapters I will provide accounts of two activities within one project. But I will first introduce the project and some of its context. 79 Introduction to the project studied and to Chapters 4 and 5 My goal was to study one project and to study how people interact with each other and how they make decisions during the process of research and design. I chose to study the Freeband FRUX project, a project in which I worked and which was planned to run from 2004 until 2007, mainly for pragmatic reasons. It would allow me to study interactions between project-team members from within and to study decision-making processes over a period of time. Moreover, I worked as a coordinator of a part of this project, which allowed me to observe also some of the efforts of organizing and managing the project. In this section I will introduce the project and some of its context, and discuss some advantages and disadvantages of choosing to study this project. In 2001, the Netherlands Ministry of Economic Affairs developed the idea to invest revenues from the national natural gas reserves in research relating to information and communication technology (ICT). The goal was to generate knowledge about developing ICT services and to disseminate and apply this knowledge for the benefit of the Dutch society and economy. Several research consortia formulated plans in which they applied for such funding. In response to this, the Ministry commissioned a project to create a joint research programme, which resulted in the cooperation between people from universities and (applied) research organizations and the advice to focus on 'fourth generation' telecommunications (Stratix 2001). Fourth-generation telecommunications refers to new communication networks such as UMTS, HSDPA (cellular, telecom), WiFi, WiMax (wireless, computer), ADSL or WLAN (wired, computer), and to combining these networks in innovative ways to create new ICT applications. The fourth generation is different from third generation in which networks and applications are related to each other as if they are hardwired: one can make a call on a mobile phone via a cellular network, send an e-mail on a PC via a data network, and watch television on a TV via cable. The ambition was to create ICT applications that can be combined freely with all manner of underlying networks, thereby enabling people to do various new things such as send e-mail from a mobile phone, watch television on a PC, communicate with others via a TV set, and a range of other combinations. The research programme was called 'Freeband', which refers to the mobile and broadband character of such innovative ICT applications and to the promise of 'Connected anywhere, anytime, 80 anyhow'. In the starting document (Stratix 2001), it was proposed to develop ICT applications that are relevant for society: in the domain of public safety and in the domain of health care. Moreover, the programme's ambition was to look at 'communication and information from the perspective of the user, and not from the supplier' (Stratix 2001, p. 4). The Freeband research programme was planned and executed in two phases: Freeband Impulse, which ran in 2003 and 2004 and consisted of twelve projects with a total budget of 26 million euros, and Freeband Communication, which ran from 2004 until 2008 and consisted of ten projects with a total budget of 60 million euros. Half of the budget comes from the Ministry of Economic Affairs and half comes from the participating organizations and companies. Over 30 organizations participated in Freeband: universities and knowledge institutes (e.g. Delft University of Technology, Eindhoven University of Technology, University of Twente, Erasmus University, VU University Amsterdam, Telematica Institute, TNO), multinational companies (e.g. Ericsson, IBM, KPN, LogicaCMG, Lucent, Philips, Siemens, Vodafone), and small and medium enterprises and not-for profit organizations (WMC, Waag Society, Surfnet, the Dutch Police). The FRUX project is one of the projects within the Freeband Communication programme. In terms of content, FRUX focused on six topics: user experience and we-centric telecom; business modelling and service bundling; and group personalization and context-awareness. The project was organized in three work packages (WP's) and each WP focused on several topics and had a specific perspective. WP1 had a users' perspective and focused on user experience and we-centric telecom. WP2 had a business perspective and focused on business modelling and service bundling, and WP3 had a technology perspective and focused on group personalization and context-awareness. The main research questions came from WP1 and WP2 and were addressed partly via desk research and partly via a 'research-oriented design' (Fallman 2005) or 'research through design' (Zimmerman et al. 2007) approach: we would design and evaluate ICT applications and conduct our research during that process. We chose to design and evaluate these ICT applications within two application domains, public safety and health care. Moreover, organizations from these domains also participated in the project: the Dutch Police and the VU University medical centre, respectively. 81 This Freeband context influenced how we worked within the FRUX project. It was a research project, not a product development project. We worked in the early, pre-competitive phases of innovation. The project was partly sponsored by the government and had no direct commissioning party or client, and decision-making occurred partly within the project, by the project-team members and was partly steered by steering and evaluation committees from the Freeband programme. As a consequence, the decision-making processes were different from, for example, those in a product development project or in a project with a commissioning party or client. The project was planned to run for a period of four years and it was necessary to write project plans for this entire period as well as for each successive year. Moreover, project-team members worked at different organizations in different locations throughout the country, and they had diverse interests and motivations for working on the project. For example, some of the team did their PhD research in this project. Most of the people worked on the FRUX project on a part-time basis, for example 200 or 300 hours in a year (less than one day a week) and worked on different tasks and in different WPs. Because of the long lead time, the shared responsibility for decision-making, the diverse interests and the part-time work, progress was relatively difficult and slow within the FRUX project. I worked on and coordinated WP1, and my empirical material comes from this part of the project. In my role as coordinator of WP1, I could only partially influence what we did in the project. I had a form of middle-management role and had to accept the people delegated to the project by the participating organizations and deal with various personnel changes. I also had to cope with different goals and changing priorities of the project partners and stakeholders. Although FRUX was primarily a research project, we did design and evaluate ICT applications as vehicles for our research. Similarly, we applied several HCD approaches as a way of conducting research. At the start of the project I did not have specific ideas on how to practise HCD and how to learn from our HCD practices; we improvised and did what seemed sensible at the time. Consequently, I was able to study HCD practices which were organized and conducted in a relatively impromptu way and within the context of designing and evaluating ICT for the purpose of researching topics such as user experience and we-centric telecom. This setup is rather different from, for example, organizing an experiment in which a specific HCD 82 method is conducted, or from how a product development project would be organized. Within the FRUX project, attention for HCD slowly emerged, partly because of my growing interest and my study of our HCD practices and partly as a result of an external review. In this review (mid-2007), the FRUX project was described as 'a complex, many party project, with too many topics' and it was suggested that the project should focus on a small number of topics. In response to this review, it was decided that FRUX would focus on delivering knowledge about the process of designing ICT applications and HCD was identified as one of the main topics that the project should focus on. The research within WP1 focused on user experience and 'we-centric' telecom (Steen et al. 2005). In practical terms, we attempted to design and evaluate two we-centric telecom applications: one with and for police officers (public safety), and one with and for informal carers (health care). At the start of the project we had only a tentative vision of what we wanted to achieve with we-centric telecom. We wished to improve communication and cooperation between people, focusing on 'in heterogeneous, spontaneous or dynamic' groups of people (Van Eijk et al. 2004). We-centric telecom applications can be positioned in the fields of computer-supported cooperative work (CSCW) and social mobile software (SoMoSo). Figure 9: I-centric telecommunication (sources: www.freeband.nl, picture on the left; and Arbanowski 2003, picture on the right) Moreover, we-centric telecom is intended as an alternative to an 'Icentric' (Arbanowski 2003) conceptualization of telecom in which people are construed as separate individuals, each monitoring and 83 controlling objects and people around them: 'An individual user is interacting with objects in his individual communication space. Communication between different individuals is done by sharing objects of their individual communication spaces' (Arbanowski et al. 2004) – see Figure 9. During the project, we further developed this idea of we-centric telecom applications, which resulted in applications that are used on a PDA (Personal Digital Assistant, a small portable information and communication device) or smart phone (a device that combines telephony and basic computer functions, similar to a PDA but with connectivity) and provide suggestions for communicating or cooperating with others. During the project, two key functions were formulated for a we-centric telecom application: 1) it composes and presents a dynamic list of people who are supposedly relevant, which is intended as a suggestion for communicating or cooperating with these other people, and 2) it presents ('context') information about these people, which is intended to assist the actual communication or cooperation with them. Our ambition was to build prototypes of the two telecom applications – the PolicePointer for police officers and WeCare for informal carers – and evaluate them with groups of users in field trials. However, this ambition was only partly achieved. A semi-functional prototype of the PolicePointer was built and evaluated with five police officers during two working days, and a demonstrator (one notch below a prototype, one notch above a visualization) of WeCare was built and evaluated in series of interviews with six informal carers. In terms of the project, this was disappointing, but for the purpose of my current study this does not really matter, since I am primarily interested in research and design processes at the 'fuzzy front end' of innovation and in the practices of researchers and designers. In my current study, the products that are created and users' evaluations of these products are a secondary interest. 84 85 4. Designing with/for police officers This chapter is about how we designed a telecom application together with and for police officers. Please bear in mind that this text is intended as a description, not as an evaluation. My goal is to provide an account of what we did in this project, including my own role: how we attempted to cooperate with police officers during our research and design efforts. My goal is not to evaluate our project in terms of good or bad. If, in this account, someone perceives examples of practising HCD well or badly, then I would remark that in my view the project-team members and police officers did their best, given their respective roles and contexts. And if one wishes to criticize the project, I would like to be held accountable for my role in it. Furthermore, the people who played key roles in the process described in this chapter – Mandy, Dirk and Harold – read draft versions of this chapter, provided feedback and approved this description. Overall, my story is about how we gradually changed the scope of our project and the product on which were working, based on what we learned from interactions with police officers. In HCD it is considered good practice to allow users to influence the project and the product. Furthermore, my account includes examples of how we unintentionally missed several opportunities to learn from police officers because we were occupied with designing a telecom application for them. Starting with an idea Early in 2004 the project started and I met project-team member Albert. He had worked for many years as a community police officer. He still worked for the police, but now had a desk job. His work involved helping to create innovative ICT applications for police 86 officers. He divided his working hours between working with the police in the south of the Netherlands, where he is from, and working at JKL, a central ICT development department associated to the Dutch police. In 2005, Albert retired. When we talked about his plans after retiring, he told us that one of his hobbies is to collect and read detective novels. He had shelves full of them and was looking forward to reading the ones he had not yet had time for. In terms of content, the project started with Albert's ideas. Within the project, Albert is responsible for identifying and defining police officers' needs that are relevant to our project – needs that we can try to solve with ICT. Albert proposed focusing on the work of community police officers and to support and help improve their work. The work of these police officers mainly involves talking with all sorts of people, with citizens and, for example, shop owners, school administrators and people from the local authority and housing associations, as a way of serving citizens and preventing crime – see Figure 10. Their work is rather different from the work of emergency police officers, who have to respond to emergencies and can be seen driving with lights flashing to incidents and accidents. Albert's idea was to empower community police officers and create tools to help them communicate and cooperate more effectively with other people in their various tasks. This idea matched the project's goal of working on a we-centric telecom application. Figure 10: The work of community police officers 87 The work on the design and evaluation of a we-centric telecom application for police officers was carried out mainly by project-team members Mandy, Dirk, Harold and me: • Both Mandy and I work at TNO, a research and consultancy organization. Mandy has a background in cognitive science and works as researcher and consultant on topics such as user experience and usability. She has ten years' experience in these areas. She is known for delivering high-quality results and for her practical approach, for example in terms of coping with time and budget constraints in projects. • Dirk has an engineering background and works as a researcher specializing in application development at research lab STU. This project was Dirk's first encounter with HCD, and he enjoyed spending time with the police officers. He also contributed to the development of the technology behind the application. • Harold joined the project around the time that Albert retired (2005). He also works at JKL (a central ICT development department affiliated to the Dutch police). His role is to organize interactions between the project and the police. Harold has a background in biology and his current job is to develop ICT applications for police officers. He is interested in the psychological, social and cultural aspects of police work. Mandy, Dirk and I worked closely together and combined research and design roles. The role of Albert and Harold was to act as intermediaries between the project and the various police organizations. I refer to various police organizations rather than the police because the Dutch police are organized in some 25 regions, each of which is divided into districts and then into base units. This organizational structure allows regional police forces a relatively large degree of autonomy in adapting their processes and practices to the regional context. As a result, the Dutch police force is less hierarchical than, for example, the French police force, which is largely centralized. In organizing the cooperation with police officers, we often dealt with people from a region or base unit. Thinking about the intermediary roles of Albert and Harold, I remember that we referred to them in terms of 'us', for example when we talked with Harold about his task of recruiting police officers for 'our' workshops. We referred to Albert and Harold as 'them', for example, when Harold acted as a spokesperson for police officers and talked about police work. My role was to coordinate design and evaluation activities for a we-centric telecom application. I will mainly write 88 about what happened within the project-team and between projectteam members and police officers; police officers feature in so far as they participate in the project. Focusing on a single topic (workshop 1) Our first contact with police officers was in a workshop (July 2004) organized by Albert, Lisette (who worked in the project for the first six months and was then replaced by Mandy) and me. We went to a city in the south of the Netherlands to talk with six police officers who manage or coordinate the work of community police officers. Most of them had worked as community police officers before their current job. This was not our very first contact with police officers, but it was our first contact with police officers in the context of the project, in our roles of researcher/designer. I once received a ticket from a police officer for cycling at night without proper lights and I felt annoyed at that time, not only because the police officer picked me out of a crowd of people with bikes without proper lights, but also because I had not repaired the lights. In that situation I was in a role of receiving a ticket from a police officer. During the workshop I did not think about that role; I was fulfilling the role of conducting a workshop, in my role as researcher/designer, and I felt comfortable. We started the workshop by asking the police officers to talk about their current work. We did not encourage them to suggest ICT solutions. We first wished to hear about their current practices and not drift too soon towards discussing alternative or future practices. We then talked about information and communication processes and tools they use to capture, retrieve or exchange information and communicate with others. We closed the workshop by identifying several problems and related ideas for solutions. We chose these because they seemed relevant, both from their perspective and from our perspective. We were looking for problems – or 'opportunities', as Albert preferred to say – that could possibly be solved through an innovative ICT application. These are the problems and solutions that we formulated together: 1. When a police officer is on the street s/he may need some information (for example an update, a history or details) that is not available. At the moment, s/he has to go to the police station to 89 retrieve the information or call someone to retrieve it. An information application might solve that problem by providing mobile access to the information required. 2. Part of a police officer's work is paperwork. Currently, this work is duplicated: officers make notes on paper while they work outdoors and, later on, back at the office, they have to type the notes into a computer system. An information application might streamline that process, for example by enabling officers to make digital notes and send them to the office electronically. 3. In order to respond adequately to emerging events, managers need to know where police officers are and who is doing what. With this knowledge, they would be able to better steer police officers and change priorities. The picture that managers currently have is incomplete. An information application could provide the required overview, for example by using localization technology. 4. Community police officers need to communicate with other police officers, with firemen or ambulance personnel (e.g. in emergencies), or with their network partners (e.g. shopkeepers, school administrators, people from the local authority or a housing association). The police organization wishes to facilitate this form of communication, but lacks the appropriate ICT tools to do so. After the workshop, the fourth problem/solution was chosen to focus upon in our project, namely helping community police officers to communicate and cooperate with others. Albert participated in this decision-making process. We chose this problem/solution mainly because it matched the scope of the project, in order to improve communication and cooperation between people with a we-centric telecom application. Although we had only tentative ideas about what such a we-centric telecom application would look like, we were able to identify this problem/solution as being within the project's scope. This made me feel comfortable: it matched Albert's ideas, it matched the police officers' concerns and it matched the scope of the project. Neglecting other topics Later in the project, for example during observations and workshops, we would again hear police officers talk about inputting, editing and 90 accessing information, and about the related problems. Such problems are closely linked to the first and second problem/solution. However, we were never very keen to pay much attention to those topics. Mandy, Dirk and I wished to focus on communication rather than information. Dirk once explained that focusing on information processes and information systems would open a Pandora's box and lead us towards matters that were too complex for our project, such as knowledge management and all manner of ICT applications for supporting knowledge management. Furthermore, Harold had an interest in what he called the 'implicit' knowledge of police officers. He argued that police officers have all sorts of knowledge which they do not enter into their information systems and that he would like to help police officers to share this implicit knowledge by means of personal communication rather than an information system. I was pleased with Dirk's and Harold's remarks, because focusing on communication and telecom would make my role as coordinator easier. Moreover, I had experience with designing and evaluating telecom products and applications and felt confident with such topics, whereas I have no experience with information systems and databases and I disliked the prospect of working on such topics. In addition, information systems remind me of chores that I dislike, such as inputting, by 12 noon every Monday, the number of hours spent on various projects, and receiving e-mails from my manager if I fail to do this. From the start of the project we were keen to focus on communication and telecom applications rather than on information and information systems. I am not saying that it is wrong to have a focus and to keep to it, I am simply observing that this is what we did. I have mentioned the conclusions from the workshop but I have not yet mentioned what happened during the workshop. In a project, I often focus on creating results. However, in this account, my aim is to pay attention to the process. In a report on the workshop, which we sent to the participants afterwards, we included comments made by the police officers during the workshop: Police work is around-the-clock-work. A police officer is solutionoriented, eager to solve problems, curious, suspicious even and is a doer, a go-getter. 91 Area-bound work [associated with community police officers] means that police officers focus on one area and work together with their 'network partners'. Police officers who do area-bound work do that very independently and often alone. Much of their work is driven by incidents and is therefore difficult to plan. A police officer is like a spider in a web: he communicates with colleagues, with the local police station's secretary, and with citizens, the local authority and neighbourhood associations. Police officers must report all their activities. They must enter their hours in a planning and control system, write reports on a content level in the police-report database, and communicate with network partners about their actions. They must indicate their whereabouts (e.g. whether they are in or out the station), in which police car, on a whiteboard at the police station; and they must keep an electronic office calendar about what they are doing and will be doing. A policeman's job is not to catch criminals, but to produce files full of information for the prosecutor to prosecute criminals. From these quotes we can learn about the fragmented and problematic identity of a police officer and about what it means to work as a police officer: about being a solution-oriented, independent professional; about being a 'spider in a web' and being dependent on others; and about being a servant to larger bureaucratic processes. The topic of identity recurred several times during our interactions with police officers, but we never made it an explicit topic within our project. In the workshop we also touched upon how quality and performance of police officers' work are managed and monitored. Similarly, we did not pay much attention to these topics. Police officers, for example, told us about controversies in monitoring the quality and performance of their work. A reduction in the number of reported burglaries can be attributed either to preventive work by police officers or to burglars being less active. An increase in the number of tickets for a certain offence can be attributed either to police officers dedicating more time to writing tickets for that specific type of offence or to an increase in that type of offence. Within the project-team we seemed implicitly to assume that we could focus on communication problems and telecom solutions, and 92 neglect all manner of socio-cultural topics such as identity, and political topics such as quality management. As if the technical can be separated from the socio-cultural or political – which would be contrary to findings from science and technology studies, which emphasize the inseparability of the social and the technical (e.g. Latour 1987; 1996). Conducting observations After the workshop, we read a number of documents about police work. This gave us a basic understanding but we wished to further our understanding through personal observations. We therefore arranged to observe police work. Mandy, Dirk and I participated in the observation (August 2004, in and around a small city in the centre of the Netherlands). Four other project-team members also participated, but they were involved only indirectly in designing the we-centric telecom application because they were working on other tasks. Each of us spent one day with one or more police officers, either during a morning-afternoon shift or an afternoon-evening shift. We accompanied the police officers almost everywhere: at the police station, walking on the street and in their cars. We were able to observe the work of community police officers as well as emergency police officers, either because we followed more than one officer or because a community police officer also worked in emergency response, that is, in the role of an emergency police officer. Researchers and designers can attempt to gain an understanding of users and their needs and preferences through personal experience. They can do this in different ways: by observing users, by participating in users' lives, or by becoming immersed in the user's world (Koskinen and Battarbee 2003, p. 45). The options of participation or immersion were not practical in this case. Furthermore, we felt that time and budgets were limited and we opted for 'rapid ethnography' (Millen 2000), which is intended to 'provide a reasonable understanding of users and their activities given significant time pressures and limited time in the field'. I had the idea that we should use our limited time with the police officers efficiently, and I prepared an observation checklist with topics such as: Which activity? Alone or together? Communication: With whom? What about? How? Information: Searching? Sending? Receiving? Reporting process: What? How? When my fellow project-team members saw this, they argued that walking around with checklists would make them feel awkward 93 towards the police officers, as if they were assessing them. They preferred to observe in a more open-minded way, without predefined checklists. I agreed, and we decided not to use checklists. I was glad about this because I hoped it would indeed result in a more open approach. All in all, our observations were largely in line with what we had already learned about police officers' work, from the first workshop and from documents. Police work is driven by incidents and requires improvisation. Officers communicate with many different people. They spend a lot of time at their desks in order to input, edit or access data. And they often need implicit knowledge – knowledge that is in the heads of people, not in information systems – or information for which they have to call a colleague at the police station or go to the police station to look it up. The primary goal of the observations was not to obtain new information but to give us personal, first-hand experiences and help us empathize with police officers and design products for them. All the project-team members remarked that the observation had indeed had this added value for them. All seven members of the project-team who participated in the rapid ethnography made observation notes, about six pages each. Based on these notes, we created three personas (descriptions of fictional police officers): community police officers Ad and Bert and emergency police officer Theo. We created short descriptions of their private lives and wrote about why they work as police officers. We also created three storylines for their work: a working day for Ad, a working day for Bert, and a working day for Theo and Ad together. The texts of the personas and storylines amounted to a 16-page memo. We constructed the personas and storylines during a project meeting in which we collectively selected situations that seemed to happen frequently and seemed to be relevant both for the police officers and for the project's scope (communication and cooperation). Here are some excerpts: About community police officer Ad Ad is 45 years old and has worked as a community police officer for 20 years. Ad is married and has two children: a daughter of 18 and a son of 16. Five years ago, Ad and his family moved from Amsterdam to Haretown [in the countryside]. Amsterdam was becoming too hectic for him and he preferred quieter surroundings. [...] 94 Monday, 11 o'clock Ad is walking around in 'his' area. He decides to go to the swimming pool to check how things are. The weather is beautiful and it will probably be very busy at the swimming pool. Over the past few days, a group of teenagers have been causing a lot of trouble. Ad arrives at the swimming pool and looks for his contact person, John. However, John appears to have a day off. [...] We portrayed Ad as relatively old and as preferring quiet work. This is in line with how we heard police officers talk about community police officers, in contrast to how they talk about emergency police officers, who would typically be younger and enjoy more hectic work. Furthermore, the way in which we wrote the storylines implies that police work could be improved by using a telecom application. A we-centric telecom application would, for example, notify Ad that his contact person at the swimming pool is absent, so Ad might decide to visit the swimming pool at another time, when his contact person is present. It was assumed that this would make police work more efficient and effective. The personas and storylines helped us to communicate within the project-team about police officers and helped us to design a product for them. In the project, we would often say that we would like to have more contact with police officers, but it was difficult to arrange this practically. We looked for ways to keep alive some of the findings from our contacts with police officers. We discussed the option of creating life-size cardboard police officers and putting these in our office, to remind us of the people for whom we were designing a product. For practical reasons, we did not do this. We work in different offices across the country and we would have had to carry our cardboard police officers with us. However, some designers, for example at design agency IDEO, do create such cardboard personas, and claim that this helps them. I see an irony here. Transferring fleshand-blood people into cardboard people, creating 'our' users by representing 'them' so they become readily available, anywhere, anytime. If we ask ourselves what a police officer would do, we just imagine what cardboard Ad would do. The irony would be that such an approach can take us further away from users, rather than closer to them. Once researchers and designers have their fictional users readily available, they may tend not to make the effort to go out and interact with real users. 95 Leaving out observations When I compared our individual observation notes with the collectively constructed storylines, I noticed differences. Our notes contained spontaneity, curiosity and excitement, whereas the storylines were relatively dull – even sterile – records of activities. Many of our subjective observations and personal notes were discarded in the process of creating the storylines. Karin wrote that, in her view, police officers spend too much time inputting or editing data in their information systems and, slightly annoyed, she suggested that their work should be made more efficient. She saw how a thief was arrested for stealing a diary from a shop and witnessed the procedure of interviewing her, taking her to the police station, searching her and removing her valuables, locking her in a cell, interviewing her again, writing and inputting reports, and requesting the auxiliary public prosecutor to see her. 'All in all, this process will take until the end of the afternoon, at least, and all this for a diary costing 9.50 euro!' In his notes, Dirk relayed a remark made by one officer as they got into the car: 'Would you like to see our advanced navigation system?' – referring to a pile of paper maps, and a remark by a community officer about emergency police officers: 'They run around like puppies. I used to be one of them, but not any more, fortunately'. Barry noted that one police officer said: 'So many reporting procedures, it drives you crazy'. He also wrote about how another officer repeatedly pointed at things on the street while driving, asking 'Did you see that?' – and laughing because Barry had not seen it. Mandy made the following note: 'The community police officer says he likes to have contact with very different people. You deal with antisocial people as well as well-to-do people. What he likes about so-called "antisocial" people is that they always tell the truth. The less pleasant people are the well-educated ones who threaten to send their lawyer'. I jotted down what one police officer said, referring to a stack of new chairs: 'I asked for that chair two years ago. As you can see, we really get things done here'. And I made notes of a mock fight between police officers during lunch in the police station canteen: 'One pulls the other's tie (which is fastened with two clips, not tied around the neck), and the other takes his gloves. They prod and tickle each other a bit'. The clip-on ties are for safety reasons: when they are attacked, they cannot be strangled with their own tie. 96 In our notes we wrote about our own feelings, for example Karin's own frustration about cumbersome procedures, and about what we saw and heard about police officers' feelings, for example their frustration about not having proper tools or resources. We omitted our notes about their culture and jokes and about our own reactions and concerns. Some of these concerns may have came from our roles as citizens, rather than from our roles as researchers/designers. We dealt with this by marginalizing and omitting these concerns from our research/design process. However, see some topics will reappear, for example cumbersome reporting procedures and the lack of tools for easily accessing information. In retrospect, I wonder what could have happened if we had paid more attention to such topics and explicitly taken them into account during our research and design process. That would be in line with the goal of empathic design: to empathize with users' experiences via one's own experiences (Fulton Suri 2003a). I think that our way of dealing with observations relates to the difficulty of combining social science and design approaches (Haddon and Kommonen 2003). For example, a social scientist would try to conduct a proper ethnography and thoroughly study other people and their experiences and concerns, whereas a designer would be able to conduct only 'rapid ethnography' in order to inform or inspire the design process. If human-centred design is more akin to design than to social science, then it was legitimate for us to focus on topics that are directly relevant to the design process and to the product being designed. But how can one know in advance what is – and what is not – relevant to the design process? Validating our observations (workshop 2) We wished to discuss the personas and storylines with the police officers who had been involved in the observations and on whom the personas and storylines were based. We wished to do this for two reasons: in order to validate our observations and interpretations with them, and in order to jointly identify problems and envision solutions that are relevant for them as well as for our project. Mandy, Harold and I therefore organized a workshop (October 2004) with the police officers in question. One week before the workshop, we sent them the memo with the personas and storylines, and asked them to read this text as a preparation. Four of the police officers with whom we had spent a day participated in the workshop. 97 We began the workshop by discussing three situations from the storylines in which a community police officer communicates and cooperates with a 'network partner' – in line with the problem/solution previously chosen (workshop 1). The swimming pool situation was one such situations. In the three situations, we implicitly suggested problems concerning communication and cooperation in order to stimulate discussion about a telecom application as a solution. We asked the police officers whether they recognized these situations, how they would react, what problems they saw, and what kind of solutions they could think of. In response to the swimming-pool situation, they said that a visit to the swimming pool is worthwhile, even if the contact person is absent. 'It is good to show your face and to meet other people working there'. They said similar things about the other situations. In short, their message was that communication and cooperation with network partners is going well as it is. Instead, they talked about other problems. They would like to be able to look up information or access their intranet from their cars, and they would like to have laptops or PDAs in the car to do this. But there is no budget for that ('management chooses to allocate budgets differently') or it is difficult from a legal perspective ('you cannot carry this kind of information outside the police station'). We made it clear that we cannot offer practical solutions for such practical problems in our workshop. We explained that we were interested in their current work in order to inform or inspire our work on a future product that might help them in their future work. Furthermore, the topics of quality and performance reappeared. The police officers talked about the difficulty of measuring the added value and quality of their work. How can one measure the added value or quality of walking around on the streets for prevention purposes? It might help a kid to stay away from crime, but that would be hard to measure. One police officer spoke proudly about the results they had achieved in a large block of flats that had been problematic for years. There had been vandalism, fights and crime. For a several years he had worked in close cooperation with people from the housing association and with the concierge, and the situation had slowly improved. 'You don't read about these things in the newspaper – they're not interesting for journalists'. When I listened to the officers, I could sense their pride in such work – which needs a longer term commitment – and also their frustration with their managers' tendency to look for short-term results. 98 They also talked about how, as community police officers, they have extensive and detailed knowledge of particular areas and of the people who live and work there. Much of their implicit knowledge is not recorded in an information system and is therefore not easily accessible for other police officers. However, they argued, this kind of knowledge could be very useful for emergency police officers. It would help them to do their work better if they knew that a particular community police officer has certain implicit knowledge. They suggested that we invent something to help community police officers to share their implicit knowledge with emergency police officers. We adopted this suggestion and changed our scope from helping community police officers to communicate and cooperate with network partners (which seemed to be going well) to helping community police officers to share their knowledge with emergency police officers. We imagined a storyline like the one below: Emergency police officer Theo is sent to an address following a report of domestic violence. One week ago, community police officer Ad visited that address following a similar incident and made all sorts of observations and interventions. It would be helpful for Theo and Ad to communicate (quickly) about that situation and about Ad's observations and interventions, before Theo arrives at the scene. A we-centric telecom application could enable and facilitate this communication. We were happy with this change, also because we were starting to realize that the idea of opening up the police's communication channels to all sorts of external network partners would be likely to cause complex and difficult legal problems, for example in terms of security and privacy. A police officer's manager talks back Shortly before, during and after the workshop, a number of problems occurred that I would normally not describe in detail because I found them rather embarrassing. Mandy and I arrived one hour before the workshop was scheduled to begin, in order to prepare things. For example, we were planning to do some role-play during the workshop. We planned to invite police officers to enact situations from the storylines. We figured that such role-play would fit the police officers' physical way of working and their natural use of their bodies, rather than sitting still, as commonly happens in meetings. 99 We were early because we wanted to examine the room and have time to decide where to do the role-play and where to put the video camera. We brought the camera in order to document the workshop, in particular the role-play, which was a rather new technique for us. When we presented ourselves at the reception desk of the police station, we were called into the police sergeant's office. It was like being called into the headmaster's office or worse: like being caught by the police. One of the first things the sergeant said was that he was going to cancel the workshop. He was irritated because he had not been informed properly beforehand. He had not found out until this morning about the workshop with 'his' police officers. I felt unsettled when the sergeant announced his intention to cancel 'our' workshop, and I concluded that I needed to do something constructive. I explained how I had made arrangements for the observation together with Jack, one of the police officers, and how he organized this workshop in consultation with his manager, Caroline. I also emphasized that the observation had been very useful for our project, as a hands-on introduction to police work, and that the police officers had enjoyed showing and explaining their work to us. Moreover, I apologized for not consulting him earlier about the project and the workshop. In retrospect, I suppose I assumed that Jack or Caroline would inform the necessary people about the workshop. After some discussion, the sergeant agreed that the workshop could proceed – but with him present as a participant. Mandy and I quickly decided to skip the role-play and the video-taping. We did not dare to push our luck by explaining that we had planned to ask police officers to do theatrical improvisation and record it on video. We went to the room where the workshop was to be held, and police officers and their sergeant entered at the scheduled time. Shortly after our introduction, the police sergeant took a copy of the storylines from the table and said that he was not amused with these 'children's stories'. (He called them 'Jip and Janneke' stories, after a popular Dutch series of children's books, originally published between 1953 and 1960 but still very popular). He explained that he did not want journalists to get hold of the stories and publish them in De Telegraaf (a popular Dutch tabloid newspaper). He was, for example, irritated by the descriptions of policemen drinking coffee ('as if we drink coffee all the time'). I was glad that we had not included the police officers' jokes about their 'advanced navigation system'. I replied that, of course, the documents were meant only for use within the 100 project. In retrospect, I think he was concerned about the public image of the police and of the section of the police for which he is responsible. His job is to let police officers do their work. He does not want them to waste their time in workshops and he does not want strange stories about his police officers to appear in the newspapers. The police sergeant was clear about his concerns and about his role. In retrospect, I think I could have been clearer about my concerns and about my role in coordinating the design and evaluation of a telecom application. This was the first time that I had experienced such feedback on my storylines from a real 'user'. It made me wonder about the legitimacy of representing another person by means of a storyline. After the workshop, the sergeant remarked that we had 'learned nothing'. He could not imagine that we had learned anything beyond the obvious. Mandy and I were surprised by this because we had learned new things and we had made a change in our project, based on what the police officers had told us. Perhaps we could have learned more. Perhaps the police officers would have been able to speak more openly without their manager present. He argued that one would need to do more observation, more thoroughly and over a longer period of time, in order to understand a complex organization such as the police. This sounded like an invitation for future cooperation. I asked him about this, and he could indeed envisage some form of cooperation. Unfortunately, this never came about because of reorganizations within the police force. As a result, we had to find another region for further interaction with other police officers. Interestingly, we were working on a telecom application that was intended to help police officers to work more proactively, selfsufficiently and in a bottom-up manner, and to communicate and cooperate more effectively. This ambition relates to questioning or challenging some of the existing power structures and practices within the police, and envisioning alternatives and initiating change. At the same time, I experienced a lack of cooperation and the exercising of power when the police sergeant announced that he intended to cancel the workshop. In retrospect, I imagine that I could have tried to see non-cooperation and power not as negative features obstructing 'my' process, but as features of a process happening here and now, between people, between him and me. I could have tried to 101 relate what happened on a process level to what we were trying to do on a content level. I could have tried to address and deal head-on with topics such as cooperation and power, in the here and now, not in a detached way and on a content level designing a telecom application, but in an immediate way and on a process level, in my interaction with the police sergeant. (See: Reflexivity, p. 188.) Reading an article and developing sympathy During my day of observing, I accompanied two police officers who were going to investigate a theft from the cash register at a car dealership. I went with them to the shop, where they interviewed several employees. Even I became suspicious of one of them, when he talked about closing up the shop the night before. Later on that day, he was taken to the police station for further questioning. I suggested that I would not be present during this questioning and the police officers agreed. In the meantime, I had the opportunity to make some notes and browse through a copy of the Dutch police's magazine. An article about community police work drew my attention. Its title was 'Community police officers' work in freefall'. It was a review of an ethnographic study of police work, and it described how little community police officers and emergency police officers communicate and cooperate with each other. Later on, I ordered the book and read about this in more detail (Stol et al. 2004, p. 143): During the 343 hours on the street with emergency police officers we observed once that they were supported by area-bound [community] police officers. During the 268 hours on the street with area-bound [community] police officers, we observed once that they were supported by emergency police officers. Furthermore, the article suggested that the work of community police officers is looked down upon within the police organization. This strengthened my sympathy for area-bound police work and the work of community police officers. Their work appealed to me; their attempts to communicate with people and to prevent crime. I felt bad that much of their work is undervalued and less visible, that it requires commitment over a longer period of time, and that the results are hard to measure. I felt happy with the ambition of attempting to support them in their work by creating a telecom application. 102 I liked the idea of drawing attention to and stimulating slow or soft aspects of police work such as prevention and care, which is associated with the work of community police officers, as an alternative to the dominant image of the police's fast or hard functions, such as enforcement and emergency relief, which are associated with the work of emergency police officers. This made me think of the practice of 'deconstruction', which aims to uncover texts/readings/practices that are currently marginalized and propose suggestions for alternative texts/readings/practices. Making sketches and recycling ideas Based on our interactions with police officers so far, Mandy, Dirk and I made sketches for a telecom application, which we gave the name 'PolicePointer'. This name refers to its primary function: to provides a policy officer with pointers for contacting certain other officers who may have useful implicit knowledge that could help in the current task. This is intended to improve communication and cooperation between police officers and to improve police work in general. We envisioned that this application would run on a PDA or smart phone. At this stage of development we focused on how a user would interact with the application, and we made some first interaction design sketches – see Figure 11. We would think about the underlying software later on. Figure 11: Sketches for the PolicePointer The idea behind a we-centric telecom application is that it is contextaware and adaptive. It adapts the content of the application based on 103 users' contexts. Triggered by a specific report, the PolicePointer would search the police-report database and identify police officers who had worked on similar reports in the past. It would check the rosters of these police officers and their current 'presence' status to assess their availability for communication, and it would then create a list of police officers likely to have implicit knowledge about the specific report and present their current availability status. In this design process, we re-used several ideas from a forerunner project in the Freeband Impulse programme, in which several projectteam members had also worked. The forerunner project involved developing and evaluating an application designed to help people communicate more efficiently and effectively. If a person wishes to contact a colleague, she can view parts of the colleague's calendars on her PDA and take this information into account when deciding when and how to contact this colleague. She can decide, for example, to call the colleague now or later, or send an e-mail or instant message (De Poot et al. 2004). Such re-use of ideas is encouraged by project managers and is appreciated by steering and evaluation committees. However, looking critically at this form of re-use, I could argue that foregrounding our own ideas from previous projects may push the police officers' ideas to the background – which would run counter to the ambition of human-centred design. After making the sketches, we wished to conduct a workshop in order to discuss them with police officers and learn how they evaluate our ideas for the PolicePointer. The next workshop was almost ten months later (workshop 2 was in October 2004 and workshop 3 was in August 2005). The long interval between the workshops was due to organizational issues, not to the fact that it took a long time to make the sketches. First, there was a technical issue. The PolicePointer application has to tap into police reports databases in order to search for matching reports and identify potentially relevant police officers. This prompted many discussions about technical and political difficulties, especially about security and privacy risks. Finally, it was decided that we would build a copy of a police reports database for our experiments, with some of its content altered or hidden, instead of connecting to the operational database. Furthermore, it took some time to settle additional contracts about confidentiality, cooperation and intellectual property between different participating organizations, and it took some time for the police to screen project-team members who were going to work on 104 the technology. Second, there was a reorganization within the police force and, as a result, the composition of the project-team changed. This also delayed the process. Albert retired and was replaced by Trevor. This also meant that the idea of improving the work of community police officers lost an advocate in the project. Trevor wished to work on another concept, which tended to divert resources from the work on the PolicePointer. Evaluating and developing the concept (workshop 3) We organized two more workshops with police officers (in a city in the east of the Netherlands) so that they could assess our ideas for the PolicePointer. Dirk, Mandy and I organized these workshops together with Harold. The goal of workshop 3 (August 2005) was to evaluate the relevance of the problem on which we were focusing – insufficient cooperation and communication between community police officers and emergency police officers – and our proposed solution: the PolicePointer, for facilitating knowledge-sharing and cooperation between community police officers and emergency police officers, which would improve communication and cooperation and police work in general. Four community police officers participated in the workshop, along with three people involved in the development and evaluation of a mobile information application, Mobile Police Info, and including one person from the emergency room. This application runs on a PDA or smart phone and enables a police officer to access several police databases anywhere and at any time, rather than having to go to the police station to look up the information or call the police station – usually the emergency room – and ask someone to find the information. The police region in which we held the workshop was one of the pilot regions for Mobile Police Info and, somewhere in the process of inviting participants, this topic became associated with the workshop. Incidentally, a few hours before the workshop began, many police officers were disconnected from the application – some explained that the management had decided to stop using it because of the costs involved. As a result, people in the workshop tended to want to talk about the application: about the frustration of suddenly being disconnected from it, about its many disadvantages, and about why they still wanted to use it. 105 During this workshop, we did some role-play (Iacucci and Kuutti 2002) in order to assess the added value of the PolicePointer in work situations. We invited police officers to act out three roles: community police officer William on the street, emergency police officer Nick on the street somewhere else, and Martin in the emergency room. We gave a small card to the police officer who was playing the role of the person in the emergency room and asked the three of them to deal with the situation as they currently would (without the PolicePointer): Card for the person in the emergency room: At 9.00 a.m. the emergency room receives a report: Burglary at Vinkenstreet 34. The burglars used a ladder to enter the apartment via the back garden. In the role-play, the person in the emergency room called emergency police officer Nick, who went to the scene. We then presented the same situation, this time with something like the PolicePointer. We could not actually use PolicePointer, of course, but we gave the officers empty boxes, which functioned as a 'magic thing' (Iacucci and Kuutti 2002) with which participants can do whatever they imagine during the role-play. The aim of this approach is to stimulate creativity based on the participants' ideas, needs and preferences, unhindered by an actual prototype or product. For this situation (with PolicePointer), we gave a similar card to the person in the emergency room. The police officers on the streets were also given these cards: Card for emergency police officer Nick: You receive this suggestion from the PolicePointer: Report: Burglary at Vinkenstreet 34. William knows more about this (click to contact) Card for community police officer William: You receive this notification from the PolicePointer: Report: Burglary at Vinkenstreet 34. Nick is currently on this case (click to contact) In this situation, emergency police officer Nick can contact William to ask him for advice or help, or William can contact Nick to offer his advice or help. The police officers recognized this problem and appreciated this solution. They spoke about the added value of 106 sharing their implicit knowledge with fellow emergency police officers: There is a lot of information in my head. [It would be] very handy for emergency police officers to know that if person X causes trouble [in a case of domestic violence], you can ask his neighbour on the left to help calm him down. But never involve the neighbour on the right, because he will only make matters worse. In many cases, only one person out of a group of ten is the real troublemaker. If you can identify that person and address him by name, you will have an effect. However, the officers questioned whether PolicePointer would be able to compile a list of people who are indeed relevant, and whether police officers would indeed contact each other on the basis of such a suggestion. They pointed to two potential shortcomings: the list may include people whom you already know and already want to call for advice or help, or it may include people whom you do not know and the suggestion may fail to make clear the added value of calling them for advice or help. We took this as advice to pay attention to the software behind the PolicePointer and to try to program it to compile a list of people who are indeed relevant and presents reasons for contacting them that are indeed useful. The idea of sending a notification to community police officer William – in addition to sending a suggestion to emergency police officer Nick – introduced the idea that communication can be initiated from both sides. Nick can decide to contact William, or William can decide to contact Nick. The community police officers valued this idea and told us that emergency police officers are gogetters and may be reluctant to 'waste time' contacting other people while they are rushing to an emergency. They appreciated the idea that the PolicePointer would also enable community police officers to proactively offer their knowledge to emergency police officers: [An emergency police officer] would first speak to the group and only later contact the community police officer. That is more practical. 107 Community police officers are proactive, they listen to all broadcast messages over the radio phone and initiate communication with their colleagues [to help them]. Based on this, we added reciprocity to the PolicePointer. When Nick receives a suggestion to call William and ask for his knowledge, William also receives a notification of that suggestion, so that William can call Nick and share his knowledge. Evaluating and developing the concept (workshop 4) Workshop 3 lacked the perspective of emergency police officers, because only community police officers participated (although some community police officers also worked occasionally within emergency response). In order to learn more about both perspectives, we invited both kinds of police officers to workshop 4 (November 2005). Tree community police officers, three emergency police officers and one employee from the emergency room participated in the workshop. One community police officer and the colleague from the emergency room also participated in workshop 3. In workshop 4, the emergency police officers explained that they have their own kind of knowledge that may be valuable to community police officers. Emergency police officers make rounds in the evenings and at night, by way of surveillance – not only when they are rushing to or from an emergency. Furthermore, they cover an area larger than one neighbourhood, which is typically a community police officer's scope. Emergency police officers see a great deal. When, for example, a community police officer has an arrangement with specific people not to hang around in a specific place, or with a café owner to close after a specific time, an emergency police officer can check, while on his rounds, whether the people in question are complying with these arrangements. It would even be interesting to know if 'nothing happened'. However, many such observations are not entered in databases and remain implicit knowledge of emergency police officers. The observation that emergency police officers have implicit knowledge that may be valuable for community police officers led us to the idea that PolicePointer should facilitate communication and sharing of knowledge between both types of police officer. 108 For a long time we had tried to focus on communication and on developing a telecommunication application, and to stay away from police information systems and the idea of developing an information application. Nevertheless, we learned more about the police reports database during workshops 3 and 4, and in particular about two types of annotation that police officers can make in the database: 'appointments on location' (AoL) and 'appointments on person' (AoP). Police officers use these annotations to indicate that a certain location or person needs special attention, for example if a person is known to be using a firearm. Because we were looking for ways to make our telecom application work, and because it became clear that our application would have to search the police report database in order to find matches, identify relevant police officers and formulate suggestions, we now became interested in the database. Now that it could help us forward with developing 'our' application, we became interested in what they wanted to say about 'their' database. The software for the PolicePointer would search for instances of AoL or AoP that have something in common with the current report, identify police officers who where involved in the AoL or AoP annotations, and suggest that they are likely to be relevant for the current report. But there were other topics to which we neglected to pay attention. When we had lunch with the police officers who attended workshop 4, they talked heatedly about their uniform trousers. They currently wear cotton trousers, but the management wants them to wear woollen trousers. They were angry about this. 'We don't want woollen trousers', they said. They explained how they have to kneel down in the mud and how easily they get blood or other stains on their trousers. They are responsible for their own uniforms. They can easily wash their cotton trousers, but the woollen trousers have to be taken to the dry cleaner's and have to have a crease in them. Moreover, the cotton trousers have a handy place for their gloves, but the woollen trousers do not. Listening to these stories, we might have learned something about what it means for them to work as a police officer, what their equipment means for their work and what it means for them to have the management impose some innovation on them – be it woollen trousers or PolicePointer. I told this story several times, for example to colleagues, and people then asked me what we could have learned by listening to what they said about their cotton or woollen trousers. We will never know, of course, what we could have learned or how it could have influenced our project or the application 109 we were developing. But it bothers me. I have the feeling that we missed something, but I don't know what it is. As an illustration of the police officers' perspective on their new uniforms, Mandy gave me a clipping from a national newspaper article, entitled 'Shopping list of complaints about police uniform' (Algemeen Dagblad, 17 May 2008). In a survey of 1,750 police officers, they complained the fact that the new uniform do not fit well, that the material becomes dirty and wet too easily, and that it does not have enough handy pockets. Creating and evaluating a prototype Based on the workshops, Mandy, Dirk and I, together with Henk, who works at a company that develops, manufactures and sells telecom equipment and who is responsible for technical development of the prototype (in Work Package 3), developed requirements for a prototype of the PolicePointer. We developed the following use case to illustrate the PolicePointer's putative added value and to guide further development: When an incident is reported, a report is generated and assigned to one police officer (A). This police officer then goes to the incident, request or emergency. [This is the current process; the next two steps are added with the PolicePointer.] The PolicePointer searches the police reports database for police officers who may have implicit knowledge about this specific report: it searches for similar reports and similar 'appointments on location' or 'appointments on person' and finds one or more police officers who may be relevant for the current report. Furthermore, the system checks the rosters of the police officers found, as well as their current availability for communication. Based on this relevance and availability, PolicePointer calculates a 'utility' for the police officers. The PolicePointer then sends a list of supposedly useful police officers (B) to the police officer (A) who was assigned to that report, including a reason for contact these officers. The list also gives their contact details, availability and an indication of their 'utility'. Simultaneously, the PolicePointer sends similar messages 110 to the 'useful' officers (B), including the name and contact details of the police officer (A) assigned to the report. Figure 12: A prototype of the PolicePointer, running on a smart phone After this, a prototype was built by other project-team members – see Figure 12. We then organized a small two-day field trial with five police officers in order to evaluate the PolicePointer concept (July 2006). During the trial the officers used a smart phone with the PolicePointer application running on it. The prototype was only partly functional. Earlier in the project it was decided that we could not tap into the police reports database and that we would build a copy of the database, but this proved too difficult and we therefore chose to simulate this functionality manually. During the trial, Harold was in the emergency room, listening to incoming reports, and for each report he searched manually through the police report database for relevant police officers, then looked up their availability and contact details and then entered what he had found in PolicePointer. The PolicePointer system then sent a suggestion to the police officer assigned to this task, and notifications of the suggestion to the potentially relevant police officers. Incidentally, very few incidents occurred on the Monday and Tuesday of the field trial. The weekend before had been hectic, with a large music festival, drunk people and stabbings. Because of the small number of incidents, there were also only few situations in which the Incident ('Overlast door jongeren'); Priority ('Prio 1'); Location ('Wilhelminapark'); and Time ('21.00 uur'). Potentially relevant police officers, with indications of their supposed 'utility' (bar graph). Suggested police officer ('Jos van Bergem'); Reason why ('Wijkzorg'); and Communication (e.g. 'Bel nu') 111 PolicePointer was put to work. Nevertheless, the participating police officers were positive about the PolicePointer, especially when they received suggestions for 'unstructured' situations – situations for which there are no standard procedures and in which they must improvise – and when they received suggestions while in an area in which they did not yet know many colleagues. Interestingly – and rather logically – they perceived added value in receiving suggestions to communicate with others who are geographically further away. In cases where they were geographically close to each other, they would usually just go to the situation to offer help. But in cases where they cannot get there quickly, the PolicePointer provides them with a tool to communicate and share knowledge over a distance. After this trial, a Master's student performed a further evaluation of the PolicePointer (Swager 2006). She studied the contents of reports and concluded that one-quarter of the reports relates to 'unstructured' situations which have some form of 'history' – situations that are related to situations about which other police officers have already entered reports in the database. This would mean that the PolicePointer can potentially be of use for one-quarter of the reports. The student also interviewed police officers about how they evaluated the PolicePointer. They saw its potential added value, but found it difficult to imagine that they would actually call the fellow officer while hurrying to the incident. One reason for this is that the incidents for which PolicePointer is likely to have added value occur most often in the evening or at night, when community police officers – who have a great deal of implicit knowledge and would often be identified as relevant – are not at work. While we discussed the findings from the field trial, we discussed how the PolicePointer might or might not fit within the police organization's culture and politics. Interestingly, this was one of the rare occasions on which we explicitly discussed such topics, and that we noted our ideas on culture and politics explicitly in a memo. We concluded that the PolicePointer would match the police's ambition to enhance cooperation between different police officers and between different police functions. At the same time, we concluded that it would not match very well with the police's tendency to organize work in a top-down manner and to make individual police officers responsible for their individual tasks. In retrospect, it occurs to me 112 that, for me, designing the PolicePointer was not about developing technology, but about developing ideas for organizing police work in a different way than is currently the case. Reflecting on the project In early 2006 I wrote a conference paper (Steen 2006b) about our project so far. I described how each interaction with police officers influenced our decision-making and how this resulted in a gradual shift in the scope of the project. I also wrote about how we focused on developing and evaluating a telecom service and, as a consequence, unintentionally missed several opportunities to learn about police work. I suggested that an understanding of the socio-cultural and political aspects of police work could have helped us to understand police work and to better position our ideas and design for the PolicePointer in relation to the context of a police organization. I organized a project meeting (May 2006) together with Mandy, Dirk and Harold to reflect together on the project and to hear their experiences and views. I sent them a draft of my paper and invited them to read it before the meeting. Harold started the discussion. He took his time to explain how he looks back on the project, gesturing to support his words: Harold: We tried to search for an application together with the user. That is of course very broad. Searching for an application. What you normally do, together with a user, then you already have a concept. [...] Now we are working in an unknown application domain, the police. We don't know how that works. I know only partially, because we [the organization where I work] are part of the police organization, but we are not police officers. [...] My overall finding is that user participation, or involvement, you must do at a certain moment, when you have yourself already an idea about a tool that might support the police. Our ideas developed during the process. So you cannot say at the outset where we are heading. But you ask at the start: Where are we going? So you go searching continuously. Where do you go to? Meanwhile, you learn, during the process. Which makes you meander. Nothing wrong with that, but it is timeconsuming. Your view will never be complete, I think. Because the piece you want to bite into, the police organization, is too large, too diverse, and has too many perspectives. People doing 113 the actual work, middle management, senior management, politicians. And even amongst the front-line workers there are all sorts of different roles, influences of experience, of age, of geographical regions. So, there are two main factors. Searching for an application from scratch is a very broad effort. And I do not know whether it is practical to do that in consultation with users. Secondly, at the start not knowing where you will eventually end. The search is unfocused. And I don't know whether it is useful to do that together with users. A lot of searching. And I don't know whether our method for searching was a practical one. Harold thought that we should have involved users at a later stage. He found our process inefficient. His suggestion was to first study the police organization, its culture and processes, then identify a problem and develop a concept for that, and only then involve users for evaluation and further development. I went along with his recommendation to study police culture more effectively. Then Mandy joined the discussion. She talked about how she had wished to have much more contact with the police officers, early on and throughout the project: Mandy: But I did have the idea that we would have wanted that [more interaction with police officers]. I think we said amongst ourselves: this is not going well. We want to have more contact with these users. [...] For example, we wanted to hold the workshop [workshop 3] much earlier. Now it looks as if we were deliberately developing the PolicePointer without ever thinking about users. But in fact we had wanted to evaluate the PolicePointer concept much earlier [with police officers]. Mandy is serious about her wish to involve users early on and throughout a project, and she feels disappointed about how little contact we had with police officers. She tried to organize additional interactions, but it was difficult to obtain cooperation within the police. She believed that we could have learned a lot from additional observation or workshops. Both Mandy and I advocated involving users early on and throughout the project. 114 I can imagine that Harold sometimes felt torn between two roles. Sometimes the project-team members associated him with the police and his task of organizing interactions with police officers. On other occasions, the police officers associated him with the project and he had to convince or persuade them to cooperate with us. I can imagine the difficulty of combining these roles. Furthermore, user involvement is somewhat controversial within Harold's organization, in which product development would typically be based on technology or procedures, and would typically be managed in a topdown manner – rather than being based on bottom-up workshops with users. Consequently, Harold may have found himself caught between my ideas for user involvement, which I tried to infuse into the project, and the context of his work. Harold also explained that organizing cooperation with police officers was difficult because he was acting within the context of interacting forces; there are all manner of different concerns within the police and priorities change over time – he had only a limited influence. Later on in the meeting, Harold suggested that we should have talked with managers rather than front-line workers about future products: 'Concepts and visions of the future [about the role of the police] are topics for managers and for policy–makers, and less so for users [police officers]'. I tend to both agree and disagree with this suggestion. Managers hold budgets for product development and policy-makers are important stakeholders, and we should therefore have talked with them. However, people higher up in the organization would typically know less about what happens on the shop-floor, and the idea of human-centred design is to give people from the shop-floor a voice or a role. During a discussion about user involvement, I made a statement about how little time we spent interacting face-to-face with police officers: Me: I think that I estimated this at two per cent, if you calculate one day of observation and one day of talking about it. Dirk: Yes. Harold: Hhhm. [overlapping] / Hhhm. Me: / Then I thought, is that a lot or is that little? Mandy: I found it really, er, very, very little Me: Too little, hey? 115 Dirk: Little, yes. Mandy explained that in many of her other projects the amount of time spent on focus groups or interviews with users or customers can amount to one-third of the budget. Harold remarked: Harold: A greyish number, two per cent. There may have been little direct contact, but we did read books, for example by Wouter Stol [2004]. I provided many documents: the police works this way, not that way. This is all user-related information. Me: That is right, totally true. That is / Harold: / significantly more than that two per cent. In retrospect, I cannot say for sure why I made the remark about two per cent and I do not feel happy about having made it. Perhaps I wanted to provoke a reaction. But then it would have been better to ask open questions. Or perhaps I made the statement to advocate more user involvement. But then it would have been to remark explicitly that I think we should have had more interactions with users. It is also possible that I made the remark on a content-related level to stay away from a discussion about the process. Perhaps I was afraid of having to discuss my role as a coordinator and my area of responsibility for organizing proper or more user involvement within our project. During the meeting, the atmosphere was sometimes tense. At such moments, Dirk often made contributions that lightened the mood. His remarks often hit the nail on the head. Dirk is used to working in research projects in which team members follow their own agenda or pursue their own pet topic. 'Everyone, of course, has their own ideas that they want to introduce', he remarked. He positions himself as being primarily interested in conducting research – and if this research delivers results that help to solve a problem, that is fine as well. Here is an example of Dirk's remarks: Harold: [argues that in the project, and in the research programme of which it is part, there is the ambition to develop mobile telecom technologies, and this idea influenced our project] At a certain point, you move on from the idea and go in a certain direction. Dirk: There has to be a communication problem. [people laughing] 116 Harold: Yes. Dirk: And we will do our best to find that. [people laughing] [...] Me: There was really a communication problem. [people laughing] Mandy: Fortunately. Me: It was also not very hard to find. Harold: That's true ... Dirk: But it's difficult to be totally unbiased ... approach it ... Me: I would like to hear some more on that, Dirk. You've already mentioned a couple of times that it is difficult to be 'totally unbiased'. Dirk: Yes, because, er, especially as a researcher, you have all kinds of specific questions you would like to solve, and you hope that there are also [laughs] problems for them. And you have certain ideas and aspects from your experience that you would like to apply and re-use, or research. Dirk brings some humour to the meeting – and possibly some irony. Mandy and I pick up on this and discuss the mismatch between us creating a telecom application for a future situation versus the police officers with their immediate problems: Mandy: Yes, it is very ambiguous because, as we said: Yes, it is a research project, so we are not really here to come up with a solution for you. [people laughing] Me: We are not going to talk about your problems and we are not going to provide you with a solution. Mandy: No [laughs] Me: But we are going to hold a two-hour workshop with you. Mandy: And you must be very cooperative for those two hours. That is very ambiguous. I think that Dirk's remarks about our project make us laugh because we feel that our attempts to cooperate with police officers were indeed ambiguous. Creating a telecom application for police officers seemed to be the primary concern, whereas the police officers, their work and what they wanted to tell us, seemed to be a secondary concern. Towards the end of the meeting, Dirk came back to what Harold said at the start: that it would have been better first to study the police, then create a concept or prototype and only then discuss it with 117 police officers. Dirk seemed to support this idea: 'People wish to visualize it for themselves'. He argued that people wish to discuss only things that have already been visualized. Looking back, however, I wonder which people are in favour of this visualization. Do the police officers wish to discuss a finished product that has been designed by us for them? Or is it our own wish first to visualize our idea until it looks like a product, and only then discuss it with police officers? Summary In the course of this project, each interaction with police officers had a degree of influence on our decision-making and we gradually adapted the scope of our project. As a result, our ideas for PolicePointer gradually changed and developed – see Table 2. The idea of helping community police officers to communicate and cooperate with people outside the police changed – through several steps – into the goal of helping community police officers and emergency police officers to communicate and cooperate with each other. Our focus on communication and on telecom, and our neglect of information processes and databases, shifted to making a telecom application designed to promote cooperation between police officers by making suggestions to communicate with each other, based on information stored in the police reports database. It is considered good practice in human-centred design to allow users to influence the design process. This is different from what would be considered good practice in, for example, a product development project, where good practice would be defined as keeping to the initial brief. Table 2: Chronology of some of the project activities and ideas for the PolicePointer Some of the project activities Some of the ideas for the PolicePointer Before Promote communication and cooperation via a we-centric telecom application April 2004 Albert's idea, on behalf of police officers Help community police officers to communicate and cooperate with others May 2004 June 2004 July 2004 Workshop 1, with community police officers Help community police officers to communicate and cooperate with their network partners Aug 2004 Rapid ethnography of police officers' work Help police officers to communicate and cooperate with their network partners 118 Sep 2004 Oct 2004 Workshop 2, with (community and some emergency) police officers Help community police officers to share their knowledge with emergency police officers Nov 2004 Make sketches of the PolicePointer Dec 2004 Jan 2005 Delay: technology/security and reorganization/politics Feb 2005 Mar 2005 April 2005 May 2005 June 2005 July 2005 Aug 2005 Workshop 3, mainly with community police officers Encourage emergency police officers to ask for and use community police officers' knowledge Sep 2005 Oct 2005 Nov 2005 Workshop 4, with community and emergency police officers Encourage community police officers and emergency police officers to share knowledge with each other Dec 2005 Jan 2006 Delay: technology/implementation Feb 2006 Mar 2006 April 2006 May 2006 June 2006 July 2006 Field trial with (community and some emergency) police officers Added value in 'unstructured' situations or when one does not know colleagues in the area However, I could also say that we stayed within our comfort zones by staying within the scope of our project, and that we unintentionally missed several opportunities to learn about police work – about what it means to work as a police officer in a police organization. Our agenda was to develop and evaluate a we-centric telecom application, which gave us a blinkered view. We invited police officers to talk about their work and their problems and to discuss our ideas for a solution. We tried to empathize with them, but not too much. We neglected several socio-cultural and political aspects of police work. In the first workshop, we decided to focus on a topic that was comfortably close to our project's scope. We created storylines that focused on problems and solutions that we already had in our minds. We neglected many of the police officers' stories, 119 such as those about their wish to have laptops in their cars, about Mobile Police Info and other information systems, and about their managers wanting them to wear woollen trousers. We focused our attention on topics that we thought were of direct interest to us and, consequently, missed topics that were relevant for police officers or topics that might have become relevant for us in the future – something which, obviously, we cannot predict. Furthermore, we allowed the police officers to participate, but not too much. When we invited them for workshops we found it hard to organize joint creativity. We prepared an agenda for a workshop and we mostly kept to that agenda. This provided the police officers with only a limited number of ways to participate, which meant that they participated less actively and less creatively than is possible in codesign. Looking at our research and design efforts, I see a mixture of approaches. I see some elements from participatory design and codesign, in that we invited police officers to talk about their current situation and problems, and discuss their and our ideas for alternative or future practices and the PolicePointer. There were elements from applied ethnography and empathic design, in that we accompanied police officers during their working day. We attempted to understand their work from their perspective, and to empathize with them and their work. There was something of a lead user approach, because the participating police officers were selected on the basis of their relative innovative approach to ICT products or services and their creative attitude. For example, one police officer in workshop 3 had developed a type of personal report database for personal use on his own PDA – a form of creativity that is officially forbidden but sometimes tolerated. Overall, cooperation between project-team members was satisfactory. However, when we reflected on the project towards the end of it, it became clear that we had different views on how and when to involve users. For example, Harold thought we should not have involved users until we had produced something to show them, whereas Mandy thought that it would have been better to have more interactions with police officers, right from the start of the project and during its iterative phases of research, design and evaluation. 120 121 5. Designing with/for informal carers This chapter is about how we designed a telecom application with and for a specific group of informal carers. We focused on people who provide informal care to a person with dementia who lives at home, not in an institution. It is similar to the previous chapter, but also different. There were differences in terms of the users and the way in which we interacted with them. The police officers participated in their professional capacity, whereas the informal carers participated in a personal capacity. Furthermore, the composition of the project-team was different. The team that worked on the telecom application for police officers was relatively small and homogeneous, whereas the team that worked on the telecom application for informal carers was relatively large and heterogeneous. My role was also different. I was actively involved in organizing the various interactions with the police officers, but I did not meet any of the informal carers who were involved in the project. This was not intentional, but happened accidentally; I was unavailable for the first observation or interviews and others were able to do these, and we continued this pattern. The differences in the project, in the composition of the project-team and in my own role allowed me to write two accounts with a different focus. In the police project, I was able to observe what happened between people in the team and the police officers, for example during workshops. In the informal care project, I was able to observe what happened between people within the project-team, for example during meetings (but not interactions with informal carers). As a result, the previous chapter focused on project-team members' interactions with users and the current chapter focuses on interactions between project-team members. 122 As in the previous chapter, my goal is to provide an account of what we did in this project, including my own role, and not to conduct an evaluation in terms of good or bad. Some readers will see examples of practising HCD well or badly. In that case, I would remark that, in my view, both the project-team members and the informal carers gave of their best, given their respective roles and contexts. If one wishes to criticize the project, I would like to be held accountable for my role in it. Furthermore, the people who played key roles in the process described in this chapter – Pauline, Rachel and Martin – read draft versions of this chapter, provided feedback, and approved the description. In general, my story is about how we interacted with informal carers and studied their needs and preferences. It is considered good practice in HCD to gather knowledge from and about users. Furthermore, it is about project-team members' difficulties in cooperating with each other and making progress. I will argue that these difficulties relate, among other things, to the differences in backgrounds and approaches of the team members and to the differing interests of the various organizations involved in the project. Starting with an idea Catherine and Edith work at MNO, a university hospital. They have many years of experience in studying and working with people with dementia and informal carers. They have developed prize-winning intervention programmes, such as 'meeting centers' (Dröes et al. 2004a): facilities, for example in community centres, designed to provide support for people with dementia and their informal carers. In these 'meeting centers', people with dementia can visit the day club several times a week and participate in activities such as gymnastic exercises or reminiscence therapy. This helps them to maintain social contacts. 'Meeting centers' also provide support for informal carers. They can meet their peers and professionals to talk about their problems and solutions, for example in discussion groups. Catherine and Edith explained that their aim is to improve the 'quality of life' of people who suffer from dementia and live at home rather than in an institution, and that of the people who are their primary informal carer. Often the primary informal carer is the husband or wife, or son or daughter, of the person suffering from dementia. Catherine and Edith advocated focusing on providing help 123 and support for informal carers because improving the informal carers' situation would, indirectly, also benefit the people with dementia, thereby improving the quality of life for both. They call this a 'systems approach'. At the start of the project (January 2005), Catherine and Edith already had ideas for both a problem to focus upon and a solution for that problem. The problem on which they proposed to focus was that a large number of organizations provide a wide range of care and related services, but the range is fragmented and not transparent. As a consequence, clients and referrers experience difficulties finding the services they need and are entitled to, so that the available services are not utilized to the full. Furthermore, finding out which services one is entitled to, obtaining permission to receive them, and actually receiving them can be a very cumbersome process. The solution that Catherine and Edith envisioned was a 'Dynamic Interactive Social Chart for DEMentia care' (DEM-DISC) (Dröes et al. 2005). They envisioned that informal carers could use DEM-DISC to obtain adequate, personalized information and advice about care and related welfare services in a user-friendly manner. A large number of project-team members were assigned to work on designing and evaluating DEM-DISC. In tandem with this, a smaller project-team was assigned to work on designing and evaluating a we-centric telecom application, for which we later created the name 'WeCare'. Much of the work on WeCare was done by Pauline, Rachel, Annelies and Martin: • Pauline is a colleague of Catherine and Edith at MNO, where the three are responsible for studying the needs of people with dementia and their informal carers, in particular through a largescale survey into the needs of people with dementia and of informal carers. Pauline's background is in social psychology and this project work is part of her PhD. The three of them act as intermediaries between the project and the informal carers and people with dementia. They have a strong sense of commitment to helping to meet these people's needs, and they regard ICT as a means to that end. • Rachel is a colleague of mine at TNO, a research and consultancy organization. Her background is in psychology. Her expertise is in user studies and user experience. During the project, she went on maternity leave twice. In 2005 she was replaced by Julia, and in 2007 by Mandy. Rachel told me that she felt moved on several 124 occasions during her encounters with informal carers. She said that she sometimes felt as if she knows one woman, whom she had interviewed several times, very well and empathizes with her. • Annelies and Martin work at media lab VWX. A large part of Martin's work involves evaluating prototypes developed by others, by interviewing people who use the prototypes during tests. He has, for example, worked on the evaluation of an information system for elderly people in a nursing home. Annelies graduated relatively recently in industrial design engineering. She is enthusiastic and likes to do things in a hands-on way. Compared to Martin, her expertise and role are more oriented towards design and creativity in the early phases of a project. Rachel, Annelies and Martin worked on the design and evaluation of WeCare. Pauline's role was to provide input to the research and design process, based on her findings from the needs study. In various situations she had an advisory role and acted as a spokesperson for informal carers, for example when she provided feedback on the ideas of other project-team member. As in the other project, my role was to coordinate activities related to the design and evaluation of the telecom application. The context of this project is relatively complex because a large number of organizations with different interests were involved, and because responsibilities for various tasks and priorities changed during the project. MNO was responsible for the needs survey, for part of the development of DEM-DISC and for evaluating DEMDISC. Research organization STU was responsible for part of the development of DEM-DISC, and media lab VWX for the user interface design of DEM-DISC. Research organization TNO was responsible for designing and evaluating WeCare. GHI, a company that develops, manufactures and sells telecom equipment, was responsible for the technical development of prototypes of DEMDISC and WeCare. It was often difficult to understand the relationships between tasks, and which person or organization is responsible for which task, and to make handovers from one task to another, for example from user studies to concept design, from concept design to building a prototype. Furthermore, there was an element of competition between the work on DEM-DISC and the work on WeCare, for example for the resources to build the DEM-DISC and WeCare prototypes. 125 A kick-off meeting A kick-off meeting (March 2005) was organized by people from media lab VWX in order to try to create a shared understanding of the problems experienced by people with dementia and their informal carers. During this meeting, a documentary was shown in which the writer/director – who participated in the meeting – had filmed the last years of the life of her mother, who suffered from dementia. This was intended to enable project-team members to connect emotionally with problems relating to dementia and informal care. The film showed how the mother became increasingly demented, how the daughter visited her and took care of her social and emotional needs, for example by reading children's books with her, and how the husband took care of the finances and organizing care and other services. Having seen the film together, people were indeed able to discuss topics later on. For example, Martin and I discussed it several times and what we took from it was that caring for a person with dementia can be seen as involving two rather different tasks: taking care of emotional or social needs, and taking care of financial and organizational matters. This distinction made us think about the different foci of DEM-DISC (providing information to help with organizational or financial matters) and WeCare (providing communication to help with social and emotional needs). A literature study and survey Catherine, Edith and Pauline wished to study the needs of people with dementia and their informal carers in order to obtain a reliable picture of their needs – a picture that would be broad as well as detailed. There was already a tentative overview of problems from the Dutch National Dementia Programme (NDP), and the purpose of conducting a literature study and survey was to investigate these problems further. The literature search into the needs of people with dementia yielded some 275 publications, of which 34 were studied in detail. The literature search into the needs of informal carers yielded some 150 publications, of which 29 were studied in detail (Van der Roest et al. 2007b). For the survey, more than 300 dyads were interviewed – a person with dementia and the primary informal carer – face-to-face, in their homes, between the summer of 2005 and the 126 summer of 2006. A total of 236 people with dementia and 322 informal carers were interviewed (Van der Roest et al. 2007a). In the survey, several standardized questionnaires were used. The subjective needs of people with dementia and their informal carers were studied using the Dutch version of the Camberwell Assessment of Needs for the Elderly (CANE) (Dröes et al. 2004b) which assesses whether people have met needs, unmet needs or no needs regarding twenty-four 'problem areas', namely Accommodation, Household skills, Food, Self-care, Care for someone else, Daytime activities, Memory, Eyesight/hearing (sometimes labelled as Communication), Mobility, Continence, Physical health, Drugs (medicine), Psychotic symptoms, Psychological distress, Information about health and treatment, Deliberate self-harm, Accidental self-harm, Abuse/neglect, Behaviour, Alcohol, Company, Intimate relationships, Money, and Benefits (allowances). Both the person with dementia and the informal carer were asked questions, separately, about these topics. CANE also contains two problem areas for the informal carer only, namely Carer's need for information about health and treatment and Carer's psychological distress. Met needs were reported if adequate care was provided to solve a problem, whereas unmet needs were reported if inadequate, insufficient or no care was provided. In the interviews, the following topics were also surveyed: the informal carer's subjective experience of burden, the severity of the dementia, background characteristics of the informal carer (46 questions, for example about the care they provide, the support they receive, and the social and emotional situation) and background characteristics of the person with dementia (20 questions, for example about the care they receive). The preliminary results of the study were discussed in several project-team meetings. The average age of the interviewees with dementia was 79 years, and the average age of their informal carers was 69 years. Two-thirds of the dyads share one household. About half of the informal carers share their care tasks with nobody. The remainder share their tasks with only one or two other people. The findings were often presented in the form of a table listing the 'most frequently reported (unmet) needs by persons with dementia and their informal carers' – see Table 3. 127 Table 3: Needs of people with dementia and informal carers (preliminary results, April 2006) People with dementia (n=151) Informal carers (n=221) Most frequently reported needs Most frequently reported unmet needs Most frequently reported needs Most frequently reported unmet needs Household skills (66.9%) Memory (12.9%) Household skills (95.5%) Memory (40.5%) Memory (66.7%) Information (11.0%) Memory (92.7%) Daytime activities (17.9%) Money (55.9%) Psychological distress (6.8%) Money (90.5%) Information for informal carer (17.3%) Food (51.7%) Drugs (5.4%) Food (85.0%) Company (12.7%) Physical health (39.2%) Daytime activities (4.7%) Daytime activities (73.9%) Psychological distress of informal carer (12.3%) Daytime activities (32.4%) Company (4.1%) Self care (71.0%) Psychotic symptoms (11.8%) Mobility (31.8%) Sight/Hearing (4.1%) Physical health (63.6%) Psychological distress (11.8%) Communication (29.1%) Intimate relations (3.4%) Mobility (57.1%) Communication (11.4%) Self care (27.3%) Benefits (2.8%) Drugs (48.2%) Continence (11.3%) Drugs (26.5%) Intentional danger (2.7%) Psychic needs of informal carer (46.4%) Information about health and treatment (10.0%) The unmet needs most frequently mentioned by informal carers relate to memory (40.5%), daytime activities (17.9%), their own need for information about dementia and treatment (17.3%), company (12.7%) and their own psychological distress (12.3%). In comparison, people with dementia reported several of these unmet needs less frequently: memory (12.9%), daily activities (4.7%) and company (4.1%). The informal carers seem to suffer more as a result of the memory loss and the lack of daytime activities and company of the person with dementia, than the person with dementia him/herself. This situation reminded me of a picture from a campaign of the Dutch Alzheimer Foundation that featured a photograph of two elderly people embracing each other, with two captions: 'He suffers from dementia' and 'She has it' – see Figure 13. Within the project-team, it was decided to address the need for information about health and treatment with DEM-DISC, which can be thought of primarily as an information application, and to address the social and emotional needs relating to psychological distress, 128 daytime activities and company with WeCare, which can be thought of primarily as a telecom application. The work on DEM-DISC often received more attention and resources, so the people working on WeCare, myself included, were happy that we could relate our work on WeCare to problems that were reported in the survey as existing out-there, and that we could position WeCare relative to DEM-DISC. Figure 13: Photograph of a campaign of the Dutch Alzheimer Foundation (source: Alzheimer Nederland) In retrospect, I realize that I often had a relatively detached position towards the survey and its tables, categories and percentages. This was not my intention, but it happened nevertheless. For example, I did not have to do any coordinating or organizing work for the survey because this was done by Catherine, Edith and Pauline. Interestingly, towards the end of the survey fieldwork (July 2006), Pauline mentioned that many interviewees had cried during the interviews. I wondered why we had never spoken about this before. For example, I had never before asked a question such as: 'Pauline, can you tell us about what happens during the survey interviews?' It is possible that I thought that quantitative research would be a 129 relatively sterile activity. My background is in design, which may have given me a bias towards preferring qualitative methods for inspiring a design process. I regarded a survey as a detached activity and I developed a detached position towards it. Instead, I could have tried to adopt a more open attitude and to ask open questions about the survey, giving Pauline the opportunity to talk about interviewees crying. This could have helped me to think of the survey more in terms of face-to-face interviews with real people and less in terms of tables, categories and percentages. Formulating a problem to address I organized a project meeting in order to develop ideas for a telecom application (July 2005) and to motivate project-team members to work on it. Pauline, Edith, Julia, Martin and I attended the meeting. I invited other project-team members to participate and the invitation was accepted by Sybil and Norah (who coordinated other parts of the project), Gregory and Duncan (who worked on other tasks within the project) and Liam (who participated on an ad-hoc basis). A large part of the meeting was dedicated to presenting and discussing the preliminary survey findings (e.g. Table 3). It took some time to understand the table, its columns and its categories, for example the difference between needs and unmet needs, and the proposal to be concerned with unmet needs rather than with needs (which include met needs). Furthermore, it took time before everyone understood the difference between the needs of people with dementia and their informal carers: Pauline: There are twenty-four domains. Here is a Top 10 of problems [...] People can indicate whether it is an existing problem, that is, something that is currently relevant and for which no extra care or solution is available now. People can also indicate that there is a 'met need', which stands for a problem to which care is applied, and the problem is more or less solved. But people can also indicate that there are no problems. Me: Pauline, if an informal carer says that daily activities are a problem. Does that informal carer than mean [overlapping] / Pauline: / No, it is / Me: / So the problem is of the person with dementia / 130 Pauline: / of the person with dementia. Me: And you ask it from two perspectives. Pauline: Yes. Here [pointing to the two columns on the left] is the perspective of the person with dementia. And of the informal carer [pointing to the two columns on the right], also of the situation of the person with dementia. Many needs are the result of the condition of the person with dementia and they are studied from two perspectives: that of the people with dementia and that of the informal carers. People with dementia reported on the needs they themselves experienced, and informal carer reported on the needs of the people with dementia and on their own need for information and their own psychological distress. Furthermore, there was some confusion about the definition of several 'problem areas'. For example, people with technology backgrounds made associations tangential to the intended definition: they associated Communication needs (later labelled as Eyesight/Hearing) with telecommunication and with problems using a (mobile) telephone or a computer with e-mail, and they associated Mobility needs (relating to physical mobility, moving around and travelling) with problems using (mobile) ICT applications while moving around or travelling. I wished to improve progress in the work on the telecom application and to that end I wanted to identify and formulate a specific problem on which to focus; a problem that we could solve with a telecom application. I encouraged people in the meeting to draw some sort of conclusion – as if this were more important than reaching a shared understanding of the complexity and variety of problems. At the end of the meeting, I invited the participants to summarize our discussion and to formulate a problem on which to focus: Edith: Well, I think the problem is that the informal carer worries about the daily activities of the person with dementia on days that s/he has no day care. And about the effects of a lack of structure on the days that the person with dementia is lonely at home ... [pausing] Me: The informal carer worries about the ... Gregory: Daily activities. Me: Daily activities of the person with dementia ... Norah: And? 131 Martin: The lack of structure and activation. Me: Structure and activation. Gregory: Lack of structure and activation on those days ... ... Me: Well, very good. Anyone want to add something? A nuance, or a... If not, then we actually have a / Norah: / Concrete, I think. Martin: Only, I think it is a problem statement / Others: / Yes. Martin: If we move down the list [of Top 10 of most frequently reported unmet needs], in a similar way to the way in which we arrived at this statement. I am happy with that. That we will then encounter other things too and arrive at other topics / Others: / Yes. We reached some sort of conclusion: to focus on the informal carer's problems when the person with dementia – often his or her partner – has little structure or few activities during the day and requires constant attention from the informal carer. Martin was content with this problem statement for the moment, but he expected a further similar discussion on other topics. Additional observations and interviews For Martin and Julia, the topics of dementia and informal care were relatively new. They wanted to conduct additional observations and interviews in order to gain a personal understanding of the lives and needs of people who provide informal care to people with dementia – in addition to the knowledge that Catherine, Edith and Pauline had generated in the literature study and the survey. To that end, they conducted four observation sessions at a meeting center, an Alzheimer Café where people with dementia and their informal carers met, and at a discussion group where informal carers exchanged experiences (between May and August 2005). They also conducted two individual interviews with informal carers and a group interview with three informal carers. They made reports (2 to 4 pages each) of the observations and interviews, distributed these to other project-team members and talked about these at various project-team meetings. One thing they learned was how a primary informal carer – often the wife or husband of the person with dementia – feels responsible for providing all the care and managing all housework, which can be very demanding, both physically and emotionally. Informal carers 132 often feel that they have to do everything alone because no-one else offers help. Or because they feel responsible and consider it their duty to provide all the care themselves, so they do not ask others for help. Rachel remarked that she thought that, in particular, older women who care for their husband feel that it is their duty to give care. This typically leaves informal carers with little time for themselves. Pauline and Edith remarked that these findings are in line with their previous experiences, with the literature, and with the survey results. Furthermore, they remarked that people – referring to many of the project-team members – who have never dealt with people with dementia tend to focus on the person with dementia. They saw this tendency, for example, in the people who watched the documentary at the kick-off meeting. Later on, we will see this tendency when, in a creative session, people developed ideas for applications which are intended primarily to help people with dementia. Conversely, Pauline and Edith advocated focusing on the needs of the informal carers. They argued that providing informal care can be very demanding, that the condition of people with dementia only gets worse, and that informal carers are at serious risk of burn-out. And if the informal carer burns-out and no-one else can provide care, the person with dementia has to be admitted to a nursing home, and this often makes things worse. Furthermore, there is a national policy to help people with dementia to live at home for as long as possible (rather than in a nursing home or institution) and supporting the informal carers can help achieve this. Making design decisions and sketches Together with several fellow project-team members, I wrote a conference paper on designing we-centric telecom applications (Steen et al. 2005). We wrote about choosing to focus on a 'range of emotional or social problems related to the role and task of an informal carer', which can be understood as an attempt to position our work on WeCare. Furthermore, we decided to choose informal carers as the primary users of our telecom application, rather than people with dementia. I influenced this decision-making and was satisfied with it. Designing a telecom application for an informal carer, often an elderly person, would be challenging enough, whereas designing a telecom application for a person with dementia could 133 very well prove to be too difficult, for example because they suffer from diminishing cognitive capabilities. At around this time, Martin and Rachel, together with Dirk and Mandy from the police project, made sketches for a telecom application for informal carers, partly based on the ideas for the telecom application for police officers that is described in the previous chapter. The idea was developed to give an informal carer a mobile device, for example a smart phone, and present a list of people who could help the informal carer, for example by offering to take over a care task or by providing social or emotional support. Further defining a problem and a solution A next project meeting was organized (September 2005) to discuss the progress of the work on the telecom application. A relatively large group attended the meeting: Pauline, Edith, Rachel, Annelies and me, and also researchers Yvette, Karin, Dirk, Barry and Pim (who worked in the FRUX project but on other tasks). The group of people at the September meeting was different from the group of people at the July meeting. Only Pauline, Edith and I participated in both meetings. Julia left the project after the July meeting (she had replaced Rachel temporarily). Annelies joined the project and the September meeting was her first. Furthermore, Sybil, Norah, Gregory, Duncan and Liam participated on an ad-hoc basis at the July meeting, and Yvette, Karin, Dirk, Barry and Pim participated on an ad-hoc basis at the September meeting. Since only three people participated in both meetings, it was hard to create or maintain a shared understanding and make progress from one meeting to the next. As a consequence, much of the work done at the July meeting was redone at the September meeting. I was unhappy with the progress of work on the telecom application, which I found remained relatively abstract. I tried to facilitate the process by inviting project-team members to talk in more concrete terms and to talk, for example, about their ('subjective') personal experiences, about what they had learned from the informal carers they interviewed, about what had struck them during these interviews and how it could help them in the design process. This intervention was partly inspired by what happened in the police project, in which we made personal and subjective notes of our 134 observations but created relatively sterile versions of these to apply in our design process – I wanted to attempt to include such personal and subjective experiences in the design process this time. Edith reacted to this and advocated talking about ('objective') factual data and the results of the survey: Me: Try to describe as concretely as possible what you experienced [during an interview or observation], how you felt, what you want to do with it now. How do we give the encounter with users a space in this meeting? Edith: I think that it will indeed start to become livelier in a meeting. But my fear is that, with such descriptions of contacts that you experienced yourself with people with dementia or with informal carers, it makes a tremendous impression. Especially when you are not used to people with dementia or this kind of problem. And my fear is precisely that you put one such experience centre stage, which does not do justice to the problems of a very large group of people. And what you see here in these tables [pointing to the data], that is a large number of people, these are all numbers, which is relatively dull and less lively, but these are the problems experienced by a large group of people. And when you set this next to one story, of one person who experienced something with one person, that might make a greater impression, but that should not be what steers us when we think about a solution. Because, however impressive it is, it is only one observation. Some of the project-team wished to take 'objective' data as a starting point, while others wished to take 'subjective' experiences as a starting point. Despite this difference, we were able to decide to focus on the problem that, in many cases, the primary informal carer provides all the care, both structural and incidental, and that only a small number of people support the informal carer. We also formulated an idea for a solution: a we-centric telecom application that would motivate other people to provide more support to the informal carer than is currently the case. This decision was in line with the idea that a telecom application can facilitate communication and cooperation. In a subsequent project-team meeting (November 2005) the findings from previous meetings (July and September 2005) were combined. The problem that the person with dementia has no or little activities 135 and requires a great deal of attention from the informal carer was combined with the problem that informal carers often have to provide a lot of care and receive little support from others. An idea for a solution was expressed: to alleviate the informal carer's burden by encouraging and facilitating other people ('people in the periphery') who would like to provide care to the person with dementia or would like to support the informal carer, but who do not currently do so, or only to a limited extent. This idea was illustrated with the following storyline and Figure 14: Dirk has dementia and his wife Rosa is his primary informal carer. Rosa feels burdened by having to provide informal care for her husband Dirk. Their world is becoming smaller and smaller, and she hardly has any time for herself or for her friends. A telecom tool would help her to ask for assistance from others. On such an occasion Piet, who is currently in the periphery, could be motivated to take up one or several care tasks. Piet can offer this help to Rosa via the same telecom tool. Figure 14: Sketches for a we-centric telecom application for informal carers While discussing this storyline, Pauline remarked that we are not dealing with a technical problem that can be solved by a technical solution, but with social or emotional needs, and that the solution must take account of such social and the emotional issues. Does Rosa dare to ask another person to help her? Is she confident that someone Rosa wishes to have some time for herself Rosa Piet can do care or other tasks Dirk Piet Dirk Rosa Piet 136 else can also provide care to her husband Dirk? Does Piet dare to take over a care task? Does he feel capable of providing such care? In other words: the social and the technical are not separate worlds (e.g. Latour 1987; 1996). Both problems and solutions have social as well as technical qualities. Attempts to improve cooperation The diverse attempts to study and understand the needs of informal carers and to apply the findings in the design process caused friction within the project-team. This happened, for example, when Martin and Julia conducted the additional interviews for their work on WeCare. On several occasions, Pauline suggested that the people working on WeCare should first study the literature and the results from their survey and do additional research only if specific data were lacking. There were also tensions with regard to what are appropriate or legitimate methods; how to obtain valid knowledge and how to generalize or apply knowledge. Pauline and her colleagues worked on a survey designed to provide a statistically representative overview of people's needs, whereas Martin and Julia, and later on Rachel and Annelies, conducted interviews because they wanted to become acquainted with some informal carers and wanted to let the informal carers inspire and inform their design process. These frictions can be understood in the light of the project-team members' different backgrounds. Pauline and her colleagues work in the (mainstream) social-science tradition and are used to conducting research in such a way that they can reliably and systematically describe a current state of affairs. They conducted a survey with a large number of respondents using standardized questionnaires and produced a statistically representative portrait of these people's needs. By contrast, Rachel and Annelies work in a design role and are typically more concerned with envisioning future possibilities. They conducted relatively loose and open-ended interviews in order to inspire and direct their creative process. This friction was described by Haddon and Kommonen (2003), who characterized (mainstream) social scientists as being concerned with existing knowledge and studying and documenting a current situation, and designers as being concerned with originality and with imagining alternative and future situations. 137 It was difficult to understand and value fellow project-team members' approaches and, more importantly, to understand how different approaches can be combined constructively and how results from different people's efforts can complement each other. On several occasions, I attempted to improve cooperation between project-team members. I did this by making explicit the differences between these approaches. I hoped that this would help to resolve the frictions and improve cooperation. But my interventions sometimes resulted in even more friction. In comparison, Rachel made a more effective attempt to advance cooperation when she sent an e-mail one afternoon (8 March 2006). She sent the e-mail as a response to several earlier, critical questions from Pauline and Edith about why she and Annelies were conducting additional interviews, given that there were already so many data from the survey interviews. Pauline and Edith felt disappointed because they thought that only a few people read or actually used the survey results. Rachel felt similarly irked about Pauline's and Edith's critical questions about her approach and her way of working. In her e-mail, Rachel explained the goal of her additional interviews and why she wished to do these in addition to the survey: These reports [of the survey, which I did read] are very informative and contain valuable information. However, it is also very important that I speak with informal carers myself. It may well be that an introductory conversation [with an informal carer] would not provide new insights for you, but for me it was very valuable and it gave me many new insights for [WeCare]. For me, the purpose of the conversation was achieved. I gained much greater insight into the situation of the informal carer and the person with dementia [which I can use as a basis for further research and design]. Rachel thought that the others underestimated how valuable these interviews were for her and how they helped her with her research and design work. She sent a 'Cc' ('carbon copy') of the e-mail to me and to Catherine. Within an hour, Catherine replied that she was happy with Rachel's explanation and that she was glad that Rachel had read their reports. Catherine suggested that good communication and clear agreements can help future cooperation. The next morning, Pauline also replied in a similar, positive tone. She also remarked that she would have liked to have had more communication beforehand – 138 before miscommunication and friction occurred. I was also happy with how this discussion developed. When Rachel's e-mail appeared in my inbox, I did not know how Pauline or Catherine would react. I feared that the discussion would become unpleasant, also because it was conducted via e-mail, which can rather easily lead to miscommunication. After this intervention, the team members started to tell each other about the results of their respective research efforts and, on that basis, together they began discussing design ideas, design sketches and user requirements for the application. I was happy that cooperation had improved. This was also convenient for Rachel, because she was planning to conduct more interviews and it would be helpful if she could recruit participants from the survey database of Pauline, Edith and Catherine. In my view, Rachel's intervention to improve cooperation was more nuanced and contextualized than mine. I merely pointed out the differences between the traditions and methods of the project-team members, whereas Rachel communicated her own concerns and also communicated to Pauline and Catherine that she understood their concerns. In retrospect, I wonder how pointing out differences would make them cease to exist. Moreover: Why would we want or need to solve differences? A degree of diversity – and hence friction – within a project-team can be constructive. That is a key idea behind multidisciplinary teamwork and behind various techniques designed to encourage creativity. I think that I failed to improve cooperation because I failed to make explicit and discuss my own concern with stimulating cooperation between project-team members in my role as coordinator. Furthermore, I could have asked my fellow team members what they thought about cooperation within the projectteam and about their ideas for improving cooperation. Making explicit my own concerns and asking them to respond could have encouraged us to speak about our concerns and this could have helped to improve cooperation. Interestingly, the telecom application for informal carers on which we were working on is designed to improve cooperation, but we ourselves had difficulty cooperating within the project-team. In retrospect, I can imagine that I could have tried to relate what happened on the process level to what we were trying to do on the content-related level. For example, I could have posed questions 139 about what hindered or promoted cooperation between us, and how that could relate to our understanding of what hinders or promotes cooperation between informal carers. We could have learned about cooperation in the here and now, on a process level, and could have improved cooperation, and perhaps we could even have applied some of our findings from such a discussion to the design of that telecom application for informal carers, on the content-related. (See: Reflexivity, p. 188.) Interview rounds 1 and 2 The work on the application was dormant for six months (between November 2005 and May 2006), largely due to several unplanned and unfortunate personnel changes within the project-team, and because the work on DEM-DISC required more attention and resources than planned. In order to promote work on the telecom application, project-team member Jasper proposed a name for it – WeCare – as a way to distinguish it from the work on DEM-DISC and to confirm that WeCare also needed attention and resources within the project. Martin, Rachel and Annelies, with occasional help from Pauline and me, organized and conducted a series of interviews with informal carers in order to involve them in the research and design process (from May to June 2006). People were selected from the survey database and invited to participate in three rounds of interviews in their homes. Four informal carers agreed to participate: • A woman who is the informal carer for her husband, who has dementia –both are in their eighties. • A woman who is the informal carer for her husband, who has dementia – both are in their sixties. • A man who is the informal carer for his husband, who has dementia – both are in their sixties. • A man who was the informal carer for his wife, who suffered from dementia, until she passed away several months earlier. Rachel and Annelies conducted an initial round of interviews with the informal carers to become acquainted with them and learn about their situations. At the end of each interview, they invited them to participate in the next two rounds of interviews, and all of them agreed to do this. The carers spoke very openly about their daily lives and their problems and needs. Here is an excerpt from the interview notes: 140 I plan all day long. How to arrange everything. How to fit things into just one day. On Friday my partner goes to the day-care centre. In the morning I play tennis [her only social activity], in the afternoon I can do some shopping, but I really have to be home by 4 p.m. (Woman, 69 years of age) On the basis of these interviews, Rachel, Annelies, Martin and I created two storylines about two couples (each storyline was approximately six pages in length). The storylines begin by describing two personas, one person with dementia and the husband/wife as primary informal carer, and then described 'a day in the life of...'. The storylines were constructed by selecting and combining situations that seemed to be relevant, both for the interviewed informal carers and for our project. Here is one excerpt: About Ans and Simon Ans (73 years) has dementia. Her husband Simon (76 years) is her 'primary informal carer'. They have been together for 51 years. They have two sons, Johan and Pieter, and four grandchildren. They were born and raised in a rural part of the country. Simon had his own business, manufacturing and repairing sails. He retired 12 years ago. Ans used to do the accounts and took care of their two sons. She used to be very active. She did volunteer work and used to go on a cycle ride once a week with the woman next door. 5:30 a.m. Ans is stumbling around the house, which awakens Simon. He sighs and tries to sleep again. He went to bed late last night because he wanted to finish reading his book. Ans calls Simon. Simon gets out of bed and goes to help her back into her bed. 6:15 a.m. Simon brushes his teeth and gets dressed. Then he chooses clothes for Ans. He helps Ans to shower, dry herself and get dressed. Helping her with the sleeves of her dress takes a while. Then Ans is dressed and they go downstairs. [...] We portrayed Ans as a woman who used to be active and social. This shows us the woman she was before she suffered from dementia and became passive and isolated. Furthermore, the situation of waking up 141 early and helping Ans to shower and dress is intended to suggest that Simon has to help her full-time and has little time for himself. Rachel and Annelies then conducted a second round of interviews with the same four informal carers. During these interviews, they read aloud one of the storylines, invited the informal carers to respond during the reading, then discussed which situations from the storyline are most recognizable and relevant for them. At the end of the interview, Rachel and Annelies summarized the situations and invited the informal carers to make notes about these or similar situations in a diary for the next two weeks. They also gave them disposable cameras and invited them to take photos of the situations (as 'cultural probes', cf. Gaver et al. 1999), and made an appointment to collect the notebooks and cameras two weeks later. All the carers made notes, but only one actually took photos. They explained that it was too much work to take photos, or that they felt uncomfortable with the idea that photos of their lives would be passed into the hands of strangers. A creative session In order to develop ideas for WeCare, a creative session was organized by Annelies and Martin (June 2006). Annelies, Rachel, Pauline and Edith selected three supposedly problematic situations from the storylines, based on the survey findings and on findings from the first and second rounds of interviews. The situations were used as starting points for the creative session. Twelve people participated: six project-team members (Pauline, Rachel, Annelies, Martin, Catherine and I) and six people from media lab VWX who were not working on the project. The latter were invited to provide additional creative input from another perspective. Quotes from the first and second rounds of interviews were hung on the walls of the room where the session took place, along with photographs with notes (from the one informal carer). This was done in order to enable workshop participants to learn more about informal carers' lives and needs. At the start of the session, the three chosen situations were discussed and participants were divided into three groups and instructed to develop ideas for one situation each (diverging phase). Half-way through the session, they were asked to choose and develop one idea that was most appropriate for the project's scope (converging phase). More specifically, they were asked to choose an idea that had a mobile character, made use of telecommunication and 142 was context-aware and adaptive – that is: it monitors the users' contexts and applies this to adapt the service to the users' contexts). One group, in which I participated, envisioned a telecom tool to enable and facilitate informal carers and others to exchange help: to offer help to others and receive help from others. Interestingly, none of the additional people from outside the project were in this group. We envisioned an application, running on a PDA or smart phone, that would compile a list of people from whom I may request help and a list of people to whom I may offer help. Alternatively, the application could be organized not around the people but around the tasks for which people could request or offer help – see Figure 15. The idea was to encourage people to cooperate with each other, which fits neatly with the project's scope of we-centric telecommunication. Figure 15: Sketches for a telecom application designed to help people exchange care tasks and communicate with each other The two other groups, in which additional designers did participate, came up with two other ideas. One idea was CaringHome, a domotics application that uses sensors to monitor what the person with dementia is doing and tries to help him/her. For example, when 143 the person gets out of bed in the middle of the night, CaringHome switches on the lights to guide him to the toilet and back to bed. The idea is to let CaringHome perform some of the tasks that the primary informal carer would normally perform. The other idea utilizes mobile localization technology. The person with dementia wears a ring, or other fashion accessory, that is fitted with a GPS receiver and telecom functions. If the person becomes lost, the ring informs the informal carer of his/her whereabouts and the carer can call the person directly via the ring. Alternatively, passers-by can help the person to get home, either by calling the informal carer for help via the ring or by directing the person home. These two ideas can be thought of as more innovative than the idea for WeCare, which can be thought of as merely a database comprising help requests and help offers, an algorithm for matching requests and offers. The plan was to choose one idea during the creative session to further develop it within the project. However, this decision was not made during the session but afterwards. The people from VWX wanted to work on the domotics or localization application because these are more innovative and focus on helping persons with dementia. I wanted to make progress and influenced the decision-making so that we chose to further develop the telecom application, which was in line with the current idea for WeCare. Discarding the WeCare idea would destroy a great deal of work and we had already decided to focus on informal carers. Furthermore, this idea was closest to the scope of the project and, compared to the other two ideas, it looked the most feasible to design, build and evaluate within the project. One can question the added value of the creative session in the context of the project. Perhaps I can understand this session as a meeting in which some people wanted to develop innovative ideas for ICT applications for people with dementia, while others wanted to continue to work on their WeCare application. Both efforts occurred in the same meeting, but were rather separate from each other. Interview round 3 In a third round of interviews, Rachel and Annelies discussed the WeCare concept with the four informal carers (August 2006). They drew a storyboard to visualize how people would use WeCare – see Figure 16. It showed some key functionalities within a short narrative 144 of finding out that Simon has dementia, of Simon and Ans trying to cope with this, of Ans trying to find help and support, and of how their daughter Miep and their neighbour Bert offer help and support. (Please note that the roles of Simon and Ans have been swapped.) Figure 16: Storyboard for WeCare 145 The storyboard left many issues open. This allowed Rachel and Annelies to discuss the concept from a practical perspective and in a relatively open manner with the informal carers. In this storyboard, the telecom application is called 'Activities Bank' and focuses on how people can exchange requests and offers and share tasks. In addition, and in a similar way, Rachel and Annelies discussed the concept with four other people: a son of a woman with dementia, a daughter of a woman with dementia, a neighbour of a woman with dementia, and the coordinator of a meeting center. These interviews were intended to evaluate the concept from perspectives other than that of the primary informal carer. All eight interviews focused on whether or how WeCare matches people's needs and preferences and their current practices. The interviews focused on functionality, not on usability. They discussed whether or how people would like to use it, what the application should and should not do, and which features should be included or excluded. Such questions are related to the human-centred design principle of an 'appropriate allocation of function between users and technology' (ISO 1999). They wanted to discuss a range of options with them, before making further design decisions and discussed questions such as: How do you wish to invite others to participate in such a group of informal carers? How would you like to form and organize such a group? How do you think participants can be motivated to offer each other help and accept help from each other? What kind of help requests would people make, for example for structural help or for incidental help? And should there be mechanisms to monitor how much help a specific person offers or receives? On the basis of these interviews and on discussions in project-team meetings, the following requirements for WeCare were formulated (November 2006): • A participant (typically the primary informal carer), can ask for help by entering a help request in her online calendar (including date and time) or on an online bulletin board, help request without date and time. • Other participants (typically secondary informal carers), can offer help by filling in their profiles (the type of help they wish to offer), their online calendars (when they are available), or by putting a message on the bulletin board, help offered. 146 • The system automatically matches help requests with other participants' profiles and calendars and identifies participants who can offer help and gives them utility scores (a function of relevance based on their profile, and availability based on their calendar). • The system then sends the help request to the person with the highest utility, either by e-mail or SMS. • This person can then either accept or reject the help request. If the request is accepted, the match is made and communicated to both people. If the request is denied, a new match is made with the person with the next-highest utility. • If no help can be found, or if the moment when the help is needed is approaching and no help has yet been found, the person asking for help is notified promptly. He or she can then look for other help, for example from professional care providers. Not surprisingly, the way in which WeCare makes a match between people by matching their 'context elements' and calculating a 'utility' based on their relevance and availability, is similar to the PolicePointer method (see previous chapter). While writing these requirements, and in order to illustrate its functionality, Rachel and Mandy made sketches for the WeCare user interface in the form of 'screenshots' (examples of the user interface) – see Figure 17. Figure 17: A sketch of WeCare, running as a web page A participant's online calendar ('Mijn agenda'), with, for example, work ('Werk Boutique') Incoming help requests are presented tentatively ('Gezelschap verzoek van Ans') A participant can choose to accept or reject a request 147 Reflecting on the project Early in 2006, I wrote a conference paper (Steen 2006c) on our project so far. I described our various efforts to study and understand informal carers' needs and preferences. Furthermore, I wrote about the difficulties of cooperating within the project-team and about our practice of representing users, portraying them through statistics or storylines and acting as their spokespersons. I described several 'redundant' activities and the difficulty of making progress: different project-team members conducted different series of interviews with informal carers and we repeatedly discussed different problems we could address and solutions we could develop for these problems. I provided an example to illustrate the discussions we often had about which need should be the main concern of our project. During the September 2005 project-team meeting, Dirk said, with some kind of humour implied, that we – the project-team members – have a need: 'Our need is to do something about that problem'. We have the ambition to create a telecom application and we are looking for people with a specific need for whom we can design this. I organized a project meeting (July 2006) together with Pauline, Rachel, Annelies and Martin, in order to reflect on the project together and to hear their experiences and views. I sent them a draft of my paper and invited them to read it before the meeting. Another goal of the meeting was to find ways to improve cooperation within the team for the remainder of our project. Rachel started the discussion by saying that she found the progress slow and that a lot of work was done twice: Rachel: What I found unpleasant is that we found that ... that the decision-making was sometimes really slow. Because, of course, you're dealing with diverse parties and everybody wants to have a say. But there were also things that were done twice. I sometimes think, can't we work faster or more efficiently? I strongly feel about that. And I've noticed it's gone better over the past couple of months, I think, because we've really made progress. Pauline also observed this lack of cooperation and progress. She made clear, in a series of clear statements, what we should do about this: 148 Pauline: I think that with so many different people and organizations, you have to be very clear. Otherwise you get the sort of thing you just spoke about. You must make clear agreements that everybody is clear about. [...] Everybody has different goals. But actually you must organize it so that everybody is singing from the same hymn sheet. What will we do? What do you want? What do you want? What do you want? Okay, what will we make of it? And I think that we missed that a lot, especially in the beginning. Pauline argued that making clear agreements would improve cooperation and progress. Furthermore, she talked about her frustration about team members not reading or using fellow team members' findings, for example the survey results. Rachel recognized this lack of cooperation: 'We have all been little cogs busily spinning around, but disconnected from one another, not connected at all'. Rachel and Pauline suggested that cooperation failed in the sense that many issues remained open or undecided for too long, and this hindered progress: Rachel: Something just stays undecided. And, later on, it is revisited. Then I think well, erm ... Pauline: Yes. Rachel: Yes. Pauline: If something is not finalized or closed properly. Rachel: Yes. Pauline: Something is not made clear. Annelies: Yes. Rachel: Yes, then it just remains open. This discussion can be understood in terms of openness versus closure. In HCD one tries to balance the attempt to be open to new insights from users, fellow project-team members and stakeholders, with the attempt to create closure, the need to draw conclusions and produce results. Furthermore, these issues relate to questions concerning the need to make iterations when one conducts research, design and evaluation activities. Iterations can be understood as an attempt to combine openness and closure. With too much closure, one would run the risk of not being able to apply new insights. But too much openness can make it difficult to make decisions and make progress. Pauline and Rachel drew attention to what happens when there is too much openness and too little closure. By contrast, Martin described 149 his need for openness and room to explore. He was searching for the right words: Martin: What bothered me in any case is that we thought, er, that it, er, that it was about DEM-DISC and about WeCare, but actually it was about DEM-DISC. Only later WeCare was introduced, as a, er, sort of, erm ... Pauline: Well, as a sort, a sort of extra idea. Because the DEM-DISC idea already existed. Martin: Yes, and that is the point, I think. Pauline: With WeCare as an extra something, so to speak. Martin: Yes, and there is, I think, the rub, or something, in any case. We were doing a research project in which it had already been decided what we would make, namely DEM-DISC. And, speaking for myself, I found that, er, more of a hindrance than a help. Because research must, in my opinion ... Pauline: Go in all directions. Martin: Yes, I mean, you can go in all directions. So WeCare was a kind of device, to, er, to canalise this wish. That we could wander in any direction. The idea to develop DEM-DISC was there from the start of the project, whereas the idea to develop WeCare was developed during the project. Martin was happy to work on WeCare as it provided him a space to 'wander' around in. Rachel agreed with Martin that there should be some room for exploration. However, she suggested that it would have been better if someone had more firmly steered the project by referring to its goal and scope. She was perhaps attempting not to directly criticize my role in the project and my failure to steer it properly: Rachel: If you are talking about goal-setting, yes, then I find it important to say, okay, er, the project has a certain goal, we have a certain goal, so to speak. I think that you shouldn't be scared to actually use that goal to bring a focus into your own ideas for applications. [...] I mean, the project is very broad and I think at a certain moment you need to make choices, so to speak. You can make these within a framework that you have all agreed upon beforehand [in the project plan]. 150 Rachel found the project's goal relatively clear and suggested that we should have used it to steer the project. In response, Annelies remarked that she was surprised, in the first project meeting she attended (September 2006), that many options were still open and many decisions had not yet been made. That lack of a 'handhold' made her feel uncomfortable and she decided to do some research herself in order to get started: Annelies: I think that people who enter the project as newcomers go looking for some sort of handhold, so, er, they repeat things that have already been done. And well, sometimes, I felt, that is, I thought okay, then we do some interviews or so, and met a lot of resistance. Is it being done again? But for new people entering the project, and for the process, it was, I think, necessary to do those [interviews] again. And, er, it could be very de-motivating to feel this kind of resistance. I thought, well, I really want to move ahead, and therefore it is necessary to do this first. Annelies was keen to start working and to do some hands-on work herself. She justified this approach by suggesting that the project's scope and goal were not clear to her. In my role as coordinator, I started to make defensive remarks: I did make minutes of project meetings, for example of the previous meeting (July 2005), and we had drawn conclusions about a problem to focus upon. Then Pauline remarked that I should have made these decisions more explicit. In retrospect, I can see her point: I could have tried harder to make the decisions explicit, communicate them to all project-team members and, probably most importantly, I could have tried harder to uphold the decisions and have others uphold them, so that we could have made progress rather than, for example, discussing decisions that had already been agreed upon. During the discussion, Pauline and Annelies requested that I make minutes of this meeting or arrange for other people to do so in subsequent meetings, and also that I try to make sure that people keep to the decisions in the minutes. I agreed, and I think that this helped to improve cooperation and progress, which made me feel relieved. Later on in the meeting, we discussed how and when to involve users. Something about this topic may have bothered me and I made a negative remark about it. I stated that we usually represented the 151 informal carers, rather than actually allowing them to be present and participate: Me: One of my supervisors said: Hey Marc, do I understand correctly that, in all your texts about the workshops, meetings and gatherings, there was never an informal carer present? I said: Yes, that's right. They were never there. We represented them, through questionnaires, interviews and observations. What do you think about that? That [the informal carers] were only allowed to participate through us, so to speak. Whereas, if I compare this to the police project: there were five or six occasions on which we sat around the table, with five police officers over there and three project-team members here. Annelies: I think that is a totally different situation. The police officers are there because of their job, they can sit around the table; they have time for that. The informal carers – at least one informal carer I spoke with – have a free afternoon on only two days a week. And I think it's too much to burden them by asking them to come here and think with us. Annelies acted as a spokesperson for the informal carer, saying that s/he would not come and participate in our project meetings. Earlier in the meeting, Pauline spoke on behalf of the informal carers, arguing that we must be careful not to burden them by asking them to participate in all sorts of project activities: 'It is not a group of people whom you can ask to do things for you, to show, discuss and test things excessively. People have little time. They have a lot on their plate. They can't simply drop in for yet another interview, or to look at something'. Pauline also drew attention to the risk of having informal carers participate in workshops or meetings: Pauline: The informal carer, if s/he were to sit here with us, would hammer at her/his own problems. So you don't know whether he or she is an 'average' informal carer or a 'unique' one. [this was followed by a discussion about one or two informal carers who did participate in a conference organized by the project-team about DEM-DISC, some months previously] Pauline: What I mean to say is, that if you put here one informal carer, and s/he is to participate in the discussion, s/he will speak up / Me: / Yes 152 Pauline: / but about her/his own problems, steer you in one direction. Me: Yes, and I think that, that, that I want to ask you about that: And what is the problem with that? Pauline: That you ignore the rest. You do not know, you don't know about the rest. There is quite a chance that you will overlook things if you pin yourself down to one or two people. Pauline drew attention to the risk of focusing on the needs or preferences of only a small number of informal carers who actually participate in a meeting. By contrast, Martin revisited my remark about representation and, in retrospect, did not like the way we acted as spokespersons for the informal carers rather than allowing them to participate directly: Martin: I find, I find your observation, that the, that the supervisor observes, that nobody is present, I find that really, er, if I hear it like this, very shocking. And then I think, well, of course. In contrast to what you think, of course somebody like that should be present – er, should have been present. Martin wished to 'wander'. Annelies was looking for a 'handhold' and was eager to start doing things. Rachel tried to improve cooperation and made a successful intervention. Pauline advocated conducting 'objective' research and making clear agreements to improve cooperation. And I often felt uncomfortable with this project and sometimes embarrassed by my role in it. Creating and evaluating a prototype The plan was to build a prototype of WeCare and to evaluate it together with informal carers. The plan was to do this in 2007. However, there was a considerable delay between writing the user requirements and making user-interface sketches (November 2006) and prototype building. One of the main reasons for the delay was the fact that building a prototype of DEM-DISC took considerably more resources and more lead time than was originally planned. And, because DEM-DISC and WeCare competed for scarce resources for technical implementation within the project, the building of the WeCare prototype was delayed several times. 153 In order to keep the work on WeCare moving to some extent, I organized the production of a short film to present and discuss the functionality of WeCare (February 2007). This would not require resources for technical implementation because the application in the film would be faked. Furthermore, the plan was to show the film at a conference of the Freeband research programme. I produced the movie with Kevin from the research organization STU. I wrote the script and he recruited three actors and someone to do the filming and the editing. We directed the film together. It was a short storyline of a primary informal carer, Marriët, who was looking for someone to take care of her husband Dirk so that she could go out for the day. Normally, she would ask her daughter Carla, but she knows that Carla is busy that day. She sends a help request via WeCare. Carla receives the request because she happens to be available on that date. She calls her mother to say that she can help, and they briefly talk about why she did not just call Carla directly. However, on the day of the trip, Carla is too busy at work and cannot help out. She sends a rejection to the system, which then sends a help request to Bart, the neighbour and friend of Marriët and Dirk. He calls Carla to say that he will go to Dirk and Marriët's house; Carla need not worry. The short film ends with Bart and Dirk having a pleasant time, chatting and watching sport on television. I showed a first rough edit of the movie to the project-team and this led to further discussion about how to handle acceptance and rejection messages, about which notification messages to send to whom and when, and about what the system should do if time is running out? We then formulated a guiding principle: the person who sends the help request should experience as less effort as possible – finding somebody for this help request is delegated to WeCare – and experience as much control over the situation as possible – the person who sends the help request should feel in control. Interestingly, these two requirements can conflict, so that deliberation is still needed, despite of the guiding principle. As a result of this discussion, we were able to adjust the user requirements and balance the need for ease-of-use and a sense of control. Eventually, when a prototype of DEM-DISC had been built and evaluated in an experimental field trial, a partly functioning prototype of WeCare was built (April-May 2008). In the meantime (March 2007), we had become acquainted with a company that offers an online service similar to WeCare and with its founder and director 154 Elisabeth. Her company provides a user-friendly website for people who want to share and coordinate care and related tasks, for example for a group of five to ten people who want to work together to provide care and support to a family member who is ill. We organized a modest evaluation of WeCare in the form of interviews with informal carers (June 2008). During this evaluation, we cooperated with Elisabeth. She recruited current users of her website as participants for the interviews, and we presented our prototype as a possible future addition to her website. More specifically, we presented two functions as innovative additions: the semi-automatic matching of help requests and help offers (which current users of her website do manually) and the possibility of using certain functions on a mobile phone (the current website is built for usage on a computer). We spoke with six informal carers during three interviews of two hours each (an interview with two sisters and a man, an interview with one man, and an interview with two ladies). During the interviews, we first talked about the participants' current situation and their current use of the website. We then presented and discussed, step by step, the functionalities of WeCare. During the interviews, the informal carers recognized and articulated several advantages of the two extra WeCare functionalities. Matching makes the work of the coordinator (most groups have an informal or formal coordinator) much easier. They suggested that the matching could be tweaked to prevent specific people from volunteering too often and to allocate tasks more evenly among participants. Furthermore, they remarked that the matching mechanism of WeCare could have an advantage for finding short-term help, because it is not necessary to call and speak with everyone individually. Moreover, most interviewees estimated that accepting or rejecting a help request on a mobile phone would be a useful addition because it would indeed enable participants to respond quickly. Other functions can be used more easily on a computer, because it has a larger screen and the keyboard is easier to use. In addition, most interviewees saw the need for participants to keep their calendars up-to-date (to ensure that the semi-automatic matching functions properly) as a weak part of the system. On the basis of these few interviews about a partly functioning prototype, it appears that informal carers would appreciate WeCare, provided that an easy-to-use solution is found for filling in, editing and synchronizing the system's online calendar. 155 Summary A recurring theme in this project was the difficulties of cooperation between project-team members with different backgrounds and the difficulties of cooperating in a project involving various organizations with different agendas. HCD is not only about interacting and cooperating with users, but also about interacting and cooperating within the project-team. This draws attention to the HCD principle of multidisciplinary teamwork and the principle of making iterations within a project (ISO 1999). The difficulties of cooperating are, of course, related to the difficulties of making progress, which can be illustrated by looking at several ('redundant') activities that were repeated two or three times – see Table 4: • Pauline, Catherine and Edith organized a survey in which more than three hundred informal carers and people with dementia were interviewed (summer 2005 to summer 2006). Julia, Rachel and Martin did additional observations and interviews (MayAugust 2005). Rachel, Annelies and Martin did three rounds of codesign-style interviews (May-June 2006). • Defining a problem to address and an associated solution was redone over the course of three project meetings (July, September and November 2005). Making progress was difficult because many different people participated in each meeting, and only a small number participated in all three meetings. • The idea for a we-centric telecom application that would promote communication and cooperation was already in the project plan, and was re-articulated several times: while writing a paper (August 2005), during project meetings (for example November 2005) and in a creative session (June 2006). Table 4: Chronology of some of the project activities and ideas for WeCare Some of the project activities Some of the ideas for WeCare Before Promote communication and cooperation via a we-centric telecom application Jan 2005 Catherine's and Edith's idea, on behalf of informal carers Support informal carers, improve the quality of life of both the informal carer and the person with dementia Feb 2005 Mar 2005 April 2005 Findings from survey into needs of informal carers and people with dementia Frequently reported needs: memory; daytime activities; info on health etc.; company; psychological distress 156 May 2005 Additional observations and interviews Informal care can be very demanding June 2005 July 2005 Project-team meeting The person with dementia has little structure and few activities and requires the informal carers' attention Aug 2005 Write a conference paper Focus on the informal carer's emotional and social needs and problems Sep 2005 Project-team meeting An informal carer receives little help or support Oct 2005 Nov 2005 Project-team meeting Alleviate the primary informal carer's burden by stimulating others to take up tasks Dec 2005 Jan 2006 Feb 2006 Mar 2006 Rachel's e-mail about teamwork April 2006 May 2006 Interview rounds 1 and 2 Storylines about the lives of people with dementia and their informal carers, including 'problematic' situations June 2006 Creative workshop Develop a telecom application to encourage primary informal carers to share tasks with others July 2006 Aug 2006 Interview round 3 Questions about how to organize tasksharing among such a group of people Sep 2006 Oct 2006 Nov 2006 Write user requirements User requirements, with attention for how help requests are sent to/from people who wish to help Dec 2006 Jan 2007 Feb 2007 Produce a short video Discussion about how people will experience using this system, especially when it is difficult to find help [...] Delay, largely due to scarce resources for technical implementation within the project Establishing cooperation with a company that offers a similar online service April 2008 Build a prototype May 2008 June 2008 Evaluate the prototype Interviews with six informal carers about WeCare prototype 157 The repetitions appear to suggest that the project malfunctioned. However, I also see some merits. For example, the key goal remained relatively stable throughout the project, that is: to improve the quality of life for both the informal carer and the person with dementia by trying to support informal carers. Furthermore, we conducted many and different types of interviews with informal carers in order to learn about their needs and preferences. It is considered good practice in HCD to interact with (potential, future) users and to learn from them. The various series of interviews helped us to define a problem to address and to design a telecom application for them. We stayed within our project's scope and, as a result, did not welcome ideas that fell outside this scope, for example an idea for a domotics application suggested during the creative session. I could try to understand these difficulties with cooperation and making progress by drawing attention to a series of complicating factors: DEM-DISC and WeCare competed for attention and resources within the project; there were many unfavourable personnel changes that hindered continuity and cooperation. For example, there were five successive people in the role of project leader at the media lab VWX in the course of two years and several people were only indirectly involved in the work on WeCare but wished to exert influence on it nevertheless; a relatively large number of organizations, with different agendas, participated in this project; and the participating organizations assigned people to work on the project and on specific tasks, which gave me little influence on who worked on which task. These factors complicated and eroded my role as coordinator. Therefore, I felt happy with my fellow project-team members' help, for example with Pauline's suggestion to make decisions and agreements more explicit, and with Rachel's effective intervention to improve cooperation within the team. Looking at our research and design efforts, I see a mixture of approaches. I see some elements from participatory design and codesign, in that we invited informal carers to talk about their current situation and problems, and we invited informal carers to discuss ideas for alternative practices and for using WeCare. There was something from applied ethnography and empathic design, in that we went to people's homes and listened to their stories about their lives, needs and preferences, and tried to empathize with them. And there was something from a lead user approach, because the informal carers who participated in the three series of interviews were selected 158 on the basis of their relatively innovative use of the computer, Internet and mobile phone. I sometimes felt like a stranger in this project. Within the project I did not meet an informal carer or a person with dementia face-to-face. I had only met people with dementia when, as a student, I worked in a nursing home. Yet here I was, trying to exert influence on the design of an application for them; imagining that they should organize their lives differently, ask others for help and delegate tasks to others, and that they would use our telecom application to do that. My supervisor Jan, after reading drafts of the chapters on both projects, asked me whether or how we tried to transfer what we learned in one project to the other project – especially from the PolicePointer project (which ran from April 2004 until July 2006)) to the WeCare project (which ran from January 2005 to February 2007 and from March to June 2008). However, the people working in both projects and the organizations involved were rather different; only Mandy participated in police project and in the last part of the informal care project. I tried, to some extent, to facilitate learning during project-team meetings and to improve cooperation by making suggestions. However, the projects were mostly conducted as relatively separate projects. Moreover, I wrote Chapters 6 and 7, in which I try to learn from the projects, during 2007, for the greater part after the projects. 159 6. Interpretation and discussion In this chapter, I will interpret and discuss my observations of and reflections on the two projects described in the previous two chapters. I will try to explore different ways of understanding what we did and I will try to learn from my experiences and explore alternative ways of practising HCD. Within certain research approaches it would be desirable to distinguish between these activities: between understanding current HCD practices and envisioning alternative HCD practices. However, for me, this would not work because I cannot separate research (trying to understand a current practice) and design (trying to envision alternative practices). My goals of understanding our current practice and of envisioning alternative practices are intertwined. As a consequence, some observations and reflections were based upon my ideas to do things differently – which I articulated during the process – and, conversely, my ideas to do things differently were based upon my observations and reflections. It would be hard to say which came first: ideas about how to articulate the problem or ideas about solutions for this problem; this is typical for 'design thinking' (see p. 181). Looking back at our HCD efforts, I see that we tended to stay within our own worlds. We found it difficult to be open to others, whereas the goal of HCD is to jointly learn new things from and with users and fellow project-team members, and we tended to go for closure and create more of the same, whereas the goal of HCD is to jointly create new things. In order to understand this practice and envision ways of bringing HCD practices closer to the potential of HCD, I opportunistically drew from several theoretical and philosophical sources, in particular from the philosophers Emmanuel Levinas and Jacques Derrida. In that sense, I acted like a designer selecting parts 160 from a supplier's catalogue without thinking very deeply about where the parts came from or how they were created. Similarly, I picked concepts from others people's texts and applied them within my own argument. In the previous two chapters, I tried to do what social scientists do – provide an account of what happened – and in this chapter I will try to do what designers do – create something new, an assemblage of texts that is designed to enable readers to look differently at HCD practice and envision alternative ways of practising HCD. I found it difficult to order the various pieces of text of this chapter. It seemed as if I was writing three types of text simultaneously: observations and reflections from the projects that I studied, concepts from theory and philosophy, and statements that I wished to make about HCD based on practice as well as on theory. I chose to order the texts in a way that – I hope – will invite the reader to follow my train of thought. I ordered the texts approximately as follows: I say what I wish to explore or argue, then I introduce concepts from theory or philosophy, then I provide examples from the projects studied to ground or illustrate my argument. I will explore several possible perspectives from which to look at HCD practices. I will first look at HCD as a socio-cultural process and as a political process, then I will explore the ethical qualities of practising HCD. These perspectives are intended to supplement, not replace, other perspectives on HCD that focus on technology or on economics. I wish to draw attention to these perspectives because they seem to be marginalized in the way that HCD is usually organized and conducted. My particular goal is to bring the ethical qualities of HCD practice to the fore because I believe this can help practitioners align their practice of HCD more closely to what HCD can be about. Human-centred design as a socio-cultural process Looking at HCD as a socio-cultural process would be in line with, for example, Louis Bucciarelli's (1994) description of design practice. He saw design as a social process in which various people negotiate with each other about the design on which they are working. The design process is full of uncertainty and ambiguity and the participants, who often have different interests, use this uncertainty and ambiguity to exert influence and to negotiate: It 'allows them room to maneuver, to 161 reshape, to relearn and come together again' (p. 188). Furthermore, Bucciarelli suggested organizing a design process in such a way as to promote a 'free exchange of [different participants'] legitimate interests' (p. 199). Similarly, Richard Lester and Michael Piore (2004) proposed looking at innovation as an interpretive process, a process in which people jointly create and recreate meanings and which requires communication between people and an active engagement with other people's ideas and meanings. They argued that communication 'is often punctuated by misunderstandings or ambiguities [and that] this ambiguity in the conversation is the resource out of which new ideas emerge' (p. 51) and suggested 'initiating and guiding conversations among individuals and groups' (p. 8). In a similar vein, Jan Buijs (2007) described innovation as a 'multi-faceted' process, consisting of four intertwined processes that must be organized simultaneously: processes of developing a new product (or technology or market); social processes between the people involved; creative processes of creating and developing ideas; and leadership processes. He suggested that people who wish to steer innovation must have a 'high tolerance for ambiguity and paradoxes'. Interestingly, there are some – but not many – texts in the field of design studies that focus on design as a socio-cultural process, for example a collection of ethnographic studies of different design and engineering practices (Vinck 2003) and a collection of different analyses of the same design practice (Cross et al. 1996). The latter includes studies that focus on what happens between project-team members in terms of roles and relations (Cross and Clayburn Cross 1996; Brereton et al. 1996). If I apply the suggestions of Bucciarelli – to promote a free exchange of participants' interests – and of Lester and Piore – to encourage conversations and interpretive processes – to HCD, where the goal is to allow users to participate in research and design, then the suggestion would be to organize HCD in such a way that users can indeed articulate their interests, contribute to conversations, exert influence and participate in negotiations. However, as I showed in the previous two chapters, users' participation and contributions can be relatively small or indirect in HCD practice. I will try to understand this by viewing HCD not only as a socio-cultural process, but also as a political process. 162 Human-centred design as a political process Scholars such as Madeleine Akrich, Michel Callon and Bruno Latour wrote about the creation and application of science and technology as political processes. They focused on agency and power (e.g. Latour 1987; 1996; Akrich et al. 2002a; 2002b). Many of their analyses can be categorized as 'actor-network theory' (ANT) and describe how different actors (or 'actants', to include people as well as things) exercise power on each other and on the science or technology that is being created or applied. Their analyses focus on the power that flows between the actors in a 'socio-technical' network. A typical ANT-style analysis of a design project would show how various actors attempt to ensure that the design problem or design solution become articulated in ways that best fit their own purposes. In ANT, the 'key to success in innovation' is in 'the art interessement' (Akrich et al. 2002b) and in 'the art of choosing good spokespersons' (Akrich et al. 2002a): in how you achieve that other actors become interested in the project and support in such a way that they believe their own interests are served and a way that best serves your own interests. One can see such politics in the projects studied. Very often, the users were absent. Police officers participated in several workshops and informal carers were interviewed, but they did not participate in project meetings in which decisions were made. Only in some of the workshops with the police officers and in some of the interviews with informal carers did they have the chance to directly influence our decision-making. They were mostly not present, but they were represented, by us. For example, we observed or interviewed them and represented them through personas and storylines. We made descriptions of fictional people and fictional situations to represent real people in real situations (see: Personas and storylines, p. 44; Conducting observations, p. 92; Interview rounds 1 and 2, p. 139). It is argued that one can very well 'engage' with a persona, that a persona fosters empathy, in a similar way to what happens when you empathize with characters in novels, movies or television programmes, and that a persona can help imagine future situations and new products or product improvements (Pruitt and Grudin 2003). I am not against constructing or applying personas or storylines, but I wish to draw attention to the politics of representation, which often remain hidden and are not discussed. Here, two meanings of the verb 'represent' are relevant: to portray 163 somebody or something and to act as a spokesperson for somebody or something. Portraying may sound like a neutral activity, but the person who creates the portrait chooses a specific perspective, creates a foreground and a background, makes a composition and uses specific lighting. The maker of the portrait makes choices, probably partly based on his or her own biases and interests. Acting as a spokesperson has a more direct political bearing. A spokesperson chooses for whom to speak, what to say and how to say it – again probably partly based on his or her own biases and interests. We portrayed police officers and informal carers as personas and in storylines, and we acted as their spokespersons when we discussed their needs and preferences, and when we made design decisions for them – decisions which were intended to influence the product, which in turn is meant to influence their life or work. Representing users is about agency and power (Rohracher 2005a, p. 16): Representing users in design is by no means a simple and straightforward process, but continuously reshaped and negotiated by actors involved in the design process. [...] User representations are constructed and shaped by the interests, specific discourses and traditions of actors involved and often are also entrenched in material infrastructures or methods to investigate demand. It is not only actors' interests that influence how users are represented, but also the methods they use to study and represent users, such as a survey and a table with percentages or an interview and a storyline. I would like to argue that representing users is similar to what Steve Woolgar (1991a) called the 'configuring of users'. With this term, he referred to product developers' attempts to define 'the identity of putative users' (p. 59) and to 'define, enable and constrain' (p. 69) what people can do with the product they are developing. Woolgar drew attention to agency and power, for example when he observed that 'certain [researchers who conducted usability tests in which people used prototypes of new computers] could claim the right to speak authoritatively on behalf of users' (p. 70). Representing users is also similar to Madeleine Akrich's (1992) concept of 'scripts'. She argued that designers attempt to anticipate the interests, skills, motives and behaviour of future users. They imagine how these people will use the product they are working on, and put their ideas into a product in the form of a script – 'like a film script, technical 164 objects define a framework of action' (p. 208). This script, after it has become materialized in a product, subsequently influences what a person does or does not do with the product. These concepts – representing users, configuring users and creating scripts for users – draw attention to how researchers and designers attempt to define a product and simultaneously attempt to define what a user of their product should be like and how he or she should use their product. Needless to say, these attempts to define what people will do with products often remain merely attempts because there is always an amount of 'interpretive flexibility' (Pinch and Bijker 1987). People have a degree of freedom to either follow the designers' intentions or expectations or to act differently. There is a great deal of evidence, for example from cultural and media studies, that people do not passively adopt products but actively and creatively appropriate or domesticate products, use products differently than intended, or change or invent products (e.g. Oudshoorn and Pinch 2003b, pp. 4-7; 11-16; Mante-Meijer and Klamer 2004; Haddon et al. 2005). The process of representing users can be seen as a political process of mobilising resources to exert influence on other actors (e.g. Latour 1987). In a typical ANT-style analysis, I would describe how Rachel talked about her interviews with informal carers or how Mandy quoted what police officers said in a workshop and how they did this to mobilize these users within their own argument. However, I like to think – perhaps naively, from an ANT perspective – that Rachel and Mandy tried to render adequate portraits and tried to be bona fide advocates for the informal carers and police officers. Given the situation that users were not present, they did their best to represent them. However, I see a drawback in using ANT-style analyses for my current purposes. I am interested in understanding processes in which people with different interests attempt to cooperate and create win-win situations – situations in which different actors can win different gains or win in different ways. Moreover, I am interested in enabling people who participate in HCD projects (including myself) to reflect in real-time on what they do, and I am interested in reflexivity about their own roles in their HCD practices. These purposes do not match the way in which power is typically conceptualized in ANT, that is, in terms of win-or-loose: if A tries to cooperate with B or asks C to participate, it is only because A wants to win. Keulartz et al (2004, p. 14) remarked that the language of ANT is derived from 'war and power struggles' and speaks of 'allies and opponents, strategic negotiations, and tactical manoeuvres'. More- 165 over, a typical ANT study would be conducted from an outsider perspective and in retrospect (e.g. Latour 1996). In contrast, I am interested in insiders' perspectives and in real-time reflection. For such purposes, a conceptualization of power from the Northern European tradition of participatory design (see: p. 36) is more appropriate. That tradition is also concerned with power, but within a context of democracy, emancipation and participation, and with the aim of creating cooperation between actors with different interests. In this tradition, practitioners are encouraged to critically reflect upon their own roles and politics (e.g. Markussen 1994; Gulliksen et al. 1999a; Beck 2002; Spinuzzi 2005; Bødker 2006; Gulliksen et al. 1999a; Iivari 2006 – see p. 55). A similar approach to reflection and reflexivity is found among Northern European scholars in (critical) management studies or organization studies (e.g. Alvesson et al. 2004). Ethical qualities of human-centred design practice I will now attempt to move from politics to ethics. Both terms are used in various ways in different traditions and by different authors. For me, politics is about agency and power and about organizing activities, and is concerned with what happens between three or more people or what happens between organizations. On the other hand, ethics, for me, is about responsibility and freedom and is concerned with what happens between two people face-to-face, and with shifts between other and self. I suppose that my understanding of politics and ethics would be roughly in line with the ideas of Levinas and Derrida. Simon Critchley, an expert on both philosophers, argued that ethics always happens within a context of politics (1999, p. 226): The ethical relation does not take place in an a-political space outside the public realm; rather, ethics is always already political, the relation to the face is always already a relation to humanity as a whole. Let me now explore the ethical qualities of practising HCD. I am keen to write about the ethical qualities of doing HCD, rather than about whether it is ethical to practise HCD, or about doing HCD in an ethical (or unethical) way. I do not write about whether HCD is good or bad, or about good or bad ways of practising HCD. I want to refer to a form of ethics as a first philosophy. Such a conceptualization of 166 ethics would be different from how ethics is often construed, that is: ethics as one branch of philosophy. In that conceptualization, ethics would deal with questions such as 'How to act?' and would sit next to other branches of philosophy such as ontology ('What is?') or epistemology ('How can we know?'). In a conceptualization of ethics as first philosophy, ethics would be fundamental to all philosophy: it would be the trunk, not a branch. This idea was elaborated by Levinas, who saw the Other and the encounter with the Other as the basis for ethics and as constitutive for all philosophy. The Other was there before I was there and appears in front of me; the Other comes before ontology. The face of the Other appeals to me before I can understand or know it; the Other comes before epistemology. Simon Critchley (1999) explained that, for Levinas, 'ethics occurs as the putting into question of the ego, the knowing subject' (p. 4) and quoted Levinas's description of ethics: 'the putting into question of my spontaneity by the presence of the Other' (from Totalité et Infini [1961, p. 13]) (p. 5). This kind of ethics occurs when the other puts into question the self. Ethics occurs in encounters between people, between the other (associated with Infini) and the self (associated with Totalité). (Please note that I try to steer clear of writing about what ethics 'is', and try to write about ethics as it 'occurs'. Likewise, I will try not to write about what deconstruction or reflexivity 'is' but about deconstruction as it 'occurs', 'takes place (a lieu)' (Critchley 1999, p. 2), or about reflexivity that 'occurs'. Below, I will try to make clear why I do that.) In a conceptualization of ethics as first philosophy, I cannot choose for or against ethics, or choose to act ethically or unethically: I always, already find myself in relations to others and therefore I find myself always, already within ethical relations, within ethics. I feel attracted to this kind of ethics because it helps me to think about what happens between people, including myself, who are involved in HCD practices in a very direct manner, and about responsibility and freedom. I realize that most approaches to ethics are concerned with what happens between people – it would be difficult to think about ethics for one isolated person – but many approaches to ethics locate the process of ethical consideration within one person. For example, deontological approaches aim to articulate and apply general moral rules based on an individual's duties and on reasoning and consequentialist (or utilitarian) approaches aim to articulate and apply rules to fairly distribute positive or negative consequences of choices amongst a group of people. (In passing, I would mention alternatives 167 to these two broad streams, for example virtue ethics, e.g. Van Tongeren 2003, which is based on Aristotle's ideas on acting in an excellent way between extremes, and pragmatic ethics, which seeks to establish constructive cooperation between people, e.g. Keulartz et al. 2004.) Deontological and consequentialist approaches to ethics tend to focus on reasoning and on finding and applying general rules, and they tend to be based on the idea that people are responsible for their actions because they have a degree of freedom. Alternatively, I feel attracted to a kind of ethics that occurs between people, between other and self, because it evokes responsibility and freedom in a very immediate manner. Paraphrasing Levinas, the face of the other appears in front of me and appeals to me. This makes me responsible; I have to respond – even attempting not to respond would be a way of responding. This responsibility constitutes my freedom. I can experience freedom based on the appeal of the other, which makes me responsible, which makes me obliged to respond to the other. I will now loosely apply these ideas to HCD. A key idea of HCD is that researchers and designers interact with other people and that these other people can influence the project: the other people can be users (the user involvement principle of HCD) or fellow project-team members (the multidisciplinary work principle of HCD). HCD is about what can happen in these encounters between people: we may jointly learn new things and we may jointly create new things. I wish to focus on the difficulty of allowing users to participate and influence a project. If researchers and designers think about users, they tend to take themselves as examples of users. In effect, they will then create inventions for themselves; they will (implicitly) follow an 'I-methodology' (Akrich 1995) or practice 'ego-design' (a term used at Delft University of Technology). Or they may design something for an 'average user' or 'average consumer'. Interaction designer Alan Cooper (1999a) argued that it is hard to make appropriate design decisions with no particular person in mind, and that such an approach often results in poor designs and in products with too many features because there was no motivation to exclude such features. Having no particular person in mind is likely to result in 'feature creep' because software engineers are trained in imagining and taking into account all sorts of situations that may happen and for which an extra feature would seem necessary – and because nobody spoke on behalf of a specific user against these features. Thackara 168 called this 'feature drift' and described it as 'the engineering equivalent of playing with your food' (2006, p. 186). One solution for this problem is that researchers and designers attempt to empathize with users. This approach is advocated by designer and researcher Jane Fulton Suri, who drew attention to two potential pitfalls into which designers can fall and suggested empathic design as a way of navigating between them (2003a, p. 52): On the one hand, many design problems arise when we assume that everyone else is just like us. Poor design is often the result of an assumption that other people will like what we like, do things the same way we do [...] Clearly, this is not the case. People are very different in many ways. On the other hand, many problems arise when we think of other people as so different from ourselves that we think of them as 'them'. Sometimes when we observe, collect data and measure people's diverse reactions to things, we adopt a kind of objectivity more appropriate to understanding physical matter than people. We begin to behave as if other people's behavior and experiences were phenomena quite divorced from our own. Clearly, this is not the case either. [...] Empathic design is all about navigating the course between these extreme ideas. Yes, people do, say, think and feel different things and in different contexts. However, we can make sense of this and design appropriately if we use our ability to learn about, and identify with, their experience. Her advice for researchers and designers is to be aware that other people's experiences can differ from their own experiences, but not so greatly that they would not be able to understand something of what other people experience. In a similar vein, it is advocated that researchers and designers attempt to approach users with an open mind and attitude. John Thackara (1999, p. 8-9) wrote about how he recalled the first encounter with 'their' putative, future users when he was leading a project with the ambition to create Internet-based telecom products for the elderly: Someone said, "There are a lot of older people out there; let's see if we can find some and help them by giving them this Internet stuff in an easy-to-use format". So we went and found some older people and told them how we had come to help them with the 169 Internet, and they said, "Piss off!" which is apparently how they say, in some long-lost dialect, "We don't need your patronising help, you designers. If you've come here to help us, you're wasting your time; we don't want to be helped, thanks just the same. Yet we do have some interesting observations to make about our daily lives, about our lifestyles, about our communication, and about all of their attendant dysfunctions. If you could kindly change your attitude and help us explore how we will live, then perhaps we can do something together". Or words to that effect. Approaching people with the idea of creating something for them is likely to be appreciated less than approaching them with the goal of learning and creating with them. In the following sections, I will draw from texts by Emmanuel Levinas and Jacques Derrida in order to understand why it is so difficult in HCD to jointly learn and to jointly create, and to envision alternative ways of practising HCD. I will understand the problems of HCD practice by using concepts of other and self and of openness and closure. Furthermore, I will explore ways in which HCD practitioners can become more aware of and more articulate about how they move between other and self and between openness and closure, as a way of aligning their practice more closely with the potential of HCD, and I will propose reflexivity as an attempt towards doing that. Other and self I see the efforts of people who practise HCD as making moves towards the other and towards the self. For example, during an interview or workshop with users they attempt to move towards the other, and when they interpret and discuss their findings within the project-team they tend to move towards the self. I described our attempts to move towards others in the previous two chapters: towards police officers and towards informal carers, trying to understand their needs and preferences, and towards fellow project-team members with other backgrounds, trying to understand what they say. I also described our tendency to move towards the self: towards our own interests and ambitions, our own methods and skills, and to stay within our project's scope. 170 We also made ambiguous moves, for example when we decided that other people are in need and must be helped. We tried to move towards the other, who is (supposedly) in need, and offered a kind of help that fits in with our own interests, ambitions, methods and skills, our selves. This ambiguity is particularly salient since the products we were working on were intended to empower users and, at the same time, to change their behaviour in a direction that we think will benefit them: PolicePointer was developed to empower police officers to work more in a more bottom-up and self-sufficient way, rather than following top-down lines of command. WeCare was developed to motivate informal carers to share their tasks with others, rather than doing everything themselves. We tried to move towards the other and we were drawn towards the self. My argument is not that moves towards the other are good or moves towards the self are bad; I am not interested in this form of ethics. Overall, I would say that we could have moved more towards the other, but my suggestion is not that we should do away with the self. This last line may sound like a moral judgement, with which I try not to be concerned. What I mean is that both other and self are needed for HCD, and I am interested in how practitioners combine and balance moves towards the other and moves towards the self. I speculate that bringing the self to the foreground can coincide with pushing the other to the background. It would not be sensible to do away with the self because the self is what researchers and designers bring into the project and which can be valuable: their interests, ambitions, methods and skills. Dirk, for example, remarked in a positive tone that project-team members often have their own pet subjects or preferred approaches: 'Everyone, of course, has their own ideas that they want to introduce' (Transcript 31 May 2006, p. 6). He provided examples: Albert who wished to experiment with location-based mobile applications such as maps on smart phones, and Barry, who liked smart phones and tended to want to apply them almost regardless of the target group or the problem at hand. When I began this study, I thought that it would be good for HCD practitioners to have a blank mind – as a tabula rasa, a slate wiped clean – when they meet users, in order to learn as much as possible from them and absorb everything they hear and see. My idea was that they make themselves almost subservient to the users and give 171 users as much agency as possible. This would be quite different from how designers (without practising HCD) would normally work: as people with ideas of themselves and with an eagerness to create. Having conducted this study, I think that HCD is about combining and balancing self and other: not practising ego-design, not abandoning their ideas and skills, not being subservient to others, and not neglecting others. Grasping and desire I will now explore a way to understand what HCD practitioners do when they attempt to gather knowledge and learn new ideas and perspectives from and with others – joint learning being at the core of what HCD can be about. I will apply some of Levinas's ideas on how people gather knowledge and learn. Levinas wrote extensively about other and self and one way in which he did so was to write about how people gather knowledge about the world – including other people. Levinas associated the search for knowledge with a tendency to look at the world in a way that leads to 'the reduction of the other to the same' (1987, p. 48, 50): The foreign being [...] becomes a theme and an object. It fits under a concept already, or dissolves into relations. It falls into the network of a priori ideas, which I bring to bear, as to capture it. When I gather knowledge, I tend to reduce everything to concepts that I am already familiar with. I 'transmute' every Other, for example a user or a fellow project-team member and what I see and hear from this other person, into the Same, into my own way of thinking and into a framework of ideas that I already have (Levinas 1996a, pp. 11-13): The knowing I is the melting pot of such a transmutation. It is the Same par excellence. When the Other enters into the horizon of knowledge, it already renounces alterity. [...] the I of knowledge is [...] the melting pot where every Other is transmuted into the Same. Levinas argued that, when I gather knowledge about another person, I make a gesture of grasping: I grasp what I see and hear from that other person and pull that into my own frame of thinking: 172 'knowledge remains linked to perception and to apprehension and to the grasp even in the concept or the Begriff, which retains or recalls the concreteness of the grasp' (1996b, p. 152, emphasis in original). This tendency can also be thought of in terms of a devouring and digestive tendency (Critchley 1999, pp. 5-6). We, the project-team members, could not escape this tendency to grasp, to draw the other into our own 'melting pots'. Our own interests, ambitions, methods and skills – our selves – made us filter what we heard, saw and understood of the other during our observations, workshop and interviews. In our attempt to gather knowledge and to learn, we made grasping gestures and reduced – or even destroyed – the otherness of the other. As a result of our ambition to develop a we-centric telecom application, we learned slowly about police work. Only after several workshops with police officers were we able to create something that is of interest to police officers as well as our own project. Our focus on telecom brought the risk of missing the larger context of police work. Listening to what police officers were talking about, even if it seemed to be outside the project's scope, could have helped us to learn about working as a police officer. For example, from their stories about their woollen trousers, which they did not like and which their managers wanted them to wear, we could have learned about culture and politics in the police and about how innovation works (or does not work) in a police organization. Moreover, we could have drawn parallels between the introduction of woollen trousers and the introduction of something like the PolicePointer. We did discuss supposedly off-track topics such as culture and politics, but only in the margins of the project and informally, for example during coffee breaks. It was only near the end of the project, during and after the prototype field trial, that we explicitly discussed how the PolicePointer could fit in the existing police organization and how it relates to culture and politics. We then discussed a question such as: if the police are currently organized top-down and respond to incidents, how will police officers think and feel about the PolicePointer, which is intended to encourage bottom-up and more proactive working methods? In various workshops, the police officers talked about problems in their work, for example about how they balance conflicting simultaneous roles or identities such as being a 'spider in a web', 173 being a 'go-getter' on an emergency call and serving wider bureaucratic processes. Although these utterances appeared in meeting minutes, they were rarely explicitly discussed during decision-making within the project. It seems that we were not particularly interested in such aspects, or less interested than someone carrying out a non-'rapid' (or proper) ethnography. We found it difficult to appreciate how police officers experienced their work. We unintentionally missed their otherness. The police officers' otherness was also reduced when we turned our observation notes from the 'rapid ethnography' into storylines. Our observation notes were relatively vivid descriptions of how project-team members experienced situations such as arresting a thief, driving with lights flashing, wearing a bullet-proof vest or interviewing suspects. However, when we made our storylines, we omitted many of the notes about such subjective experiences and supposedly off-track topics. As a consequence, the storylines were relatively sterile. We constructed storylines with the project focus in mind and concentrated on situations where a we-centric application might be of value. We tended to move towards self. The people working on WeCare used different methods to study and represent users and their needs and preferences. We conducted survey interviews with a large group of people, in a social-science tradition, and we conducted a small number of qualitative interviews in a design tradition. The different traditions and approaches led to friction within the team. Our focus on our own respective methods and our discussions about methods may have blurred our view on the users. During one meeting we were confused about which problem and whose problem we were trying to solve. We discussed the meaning of percentages in a table summarizing preliminary survey results. The different columns in the table represented the needs of people with dementia and the needs of informal carers. The confusion was solved when we understood that many problems experienced by the people with dementia, such as a bad memory, also cause problems for the informal carers and that we were going to try to solve the informal carers' needs, for example the need for emotional or social support, and that this would also help the people with dementia. In the middle of this discussion, Dirk remarked that the project-team members themselves had a need, namely to develop a solution that fits the project's scope and to find people who have a problem that matches this solution. This draws attention to the tendency of researchers to be concerned with their own inquiries and 174 the tendency of designers to be concerned with their own creativity – at the risk of forgetting the users altogether. We wanted, of course, to learn about users' needs and create solutions for them, but sometimes our own interests, ambitions, methods and skills may have taken us away from them, rather than towards them. Another example of unintentionally missing the otherness of the other can be seen when we applied questionnaires with predefined questions and categories for answers to interview the informal carers, and when we summarized our findings in one table with predefined categories for 'problem domains'. To me, this seemed to be a relatively sterile way of working. However, Pauline once mentioned that almost all the interviewees had cried during the interviews. This fact had not been reported, nor had I asked about this. I was reducing the otherness of the other. I had assumed that conducting a survey is a relatively sterile activity and had not even thought about asking Pauline about what happened during the interviews. I looked at the numbers in the table and found these numbers sterile, whereas I could have asked Pauline to talk about the interviews so that she could have talked about the informal carers crying, and I could have better understood what happens during survey interviews and appreciated the survey results. A key goal of HCD is to interact with others – users and fellow project-team members – and to jointly learn new things. Therefore I hope that there will be some moments that I can escape the tendency to grasp to some extent. Otherwise, I would pull what I hear and see of the other into my own thinking, I would turn the other into a theme of the self and learn nothing new. Levinas suggested a way of trying to escape this grasp when he wrote about infinity and desire. He noticed that, when we think, our ideas tend to reduce the object we think of into something that our thoughts can grasp: this object is then reduced to an idea. Only the object of infinity escapes this reduction into an idea, because the object of infinity always remains larger than the idea of infinity (Levinas 1987, p. 54): Infinity does not enter into the idea of infinity, is not grasped; this idea is not a concept. The infinite is the radically, absolutely other. Levinas associated infinity with the other and explained that infinity 'occurs in the relationship with the other. The idea of infinity is the social relationship' (p. 54), which becomes manifests in the 'face of 175 the other'. Furthermore, he suggested that this idea of infinity 'at every moment thinks more than it thinks' and is a desire: This desire is unquenchable, not because it answers to an infinite hunger, but because it does not call for food. This desire without satisfaction hence takes cognizance of the alterity of the other. According to Levinas, I can attempt to relate to and interact with the other without grasping the other if I have a desire that is not aimed at satisfying the self, a desire that respects the otherness of the other. (See below: Reflexive practice, p. 191.) Openness and closure I looked at HCD as a process that happens between people, as moves between other and self. I associate these moves with the horizontal axis of Figure 1, because it draws attention to the attempts of researchers/designers and users to move towards each other. Additionally, I propose to look at HCD as a process that proceeds by means of decision-making, and as moves towards openness and towards closure. I associate these moves with the vertical axis of Figure 1. Understanding current situations ('is') requires an openness and sensitivity of HCD practitioners towards these situations and the people involved, so that they can jointly learn from them. At the same time, HCD requires that they move towards closure since they must make descriptions of these situations and draw conclusions about these. In addition, envisioning alternative or future situations ('ought') requires an openness and creativity of HCD practitioners so that they can jointly create new ideas, and at the same time they need to move towards closure since they must visualize and detail these ideas and create designs that can be turned into products. Likewise, Lester and Piore noticed that innovation managers must move their projects forward and create results, and that they often do this by creating closure. Alternatively, they suggested organizing innovation as an interpretive process, which would allow people to 'keep things moving forward without closure' (2004, pp. 49, emphasis in original). A key idea of HCD is that researchers/designers try to be open towards others and towards the ideas of others. Openness seems to be a necessary precondition for jointly learning new things and jointly creating new things. If we fail to be open towards others, we could 176 spare the effort of organizing interactions with users or of trying to cooperate in multidisciplinary teams. A focus on technology can be an example of moving towards closure because it can easily result in overlooking all manner of emotional, socio-cultural or political aspects: as if lack of technology is the problem, and as if providing new technology is the solution. As if a lack of telecom equipment prevents police officers from working effectively and as if they will simply communicate and cooperate with each other as soon as they have the new equipment. As if it is a lack of telecom equipment that makes informal carers suffer, and as if they will simply ask for help from others and offer help to others as soon as they have the new equipment. Obviously – at least in these cases – the emotional, socio-cultural and political aspects are more important than technology, both from a problem perspective and a solution perspective. Looking at the two projects in general, I think that we had problems in balancing the moves towards openness and closure. One can argue that we did not go towards closure sufficiently, that we remained too open for too long, and that decision-making was slow. In my role as coordinator, I sometimes tried to steer the other team members to stay within the scope of the project as a move towards closure: to focus on needs or problems that can be related to communication (and to neglect other problems or needs) and to develop a telecom application (and to disregard other kinds of solutions). But I was not always successful in creating closure as a way of making progress. In the work on the PolicePointer, I found it relatively easy to balance openness and closure and we allowed ourselves to gradually change the project's focus and goal after each workshop with the police officers. But in the work on WeCare, I found it more difficult to balance openness and closure because the project-team members and the organizations for which they worked seemed to have different interests and priorities. Within the WeCare project-team, frictions occurred several times, for example when we tried to define a problem to focus upon and when we tried to develop a solution for this, which can be understood as frictions between people wishing to move towards closure, make decisions and keep to them, and people wishing to move towards openness, explore alternative options and discuss prior decisions. Some preferred to make a decision about a specific feature and then keep to this, whereas others preferred to 177 explore the pros and cons of this feature and to re-think and re-do the decision-making. Some wanted to do social science, whereas others wanted to do design. Some wanted to create a specific telecom application, while others wanted to explore innovative ICT applications. I wanted to keep to the project goal and scope. I was afraid that moving too far away from that would also move us away from commitments and associated resources from the participating organizations. At the same time, I wanted to allow for a degree of openness and diversity because I was afraid of losing project-team members. I tried to allow for some openness within the project-team, and at the same time I tried to move our project work towards some sort of closure. On the other hand, one may argue that we went for closure too soon. Going for closure happened, for example in the very first workshop with police officers, when we chose to focus on the fourth problem/opportunity because it best matched our project's scope. Looking back, I think we could have allowed ourselves more openness, if only momentarily. I speculate that such an approach would have allowed us to learn more or learn faster about police work, its context and its socio-cultural or political qualities. Now we will never know what we missed, and that bothers me. We could have learned 'something that we didn't know we needed to know' (Muller 2002; emphasis in original). Going for closure also happened, for example, when we held a creative session to develop ideas for ICT applications for informal carers. Half-way through the session, we asked the participants to stay within the project's scope. We asked them to create something that was mobile, context-aware and adaptive. We then selected an idea that was very close to the WeCare application we already had in mind and to PolicePointer, which had been developed previously. We neglected two other ideas that were more out-of-the-box. Such recycling of ideas is promoted by project managers and steering committees because it can help to build knowledge and expertise. Recycling ideas is probably not a bad idea in itself, but it can become a move towards closure if it hinders joint learning and creating new things. Furthermore, I see the practice of creating personas and storylines as a move towards closure (see: Conducting observations, p. 92; Interview rounds 1 and 2, p. 139). I think that when researchers and 178 designers make personas and storylines – their own descriptions of fictional users and fictional situations – they risk reifying their ideas about other people and moving away from real users and real situations. When they face questions, they can simply turn to their personas and storylines and find the answers, rather than making the effort to go into-the-field to meet real people in real situations. I sometimes encouraged project-team members to reach some sort of conclusion as a way to create closure. As if such a conclusion, which is not supported by the people involved, is a conclusion. This happened, for example, in the July 2005 meeting, when I jumped to conclusions about the meanings of the different columns in the table. It might have been more effective to ask the people who did the survey to explain the results and to suggest what others could do with the results. Or I could have asked the others how they interpreted the table and about their ideas for applying the survey findings. A similar attempt to move towards closure happened when I invited Edith to define one problem on which we could focus. It could have been more effective to ask somebody to make notes on a flip-over pad throughout the discussion so that we would have an overview of diverse problems and jointly decide how to cope with this diversity. Although I feel responsible for reaching conclusions, for moving towards closure, I could have asked others to jointly think of ways to draw shared conclusions. Iterations The idea to organize a project in such a way that one can have iterations of design and evaluation is one of the HCD principles (ISO 1999). I understand iterations as a way of combining and balancing moves towards openness and closure. On the one hand, if one aims for closure too soon, one runs the risk of creating something inferior to what could have been created if there had been greater openness. On the other hand, if one aims for closure too late, or fails to reach closure, one is unable to draw conclusions and deliver results. Ideally, such iterations are virtuous circles that bring us further via iterations of diverging and converging phases, and allow for learning. Jan Buijs (2003) characterized the design process as 'openended, circular and chaotic' and he visualized it in the form of a circle, with phases of diverging and phases of converging – in contrast to many other and earlier visualizations of the design process as a linear process. Ideally, the participants learn during this 179 process. Similarly, Andrew Van de Ven et al. characterized an innovation process as 'messy and complex', as a 'nonlinear cycle of divergent and convergent behaviors that may repeat itself over time and reflect itself at different organizational levels' (1999, p. 212-3). They compared an innovation process with a journey on a raft, down a wild and uncharted river, and they recommended that innovation managers 'go with the flow – although we can learn to maneuver the innovation journey, we cannot control it'. Looking at HCD practice, I think we find it difficult to make such iterations, to make virtuous circles, to learn and to 'go with the flow'. We often try to make iterations, but we run in circles, returning to the same track each round, sticking to what we already have, afraid of stepping into new territory. That would be a case of too much closure and would probably not lead to learning or creating anything new. Alternatively, we often try to make iterations but fail to learn during the process. In such a case we can experience iterations as 'redundant'. This happened, for example, in the WeCare project, in which we had several seemingly unnecessary repetitions that we experienced as irritating. One way of understanding these repetitions, not as negative features of a process gone-wrong but as something constructive, comes from actor-network theory and is related to the idea of gathering allies. In order for an innovation to materialize, it is necessary that people become interested in the project, gather around it and become 'allies' (Latour 1996; Akrich et al. 2002b; Akrich et al. 2002a). Otherwise, the idea will remain only an idea in the minds of only a few people. Allies are needed to make the idea into a product. Interestingly, these allies do not always appear as friendly; becoming allies is not always pleasant. 'Allies' may seem to spoil the project, ask irrelevant questions, be unaware of decisions made two meetings ago, and repeat tasks that have already been done. The process of becoming allies can be 'like a reception where the invited quests have failed to show; in their place a bunch of unruly louts turn up and ruin everything' (Latour 1996, p. 72). Nevertheless, it is precisely because these people become involved and exert influence that an idea has any chance of becoming a product. Pauline and Edith were busy conducting their survey when Annelies and Martin joined the project and wished to do some hands-on fieldwork themselves as well. They eventually became allies, but the 180 process required many 'redundant' repetitions and negotiations about which problem to address and which kind of solution to develop. This process was not always pleasant but one can argue that it was necessary; otherwise WeCare would not have materialized. Or if a product had materialized, it would not receive the support of the people who worked on it and of the participating organizations. If we accept that we have to become allies then it can feel slightly productive when people do work that is similar to work that has already been done, or when people discuss topics that others have already agreed upon. Iterations are also difficult because project managers and steering committees seem to like the idea of research and design as a linear process; as if it were a social-science study or engineering project. But these are quite different from a research and design process. In engineering one (supposedly) starts with an assignment or brief and then proceeds via the steps of exploring and choosing alternative solutions until one has an optimum solution for the assignment or brief. Likewise, in social science, one (supposedly) starts with a question or hypothesis, develops a method and conducts a study, interprets the data and then answers the question or tests the hypothesis. I added 'supposedly' because I am aware of findings from science and technology studies (STS) that show that such efforts, when studied empirically, are not simple and linear processes but complex socio-cultural and political processes. Much of this chaos and many of the socio-cultural and political qualities are normally not reported and are glossed over as irrelevant. However, this knowledge from STS can co-exist with the observation that project managers and steering committees seem to find it comfortable to think of research and design as a linear process, probably because it gives them a sense of being able to monitor and steer the project, as if it were behaving in a linear manner. This goes together with a tendency to make linear project-planning sheets and plot project deliverables along these lines; this gives a suggestion of progress, of going from A to B. I would like to argue that an HCD project, or any research and design project, is about making decisions. There are many options open at the start of a project. At the same time, there are many uncertainties and only a few criteria to ground decision-making. Nevertheless, one has to make decisions in order to proceed: to create ideas, to choose between ideas, to turn an idea into concepts, to choose between 181 concepts, to turn a concept into a prototype, to evaluate the prototype and to turn it into a product. One proceeds by gradually bringing the 'design space' (a term used at Delft University of Technology), the space in which one can articulate problems and envision solutions, which is relatively open at the start, to a closure, step by step, decision by decision, until one has a product. Sometimes explicitly, often implicitly, one makes decisions about what problem to address, about criteria for choosing between problems, about the direction for searching for solutions, about criteria to choose between solutions, et cetera. Below, I will explore decision-making in relation to design thinking. Design thinking It has been argued that decision-making happens in a peculiar way in design thinking. Bryan Lawson argued that 'design problems cannot be comprehensively stated' and 'require subjective interpretation', that 'the number of possible solutions is inexhaustible', that no one is optimal and that the 'design process involves finding as well as solving problems' (2006, pp. 120-125). Similarly, Nigel Cross argued that processes of exploring and articulating problems and processes of exploring and articulating solutions are often intertwined: 'The problem and solution co-evolve' (2006, p. 80). Exploring and articulating problems and exploring and envisioning solutions are intertwined activities and can happen simultaneously. Furthermore, Cross (2004) observed that good designers do not spend too much time on formulating an initial problem statement, but move between problem-solving and trying out solutions as a way of further exploring the problem – in an iterative process. In that respect, the design task can be understood as a task to deal with 'wicked problems' (Rittel and Webber 1984; Buchanan 1995): problems that one can approach in very different ways and that one can only define during the process of solving the problem, and for which the different solutions are difficult to compare with each other. This interweaving of problems and solutions is especially relevant at the 'fuzzy front end' (Koen et al. 2002), in which problems and solutions are often discussed simultaneously. In their textbook on design methodology, Roozenburg and Eekels (1995) explained that design thinking, or innoduction, is different from other, 'logical' ways of thinking, such as deduction, induction or abduction: 182 • Deduction starts with two or more premises and then one draws a conclusion, for example: one starts with premises 'If Socrates is a human being, then Socrates is mortal' (p>q) and 'Socrates is a human being' (p), and then deduces that 'Socrates is mortal' (q) – this kind of reasoning is typical for mathematics or logic. • Induction starts with two or more observations and then one speculates about a pattern, for example: one observes 'if copper is heated, it expands' (p1>q1), 'if steel is heated, it expands' (p2>q2), et cetera, and induces: 'if metal is heated, it expands' (p>q) – this is typical for natural science and for some social sciences. • Abduction starts with observing an effect and knowing a process, and then one reasons backward to a possible cause, for example: based on 'there are fingerprints of X on the display from which a ring has stolen' (q) and 'if X steals a ring, X will leave fingerprints on the display case' (p>q), one speculates that 'X has stolen the ring' (p) – this kind of reasoning typically happens in history, medicine or law. Pragmatist philosopher C.S. Peirce introduced the concept of abduction and positioned it as follows: 'deduction proves that something must be; induction shows that something actually is operative; abduction merely suggests that something may be' (quoted in: Cross 1995, p. 110). Design thinking is rather different from deduction or induction and similar to abduction. Design thinking does not start with two or more premises – p and p>q in deduction; p1>q1...pn>qn in induction; or q and p>q in abduction – but it can start with only one idea. Design thinking can start with the idea that something is wrong with a current situation and with articulating a problem (q), then one imagines a way to approach the situation and try to solve it (p>q) and simultaneously imagines products that can play a role (p) – and in the process one can redefine the problem or try out other solutions. Design thinking can start with defining some desirable future situation or solution (q), then one imagines ways to make that situation happen and problems that one encounters (p>q) and simultaneously imagines products that can play a role (p) – and in the process one can redefine the desired situation or address other problems. Innovation starts with a bet, rather than with a well-defined problem or a crystal-clear brief: 'No innovation, no invention develops without this initial bet' (Akrich et al. 2002a, p. 219). Albert bet that it would be worthwhile to help community police officers to do their 183 work better, and then we imagined a telecom application that they could use to communicate with each other and that would improve their work. And Catherine and Edith bet that it would be worthwhile to try to improve the quality of life of people with dementia and of informal carers, and then we imagined a telecom application that informal carers could use to share tasks and that would improve their quality of life. However, and despite the peculiar qualities of design thinking, many HCD projects are organized and conducted as if they proceed linearly and are based on 'logical' thinking and straightforward decisionmaking. For example, in the police and informal care projects we tried first to establish a problem and then keep to it and find solutions for it. Furthermore, we tended to follow 'logical' rules when we decided to prioritize the informal carers' needs that were reported most frequently and when we selected situations for our storylines that we encountered most frequently. As if problems or situations that happen frequently are necessarily the most worthwhile to focus upon. What else could we have done? Could we have chosen a problem that struck us in a particular way? Could we have pursued a solution that appealed to us specifically? HCD is all about making decisions. Decision and invention I will now explore a way to understand what HCD practitioners do when they make decisions and attempt to create new ideas, concepts and designs – jointly creating new things being at the core of what HCD can be about. I will apply some of Derrida's ideas on decision and invention, because I think that making decisions is related to closure and invention is related to openness. Derrida argued that one can only make a genuine decision if one does not apply knowledge or logical or moral rules (1995, pp. 147-8): The only decision possible is the impossible decision. It is when it is not possible to know what must be done, when knowledge is not and cannot be determining that a decision is possible as such. Otherwise, the decision is an application: one knows what has to be done, it's clear, there is no more decision possible; what one has here is an effect, an application, a programming. 184 He calls decisions impossible because one cannot use knowledge or rules – because if one does, it would not be a genuine decision – and one still has to make a decision. Furthermore, Derrida argued that such an impossible decision makes freedom and responsibility possible (2001, p. 28): A decision, as its name indicates, must interrupt, cut, rend a continuity, the fabric or the ordinary course of history. To be free and responsible, it must do other and more than deploy or reveal a truth already potentially present, indeed a power or a possibility, an existent force. If we organize a research and design project in such a way that rules steer our decision-making, new possibilities and innovation will not be possible. Innovation can only happen if we make impossible decisions. I associate this kind of impossible decision with attempts to escape logocentrism and with attempts to think out-of-the-box. Derrida observed that people used to see 'invention' as an 'erratic occurrence, the effect of an individual stroke of genius or of unpredictable luck' and that people currently try to 'program invention' via all sorts of 'powerful movements of authoritarian prescription' (1989, p. 46). He argued that such programmed invention – which I associate with moving towards closure – leads to 'invention of the same. An order where there is no absolute surprise' (p. 55). Programming invention will keep me inside-the-box. One goal of HCD is to interact with others – with users and with fellow project-team members – and to jointly create new things. Therefore I hope that there will be moments in which I can make 'impossible' decisions and escape this tendency to program to some extent. Otherwise, I will not be able to open up to others, and I will create nothing new but only more of the same. Derrida suggested a way out of this and towards the 'invention of the other'; an approach that would welcome the other, an approach that would require a kind of passivity (Derrida 1989, p. 55-6): Yet it is necessary to prepare for it; for to allow the coming of the entirely other, passivity, a certain kind of resigned passivity for which everything comes down to the same, is not suitable. Letting the other come is not inertia open to anything whatever. No doubt the other, if it has to remain incalculable and in a certain way aleatory (one happens onto the other in the encounter), escapes 185 from all programming. [...] To invent would then be to "know" how to say "come" and to answer the "come" of the other. I understand this as a suggestion to not program invention, but to let invention happen between people, in the encounter with the other, whom I welcome. This approach may seem passive, but it requires an effort because I have to try not to make the other into an ingredient or a theme within my own programme. (See below: Reflexive practice, p. 191.) Other interpretations So far, I have interpreted and discussed what we did in the project by drawing from literature. But other interpretations are possible, based not on the literature but on our practice – on how we conducted the project and my role in it. For example, one may argue that I was a bad coordinator and that I should have organized the project better. One of the things that 'went wrong' is that people found it difficult to cooperate: the people working on the PolicePointer cooperated relatively well within the team but cooperation with the police organization was difficult. The people working on WeCare also had difficulty working together within the team. Another thing that 'went wrong' is that the project as a whole proceeded slowly. I will provide some background information that will aid the understanding of the project and my role in it. The project was planned to run for four years (2004-2008) and it was expected that we keep to certain themes, which we had agreed upon beforehand and which were described in the original project plan. This made it difficult to accommodate changing insights. Furthermore, the project was organized in three separate work packages: one about users, one about business, and one about technology. This made it difficult to work across disciplines. Moreover, project-team members came from different organizations, which often had different interests or changing priorities. Almost all the team members were assigned to the project on a part-time basis, and they came from around the country, which made face-to-face meetings relatively difficult to organize. Sometimes, several months passed between project meetings and different people would participate or not participate in these. Additionally, there were some unfortunate personnel changes, especially with regard to people with 186 coordinating tasks. All of these factors together resulted in a difficult and slow project. Furthermore, my role as coordinator of one part of the project was similar to that of a middle manager. I tried to match what was handed down by management, such as budgets or planning sheets, to what was happening on the shop floor, where the project-team members were involved in the research and design work. However, if I take seriously the quotes of Levinas (above), such an explanation would not diminish my responsibility. My responsibility is always already there, and it creates freedom. I have to respond to questions about how we conducted the project and about my role in this, and I can choose how to respond. One way in which I tried to respond is by trying to support learning within the team, for example by organizing meetings in which I shared my understanding of what we did in the project and let others share their ideas about the project (see: Reflecting on the project, p. 112; Reflecting on the project, p. 147) and by organizing a meeting in which I shared my tentative conclusions and recommendations and invited others to discuss these (July 2007). I tried to speak responsibly and freely in these meetings, but I found it difficult to do this; discussions would easily move towards what 'went wrong' or towards discussing content. I found it hard to foster an open atmosphere and to facilitate jointly learning. Concerning the influence of my role on the project and on my interpretation and discussion of what happened in the project, I speculate that, even if I had managed to organize the project in such a way that cooperation with users and other project-team members had been more smooth, I would still be able to see moves between other and self and moves between openness and closure. Possibly I would see these moves less clearly if cooperation ran smoothly and possibly I would need more subtle analyses or more elaborate examples, but I speculate that I would still be able to create a similar interpretation, discussion and argument. Another reaction to my interpretation and discussion could be that I quote Levinas and Derrida out of context. This happened, for example, when I presented a paper on Levinas and innovation (Steen 2004). A professor of ethics remarked that I need not and indeed should not apply a serious philosopher like Levinas to a mundane activity such as designing products. What can I say? I hoped that these philosophers would help me to understand HCD practice 187 differently and to envision alternative HCD practices. Moreover, there were moments when I felt uneasy about making references to Levinas and Derrida, about grasping bits and pieces of their texts, using them as parts from a supplier's catalogue, fitting them within my own programme, drawing them into my own frame of thinking. At such moments I feel uneasy about not bothering with the significance of Levinas writing about the Other (with a capital letter) and paraphrasing him in terms of the other (in lower case). I am aware that Levinas wrote religious texts such as commentaries on the Talmud, that Derrida wrote about messianism, that both drew from Jewish traditions, and that both authors took the reading and writing of texts very seriously. Anther reaction to my account is that I am splitting hairs and making things overly and unnecessarily complicated. One can consider HCD simply as a tool with which researchers and designers can create innovations and one need not focus on the process, but on the results. So what if researchers and designers make grasping gestures and destroy the otherness of the other? So what if they program invention and create more of the same? So long as it delivers product, it is fine. I can think of two reactions to such comments. One reaction would be – and I will try not to moralize – that I point to the HCD principles (ISO 1999) in which I read an appeal to HCD practitioners to be open towards users and towards other project-team members and point to the possibility for HCD practitioners to align their practice more closely to their principles. Of course, one is always free not to do HCD or not to call it 'human-centred' design. Another reaction would be to point to the many ICT products and services that people do not want to use or cannot use. My suggestion would be that HCD practitioners apply their ambitions and skills better – or effectively and efficiently, if this terminology appeals to them – and create innovations that better fit people's needs and preferences, and that HCD, as I understand it, offers a way towards that. I was only trying to help fellow practitioners. Imagine that you were organizing an HCD project, that you were going through the effort of interacting with users – you would, for example, visit them in order to talk with them or you would invite them to creative workshops. And imagine that you were going through the effort of creating and organizing a multidisciplinary project-team comprising people with different backgrounds and skills. Then imagine that the people involved are not open to each 188 other. I can imagine that they would stay within their own boxes and would find it hard to jointly learn and create new things. Reflexivity (2) I have shown some differences between HCD principles and HCD practice. Additionally, I will envision other ways of practising HCD, more in line with what HCD can be about and I propose to organize my recommendations around the concept of reflexivity – which I associate with deconstruction and with ethics. My reflexivity was an attempt to deconstruct my own practice: to look at my practice, to draw attention to what I was unable to do, and to envision what I could have done. This proved to be difficult because I was inside my practice and could not easily deconstruct it from the inside. Furthermore, I would like to argue that such reflexivity occurs – if it occurs – between people, between other and self in the here and now of an encounter. Such reflexivity is closely related to my understanding of ethics: it is enabled by the other who asks me questions about my role and asks me to respond; the other thus enables my responsibility and my freedom. I feel tempted to distinguish between two kinds of reflexivity that correspond to my analyst role and my practitioner role. I encountered reflexivity as an analyst when I attempted to reflect on a project in which I was involved. As a practitioner, I encountered reflexivity while working in a project and reflecting on my own role in it. But, of course, these two kinds of reflexivity were connected. Moreover, I will recommend that practitioners combine these reflexivities; reflexivity will be a key ingredient for an alternative way of practising HCD that I will explore below (see: Reflexive practice, p. 191). I encountered reflexivity in my methodology and tried to see it not only as bug but also as a feature (see: Reflexivity (1), p. 70). I often found it difficult to combine practitioner and analyst roles because of reflexivity. And I did not always like it when people questioned me about my dual role or asked me to be reflexive. I tried to write reflexively and I found it difficult, yet I would recommend reflexivity to HCD practitioners as a way towards learning and as a way to bring their practice closer to their principles. 189 I understand reflexivity as the realization that practising HCD is a procedure of researchers and designers and, in a sense, similar to procedures of users (see: Traditions of reflexivity, p. 73). Reflexivity creates a connection between the procedures of users (which I would normally think of as happening on a content level) and the procedures of doing HCD (which I would normally think of as happening on a process level). Reflexivity may occur if there is a relation between what happens on a process level to what happens on a content level; if they are treated not as if they are separate. Reflexivity is like applying a tool that I would normally apply to others, to myself. The arrows that I would normally shoot at others are now being fired in my direction – and that can hurt. Let me review four situations to illustrate this type of reflexivity. Reflexivity could have occurred when the police officers' manager became irritated and asked me to respond (see: A police officer's manager talks back, p. 98). What I did not do, but what I could have done, is to react in the here and now of that encounter. I could have tried to see non-cooperation and power not as negative features obstructing 'my' process, but as features of a process occurring between him and me, between other and self. I could have tried to make these topics – cooperation and power – explicit in my discussion with the manager, within our encounter. This could have helped to discuss cooperation and power on a process level, our encounter and our mutual irritations, as well as on a content level, about the problem that we wished to address in our project, with our PolicePointer. Reflexivity could also have occurred when I was being questioned about the lack of cooperation between the project-team members working on WeCare and about my role in it (see: Attempts to improve cooperation, p. 136). What I did not do then, but what I could have done, is to make explicit and discuss my own concern to improve cooperation. I could have asked my fellow project-team members to think about and discuss ways to improve cooperation with each other. Making explicit my own concerns could have helped others to speak about theirs, and this could have helped to improve cooperation. I could have related what happened between ourselves, on a process level, to what we are working on, on a content level: to improve cooperation. 190 My colleague Mandy once asked me, informally: 'Why do you write so negatively about our project? Haven't we done our best, given the circumstances and the context of the project?' I would point out that Mandy and I have been cooperating in this project since the start, that we cooperate in other projects as well, and that we get along rather well. The background of her question is that clients of our commercial projects often find it difficult enough to understand a simple version of HCD and its benefits – so it is better not to bother them with complicated details and farfetched philosophical concerns. Furthermore, she asked me why I give out such an ambiguous message: I practice HCD and I preach its shortcomings. Perhaps I am turning into a narrow-minded specialist, unable to talk normally about HCD. More likely, I feel concerned about the importance and the difficulty of HCD – about its fragility – and I would like to handle it with care. If I were to position HCD as not very important, then I fear that it would be off the agenda in no time, overruled by economic or technical concerns. And if I were to position HCD as not very difficult, then I fear that it would turn into something like doing usability tests at the end of a project. HCD would then lose the potential that I see in it. The next time Mandy or someone else asks me such questions, I could try to articulate my concerns so that others may understand them and perhaps appreciate my ambiguous gesture. At the meeting in which we reflected on the WeCare project, Martin bluntly asked me whether I had intentionally let our project derail: 'Has Marc consciously kept the project unstructured, so that he could conveniently research how [a badly organized project] works?' (Transcript 4 July 2006, p. 25). I took fright at that question. On earlier occasions, I had observed how carefully Martin formulates his remarks and questions. He is one of the few people in the project who frequently asks others questions in order to better understand other team members. My first reaction was to feel attacked. I talked for about two minutes about how in my study of the project – and in writing the paper about the project, which we were discussing – I went through reports, meeting minutes and notes we made, and how I thus developed a more detached position from which I was able to see the project and its shortcomings – and how I was unable to look upon the project and see its shortcomings while we were in the middle of it. So, in my role as project coordinator, while engaged in it, I had not seen the project derail, and it was only with hindsight, in my role as analyst, that I saw how the project had derailed. At the 191 end of this monologue, I pleaded not guilty: 'I would never let it go all wrong for the sake of research. I am not that kind of person'. Why did I talk for two minutes? Why did I not simply say: 'No, that is not what I did, and I will explain what I did' or 'Yes, that is what I did, and I will explain why I did it'? It is hard for me to recall what I did and why I did it. I suppose I tried to steer the project, but there were other forces, outside my control, which caused it to derail. I suppose I saw the project as a learning process in which there is room to make mistakes. Reflexive practice Based on my study of HCD practice and of the differences between the principles and practice of HCD, I would like to suggest that HCD practitioners become more reflective and reflexive. My recommendation is that HCD practitioners move towards reflexive practice. I would argue that HCD practitioners tend to move too much towards the self, they grasp the other and learn nothing new, and that they tend towards closure rather than towards openness, they program invention and create nothing new – and that they are mostly unaware of and not very articulate about making these moves. My suggestion is that HCD practitioners become more aware of and more articulate about their own roles, their own interests and concerns, and about their relations and interactions with others, with others' interests and concerns. My suggestion is that they become more aware of and talk more explicitly about the moves they make between other and self and between openness and closure. I speculate that, if one is aware of these moves, one can try to make different moves or make the moves in a different way, and that if one is articulate about these moves, one can provide an account to others and make oneself accountable to others and the questions of others. I speculate that being more aware of and more articulate about making these moves can be a way to escape the grasp and to learn new things together, and to escape this programming and to create new things together. My suggestion is to be aware of and articulate about what happens between people, in the here and now, on a process level, in addition to attention for the content level of the product that is being developed. I speculate – and this will remain a mere speculation 192 within this text – that relating what happens on a process level to what happens on a content level could be a way to attempt to bridge the gaps between 'them' (users) and 'us' (researchers/designers) and between 'is' (a current situation) and 'ought' (an alternative or future situation). We think that they experience problems with certain themes, such as communication or cooperation, in their current situation, and we wish to solve these problems for them and envision alternative or future situations for them, but we ourselves are struggling with these same themes, such as communication or cooperation. So they may be able to tell us interesting things about these themes, not only on a content level relating to the product, but also on a process level relating to the dynamics within our projectteam. That would turn the tables around. We are used to them having problems and us having solutions, and may be unpleasantly surprised if they were to question us and our process or suggest recommendations or solutions for our process. Perhaps we are struggling with similar themes and could learn together about our problems and create solutions together. Reflexive practice would take seriously what happens between people, in the here and now of an encounter. If I make a storyline about police officers, then a police officer can talk back and ask me to respond to his questions about these storylines – especially if I relate the politics of representation in storylines with the politics of the police officer's intervention. And if cooperation between project-team members is difficult, then I can make explicit my concern to improve cooperation – especially since we are working on an application that is designed to improve cooperation between people. If I study a project and talk and write about it, then I must be prepared to respond to my fellow project-team members when they ask about how I study that project and talk and write about it. My suggestion is to move HCD towards reflexive practice, which I see as a combination of action and reflexivity – see Figure 8, p. 67. Let me point out that by reflexive practice I mean something different than reflective practice, a concept of Donald Schön, which was, for example, used by Kees Dorst and Rianne Valkenburg to study and understand design activity. Reflective practice is understood as a process in which a designer approaches a (design) problem and explores (design) solutions (Dorst 1997, p. 65-73). This process of 'reflection in action' can be understood as a cyclic process of 'naming the relevant factors in the situation, framing the problem in a certain 193 way, making (experimental) moves toward a solution and reflecting [on] those moves' (Valkenburg 2000, p. 58). Reflective practice draws attention to what happens on a rational or cognitive level when people approach problems and explore solutions. Alternatively, with the term reflexive practice, I wish to draw attention to what happens between people in a research and design process and to the ethical qualities of those relations and interactions. In my comments on grasping and desire (p. 171) I wrote about how, if I have a certain kind of desire – one that does not approach the other as an instrument to satisfy the appetite of the self – I can (to some degree) escape my tendency to grasp the other, which would normally destroy the otherness of the other, so that we can jointly learn new things. And in my comments on decision and invention (p. 183) I wrote about how, if I have a certain kind of passivity – a passivity which welcomes the other – I can (to some degree) escape my tendency to follow rules and program invention, so that we can jointly create new things. So, my suggestion for practising HCD differently would be based on desire and on passivity – it would be based on attempts to be open towards the other. My suggestion is to try to counter my tendency towards self and closure by attempting to be more sensitive and responsive to the other who brings my self into question. This would be similar to Critchley's description of ethics as 'the critical mise en question of the liberty, spontaneity, and cognitive emprise of the ego that seeks to reduce all otherness to itself' (1999, p. 5). Or, as Levinas (1996a, p. 17) put it: The putting into question of the self is precisely a welcome to the absolutely other. The other does not show it to the I as a theme. The other putting me into question can help me to welcome the other and it can help me to act responsibly and freely; responsibly in the sense that the other questions my self and that I have to respond, and freely in that I can and must choose between different possible responses. My suggestion for reflexive practice can also be understood as a suggestion that HCD practitioners attempt to step out of their professional roles and interact in the here and now with other people, with users and with other project-team members, and that they relate what happens on a process level to what they try to do on the content-related level. My suggestion is that HCD practitioners 194 attempt to encounter other people and pay more attention to process, relations and interactions. Here are two situations from other projects in which I tried to step out of my role because another person asked me to respond. Some years ago, I held a workshop with a group of ten people of about 50 years old. This was part of a project for a telecom operator in which we explored the future of ICT through the perspectives of three groups of people: one of about 20 years old, one of about 35 years old, and one of about 50 years old. I facilitated one workshop and two colleagues facilitated the other two workshops held at the same time. We had collective starting and closing sessions in which all participants interacted which each other across the three groups. The discussion in my group of older people drifted towards ringtones for mobile phones and how young people spend too much money on these. One man remarked 'But that's fine with you [addressing me], of course, you [possibly also referring to the telecom operator we did the project for] want to sell as much as possible' (paraphrased). I then stepped out of my role of researcher and spoke with him and the others about my unease with working for a company that seems to have different ideas than me about innovation and marketing. We talked further about our concerns for young people who use their mobile phones too much or spend too much money on them. After that, I stepped back into my role of researcher and the discussion continued. Another example is from a recent project in which we held a participatory design workshop with employees from a call centre. This workshop was part of a larger project in which an office chair was developed with a specific function in it, enabled by an innovative technology. The goal of the workshop was to develop ideas for other functions based on this technology. We did not disclose the technology and function until the second half of the session, because we thought that not knowing about this would help them to generate ideas more freely. In the first half of the workshop we had a brainstorming session about 'an ideal office chair'. The participants wrote their ideas on sticky notes and I then clustered these on a flipover pad and prioritized the clusters. One of the participants interrupted and remarked that we were not being fair: 'You let us drift for half an hour. I feel as if you manipulated and used me. Why didn't you just put your cards on the table?' (paraphrased). He noticed that we were privileging ideas that were close to the 195 technology for which we wanted to develop new functions. He was not supposed to know about this technology. He explained that he had learned about it during the process of inviting him. Then I explained my position and why I had chosen to wait to disclose the technology. It took us some time to understand each other's position. He then insisted that we proceed with the workshop as planned – which we did. These are examples of situations in which a 'user' interrupted 'my' process in a way that I experienced both as embarrassing – as if I was being caught doing something bad – and as an invitation to respond. I reacted by stepping out of my expert role of conducting a workshop and by providing an account of what I was trying to do in the workshop. I think that such interruptions and responses make a constructive contribution to the process – although I cannot say exactly how they influence the outcomes of this process. Fragility Let me make a few remarks about the word 'fragility' in the title of this text. I was looking for a title that would not only denote what it is about, but also convey a message. I had heard of Martha Nussbaum's book The fragility of goodness (1986) and I felt that 'fragility' could convey my main message about HCD because it has an ambiguity: it can refer to being 'delicate and often beautiful' as well as to being 'easily broken or damaged' (Oxford Advanced Learner's Dictionary, 7th ed.). I think that HCD is both a beautiful and a vulnerable process. Furthermore, I can draw some parallels between Nussbaum's book and my project. She wrote about classical Greek tragedies and classical Greek philosophy and how these texts treat ethics. She argued that the Greek saw ethics as a technè, a construction of man, such as science, technology, arts or crafts, which can help people towards eudaimonia, to live a good and happy life, in a world in which tuchè random things outside my control – can affect people at any time. She described how a tragedy shows people in very difficult situations, in which tuchè hits hard, and how people act in these situations. A choir comments on what the people do and suggests interpretations and evaluations. Nussbaum argued that a tragedy is a technè and that it contains ethics, in that it is meant to help people in the audience learn how to live the good life and how to deal with 196 tuchè. She felt attracted to this approach to ethics because it deals with situations in which people's lives are vulnerable, with situations in which one must choose between conflicting but equally important values – often with disastrous outcomes – and with situations in which one experiences and suffers from passions and obsessions. If I apply Nussbaum's concepts to my project, then I can see HCD as a technè, a man-made construction to create products intended to help people to live the good life. But the world is not ideal, there is tuchè: many things happen outside my control. As an HCD practitioner I sometimes felt like an actor in a play. I leave it to the reader's imagination to decide what genre that play could be: a tragedy, a comedy, an absurd play or a mixture of these. I found myself in situations in which people's lives are vulnerable. This struck me when one police officer, with whom I spent a working day during the 'rapid ethnography', took a man from his flat into custody while the man's children were playing on the street. The police officer told me that this had happened before and that his children have a door key on a cord around their necks. I felt awful with the idea of the children growing up in this way, and I would not like to be in the role of the police officer. I would not know what to do – let the man free so he can take care of his children, lecture the man about the consequences for his children, coach the man so that he can develop better parenting skills, et cetera. And it struck me when Rachel or Pauline talked about their interviews with informal carers and how difficult these people's lives can be. On several occasions, Rachel told me how she was affected by what the informal carers told her during interviews, especially when one older woman told her that she does not want to let other people care for her husband, who suffers from dementia. She felt that it was her duty and an act of love to care for him – even when the burden was becoming too heavy for her. In addition, I experienced situations in which I had to choose between conflicting interests, for example those of the organization where I work, of the organizations where fellow project-team members work, or those of the project as a whole. And I found myself feeling passionate about, for example, a certain approach to research and design or feeling biased against other approaches. I often wished we could cooperate more effectively, more constructively – but I could not make that happen and I felt unhappy about this. In short, I like the idea of HCD as a fragile process and I feel attracted to seeing HCD as a process in which 197 vulnerable people participate and must choose between their and other people's values and deal with their own passions and obsessions. Topics and perspectives outside the scope of my study There are several topics and perspectives that relate to my study but which I have chosen to position outside the scope of my study. Some of these topics may be interesting for further research. I can imagine questions about the benefits of practising HCD: about how users evaluate the products that come out of an HCD process and about whether these products are successful. I focused on what happens within an HCD project-team and was not very concerned with any 'external' 'effects' of HCD. (I write 'external' with quotation marks to show that I am aware that a distinction between internal and external is arbitrary; I simply drew a line between what I call internal and what I call external. Furthermore, I write 'effects' between quotation marks to show an awareness that a distinction between causes and effects is artificial if we take seriously the idea of mutual influences between people and technology.) I did not study such external effects for several reasons. Most importantly, I wished to remain within a social constructionist paradigm. It has been suggested that I study – as a minimal version of studying the benefits of practising HCD – how users evaluate the designs that we created with/for them. We could, for example, do interviews or questionnaires with police officers and informal carers to learn about how they evaluate the PolicePointer and WeCare. We did, of course, organize workshops and interviews in which police officers and informal carers could discuss the ideas, concepts and prototypes during the research and design process, but we did not ask them formally to evaluate the designs as end-results. This was not (yet) possible because the prototypes were only prototypes and they could not be used for a realistic evaluation, for example in a field trial. Another reason for not doing such an evaluation of the end-results is that it would introduce a positivist paradigm to my study, which I do not want. My study is currently based on a social constructionist paradigm, which holds that people, in their interactions, create, recreate and experience reality. This is different from a positivist/realist paradigm, which holds that reality exists externally to me and that I can measure it. I could have interviewed police 198 officers or informal carers about how they evaluate the product but then I would slip into a positivist paradigm: as if I can measure 'real' reality that exists out-there. More subtly, I could have interviewed the police officers or informal carers and studied how the project-team members interpret the outcomes of such interviews. But then I would not capture the users' perspectives; I would only capture how the researchers and designers attempt to capture the users' perspectives. Normally, within an HCD project, I would be interested in what users do and what they say, but within my current study, I chose not to be overly interested in how users evaluate the end-results of our project. Furthermore, I chose not to study the success of the results from HCD. It would seem very difficult to conduct such a study. There are examples of 'excellent' companies from Peters and Waterman's book In search of excellence, which many evaluated as less excellent relatively soon after the book was published, and there are examples of 'successful' products from the SAPPHO studies that were considered less successful shortly after the study (cf. Buijs and Valkenburg 1996, p. 264). There are so many questions one must address when writing about success. Successful in what sense? Technological, economic or societal? Successful for whom? For the manufacturer, for the resellers, for customers or for users? And at what stage shall we measure it? At the time of launch, after six months, or after five years? And how will we quantify success? In terms of units sold, usage frequency, cost reduction, additional revenues or increased market share? I am not saying that it is impossible to study success of innovation or design projects, only that I did not do that and that I think it would need another type of study and that such a study should be conducted carefully. Moreover, studies of different processes are more difficult than studies of different products. It would be relatively easy to design an experiment in which one studies product A versus product B, but it would be more difficult to organize to study process A versus process B. I can imagine an experiment in which a team of five people work for one year with an HCD approach and another team of five people works for one year without an HCD approach, as a control group, and in which one would compare the results of these processes. But this would be a costly experiment and it would be difficult to control the context, which would typically be necessary in an experiment. Alternatively, one could organize an experiment in a lab setting and, 199 for example, let the two project-teams work for a few days in a lab, one working with HCD and one working without HCD. However, I suppose that people would question the generalizability or practical relevance of such an experiment. Additionally, I can imagine that other practitioners or scholars can interpret and discuss the same empirical data (chapters 4 and 5) in very different ways, with other foci or perspectives – see Analysing Design Activity (Cross et al. 1996) for an example of twenty different analyses of the same empirical data. That would, of course, be interesting and relevant. I did study HCD practice and I focused on how participants interacted with each other. I did not pay much attention to people's inner lives or their experiences (except my own) and I neglected much of the participants' socio-cultural and political contexts. Nevertheless, I can imagine that other researchers would be interested in participants' inner lives or experiences and would study these via psychology perspectives, or would be interested in participants' socio-cultural or political contexts and would study these via ethnography or sociology perspectives. In addition, I can imagine a range of questions about professional roles, professionalism and expertise. I was primarily concerned with the professional roles of researchers and designers, and with their professional responsibility and freedom within the project. As if separate responsibilities and freedoms are attached to their different roles. I chose that focus because I am interested in professional roles. For example, I could be interested in what motivates people to become teachers or nurses, in their ambitions to help other people to learn or to care for others, and in what came of their ambitions after they started to work as teachers or as nurses. Possibly the organization in which they work provided them with opportunities to practise what they wanted to do, and possibly the organizational context prevented them doing what they originally wanted to do because they had to do other tasks or because there were practical limitations. I suppose that people, when they work within an organization, can experience positive as well as negative influences from the organization. I can imagine research into HCD practitioners' professional roles and their experience of responsibility and freedom, and whether and how these differ from their more private roles and feelings of responsibility and freedom. 200 Finally, I can imagine questions concerning my recommendation to practise HCD differently, for example: What would happen if HCD practitioners were to act more reflexively? What would happen if researchers and designers and their managers were to become more aware of and explicitly discuss their attempts to move towards the other and towards otherness, and their tendencies to move towards the self and towards closure? It was not until we were approaching the end of the project that I was able to articulate my recommendations, so I had little opportunity to apply them or try them out. Therefore, it would be interesting to further research reflexive practices of HCD. 201 7. Conclusions and recommendations My study was exploratory and it was not my goal to deliver definitive answers, but to contribute to a discussion about humancentred design (HCD). I would like this last chapter to function as an opening chapter (symmetrical to the first chapter, which I presented as a closing chapter). Ideally, this text would function as a 'turn in a conversation' (Steven D. Brown, personal communication 2006): people have been discussing HCD for some time, then I contribute some 200 pages to this discussion and the conversation will continue and others take their turn. About form (2) I did ponder upon an appropriate form for my conclusions and recommendations. I entertained the idea of writing them in the form of scripts, similar to the scripts in the first chapter. With that idea in mind, I organized a project-team meeting (July 2007) in which I discussed my tentative conclusions and recommendations with my fellow project-team members. I recorded, transcribed and analysed the meeting and started to write drafts, but I drifted towards writing a form of dialogue in which my fellow project-team members said exactly what I wanted them to say – as if they were glove puppets and I was the ventriloquist. Alternatively, I chose to present my main findings in the form of several pieces of monologue. I hope that this form can help to create a kind of openness via which others can relate to my findings and react to them. In response to discussions about my findings and in order to facilitate further conversations, I added brief discussions on legitimacy (related to my conclusions) and on realism (related to my recommendations). Finding a form in which to present my recommendations was especially difficult for me, because I associate recommendations with 202 a prescriptive form, for example: 'You must do X!' Such a form would fit awkwardly with my view on HCD, which I see as a process of joint learning and joint creating, and as rather different from giving or obeying orders. My key recommendation would be something like: 'Be reflexive!' But this would be an example of 'paradoxical communication' (a term of communication theorist Paul Watzlawick). The content and form of the message do not match; other examples would be saying to somebody that he or she must be spontaneous or be creative. Conclusions My research started with uneasiness and curiosity. I work as a practitioner in research and design projects in which we attempt to follow HCD approaches and I felt uneasy about my own HCD practice. The principles of HCD appear to be relatively simple: researchers and designers involve future or potential users in their activities; they attempt to cooperate constructively with them and they organize their project in iterative phases of design and evaluation and as multidisciplinary teamwork (ISO 1999). However, it seems to be difficult to put these HCD principles and best intentions into practice. I became curious about our HCD practice and I formulated a relatively open research question: What happens in human-centred design practice and how does this differ from the theory and principles of human-centred design? My study was an attempt to open the 'black box' (Latour 1987; Winner 1993) of HCD practice and study what HCD practitioners, including myself, actually do. In another vocabulary, my study was an attempt to 'deconstruct' (Derrida 1991; Critchley 1999) HCD practice: to draw attention to qualities that usually remain hidden and to propose alternative practices. To that end, I conducted desk research and an empirical study. I reviewed several different HCD approaches and argued that different approaches to HCD can be understood as different attempts to bridge the gap between researchers/designers and users, and as different attempts to combine concerns for understanding a current situation and concerns for envisioning future situations (Chapter 2). My empirical study was done by conducting 'participant observation' (Chapter 3) in one project in which we applied various HCD approaches while 203 designing and evaluating two ICT applications together with users: one with/for police officers (Chapter 4); and one with/for informal carers (Chapter 5). I had several roles in these projects: I worked in research and design roles, I coordinated parts of the projects, and I studied the projects and wrote about them. In the police project we held a series of workshops with different groups of police officers as part of our research and design processes. Each interaction had a degree of influence on our project; we gradually changed our project's goal and focus, which resulted in a telecom application that is interesting both for police officers and for our project. This application, the PolicePointer, helps police officers to share 'implicit' knowledge with each other and to improve their police work. This way of working – allowing users to influence the project – is considered good practice in HCD. However, we unintentionally missed several opportunities to learn about police work and to let the police officers participate more actively or creatively in research and design activities. This drew my attention to our tendency to follow our own agenda, designing a telecom application, which gave us a blinkered approach. This illustrates the difficulty of being open towards the other, towards users, and the tendency to move towards the self. In the informal care project we had difficulties in cooperating within the project-team. We did several 'redundant' activities: we conducted several series of interviews, we repeatedly discussed which problem to address and which solution to pursue, and we re-invented a telecom application several times. Project-team members followed different research and design approaches and found it hard to combine these constructively. This drew my attention to the difficulty of being open towards the other, towards other project-team members. Furthermore, it illustrates the difficulty of making constructive iterations of research and design and of balancing moves towards openness and towards closure. However, and on the positive side, the key problem remained relatively constant: to improve the quality of life for informal carers and the people they were caring for. We created a telecom application which is interesting both for informal carers and for our project. This application, WeCare, can help informal carers to share and coordinate care and other tasks with other people. 204 On the basis of these two cases, I argued that I can understand HCD practice as a socio-cultural process in which researchers and designers, together with users, try to jointly learn and create new things. Furthermore, HCD can be understood as a political process in which the people involved try to exert influence on the project. Ideally, this would be in line with the HCD principles of users contributing to the project and of multidisciplinary teamwork. However, this perspective of HCD as a political process also shows how researchers and designers tend to represent users, for example by creating personas or storylines, and to talk about them and make decisions for them, rather than allowing users to be present and participate directly in discussions and decision-making. Moreover, I conceptualized HCD as a process in which project-team members make moves between other and self and between openness and closure. Sometimes we tried to move towards the other, for example when we tried to listen to users or to other project-team members, and we tried to move towards openness when we tried to jointly learn and create new things. Simultaneously, we tended to move towards the self when we foregrounded or privileged our own interests, ambitions, methods or skills, and we tended to move towards closure when we focused on drawing conclusions and on creating results. I interpreted and discussed these moves by borrowing several ideas from the philosophers Emmanuel Levinas and Jacques Derrida (Chapter 6). When I approach the other in order to learn, I tend to grasp the other: I tend to draw the other towards the self, into my own frame of thinking, so that I cannot see the otherness of the other – and I run the risk of learning nothing new, only what I already know. Likewise, when I organize a project, I tend to want to create and follow a programme: I tend to want to control the process, to stay within my own box, to go towards closure rather than towards openness – and I run the risk of creating nothing new, only more of the same. I concluded that HCD practice has ethical qualities – ethical in a Levinasian or Derridaen sense – and that these qualities usually remain hidden and are seldom explicitly taken into account when organizing or conducting HCD. My proposal is to understand learning and creativity in HCD practice as happening not within one person, but as happening between people. Ideally, such learning and such creativity happen in face-to-face encounters in which the other can remain the other, in which the self can be open towards the other and can be questioned by the other. 205 This is not to say that researchers and designers cannot or should not contribute their interests, ambitions, methods and skills. On the contrary: they can contribute these to a project in a constructive way, and if they wish to take HCD seriously, they can attempt to combine them with users' and other project-team members' interests, ambitions, methods and skills. I probably take the assumptions behind HCD more seriously than is commonly done. A strongest version of my conclusion would be to say that it is impossible to do HCD. A more nuanced version would be to say that HCD is fragile: that it can be beautiful and that it can break easily, that it is difficult to practise HCD, and that one can try to practise HCD more in line with what it can be. These findings have theoretical as well as practical implications. My findings can contribute to a debate about innovation, design and ethics. My study was conducted within a science and technology studies (STS) tradition, in which most studies stay away from ethics. In that respect, my focus on ethics is intended as a contribution to 'help STS to overcome its normative sterility' (Van de Poel and Verbeek 2006). Furthermore, in the context of engineering and design, deontological or consequentialist approaches to ethics tend to dominate, so my application of ideas on ethics of Levinas and Derrida is innovative. Moreover, my study of HCD from an STS perspective and my combining of practitioner and analyst roles is innovative and created a unique chance to study HCD behind-thescenes: from within and over an extended period of time. On a content level, my study of how researchers and designers construe users by creating personas and storylines (descriptions of fictional users and situations in which they use the product being designed), contributes to the study, in STS, of how researchers, designers and the like attempt to 'configure' (Woolgar 1991a), 'script' (Akrich 1992) or 'represent' (Rohracher 2005a) users while they develop products for them. Legitimacy Let me briefly discuss legitimacy. In the project and my study of it, I combined four very different traditions: • A instrumentalist tradition of design, based on ideas of progress and of creating, improving and applying technology; 206 • A tradition of HCD and, more specifically, participatory design, based on ideas about participation, democracy and emancipation; • A tradition of science and technology studies, where one tends to be descriptive and detached and tries to stay away from ethics; • A tradition of the 'difficult' philosophers Emmanuel Levinas and Jacques Derrida and their ideas on ethics. This combination of traditions raises questions about legitimacy. In the project we mainly worked within a design tradition of creating, improving and applying technology. I sometimes tried out forms of participation and democracy, but this sometimes made the decisionmaking go in all directions, which was not always conducive to making progress in the project. Moreover, I combined practitioner and analyst roles, which must have been puzzling for my fellow project-team members sometimes, and which made them ask me questions: Martin asked me whether I had intentionally let the project derail so that I could study an interesting process, and Mandy asked me why I was so negative about our HCD approach that we also try to sell as consultants (see: Reflexivity (2), p. 188. Legitimacy means something different in different contexts and, looking back, I think I was not always aware and also not explicit to others about the different contexts from which I was acting. I was not always aware and articulate about my different roles and about how I would like to legitimize my actions. For me, this was a key learning experience, namely to try to be more aware and articulate about my own role – which is also a key recommendation for practice. Recommendations My main conclusion is that HCD practice has ethical qualities and my main recommendation is to take these ethical qualities into account when organizing and conducting HCD. It is assumed that researchers and designers can simply and constructively cooperate with users, that they can be open towards others, and that they can jointly learn new things and jointly create new things. However, people – including HCD practitioners – tend to move towards the self and towards closure: to grasp the other and risk learning nothing new; and to program their project and move towards closure and risk creating nothing new. When I presented these conclusions to my colleagues (May 2008), they asked me what we can do about that: Can we improve HCD? Or 207 organize HCD differently so that we can (better) cooperate with users and so that we can jointly learn and create new things? A short answer would be that the conflicts between other and self and between openness and closure are intrinsic to being human, including practising HCD, and cannot be escaped or solved. A longer answer would be – and here I again borrow concepts from Levinas and Derrida – that practitioners can try to become more aware of and more articulate about the moves they make between other and self and between openness and closure; about the ethical qualities of HCD. One can attempt to escape one's tendency to grasp the other via a kind of desire that does not approach the other as an instrument to satisfy the appetite of the self. This would be an attempt to preserve the otherness of the other and to jointly learn new things. Likewise, one can attempt to escape one's tendency to program, via a kind of passivity which is open towards the other. This would be an attempt to come out-of-the-box and jointly create new things. One can attempt to let others – users and fellow project-team members – put the self into question and respond to the other. In other words, I recommend that practitioners attempt to become more reflexive, to move towards reflexive practice. This would be an attempt to be more aware of and more articulate about one's own roles in a HCD project, of the moves one makes towards the other and the self and towards openness and closure, to provide accounts of these moves to others, and to be held accountable for these moves. Such reflexivity would help to attempt to move towards the other, away from one's tendency towards the self, and to attempt to move towards openness, away from one's tendency for closure. In line with suggestions from STS (e.g. Woolgar and Ashmore 1988; Ashmore 1989) and from the tradition of participatory design (e.g. Markussen 1994; Beck 2002; Bødker 2006; Gulliksen et al. 1999b), I try to see reflexivity not as a bug, but as a feature – as an approach that can help to explore, envision and draw attention to alternative perspectives and alternative practices (to open the 'black box' of HCD, to 'deconstruct' HCD). A question that remains, of course, is whether we can organize such ways of working, such reflexive practice. I tend to think that we cannot, because when we attempt to organize openness to others and reflexive practice, we immediately introduce the risk of reifying this way of working: 'You must be reflexive.' However, I do think that, on an individual level, face-to-face, people can help one another to be 208 more open towards others and to work more reflexively. Another question is: What would such a reflexive practice bring? I do not know. I have not yet formally tried out or evaluated reflexive practice. Nevertheless, I did articulate some tentative conclusions and recommendations and discuss these with my fellow project-team members (July 2007). In that meeting, I grouped my findings around three themes: interacting with users, cooperating within the projectteam, and organizing a HCD project. Often, HCD practitioners organize their interactions with users within a given agenda or framework, for example by creating and following interview checklists or workshop formats, and this brings a risk that users can act only within that agenda or framework, which can result in a monologue going one way and another monologue going the other way. Similarly, when HCD practitioners do observation, they are likely to pay attention to what already interests them, which brings a risk of unintentionally missing perspectives or topics that are relevant for the users and may be relevant for the project. Alternatively, we could organize the interactions more openly and more like a dialogue, so that they may learn 'something that we didn't know we needed to know' (Muller 2002; emphasis in original). This suggestion is not intended to make practitioners stop using checklists or formats, but to make them more aware of and more explicit about the methods they use to interact with users and about their own roles in these interactions, and to enable them more consciously to decide how much or what kind of user participation they wish to allow, and how much or what kind of empathy they wish to have for users. Cooperating within a multidisciplinary project-team can be difficult, precisely because of the differences between the project-team members, for example between people who follow engineering methods when they develop technology, people who follow socialscience methods when they conduct user studies, and people who follow design methods when they generate ideas and concepts. It occurred to me that maybe communication and cooperation can be improved if project-team members attempt to step out of their different traditions and methods, and attempt to connect to the other project-team members by talking about their research and design efforts – for example their fieldwork with users, their observations, interviews, workshops and the like – in more personal and subjective ways – and more reflexively, providing accounts of their own role 209 and agency in these processes. One would then, for example, talk about one's own experiences during a day of observation, or about what one thought or felt during or after an interview or a workshop. One project-team member agreed with this suggestion and remarked that relating personal and subjective anecdotes about interactions with several individual users within the project-team can help the creative process. Another project-team member remarked that such anecdotes should be balanced with other ways of studying and discussing users, such as surveys that help to understand a larger group of people. My recommendation would be that HCD practitioners become aware of their different approaches and try to combine their different approaches constructively. Furthermore, I would recommend that they become more aware of and articulate about how they represent users in their project, portray them and act as their spokespersons; that they become more aware of and more explicit about how they conceptualize users and take them into account in their project. A third tentative recommendation example relates to organizing HCD. Many HCD projects are organized as if they are a linear process or a logical process, as if one moves from A to B by applying logic. However, a HCD project, or any research and design project, can be better understood and organized as an 'interpretive process' (Lester and Piore 2004), an iterative and chaotic process (Buijs 2003; Buijs 2007) that proceeds via 'design thinking' (Cross 2006; Lawson 2006): an uncertain and confusing process in which problems and solutions are developed in parallel and in which people create and negotiate all sorts of meanings (Chapter 6). I am not arguing that one should not try to organize or plan an HCD project, but it is difficult to organize and plan HCD when one wishes to take HCD seriously. My recommendation would be to carefully balance other and self and openness and closure and to foster processes of joint learning and joint creating – which would be similar to a recommendation to simultaneously organize and not-organize HCD. Realism Normally, when I work in a HCD project, I operate in a practitioner mode, which can be characterized as realist and action-oriented: I am aware of a world out-there on which I attempt to exert influence. By contrast, when I was studying this HCD project, I moved towards an analyst role: towards observation, description, reflection and 210 reflexivity (Chapter 3). I attempted to follow a social constructionist approach, to focus on how reality is created and re-created and negotiated between people. However, I wish to confess that realist and action-oriented modes have always been lurking in the background. I am still a practitioner and I hope to contribute to practice. With this text – although I attempted to follow a social constructionist approach – I mean to say something about a world out-there and to exert influence in that world. To complicate things, I like to see myself not as a realist who believes that a text is a realist description of reality – 'absolutely a slice of life or a report upon the world' (Ashmore 1989, p. 198) – and I tend to agree with Ashmore when he remarks that 'The distinction between fiction and non-fiction is illusory' and that 'All writing is fiction' (ibidem, p. 197). However, I would consider my text as malfunctioning if it does not create some relation to HCD practice in a world out-there. I would like to argue that the problems upon which we focused in our projects (Chapters 4 and 5) were 'real'. There are police officers who face difficulties with communication and cooperation, and there are informal carers who have emotional and social problems and suffer from burn-out. A recent study (Kleijer 2008) described the difficulties of police work and drew attention to the different functions a police officer must fulfil: maintain order, repress offences, prevent crime and help citizens. He or she must be a 'spider in the web' (the same description we heard in our first workshop with police officers). Another study (Peeters et al. 2007) revealed that 'For one out of five informal carers, providing care to a partner or parent with dementia is both physically and emotionally too demanding. The informal carer has strong feelings of being alone and having nobody to go to with questions or problems'. Additionally, and regarding the telecom applications we developed for them, I can say that, based on two relatively quick-and-dirty evaluations of prototypes, it seems that these telecom applications can help to solve some of the problems of police officers and informal carers out-there. Related to the relationship between research and action, Wiebe Bijker (1993) advocated making a shift from an academia-oriented STS (science and technology studies) back to practical application of the findings from STS in society. He referred to a previous meaning of STS, namely: science, technology and society. He advocated to 'turn to practice' after 'the academic detour'; to take the findings from our research and to make them applicable practically. 211 A checklist In order to satisfy my own and other practitioners' tendency to work with bulleted lists and in order to promote the application of my recommendations, I provide a checklist of my recommendations – in a prescriptive ('paradoxical communication') form: • Try to move towards others, towards users and fellow project-team members, and try to be open towards others – moves towards the self and closure come almost automatically and need no emphasis. • Try to learn new things together with others – including things you did not yet know that you may be or become interested in. • Try to create new things together with others – and let users and fellow project-team members contribute actively and creatively. • Try to be aware of your tendency to see and hear only those things of the other that fit your current frame of thinking – your tendency to grasp the other and pull the other into the self, and the risk of learning nothing new. • Try to be aware of your tendency to move towards closure, to stay within your own box, to follow rules rather than create – your tendency to program invention and create more of the same, and the risk of creating nothing new. • Try to be explicit and articulate about your moves towards the other and the self and towards openness and closure. • Try to be reflexive: (more) aware of and (more) articulate about your own interests, ambitions, methods and skills, and your own role in the process. • Reflexivity would help to balance the moves between other and self and between openness and closure. • Reflexivity can occur if the other can put into question the self, and this can help to some degree to escape the tendency to grasp and to program, and can help to jointly learn and jointly create. • Sometimes it may be necessary to step out of one role and into another role. I hope that this text can help HCD practitioners, including myself, to look differently at our HCD practices and to practise HCD in a different way. You can read my accounts of HCD practice (Chapters 4 and 5) and see how these relate to your own ideas about HCD or your own experiences with HCD. You can read about different HCD 212 approaches (Chapter 2) or about theories and concepts that I used for interpretation and discussion (Chapter 6) and develop your own ideas on HCD. You can organize HCD practices that help to facilitate learning-while-doing and reflexivity. Or you can use parts of this text for education or training purposes. I hope this text will help HCD practitioners to align HCD practice more closely to what it already is: a process that happens between people, a socio-cultural and political process, and a process with ethical qualities. This can lead towards responsibility in the sense that one can better respond to other people's questions about HCD and become more accountable for one's HCD practice, and towards freedom in the sense that one will more consciously choose between possible ways of acting – and towards processes of joint learning and jointly creating. 213 Bibliography Achterhuis, Hans (2006), Utopie [Dutch]. Amsterdam: Ambo. Achterhuis, Hans, ed. (1992), De maat van de techniek: Zes filosofen over techniek: Günther Anders, Jacques Ellul, Arnold Gehlen, Martin Heidegger, Hans Jonas and Lewis Mumford [Dutch]. Amsterdam: Ambo. Akrich, Madeleine (1995), 'User representations: Practices, methods and sociology', in Managing technology in society, Arie Rip, Thomas J. Misa and Johan Schot, eds. London and New York: Pinter Publishers, 167-84. Akrich, Madeleine (1992), 'The de-scription of technical objects', in Shaping technology / Building society: Studies in sociotechnical change, Wiebe E. Bijker and John Law, eds. Cambridge, Massachusetts and London, England: MIT Press, 205-24. Akrich, Madeleine, Michel Callon and Bruno Latour (2002a), 'The key to success in innovation – Part 2: The art of choosing good spokespersons', International Journal of Innovation Managment, 6(2), 207-25. Akrich, Madeleine, Michel Callon and Bruno Latour (2002b), 'The key to success in innovation – Part 1: The art of interessement', International Journal of Innovation Management, 6(2), 187-206. Alam, Ian (2002), 'An exploratory investigation of user involvement in new service development', Journal of the Academy of Marketing Science, 30(3), 250-61. Alam, Ian (2005), 'Removing the fuzziness from the fuzzy front-end of service innovations through customer interactions', Industrial marketing management, 35 468-80. Aldersey-Williams, Hugh, John Bound and Roger Coleman (1999), 'The methods lab: User research for design', in Presence: New media for older people, Kay Hofmeester and Esther De Charon de Saint Germain, eds. Amsterdam: Netherlands Design Institute, 121-64. Alexander, Ian and Neil Maiden (2004), Scenarios, stories, use cases. Chichester; Hoboken, New Jersey: John Wiley & Sons. Alvesson, Mats and Stanley Deetz (2000), Doing critical management research. London: Sage. Alvesson, Mats, Cynthia Hardy and Bill Harley (2004), 'Reflecting on Reflexive Practices in Organization and Management Theory', Lund, Sweden: Lund Institute of Economic Research. Ante, Spencer E. (2006), 'The science of desire', BusinessWeek (June 5, 2006), 98-106. Arbanowski, Stefan (2003), 'I-centric Communications' [Doctoral thesis], Berlin: Technischen Universität Berlin. Arbanowski, Stefan, Pieter Ballon, Klaus David, Olaf Droegehorn, Henk Eertink, Wolfgang Kellerer, Herma Van Kranenburg, Kimmo Raatikainen and Radu Popescu-Zeletin (2004), 'I-centric communications', IEEE Communications Magazine, (Sept), 63-9. Ashmore, Malcolm (1989), The reflexive thesis: Wrighting sociology of scientific knowledge. Chicago and London: The University of Chicago Press. Bacon, Francis (1627), The new Atlantis. Bannon, Liam J. (1991), 'From human factors to human actors: The role of psychology and human-computer interactions studies in system design', in Design at work: Cooperative cesign of computer systems, Joan Greenbaum and Morten Kyng, eds. Hillsdale, New Jersey: Lawrence Erlbaum Associates, 25-44. Beck, Eevi (2001), 'On participatory design in Scandinavian computing research', Oslo: University of Oslo, Department of Informatics. 214 Beck, Eevi (2002), 'P for Political – Participation is not enough', Scandinavian Journal of Information Systems, 14(1), 77-92. Berg, Marc (1998), 'The politics of technology: On bringing social theory into technological design', Science Technology & Human Values, 23(4), 456-90. Beyer, Hugh and Karen Holzblatt (1996), 'Contextual techniques', interactions, (November + December), 44-50. Beyer, Hugh and Karen Holzblatt (1998), Contextual design: Defining customer-centred systems. San Fransisco, California: Morgan Kaufmann. Bijker, Wiebe E. (1993), 'Do not despair: There is life after constructivism', Science, Technology, & Human Values, 18(1), 113-38. Binder, Thomas, Eva Brandt and Judith Gregory (2008), 'Editorial: Design participation(-s)', CoDesign, 4(1), 1-3. Blomberg, J, J Giacomi, A Mosher and P Swenton-Hall (1993), 'Ethnographic field methods and their relation to design', in Participatory design: Principles and practices, Douglas Schuler and Aki Namioka, eds. Hillsdale, New Jersey: Lawrence Erlbaum, 123-55. Bødker, Susanne (2006), 'When second wave HCD meets third wave challenges', in Proceedings of NordiCHI 2006, 14-18 October 2006, Oslo, Norway, 1-8. Bødker, Susanne, Kaj Grønbaek and Morten Kyng (1993), 'Cooperative design: Techniques and experiences form the Scandinavian scene', in Participatory design: Principles and practices, Douglas Schuler and Aki Namioka, eds. Hillsdale, New Jersey: Lawrence Erlbaum, 157-75. Brereton, Margot, David Cannon, Ade Mabogunje and Larry Leifer (1996), 'Collaboration in design teams: How social interaction shapes the product', in Analysing Design Activity, Nigel Cross, Henri Christiaans and Kees Dorst, eds. Chichester: John Wiley & Sons, 291-318. Bruining, Ton (2005), 'Learning behind the frontline of public service', 'sHertogenbosch: KPC Group. Bucciarelli, Louis (1994), Designing engineers. Cambridge, Massachusetts and London, England: MIT Press. Buchanan, Richard (1995), 'Wicked problems in design thinking', in The idea of design: A Design Issues Reader, Victor Margolin and Richard Buchanan, eds. Cambridge, Massachusetts and London, England: MIT Press, 3-20. Buchenau, Marion and Jane Fulton Suri (2000), 'Experience prototyping', in Proceedings of Designing Interactive Systems (DIS 2000), 17-19 August, New York. New York: ACM Press, 424-33. Buijs, Jan (2003), 'Modelling product innovation processes, from linear logic to circular chaos', Creativity and innovation management, 12(2), 76-93. Buijs, Jan (2007), 'Innovation leaders should be controlled schizophrenics', Creativity and innovation management, 16(2), 203-10. Buijs, Jan and Rianne Valkenburg (1996), Integrale productontwikkeling [Integral product development]. Utrecht: Lemma. Button, Graham (2000), 'The ethnographic tradition and design', Design Studies, 21, 319-32. Carroll, John M., ed. (1995), Scenario-based design: Envisioning work and technology in system development. New York: John Wiley & Sons. Carroll, John M. and Kentaro Go (2004), 'The blind men and the elephant: Views of scenario-based system design', interactions, (November + December), 44-53. Case, Peter (2000), 'Why Rapid Results Ethnography? Why Now?', The Newsletter of the Standing Conference on Organizational Symbolism, May 2000. Chesbrough, H. W. (2003), Open innovation: The new imperative for creating and profiting from new technology. Boston, Massachusetts: Harvard Business School Press. 215 Cooper, Alan (1999a), The inmates are running the asylum: Why high-tech products drive us crazy and how to restore the sanity. Indianapolis, Indiana: SAMS Publishing. Cooper, Alan and Robert M. Reimann (2003), About Face 2.0: The Essentials of Interaction Design. Indianapolis, Indiana: John Wiley & Sons. Cooper, Robert (1999b), 'The invisible success factors in product innovation', Journal of Product Innovation Management, 16(2), 115-33. Coopmans, Catelijne, Daniel Neyland and Steve Woolgar (2004), 'Does STS mean business? – some issues and questions', presented at a workshop at Saïd Business School, University of Oxford, on 30 June 2004. Crabtree, Andy (2003), Designing Collaborative Systems: A Practical Guide to Ethnography. London: Springer-Verlag. Crisler, Ken, Michele Visciola, Mikael Anneroth, Angela Sasse and Satu Kalliokulju (2004), 'Considering the user in the wireless world', IEEE Communications Magazine, (September), 56-62. Critchley, Simon (1999), The ethics of deconstruction: Derrida and Levinas (2nd ed.). Edinburgh: Edinburgh University Press. Cross, Nigel (1995), 'Discovering design ability', in Discovering design: Explorations in Design Studies, Richard Buchanan and Victor Margolin, eds. Chicago and London: The University of Chicago Press, 105-20. Cross, Nigel (2004), 'Expertise in design: an overview', Design Studies, 25(5), 427-41. Cross, Nigel (2006), Designerly ways of knowing. London: Springer-Verlag. Cross, Nigel, Henri Christaans and Kees Dorst (1996), Analysing design activity. Chichester: John Wiley & Sons. Cross, Nigel and Anita Clayburn Cross (1996), 'Observations of teamwork and social processes in design', in Analysing Design Activity, Nigel Cross, Henri Christiaans and Kees Dorst, eds. Chichester: John Wiley & Sons, 291-318. De Poot, Henk, Joke Kort and David Langley (2004), 'Enhancing presence and context awareness in collaborative settings', in Proceedings of EChallenges 2004, Vienna, Austria, Oct 27-29, 2004. Deetz, Stanley (1994), 'The micro-politics of identity formation: the case of a knowledge intensive firm', Human Studies, 17, 23-44. Denzin, Norman K. and Yvonna S. Lincoln (2000), 'Introduction: The discipline and practice of qualitative research', in Handbook of qualitative research (2nd edition), Norman K. Denzin and Yvonna S. Lincoln, eds. Thousand Oaks: Sage, 1-28. Derrida, Jacques (1989), 'Psyche: Inventions of the Other' (Translated by Catherine Porter), in Reading de Man Reading, Lindsay Waters and Wlad Godzich, eds. Minneapolis, Minnesota: University of Minnesota Press. Derrida, Jacques (1991), 'Letter to a Japanese friend' [original 1987], in A Derrida reader: Between the blinds, Peggy Kamuf, ed. New York: Columbia University Press, 270-6. Derrida, Jacques (1995), Points: Interviews, 1974-1994. Stanford, California: Stanford University Press. Derrida, Jacques (2001), 'Deconstructions: The Im-possible', in French Theory in America, Sylvere Lotringer and Sande Cohen, eds. New York and London: Routledge, 12-32. Dobbelaar, Tanny (2005), Schrijven met Montaigne [Writing with Montaigne]. Amsterdam: Ambo. Dorst, Kees (1997), Describing design: A comparison of paradigms [Doctoral thesis]. Delft: Delft University of Technology. Dourish, Paul (2006), 'Implications for design', in Proceedings of CHI 2006, April 22-27, 2006, Montréal, Canada New York: ACM Press, 541-50. 216 Dröes, R.M., F.J. Meiland, M.J. Schmitz, I. Boerema, E. Derksen, J. De Lange, M.J. Vernooij-Dassen and W. Van Tilburg (2004a), 'Variations in meeting centers for people with dementia and their carers. Results of a multi-center implementation study', Archives of Gerontology and Geriatrics: Supplement, 9 127-47. Dröes, R.M., F.J.M. Meiland, C. Doruff, I. Varodi, H. Akkermans, Z. Baida, E. Faber, T. Haaker, F. Moelaert, T. Kartseva and Y.H. Tan (2005), 'A dynamic interactive social chart in dementia care: Attuning demand and supply in the care for persons with dementia and their carers.', in Medical and Care Compunetics 2, Volume 114, L. Bos, S. Laxminarayan and A. Marsh, eds. Amsterdam, The Netherlands: IOS Press, 210-20. Dröes, R.M., H.P.J. Van Hout and E.S. Van der Ploeg (2004b), 'Camberwell Assessment of Need for the Elderly (CANE): Revised Version (IV)', Amsterdam / Rotterdam: VU medisch centrum / Erasmus Medisch Centrum. Duyndam, Joachim and Marcel Poorthuis (2003), Levinas [Dutch]. Rotterdam: Lemniscaat. Easterby-Smith, Mark, Richard Thorpe and Andy Lowe (2002), Management Research: An Introduction (2nd ed.). London: Sage. Edvardsson, Bo, Anders Gustafsson, Per Kristensson, Peter Magnusson and Jonas Matthing, eds.(2006), Involving customers in new service development. London: Imperial College Press. Ehn, Pelle (1988), Work-oriented design of computer artifacts. Stockholm: Arbetslivscentrum. Ehn, Pelle (1993), 'Scandinavian design: On participation and skill', in Participatory design: Principles and practices, Douglas Schuler and Aki Namioka, eds. Hillsdale, New Jersey: Lawrence Erlbaum, 41-77. Ellis, Carolyn and H. R. Bochner (2000), 'Autoethnography, personal narrative, reflexivity: Researcher as subject', in Handbook of qualitative research (2nd edition), Norman K. Denzin and Yvonna S. Lincoln, eds. Sage: Thousand Oaks, London, New Delhi, 733-68. Fallman, Daniel (2005), 'Why research-oriented design isn't design-oriented research', in Proceedings of Nordes: Nordic Design Research Conference, 29-31 May, Copenhagen, Denmark. Florman, Samuel C. (1994), 'The existential pleasures of engineering (2nd ed.)', New York: St. Martins's Press. Foucault, Michel (1992), Discipline and punish: The birth of the prison. London: Penguin. Franke, Nikolaus, Eric Von Hippel and Martin Schreier (2006), 'Finding commercially attractive user innovations: A test of lead-user theory', Journal of Product Innovation Management, 23(4), 301-15. Frascara, Jorge (2002), 'Design and the social sciences: Making connections', London and New York: Taylor & Francis. Friedman, Batya and Peter Kahn (2002), 'Human values, ethics, and design', in The human-computer interaction handbook: fundamentals, evolving technologies and emerging applications, Julie Jacko and Andrew Sears, eds. Mahwah, New Jersey: Lawrence Erlbaum Associates, 1177-201. Fulton Suri, Jane (2003a), 'Empathic design: Informed and inspired by other people's experiences', in Empathic design: User experience in product design, Ilpo Koskinen, Katja Battarbee and Tuuli Mattelmäki, eds. Helsinki: IT Press, 51-8. Fulton Suri, Jane (2003b), 'The experience revolution: Developments in design practice', The Design Journal, 6(2), 39-48. Fulton Suri, Jane, Katja Battarbee and Ilpo Koskinen (2005), 'Designing in the dark: Empathic exercises to inspire design for our non-visual senses', in Proceedings of 217 International conference on inclusive design, 5-8 April, Royal College of Art, London, UK. Ganzevles, Jurgen (2005), 'Should users be involved in innovation processes?', EASST Review, September 2005. Garfinkel, Harold (1967), Studies in ethnomethodology. Englewood Cliffs, New Jersey: Prentice-Hall. Gaver, Bill, Tony Dunne and Elena Pacenti (1999), 'Cultural probes', interactions, (Januari + February), 21-9. Goffman, Erving (1959), The presentation of self in everyday life. New York: Doubleday. Greenbaum, Joan (1993), 'PD: A personal statement', Communications of the ACM, 36(4), 47. Greenbaum, Joan and Morten Kyng (1991), 'Introduction: Situated design', in Design at work: Cooperative design of computer systems, Joan Greenbaum and Morten Kyng, eds. Hillsdale, New Jersey: Lawrence Erlbaum Associates, 1-24. Grudin, Jonathan and John Pruitt (2002), 'Personas, participatory design and product development: An infrastructure for engagement', in Proceedings of Participatory Design Conference 2002 (PDC 2002), 23-25 June, Malmo, Sweden. Computer Professionals Social Responsibility, 144-61. Gulliksen, Jan, Ann Lantz and Inger Boivie (1999a), 'User Centered Design in Practice Problems and Possibilities', Stockholm: Royal Institute of Technology: CID Centre for User Oriented IT Design. Gulliksen, Jan, Ann Lantz and Inger Boivie (1999b), 'User Centred Design – Problems and Possibilities', SIGCHI Bulletin, 31(2), 25-35. Gummeson, Evert (2000), Qualitative methods in management research. Thousand Oaks: Sage. Haddon, Leslie and Kari-Hans Kommonen (2003), 'Interdisciplinary explorations: A dialogue between a sociologist and a design group', Helsinki: University of Art and Design. Haddon, Leslie, Enid Mante, Bartolomeo Sapio, Kari-Hans Kommonen, Leopoldina Fortunati and Annevi Kant, eds. (2005), Everyday Innovators: researching the role of users in shaping ICTs. Dordrecht: Springer. Hamm, Steve (2006), 'A passion for the planet', BusinessWeek (August 21/28, 2006), 98106. Hekkert, Paul and Matthijs Van Dijk (2001), 'Designing from context', in Designing in context, Peter Lloyd and Henri Christiaans, eds. Delft: Delft University Press Science, 383-94. Hemmings, Terry, Andy Crabtree, Tom Rodden, Karin Clakre and Mark Rouncefield (2002), 'Probing the Probes', in Proceedings of Participatory Design Conference 2002 (PDC 2002), 23-25 June, Malmo, Sweden. Computer Professionals Social Responsibility, 42-50. Hofmeester, Kay and Esther De Charon de Saint Germain, eds. (1999), Presence: New media for older people. Amsterdam: Netherlands Design Institute. Holzblatt, Karen and Sandra Jones (1993), 'Contextual inquiry: A participatory technique for system design', in Participatory design: Principles and practices, Douglas Schuler and Aki Namioka, eds. Hillsdale, New Jersey: Lawrence Erlbaum, 177-210. Holzblatt, Karen, Jessamyn B. Wendell and Shelley Wood (2005), Rapid contextual design: A how-to guide to key techniques for user-centered design. San Fransisco: Morgan Kaufmann. Hosking, Dian M. (2002), 'Constructing changes: A social constructionist approach to change work (and beetles and witches) [Inaugural speech]',. 218 Hulkko, Sami, Tuuli Mattelmäki, Katja Virtanen and Turkka Keinonen (2004), 'Mobile probes', in Proceedings of the third Nordic conference on Human-computer interaction (NordiCHI 2004). Tampere, Finland: ACM Press, 43-51. Hutchinson, Hilary, Wendy Mackay, Bosse Westerlund, Benjamin. B. Bederson, Allison Druin, Catherine Plaisant, Michel Beaudouin-Lafon, Stéphane Conversy, Helen Evans, Heiko Hansen, Nicolas Roussel, Bjørn Eiderbäck, Sinna Lindquist and Yngve Sundblad (2003), 'Technology probes: inspiring design for and with families', in Proceedings of CHI 2003, April 5–10, 2003, Ft. Lauderdale, Florida, USA. Ft. Lauderdale, Florida, USA: ACM Press, 17-24. Iacucci, Guilo and Kari Kuutti (2002), 'Everyday Life as a Stage in Creating and Performing Scenarios for Wireless Devices', Personal Ubiquitous Computing, 6(4), 299-306. Iacucci, Guilo, Kari Kuutti and Mervi Ranta (2000), 'On the move with a magic thing: role playing in concept design of mobile services and devices', in Proceedings of Designing Interactive Systems (DIS 2000), 17-19 August, New York. New York: ACM Press, 193-202. Iivari, Juhani and Netta Iivari (2006), 'Varieties of user-centredness', in Proceedings of the 39th Hawaii International Conference on System Sciences (HICSS 2006). Iivari, Netta (2006), 'Exploring the rhetoric on representing the user – Discourses on user involvement in academia and the IT artifact product development industry', International Journal of Technology and Human Interaction, 2(4), 54-81. ISO (1999), ISO 13407: Human-Centred Design Processes for Interactive Systems. Geneva, Switzerland: ISO. Jones, Campbell (2003), 'As if business ethics were possible, "within such limits"...', Organization, 10(2), 223-48. Jordan, Patrick W. (2002), 'Human factors for pleasure seekers', in Design and the social sciences: Making connections, Jorge Frascara, ed. Taylor & Francis. Jordan, Patrick W. (2000), Designing pleasurable products: An introduction to the new human factors. London and New York: Taylor & Francis. Kanstrup, Anne M. and Ellen Christiansen (2005), 'Model power – Still an issue?', in Between sense and sensibility: Proceedings of the fourth decennial Aarhus Conference, 20-24 August, Aarhus, Denmark, Olav W. Bertelsen, Niels O. Bouvin, Peter G. Krogh and Morten Kyng, eds. ACM Press, 165-8. Kaulio, Matti A. (1998), 'Customer, consumer and user involvement in product development: A framework and a review of selected methods', Total Quality Management, 9(1), 141-50. Kensing, Finn and Jeanette Blomberg (1998), 'Participatory design: Issues and concerns', Computer Supported Cooperative Work, 7(3-4), 167-85. Keulartz, Jozef, Maartje Schermer, Michiel Korthals and Tsjalling Swierstra (2004), 'Ethics in technological culture: A programmatic proposal for a pragmatist approach', Science, Technology, & Human Values, 29(1), 3-29. Kleijer, Lianne (2008), 'Handhavers van de vrede of heroveraars?', The Hague: Boom. Kleinsman, Maaike (2006), Understanding collaborative design [Doctoral thesis]. Delft: Delft University of Technology. Knorr Cetina, Karin (1995), 'Laboratory studies: The cultural approach to the study of science', in Handbook of Science and Technology Studies, Sheila Jasanoff, Gerald E. Markle, James C. Petersen and Trevor Pinch, eds. London: Sage, 140-66. Koen, Peter, Greg Ajamian, Scott Boyce, Allen Clamen, Eden Fisher, Stavros Fountoulakis, Albert Johnson, Pushpinder Puri and Rebecca Seibert (2002), 'Fuzzy front end: Effective methods, tools, and techniques', in PDMA toolbook for new product development. John Wiley & Sons, 2-35. 219 Koskinen, Ilpo and Katja Battarbee (2003), 'Introduction to user experience and empathic design', in Empathic design: User experience in product design, Ilpo Koskinen, Katja Battarbee and Tuuli Mattelmäki, eds. Helsinki: IT Press, 37-50. Kristensson, Per (2006), 'Managing ideas that are unthinkable in advance', in Involving customers in new service development, Bo Edvardsson, Anders Gustafsson, Per Kristensson, Peter Magnusson and Jonas Matthing, eds. London: Imperial College Press, 127-41. Kristensson, Per and Peter Magnusson (2005), 'Involving users for incremental or radical innovation – A matter of tuning', in Proceedings of International Product Development Management Conference, 12-14 June, Copenhagen, Denmark. Kristensson, Per, Peter Magnusson and Jonas Matthing (2002), 'Users as a Hidden Resource for Creativity: Findings from an Experimental Study on User Involvement', Creativity and innovation management, 11(1), 4-14. Kujala, Sari (2003), 'User involvement: a review of the benefits and challenges', Behaviour and Information Technology, 22(1), 1-17. Kunda, Gideon (1992), Engineering culture: Control and commitment in a high-tech corporation. Philadelphia: Temple University Press. Latour, Bruno (1988), 'The politics of explanation: an alternative', in Knowledge and reflexivity: New frontiers in the sociology of knowledge, Steve Woolgar, ed. London: Sage, 155-76. Latour, Bruno (1987), Science in action: How to follow scientists and engineers through society. Milton Keynes: Open University Press. Latour, Bruno (1996), Aramis, or the love of technology (Translated by Catherine Porter) [original 1993]. Cambridge, Massachusetts and London, England: Harvard University Press. Latour, Bruno and Steve Woolgar (1986), Laboratory life: The construction of scientific facts (2nd ed.). Princeton, New Jersey: Princeton University Press. Lawson, Bryan (2006), How designers think: The design process demystified (fourth edition). Amsterdam: Elsevier. Leonard, Dorothy and Jeffrey F. Rayport (1997), 'Spark innovation through empathic design', Harvard Business Review, 75(6), 102-13. Lester, Richard and Michael Piore (2004), Innovation: The missing dimension. Cambridge, Massachusetts and London, England: Harvard University Press. Letiche, Hugo (1998), 'Business ethics: (In-)justice and (anti-)law. Reflections on Derrida, Bauman and Lipovetsky', in Ethics and organizations, Martin Parker, ed. London: Sage, 122-49. Letiche, Hugo (2008), 'Humanist organization studies: An intersubjective research agenda for Open(-plan) fieldwork', in Handbook of the new and emerging in management and organization, David Barry and Hans Hansen, eds. Sage. Levinas, Emmanuel (1996a), 'Transcendence and height [original 1962]', in Emmanuel Levinas: Basic philosophical writings, Adriaan Peperzak, Simon Critchley and Robert Bernasconi, eds. Bloomington and Indianapolis: Indiana University Press, 11-32. Levinas, Emmanuel (1996b), 'Transcendence and intelligibility [original 1984]', in Emmanuel Levinas: Basic philosophical writings, Adriaan Peperzak, Simon Critchley and Robert Bernasconi, eds. Bloomington and Indianapolis: Indiana University Press, 149-59. Levinas, Emmanuel (1987), 'Philosophy and the idea of infinity' (Translated by Alphonso Lingis) [original 1957], in Collected philosophical papers. Dordrecht: Martinus Nijhoff Publishers, 47-59. Limonard, Sander and Nicole de Koning (2005), 'Dealing with dilemmas in precompetitive ICT development projects: The construction of 'the social' in 220 designing new technologies.', in Everyday Innovators: researching the role of users in shaping ICTs, Haddon, Leslie, Enid Mante, Bartolomeo Sapio, Kari-Hans Kommonen, Leopoldina Fortunati and Annevi Kant, eds. Dordrecht: Springer. Lüthje, Christian and Cornelis Herstatt (2004), 'The Lead User method: an outline of empirical findings and issues for future research', R & D Management, 34(5), 55368. Lüthje, Christian, Cornelis Herstatt and Eric Von Hippel (2005), 'User-innovators and 'local" information: The case of mountain biking', Research Policy, 34 951-65. Mackay, Hugh, Chris Carne, Paul Beynon-Davis and Doug Tudhope (2000), 'Reconfiguring the user: Using rapid application development', Social Studies of Science, 30(5), 737-59. MacKenzie, Donald and Judy Wajcman (1999), The social shaping of technology (2nd edition). Buckingham, Philadelphia: Open University Press. Magnusson, Peter (2003), 'Benefits of involving users in service innovation', European Journal of Innovation Management, 6(4), 228-38. Magnusson, Peter (2006), 'Learning from experiments involving users in service innovation', in Involving customers in new service development, Bo Edvardsson, Anders Gustafsson, Per Kristensson, Peter Magnusson and Jonas Matthing, eds. London: Imperial College Press, 143-58. Magnusson, Peter, Jonas Matthing and Per Kristensson (2003), 'Managing user involvement in service innovation: Experiments with innovating end users', Journal of Service Research, 6(2), 111-24. Mante-Meijer, Enid and Lajla Klamer (2004), ICT capabilities in action: What people do. Brussels: COST Action 269. Markussen, Randi (1994), 'Dilemmas in cooperative design', in Proceeding of Participatory Design Conference (PDC'94), 59-66. Markussen, Randi (1996), 'Politics of intervention in design: Feminist reflections on the Scandinavian tradition', AI & Society, 10 127-41. Marzano, Stefano (2005), 'People as a source of breakthrough innovation', Design Management Review, 16(2), 23-9. Mattelmäki, Tuuli (2006), 'Design probes' [Doctoral thesis], University of Art and Design Helsinki. Moriceau, Jean-Luc (2004), 'Event, speech, encounter: The making of the research interview', presented at the 20th EGOS Colloquium, 1-3 July 2004. Muller, Michael J. (2002), 'Participatory Design: The third space in HCI', in The human-computer interaction handbook: fundamentals, evolving technologies and emerging applications, Julie Jacko and Andrew Sears, eds. Mahwah, New Jersey: Lawrence Erlbaum Associates, 1051-68. Muller, Micheal J. and Sarah Kuhn (1993), 'Participatory design', Communications of the ACM, 36(6), 24-8. Nielsen, Jacob (1993), Usability Engineering. London: Academic Press. Norman, Donald A. (1988), The Psychology of Everyday Things. Basic Books. Nussbaum, Martha C. (1986), The fragility of goodness. Cambridge University Press. Oudshoorn, Nelly and Trevor Pinch, eds. (2003a), How users matter: The coconstruction of users and technology. Cambridge, Massachusetts and London, England: MIT Press. Oudshoorn, Nelly and Trevor Pinch (2003b), 'Introduction: How users and non-users matter', in How users matter: The co-construction of users and technology, Oudshoorn, Nelly and Trevor Pinch, eds. Cambridge, Massachusetts and London, England: MIT Press, 1-25. 221 Oulasvirta, Antti, Esko Kurvinen and Tomi Kankainen (2003), 'Understanding contexts by being there: case studies in bodystorming', Personal Ubiquitous Comput., 7(2), 125-34. Panne, Gerben v. d., Cees v. Beers and Alfred Kleinknecht (2003), 'Success and failure of innovation: A literature review', International Journal of Innovation Management, 7(3), 309-38. Papanek, Victor (1991), 'Design for the real world (2nd ed.)', London: Thames & Hudson. Pearce, W. B. (1992), 'A "camper's guide" to constructionisms', Human Systems: The Journal of Systemic Consultation & Management, 3 139-61. Peeters, José, Sandra Van Beek and Anneke Francke (2007), 'Problemen en wensen van mantelzorgers van mensen met dementia: Resultaten van de monitor van het Landelijk Dementieprogramma', NIVEL (Nederlands instituut voor onderzoek van de gezondheidszorg). Pinch, Trevor and Trevor Pinch (1988), 'Reservations about reflexivity and new literary forms or Why let the devil have all the good tunes?', in Knowledge and reflexivity: New frontiers in the sociology of knowledge, Steve Woolgar, ed. London: Sage, 178-97. Pinch, Trevor J. and Wiebe E. Bijker (1987), 'The social construction of facts and artifacts: Or how the sociology of science and the sociology of technology might benefit each other', in The social construction of technological systems, Wiebe E. Bijker, T. P. Hughes and Trevor J. Pinch, eds. Cambridge: MIT Press, 17-50. Pine, B. J. and James H. Gilmore (1999), The experience economy: Work is theatre and every business a stage. Boston, Massachusetts: Harvard Business School Press. Postman, Neil (1993), Technopoly: The Surrender of Culture to Technology. Vintage. Prahalad, C. K. and Venkat Ramaswamy (2004), The future of competition: Co-creating unique value with customers. Boston, Massachusetts: Harvard Business School Press. Pruitt, John and Jonathan Grudin (2003), 'Personas: practice and theory', in Proceedings of the 2003 conference on Designing for user experiences (DUX 2003) San Francisco, California: ACM Press, 1-15. Redstrom, Johan (2005), 'Towards user design? On the shift from object to user as the subject of design', Design Studies, 27(2), 123-224. Rip, Arie (2000), 'There's no turn like the empirical turn', in The empirical turn in the philosophy of technology (Volume 20), Carl Mitcham, Peter Kroes and Anthonie Meijers, eds. Elsevier Science, 3-17. Rip, Arie, Thomas J. Misa and Johan Schot (1995), 'Constructive Technology Assessment: A new paradigm for managing technology in society', in Managing technology in society, Arie Rip, Thomas J. Misa and Johan Schot, eds. London and New York: Pinter Publishers, 1-12. Rittel, H. W. J. and M. M. Webber (1984), 'Planning problems are wicked problems', in Developments in design methodology, Nigel Cross, ed. Chisester: Wiley. Rohracher, Harald (2005a), 'The diverse roles of users in innovation processes', in User involvement in innovation processes: Strategies and limitations from a sociotechnical perspective, Harald Rohracher, ed. Munchen/Wien: Profil Verlag, 9-35. Rohracher, Harald, ed. (2005b), User involvement in innovation processes: Strategies and limitations from a socio-technical perspective. Munchen/Wien: Profil Verlag. Roozenburg, N. F. M. and J Eekels (1995), Product Design: Fundamentals and Methods. Chichester, UK: John Wiley & Sons. Sandén, Bodil, Jonas Matthing and Bo Edvardsson (2006), 'New service development: Learning from and with customers', in Involving customers in new service 222 development, Bo Edvardsson, Anders Gustafsson, Per Kristensson, Peter Magnusson and Jonas Matthing, eds. London: Imperial College Press, 99-126. Sanders, Elizabeth B. N. (2000), 'Generative Tools for CoDesigning', in Collaborative Design: Proceedings of CoDesigning 2000, Stephen A. R. Scrivener, Linden J. Ball and Andree Woodcock, eds. London, Berlin, Heidelberg: Springer-Verlag, 3-12. Sanders, Elizabeth B. N. (2002), 'From User-Centred to Participatory Design Approaches', in Design and the Social Sciences, J Frascara, ed. Taylor & Francis. Sanders, Elizabeth B. N. (2006a), 'Design serving people', in Copenhagen – Cumulus working papers, Eija Salmi and Jani Anusionwu, eds. Helsinki: University of Art and Design Helsinki, 28-33. Sanders, Elizabeth B.N. (2006b), 'Design research in 2006', Design Research Quarterly, 1(1), 1-8. Sanders, Elizabeth B.N. and Uday Dandavate (1999), 'Design for Experiencing: New Tools', in Proceedings of the First International Conference on Design and Emotion, C. J. Overbeeke and Paul Hekkert, eds. Delft: Delft University of Technology. Sanders, Elizabeth B. N. and Pieter J. Stappers (2008), 'Co-creation and the new landscapes of design', CoDesign, 4(1), 5-18. Schuler, Douglas and Aki Namioka, eds. (1993), Participatory design: Principles and practices. Hillsdale, New Jersey: Lawrence Erlbaum Associates. Seybold, P. B. (2006), Outside innovation: How your customers will co-design your company's future. New York: Collins. Shotter, John (1993), Conversational realities: The construction of life through language. London: Sage. Sleeswijk Visser, Froukje and Merlijn Kouprie (2008), 'Stimulating empathy in ideation workshops', in Proceedings of Participatory Design Conference 2008 (PDC 2008). Sleeswijk Visser, Froukje, Pieter J. Stappers, Remko Van der Lugt and Elizabeth B. N. Sanders (2005), 'Contextmapping: Experiences from practice', CoDesign, 1(2), 11949. Sleeswijk Visser, Froukje, Remko Van der Lugt and Pieter J. Stappers (2007), 'Sharing user experiences in the product innovation process: Participatory design needs participatory communication', Creativity and innovation management, 16(1), 35-45. Smulders, Frido (2006), Get synchronized: Bridging the gap between design and volume production [Doctoral thesis]. Delft: Delft University of Technology. Spinuzzi, Clay (2005), 'The methodology of participatory design', Technical Communication, 52(2), 163-74. Steen, Marc (2004), 'Andere innovatie – Essay over innoveren waarin onderzoekers en ontwikkelaars meer open kunnen staan voor de ander' ['Other innovation'], presented at 26th Dutch-Flemish Philosophy Day, 6 November 2004, Utrecht. Steen, Marc (2006a), 'Open voor eindgebruikers' ['Open for end-users'], in Open stellingen [Open theses] The Hague: Advisory Council for Science and Technology Policy, 49-55. Steen, Marc (2006b), '"We don't want woollen trousers" – Studying how researchers and developers interact with police officers during an innovation project', in Proceedings of SCOS 2006 (Standing Conference on Organisational Symbolism), 13-15 July, Nijmegen, The Netherlands, Rene ten Bos and Ruud Kaulingfreks, eds., 64466. Steen, Marc (2006c), '"Our need is to do something about that problem" – Studying how researchers and developers interact with informal carers during an innovation project', presented at EASST 2006 Conference (European Association for Studies of Science and Technology), 23-26 August, Lausanne, Switzerland. 223 Steen, Marc, Ronald Van Eijk, Henny Gunther, Sander Hooreman and Nicole de Koning (2005), 'We-centric services for police officers and informal carers', in Proceedings of SIGCHI.NL 2005 Conference 'HCI Close to you" (The Hague, Oct 13, 2005) Amsterdam: ACM Press. Steen, Marc, Lottie Kuijt-Evers and Jente Klok (2007), 'Early user involvement in research and design projects – A review of methods and practices', presented at The 23rd EGOS Colloquium (European Group for Organizational Studies), 5-7 July, Vienna, Austria. Stewart, James and Robin Williams (2005), 'The wrong trousers? Beyond the design fallacy: Social learning and the user', in User involvement in innovation processes: Strategies and limitations from a socio-technical perspective, Harald Rohracher, ed. Munchen/Wien: Profil Verlag, 39-71. Stol, W.Ph., Ph. van Wijk, G. Vogel, B. Foederer and L. van Heel (2004), Politiestraatwerk in Nederland: Noodhulp en Gebiedswerk [Police streetwork in The Netherlands]. Apeldoorn / Zeist: Nederlandse Politie Academie / Kerkebosch. Stratix (2001), VrijBand: Een breedband visie voor Nederland (FreeBand: A broadband vision for The Netherlands', Schiphol, The Netherlands: Stratix. Suchman, Lucy A. (1987), Plans and situatated actions: The problem of human-machine communication. Cambride University Press. Svanaes, Dag and Gry Seland (2004), 'Putting the users center stage: role playing and low-fi prototyping enable end users to design mobile systems', in Proceedings of the SIGCHI conference on Human factors in computing systems (CHI 2004) Vienna, Austria: ACM Press, 479-86. Swager, Linda (2006), Can the WijkWijzer have added value? [Master thesis]. Delft: Delft University of Technology. Thackara, John (1999), 'An unusual expedition (Preface)', in Presence: New media for older people, Kay Hofmeester and Esther De Charon de Saint Germain, eds. Amsterdam: Netherlands Design Institute, 7-9. Thackara, John (2006), In the bubble: Designing in a complex world. Cambridge, Massachusetts and London, England: MIT Press. Tidd, Joe, John Bessant and Keith Pavitt (2001), Managing innovation: Integrating technological, market and organizational change (2nd ed.). Chichester: John Wiley & Sons. Törpel, Bettina (2005), 'Participatory Design: A multi-voiced effort', in Between sense and sensibility: Proceedings of the fourth decennial Aarhus Conference, 20-24 August, Aarhus, Denmark, Olav W. Bertelsen, Niels O. Bouvin, Peter G. Krogh and Morten Kyng, eds. New York: ACM Press, 177-81. Valkenburg, Rianne (2000), The reflective practice in product design teams [Doctoral thesis]. Delft: Delft University of Technology. Van de Poel, Ibo and Peter-Paul Verbeek (2006), 'Ethics and engineering design', Science Technology & Human Values, 31(3), 223-36. Van de Ven, Andrew, Douglas E. Polley, Raghu Garud and Sankaran Venkataraman (1999), The innovation journey. New York and Oxford: Oxford University Press. Van der Roest, H.G., F.J.M. Meiland, H.C. Comijs, M.J.F.J. Vernooij-Dassen, H. Van Hout, C. Jonker and R.M. Dröes (2007a), 'What do you need? That is the question. The subjective and objective needs of people with dementia living in the community', presented at the Alzheimer Europe Congres, Estoril, Portugal. Van der Roest, H.G., F.J.M. Meiland, F.J.M. Maroccini, H.C. Comijs, C. Jonker and R.M. Dröes (2007b), 'Subjective Needs in People with Dementia. A Review of the Literature', International Psychogeriatrics, 19 559-92. 224 Van Eijk, Ronald, Ingrid Mulder, Henri ter Hofte and Marc Steen (2004), 'We-centric, context-aware, adaptive mobile service bundles: Defining concepts, functionalities and research questions', Enschede: Freeband/Telematica Instituut. Van Gorp, Anke (2005), Ethical issues in engineering design: Safety and sustainability [Doctoral thesis], Delft: Delft University of Technology. Van Kleef, Ellen, Hans C. M. van Trijp and Pieternel Luning (2005), 'Consumer research in the early stages of new product development: a critical review of methods and techniques', Food Quality and Preference, 16(3), 181-201. Van Maanen, John (1998), Tales of the field: On writing ethnography. Chicago and London: University of Chicago Press. Van Tongeren, Paul (2003), Deugdelijk leven [Virtuous living]. Amsterdam: SUN. Vinck, Dominique, ed. (2003), Everyday engineering: An ethnography of design and innovation. Cambridge, Massachusetts and London, England: MIT Press. Von Hippel, Eric (1988), The sources of innovation. New York and Oxford: Oxford University Press. Von Hippel, Eric (2005), Democratizing Innovation. Cambridge, Massachusetts: MIT Press. Von Hippel, Eric and Ralph Katz (2002), 'Shifting Innovation to Users via Toolkits', Management Science, 48(7), 821-33. Von Hippel, Eric, S. Thomke and M. Sonnack (1999), 'Creating breakthroughs at 3M', Harvard Business Review, 77(5), 47-57, 183. Winner, Langdon (1993), 'Upon opening the black box and finding it empty: Social constructivism and the philosophy of technology', Science, Technology, & Human Values, 18(3), 362-78. Wixon, Dennis and Judith Ramey, eds. (1996), Field methods casebook for software design. New York: John Wiley & Sons. Woolgar, Steve (1983), 'Irony in the social study of science', in Science observed: Perspectives on the Social Study of Science, Karin Knorr Cetina and Michael Mulkay, eds. London: Sage, 239-66. Woolgar, Steve (1988), 'Reflexivity is the ethnographer of the text', in Knowledge and reflexivity: New frontiers in the sociology of knowledge, Steve Woolgar, ed. London: Sage, 14-34. Woolgar, Steve (1991a), 'Configuring the user: The case of usability trials', in A sociology of monsters: Essays on power, technology and dominations, John Law, ed. London and New York: Routledge, 57-102. Woolgar, Steve (1991b), 'The turn to technology in social studies of science', Science, Technology, & Human Values, 16(1), 20-50. Woolgar, Steve (1993), 'What's at stake in the sociology of technology? A reply to Pinch and to Winner', Science, Technology, & Human Values, 18(4), 523-9. Woolgar, Steve and Malcolm Ashmore (1988), 'Introduction to the reflexive project', in Knowledge and reflexivity: New frontiers in the sociology of knowledge, Steve Woolgar, ed. London: Sage, 1-11. Woolgar, Steve, Catelijne Coopmans, Daniel Neyland and Elena Simakova (2005), 'Does STS Mean Business Too?', presented at a workshop at Saïd Business School, University of Oxford, on 29 June 2005. Yin, Robert (1994), Case study research (2nd ed.). Thousand Oaks: Sage. Zimmerman, John, Jodi Forlizzi and Shelley Evenson (2007), 'Research through design as a method for interaction design research', in Proceedings of CHI 2007, April 28-May 3, 2007, San Jose, California, USA ACM Press. 225 Summary Marc Steen: The fragility of human-centred design Doctoral thesis, 2008, Delft University of Technology I wrote this book with a specific audience in mind: people who, like me, attempt to organize or conduct human-centred design (HCD). I understand HCD as an attempt by researchers and designers to step outside their ivory tower, to meet with future or potential users of the products they are working on and to give them a voice or a role in their projects. This may seem obvious: to talk with the people for whom you are creating something and to learn about their needs and preferences. However, this is not always done in the information and communication technology (ICT) industry; many innovations in that industry are driven by the development of new technologies. In my day-to-day work at TNO Information and Communication Technology, I am involved in projects in which we attempt to practise HCD. As a practitioner, I began to feel uneasy about HCD. The principles of HCD appear to be simple: researchers and designers cooperate with users in their project, and organize iterative phases of research, design and evaluation, and multidisciplinary teamwork. The idea is to involve users from the start of a project and throughout its iterative cycles. However, in practice it appears to be difficult to put these principles into practice. Often, users are only involved at the end of a project or little is done with what they say. Perhaps HCD is more difficult than people tend to think at first glance. I became curious and formulated a relatively open research question: What happens in human-centred design practice and how does this differ from the theory and principles of human-centred design? My attempt was to open the 'black box' of HCD; to study what practitioners, including myself, actually do in practice. I attempted to 'deconstruct' HCD; to draw attention to some of its qualities that are usually hidden, and to propose alternative practices. I attempted to make a twofold gesture: I practised HCD in my day-to-day work, and I reflected on and wrote about that HCD practice. Through a review of several HCD approaches, I argued that there are two tensions in HCD and that different approaches are attempts to deal with these tensions in different ways (Chapter 2). One tension occurs between the roles and agency of researchers/designers and 226 the roles and agency of users. Are researchers/designers designing with or designing for users? In methods such as participatory design, the lead user approach and co-design, users are invited to participate in research and design processes and attempts are made to foreground their knowledge. Conversely, in methods such as applied ethnography, contextual design and empathic design, researchers/ designers attempt to move towards users, and their knowledge about users can play a dominant role. Another tension occurs between a concern for understanding current situations ('is'), a research orientation, versus a concern for envisioning alternative or future situations ('ought'), a design orientation. Applied ethnography and participatory design often have specific, current practices as starting points, whereas co-design and empathic design can start with ideas for alternative or future practices. Contextual design and the lead user approach are attempts to combine 'is' and 'ought': in contextual design, researchers/designers aim to understand a current situation and apply their findings in the design process, and lead users develop ideas or products within their current practice and contribute these to the design process. These tensions provided me with a focus for my empirical study; I studied how these two tensions are played out in practice. I developed a research approach involving the study of one HCD project in which I was working as a 'participant observer' (Chapter 3). This allowed me to study HCD in practice, from within and in realtime. I focused on what happened between project-team members and how we made decisions over a period of time. I did not focus on users, but paid attention to users only when project-team members interacted with them. I positioned my study in the academic field of science and technology studies (STS): an 'empirical turn' in the philosophy of science and technology, or a field of social science, in which the practices of people who create or use science or technology are studied. Furthermore, I opted for a social constructionist research approach. In such an approach, researchers assume that social reality does not exist externally to them, but that they are part of it, and that people construct and experience social reality in interactions with each other. Moreover, I chose to follow an explorative approach, which I justified by observing that there are only a few critical research texts about HCD from a practitioner's or insider's perspective. During my study I did struggle with combining my practitioner role and my analyst role. How can I analyse situations in which I am an active participant? And how can I make my analysis 227 relevant for other practitioners? I engaged with reflexivity in order to address such questions and I attempted to see reflexivity not as a bug, but as a feature. My empirical study is based on two cases in one project. In this project, we attempted to design two telecom applications: one together with and for police officers, and one together with and for people who provide informal care to a person with dementia (Chapters 4 and 5). These project activities were different and allowed me to observe different things. The team that worked with police officers was relatively small and homogeneous and I was actively involved in organizing workshops and similar activities with police officers. This allowed me to observe what happened between project-team members and police officers. In contrast, the team that worked with informal carers was relatively large and heterogeneous and I was not personally involved in interactions with informal carers. This allowed me to focus on what happened between project-team members, for example on decision-making during meetings. In the police project (Chapter 4), we conducted a series of workshops with different groups of police officers as part of our research and design process. Each interaction with police officers influenced our project; we gradually changed our project's goal and focus, which resulted in a telecom application that is interesting for police officers and for our project. The idea of helping community police officers to communicate and cooperate with people outside the police changed, through several steps, into the idea of helping community police officers and emergency police officers to communicate and cooperate with each other. Our focus on communication and telecom, and our initial neglect of information processes and databases, shifted to making a telecom application that is based on information from a police database. This application, the PolicePointer, is designed to promote cooperation between police officers, by making suggestions to share 'implicit' knowledge with each other. This would improve police work as a whole. This way of working – allowing users to influence the project – is considered good HCD practice. (This is different from, for example, a product development project, where good practice would be understood as keeping to an initial brief.) However, we unintentionally missed some opportunities to learn about police work and to cooperate with police officers. We tried to empathize with them, but not too much. For example, in the first workshop, we decided to focus on one topic that was comfortably 228 close to our project goal. We focused our attention on topics that we thought were of direct interest to us and, consequently, missed topics that were relevant for police officers or topics that might have become relevant for us in the future. Furthermore, we allowed police officers to participate, but not too much. When we invited them to workshops, we found it hard to facilitate joint creativity. We would typically prepare a format and an agenda for a workshop and keep to it. This provided the police officers with a limited number of ways to participate actively and creatively. This case illustrates the difficulty of being open towards others, towards users, and of organizing processes of joint learning and creating. In the other project we cooperated with informal carers during our research and design activities (Chapter 5). In this project, we experienced difficulties with cooperating within the project-team and with making progress. Project-team members followed different research and design approaches and found it hard to combine these constructively, and the organizations involved in this project sometimes had different interests. A recurring theme was the conducting of 'redundant' activities. Some project-team members conducted a survey in which they interviewed hundreds of informal carers and people who suffer from dementia. Parallel to that, and sometimes only loosely related, other project-team members conducted informal observations and interviews, and a series of codesign interviews. Furthermore, the process of identifying a problem was re-done over the course of several meetings; making progress was difficult because different people participated in these meetings and many people wanted to have a say. Similarly, the idea to develop a specific kind of telecom application was formulated and discussed several times, during several meetings. However, and on the positive side, the key goal remained relatively stable throughout the project, namely to improve the quality of life for both informal carers and the people with dementia, by supporting informal carers. We created a telecom application that is interesting for informal carers and for our project. This application, WeCare, can help 'primary' informal carers to share tasks with others and thus alleviate their burden. Furthermore, we conducted many and diverse interviews with informal carers in order to learn about their needs and preferences, which is considered 'good practice' in HCD. This case draws attention to the difficulty of being open towards fellow project-team members and to the difficulty of combining openness and closure; the need to draw conclusions and to deliver results. 229 I interpreted and discussed my observations, drawing from theory (Chapter 6). I argued that HCD can be understood as a socio-cultural process in which researchers and designers, together with users, participate in an uncertain, chaotic and 'interpretive' process in which people create and negotiate meanings, and that in this way they can create innovations. Furthermore, I argued that HCD can be understood as a political process in which people try to exert influence on the project. I showed how researchers and designers tend to represent users by creating personas and storylines (descriptions of fictive people and fictive situations) and how they tend to talk about users and make decisions for users, rather than let them participate directly in discussions and decision-making. Moreover, I presented HCD as a process with ethical qualities. I did this by borrowing concepts from the French philosophers Emmanuel Levinas and Jacques Derrida. I understand ethics – a Levinasian or Derridaen take on ethics – not as a branch of philosophy that deals with questions about good or bad, nor as a search for and application of moral rules, but as a 'first philosophy' that is concerned with what happens between people and with responsibility and freedom that emerge from the appeal of the other. Taking some of their ideas as points of departure, I discussed the tensions (Chapter 2) between researchers/designers and users in terms of movements between other and self, and the tension between concerns for 'is' and 'ought' in terms of movements between openness and closure. We tried to move towards the other when we tried to listen to users or fellow project-team members, and we tried to move towards openness when we tried to jointly learn and create. At the same time we tended to move towards the self when we foregrounded or privileged our own interests, ambitions, methods or skills, and we tended to move towards closure when we focused on drawing conclusions and delivering results. When I approach the other in an attempt to learn, I tend to grasp the other; I tend to draw the other towards my self, into my own frame of thinking, so that I cannot see the otherness of the other – and chances are that I learn nothing new, only what I already knew. Likewise, when I organize a project, I tend to create and follow a program: I tend to want to control the process, to stay within my own box and to go towards closure, rather than towards openness – and chances are that I create nothing new, only more of the same. My main conclusion is that practising HCD is not easy or unproblematic (Chapter 7). I see HCD as a fragile process; it can be 230 beautiful and it can break easily. My main recommendation for people who attempt to practise HCD is to become more aware of and more articulate about the ethical qualities of HCD: how they move between other and self, and between openness and closure. Furthermore, I suggested reflexive practice as a way for HCD practitioners to become more aware of and more articulate about these moves: about their own role and agency in their HCD practices. Such reflexivity would help them to balance their attempt to move towards the other and towards openness and their tendency to move towards the self and towards closure. I can attempt to escape my tendency to grasp the other via a kind of desire that does not approach the other as an instrument to satisfy the appetite of the self. This would be an attempt to preserve the otherness of the other and to jointly learn new things. Likewise, I can attempt to escape my tendency to program via a kind of passivity that is open towards otherness. This would be an attempt to 'come out of the box' and to jointly create new things. I can attempt to let others – users and fellow project-team members – put the self into question and respond to the other. Reflexive practice would help them to align their practice more closely with their intentions and with what HCD can be about: processes of learning and creativity that happen between people. This is not to say that researchers and designers should not contribute their own interests, ambitions, methods and skills. On the contrary: they could attempt to connect with users and fellow project-team members and to connect their respective interests, ambitions, methods and skills. These findings can contribute to a debate about innovation, design and ethics. I conducted my study in the tradition of science and technology studies (STS), in which many studies say little or nothing about ethics. In that respect, my study would be a welcome addition. On a content level, my study of how researchers and designers construct personas and storylines can further our understanding of how users are 'configured' or 'scripted' during research and design processes. I do not know yet how my recommendations will work in practice. I have not yet formally tried out and evaluated them. Nevertheless, I discussed three tentative, recommendations: about interacting with users, about cooperation within a project-team and about managing a project. Researchers and designers often organize their interactions 231 with users within a previously specified framework; instead, they could try to organize these interactions more openly and more like a dialogue, in order to foster processes of joint learning and creating. Cooperating within a multidisciplinary project-team can be difficult, precisely because of the differences between people; in order to improve communication and cooperation, they could attempt to step out of their different traditions and methods by talking with each other about their project activities in more personal and subjective ways. Many HCD projects are organized as if they proceed as a linear or logical process. However, HCD can be better understood as a social process in which both problems and solutions are explored and developed, all in parallel – perhaps we could try simultaneously to organize and not-organize HCD. The goal of this text is to inform and to inspire HCD practitioners to look differently at HCD and to practise HCD differently, more closely to what it can be about: processes of jointly learning and creating. 232 233 Samenvatting Marc Steen: The fragility of human-centred design (De kwetsbaarheid van mensgericht ontwerpen) Proefschrift, 2008, Technische Universiteit Delft Ik heb dit boek geschreven met een bepaalde doelgroep in gedachten: mensen die, zoals ik, proberen mensgericht ontwerpen – humancentred design (HCD) – in de praktijk te brengen. Ik zie HCD als een poging van onderzoekers en ontwerpers om uit hun ivoren toren te stappen, om de mensen te ontmoeten die mogelijk de producten gaan gebruiken waaraan ze werken, en om hun een stem of een rol te geven in hun projecten. Dat lijkt een open deur: te praten met de mensen voor wie je iets aan het maken bent en om hun behoeften en voorkeuren te leren kennen. Echter, in de sector van informatieen communicatietechnologie (ICT) wordt dat niet altijd gedaan; veel ICT innovaties worden gedreven door het ontwikkelen van nieuwe technologieën. In mijn dagelijkse werk bij TNO Informatieen Communicatietechnologie ben ik betrokken bij projecten waarin we proberen HCD uit te voeren. Vanuit die praktijk begon ik me ongemakkelijk te voelen over HCD. De principes van HCD lijken eenvoudig: onderzoekers en ontwerpers werken samen met gebruikers, en organiseren hun project in iteratieve fasen van onderzoeken, ontwerpen en evalueren, en als multidisciplinair teamwork. Het idee is om gebruikers vanaf de start van een project te betrekken en gedurende verschillende iteraties. Echter, in de praktijk blijkt het moeilijk om deze principes in de praktijk te brengen. Vaak worden gebruikers pas op het einde van een project betrokken of er wordt weinig gedaan met wat ze vertellen. Misschien is HCD wel moeilijker dan mensen op het eerste gezicht denken. Ik werd nieuwsgierig en formuleerde een relatief open onderzoeksvraag: Wat gebeurt er in de praktijk van mensgericht ontwerpen (HCD) en hoe verschilt dat van de theorie en principes van mensgericht ontwerpen (HCD)? Mijn poging was om de 'black box' van HCD te openen en te bestuderen wat mensen die HCD uitvoeren, inclusief mijzelf, daadwerkelijk doen. Ik heb geprobeerd om HCD te 'deconstrueren'; om aandacht te vestigen op eigenschappen die meestal verborgen blijven en om alternatieve manieren van werken voor te stellen. Ik heb geprobeerd een dubbel gebaar te maken: ik mijn dagelijkse werk 234 heb ik HCD uitgevoerd, en ik heb gereflecteerd op en geschreven over die HCD praktijk. Door middel van een overzicht van enkele HCD benaderingen heb ik betoogd dat er twee spanningen in HCD spelen en dat verschillende benaderingen verschillende manieren zijn om met die spanningen om te gaan (Hoofdstuk 2). Eén spanning speelt tussen de rollen en invloed van onderzoekers/ontwerpers en de rollen en invloed van gebruikers. Zijn de ontwerpers/onderzoekers aan het ontwerpen samen met of voor gebruikers? In methoden zoals participatory design, de lead user benadering en co-design worden gebruikers uitgenodigd om deel te nemen in onderzoeksen ontwerpprocessen en om hun kennis naar voren te brengen. Daartegenover staan methoden zoals toegepaste etnografie, contextual design en empathic design waarin onderzoekers en ontwerpers proberen om richting gebruikers te bewegen en hun kennis over gebruikers kan een dominante rol spelen. Een andere spanning speelt tussen de aandacht voor het begrijpen van huidige situaties ('is'), een onderzoeksfocus, en de aandacht voor het zich voorstellen van alternatieve of toekomstige situaties ('ought'), een ontwerpfocus. Toegepaste etnografie en participatory design starten vaak met specifieke, huidige praktijken, terwijl co-desigen en empathic design kunnen starten met ideeën voor alternatieve of toekomstige praktijken. Contextual design en de lead user benadering zijn pogingen om 'is' en 'ought' te combineren: in contextual design proberen onderzoekers/ontwerpers een huidige situatie te begrijpen en hun bevindingen toe te passen in een ontwerpproces, en lead users ontwikkelen ideeën en producten vanuit hun huidige praktijk en brengen deze in een ontwerpproces in. Deze twee spanningen gaven mij een focus voor mijn empirisch onderzoek; ik heb onderzocht hoe deze twee spanningen spelen in de praktijk. Ik heb een onderzoeksbenadering ontwikkeld om één HCD project te bestuderen waarin ik zelf werkte, als 'participant observer' (Hoofdstuk 3). Op deze manier kon ik HCD in de praktijk bestuderen, van binnenuit en terwijl het plaatsvond. Ik lette op wat plaatsvond tussen projectteamleden en hoe ze beslissingen namen in verloop van tijd. Ik lette niet op gebruikers, maar had alleen aandacht voor hen wanneer projectteamleden met hen in aanraking kwamen. Ik heb mijn studie gepositioneerd binnen science and technologie studies (STS); een 'empirische wending' in de wetenschapsen techniekfilosofie, of een veld in sociaalwetenschappelijk onderzoek, waarin de praktijken van mensen die wetenschap of technologie maken of gebruiken worden 235 bestudeerd. Verder koos ik voor een sociaal-constructionistische onderzoeksbenadering; daarin nemen onderzoekers aan dat de sociale werkelijkheid niet buiten hen bestaat, maar dat zij eraan deelnemen, en dat mensen de sociale werkelijkheid construeren en beleven in interacties met elkaar. Bovendien koos ik voor een exploratieve benadering en ik onderbouwde deze keuze door op te merken dat er slechts weinig kritische onderzoeksteksten zijn over HCD vanuit de praktijk of vanuit binnenuit. Tijdens mijn onderzoek heb ik geworsteld met het combineren van mijn praktijk-rol en onderzoeker-rol. Hoe kan ik situaties onderzoeken waarin ik zelf actief deelneem? En hoe kan ik mijn observaties relevant maken voor andere mensen in de praktijk? Ik heb reflexiviteit toegepast om met dergelijke vragen om te gaan en ik heb geprobeerd om reflexiviteit niet als een nadeel te zien, maar als een voordeel. Mijn empirisch onderzoek is gebaseerd op twee casussen in één project. In dit project hebben we geprobeerd om twee telecom applicaties te ontwerpen: één samen met en voor politieagenten en één samen met een voor mantelzorgers die zorgen voor iemand met dementie (Hoofdstukken 4 en 5). Deze projectactiviteiten waren verschillend en daardoor kon ik verschillende dingen observeren. Het team dat samenwerkte met politieagenten was relatief klein en homogeen en ik was actief betrokken bij het organiseren van workshops en dergelijke met politieagenten; hierdoor kon ik observeren wat er gebeurde tussen projectteamleden en politieagenten. Het team dat samenwerkte met mantelzorgers daarentegen was relatief groot en heterogeen en ik was niet persoonlijk betrokken bij de interacties met mantelzorgers; hierdoor kon ik me concentreren op wat er tussen de projectteamleden plaatsvond, bijvoorbeeld op hoe we beslissingen namen tijdens vergaderingen. In het politieproject (Hoofdstuk 4) hebben we een serie workshops met verschillende groepen politieagenten uitgevoerd als deel van ons onderzoeksen ontwerpproces. Iedere interactie met politieagenten had invloed op ons project; we hebben gaandeweg het doel en de focus van ons project aangepast. Dat leverde een telecom applicatie op die interessant is voor politieagenten en voor ons project. Het idee om wijkagenten te helpen communiceren en samenwerken met mensen buiten de politie veranderde, via enkele stappen, naar het idee om wijkagenten en noodhulpagenten te helpen onderling te communiceren en samen te werken. Onze focus op communicatie en telecom, en ons aanvankelijke verwaarlozen van informatieprocessen 236 en databases, verschoof naar het maken van een telecom applicatie die is gebaseerd op informatie uit een database van de politie. Deze applicatie, de WijkWijzer (PolicePointer), is ontworpen om samenwerking tussen politieagenten te stimuleren, door suggesties te geven om 'impliciete' kennis met elkaar te delen. Dit kan het politiewerk als geheel verbeteren. Deze manier van werken – gebruikers invloed geven in het project – wordt beschouwd als 'good practice' van HCD. (Dit is anders dan in bijvoorbeeld een productontwikkelingsproject, waar vasthouden aan een initiële opdracht 'good practice' zou zijn.) Aan de andere kant hebben we, onopzettelijk, enkele kansen gemist om te leren over politiewerk en om samen te werken met politieagenten. We hebben geprobeerd om ons in politieagenten in te leven, maar niet teveel. In de eerste workshop hebben we bijvoorbeeld besloten om ons te richten op een onderwerp dat comfortabel dicht bij ons projectdoel lag. We hebben onze aandacht gericht op onderwerpen waarvan we dachten dat ze van direct belang waren voor ons en als gevolg daarvan hebben we onderwerpen gemist die belangrijk waren voor politieagenten of die relevant voor ons hadden kunnen worden in de toekomst. Verder hebben we politieagenten laten deelnemen, maar niet teveel. Wanneer we hen uitnodigden voor workshops, vonden we het moeilijk om gezamenlijke creativiteit te faciliteren. We hadden vaak een opzet en een agenda voor een workshop en we hielden ons daar aan. Dit gaf de politieagenten beperkte gelegenheden om actief en creatief deel te nemen. Deze casus illustreert de moeilijkheid om open te zijn naar anderen, naar gebruikers, en om processen van gezamenlijk leren en creëren te organiseren. In het andere project hebben we samengewerkt met mantelzorgers tijdens onze onderzoeksen ontwerpactiviteiten (Hoofdstuk 5). In dit project hebben we moeilijkheden ervaren om samen te werken binnen het projectteam en om vooruitgang te boeken. Projectteamleden volgden verschillende onderzoeksen ontwerpbenaderingen en vonden het moeilijk om deze constructief te combineren, en de organisaties die deelnamen in dit project hadden soms verschillende belangen. Een terugkerend thema was het uitvoeren van 'dubbel werk'. Sommige projectteamleden voerden een vragenlijstonderzoek uit waarin ze honderden mantelzorgers en mensen met dementie interviewden. Ondertussen, en soms los daarvan, voerden andere projectteamleden informele observaties en interviews uit, en serie codesign interviews. Ook werd het proces van probleemformulering enkele keren uitgevoerd, gedurende verschillende vergaderingen; 237 vooruitgang boeken was moeilijk omdat verschillende mensen deelnamen in de vergaderingen en veel mensen inspraak wilden hebben. Op een dergelijke manier werd ook het idee om een specifieke soort telecom applicatie te ontwikkelen enkele malen opnieuw besproken tijdens vergaderingen. Positief is echter dat het voornaamste doel relatief stabiel bleef gedurende het project, namelijk: om de kwaliteit van leven van zowel mantelzorgers als van mensen met dementie te verbeteren, door de mantelzorgers te ondersteunen. We hebben een telecom applicatie ontwikkeld die interessant is voor mantelzorgers en voor ons project. Deze applicatie, WeCare, kan 'primaire' mantelzorgers helpen om taken te delen met anderen en op die manier kan de druk op hen worden verminderd. Verder hebben we veel en diverse interviews met mantelzorgers uitgevoerd om hun behoeften en voorkeuren te leren kennen, wat als 'good practice' van HCD wordt beschouwd. Deze casus laat zien hoe moeilijk het is open te zijn naar anderen, naar gebruikers en andere projectteamleden, en hoe moeilijk het is om openheid en sluiting (afronding) te combineren; er is de noodzaak om conclusies te trekken en resultaten op te leveren. Ik heb mijn observaties geïnterpreteerd en besproken, gebruikmakend van theorie (Hoofdstuk 6). Ik heb betoogd dat HCD kan worden begrepen als een sociaal-cultureel proces waarin onderzoekers en ontwerpers, samen met gebruikers, deelnemen aan een onzeker, chaotisch en 'interpretatief' proces waarin mensen betekenissen creëren en daarover onderhandelen – en dat ze op die manier innovaties kunnen creëren. Verder heb ik betoogd dat HCD kan worden begrepen als een politiek proces waarin mensen invloed proberen uit te oefenen op het project. Ik heb laten zien hoe onderzoekers en ontwerpers ertoe neigen om gebruikers te representeren door personas en storylines (beschrijvingen van fictieve personen en fictieve situaties) te creëren, en om over gebruikers te praten en beslissingen te nemen voor gebruikers, in plaats van hen zelf te laten deelnemen in discussies en besluitvorming. Bovendien heb ik HCD gepresenteerd als een proces met ethische kwaliteiten. Ik heb dat gedaan door begrippen te lenen van de Franse filosofen Emmanuel Levinas en Jacques Derrida. Geïnspireerd door Levinas en Derrida zie ik ethiek niet als een tak van filosofie die gaat over goed of slecht of als een zoeken naar en toepassen van moraalregels, maar als een 'eerste filosofie' over wat er gebeurt tussen mensen, over verantwoordelijkheid en vrijheid die voortkomen uit het appel van de ander. Vanuit enkele van hun ideeën heb ik de spanning tussen onderzoekers/ontwerpers en gebruikers besproken als bewegingen tussen 238 ander en zelf, en de spanning tussen aandacht voor 'is' en 'ought' als bewegingen tussen openheid en sluiting (afronding). We probeerden om richting de ander te bewegen als we probeerden om te luisteren naar gebruikers en andere projectteamleden, en we probeerden om richting openheid te bewegen als we probeerden om gezamenlijk te leren en te creëren. Tegelijkertijd hadden we de neiging om naar het zelf te bewegen als we onze eigen interesses, ambities, methoden of vaardigheden naar voren brachten of voorrang gaven, en we hadden de neiging om richting sluiting te bewegen als we de nadruk legden op het trekken van conclusies en het opleveren van resultaten. Zodra ik de ander benader in een poging om iets te leren (be-grijpen) heb ik de neiging om de ander te grijpen; ik neig ernaar om de ander richting mijn zelf te trekken, binnen mijn eigen denkkader, zodat ik de andersheid van de ander niet kan zien – en dan leer ik niets nieuws, alleen wat ik zelf al wist. Op een dergelijke manier neig ik ernaar om, als ik een project organiseer, een programma te creëren en uit te voeren: ik neig ernaar om het proces te willen beheersen, om binnen mijn eigen 'box' te blijven, om richting sluiting te bewegen, in plaats van richting openheid – en dan creëer ik niets nieuws, alleen meer van hetzelfde. Mijn voornaamste conclusie is dat het uitvoeren van HCD niet gemakkelijk of onproblematisch is (Hoofdstuk 7). Ik zie HCD als een kwetsbaar proces; het kan mooi zijn en het kan gemakkelijk stuk gaan. Mijn voornaamste aanbeveling voor mensen die HCD willen uitvoeren, is dat zij zich meer bewust worden van en zich meer expliciet uitdrukken over de ethische eigenschappen van HCD: hoe ze zich bewegen tussen ander en zelf, en openheid en sluiting. Verder heb ik reflexieve praktijk gesuggereerd als een manier waarop mensen die HCD in de praktijk willen brengen zich meer bewust kunnen worden van en zich meer expliciet kunnen uitdrukken over deze bewegingen: over hun eigen rol en invloed in HCD praktijken. Dergelijke reflexiviteit zou hen kunnen helpen om balans te brengen tussen hun poging om richting de ander en richting openheid te bewegen en hun neiging om richting het zelf en richting sluiting te bewegen. Ik kan proberen te ontkomen aan mijn neiging om de ander te grijpen, via een soort verlangen dat de ander niet benadert als een instrument om de begeerte van het zelf te bevredigen. Dit zou een poging zijn om de andersheid van de ander niet te vernietigen en om gezamenlijk nieuwe dingen te leren. Op een dergelijke manier kan ik 239 proberen te ontkomen aan mijn neiging om te programmeren, via een soort passiviteit die open is naar andersheid. Dit zou een poging zijn om out-of-the-box te komen en om gezamenlijk nieuwe dingen te creëren. Ik kan proberen toe te staan dat anderen – gebruikers en andere projectteamleden – mij vragen stellen en proberen hun te antwoorden. Dit zou hen kunnen helpen om hun praktijk meer in lijn te brengen van hun bedoelingen en van waar HCD over kan gaan: processen van leren en creëren die plaatsvinden tussen mensen. Daarmee beweer ik niet dat onderzoekers en ontwerpers hun eigen belangen, ambities, methoden en vaardigheden niet zouden mogen inzetten. Integendeel: zij kunnen proberen om deze te verbinden met de belangen, ambities, methoden en vaardigheden van gebruikers en van andere projectteamleden. Deze bevindingen kunnen bijdragen aan een debat over innoveren, ontwerpen en ethiek. Ik heb mijn studie uitgevoerd in een traditie van science and technologie studies (STS), waarin veel studies weinig of niets zeggen over ethiek. In dat opzicht kan mijn studie een welkome aanvulling zijn. Inhoudelijk kan mijn studie van hoe onderzoekers en ontwerpers personas en storylines construeren bijdragen aan een beter begrip van hoe gebruikers worden 'ge-configureerd' of 'ge-script' tijdens onderzoeksof ontwerpprocessen. Ik weet nog niet hoe mijn aanbevelingen zullen werken in de praktijk. Ik heb dat die nog niet formeel uitgeprobeerd en geëvalueerd. Toch heb ik drie voorlopige aanbevelingen besproken: over omgaan met gebruikers, over samenwerken in een projectteam en over managen van een project. Onderzoekers en ontwerpers organiseren hun interacties met gebruikers vaak binnen een van tevoren bepaald kader; in plaats daarvan zouden ze die interacties meer open en meer als dialoog kunnen organiseren, om gezamenlijk leren en creëren te bevorderen. Samenwerken binnen een multidisciplinair projectteam kan moeilijk zijn, juist door de verschillen tussen mensen; om communicatie en samenwerking te stimuleren, zouden ze kunnen proberen om uit hun verschillende tradities en methoden te stappen en om meer persoonlijk en subjectief met elkaar te praten over hun projectactiviteiten. Veel HCD projecten worden georganiseerd alsof het lineaire of logische processen zijn; echter, HCD kan beter worden begrepen als een sociaal proces waarin tegelijkertijd problemen en oplossingen worden verkend en ontwikkeld – misschien zouden we HCD wel tegelijkertijd moeten organiseren en niet-organiseren. 240 Het doel van deze tekst is om mensen die HCD in de praktijk willen brengen te informeren en te inspireren, zodat ze anders naar HCD kunnen kijken en HCD anders kunnen uitvoeren, meer in lijn met wat HCD kan zijn: processen van gezamenlijk leren en creëren. 241 Acknowledgements Working on a PhD can be a lonesome task. For me it was sometimes, for example when I was reading books or editing texts, but most of the time I experienced it as a social process. There were many people who supported my research project in various ways. I am indebted to TNO Information and Communication Technology, my employer, for supporting my research project. I would like to thank Jan Burgmeijer, Erik Fledderus, Laurens Hoedemaker, Rien Paulus, Angelien Sanderman and Valerie Frissen for their constructive feedback and their kind permission to 'script' (Chapter 1). Furthermore, I would like to thank Aloys Maas (my former manager) for supporting me in starting this research and Natascha Agricola (my current manager) for supporting me in continuing and completing it. I would also like to thank Jente Klok, Lottie Kuijt, Nicole de Koning, Sander Limonard and Sonoko Takahashi for jointly learning about human-centred design (in another project), Lex Dekkers and Thijs van der Horst (who completed their Master's theses with me) for the opportunity of learning from them, and many other colleagues with whom I talked about my research project on occasions ranging from brief encounters to long discussions. Moreover, I would like to thank Yvette Mead for her review of my use of English. Any incorrect use of English is due to my editing after her review. I would especially like to thank my fellow project-team members in the FRUX project, especially Ronald van Eijk, Henny Gunther, Sander Hooreman, Esther Huisman, Kristel Kerstens, Nicole de Koning and Henriëtte van der Roest, and project manager Edward Faber for supporting my research project. I am grateful for the opportunity of working and learning together with them, for their comments on earlier drafts of parts of this thesis and for their kind permission to be portrayed in this text. The empirical research was conducted within the Freeband research programme, which was supported by the Dutch Ministry of Economic Affairs under contract BSIK 03025. I would like to thank the tutors and teachers for the coaching they provided within the part-time PhD programme of the University for Humanistics, in which I conducted my research, for their coaching, especially Heather Höpfl for talking inspiringly about ethnography, Steve Brown for his talks on research methodology and on writing, 242 Jean-Luc Moriceau for talking about French philosophers and Peter Peltzer for cheering me up at a SCOS conference. Furthermore, I would like to thank my fellow PhD students for their support, especially Richard Ahl, Robert Earhart, Loes Houweling, Chris Kuiper, Robbert Masselink and Karin Sligting. I would like to thank people from the audiences of conferences for their reactions to papers I presented, parts of which I incorporated in revised form in this thesis: the 26th Dutch-Flemish Philosophy Day 2004 (Steen 2004), SCOS XXIV (Standing Conference on Organisational Symbolism) (Steen 2006b, early version of Chapter 4), EASST 2006 (European Association for the Study of Science and Technology) (Steen 2006c, early version of Chapter 5), the 23rd Colloquium of EGOS (European Group for Organizational Studies) (Steen et al. 2007, early version of Chapter 2), the fifth CMS (Critical Management Studies) (Steen 2007b, parts of which are used in Chapters 3, 4, 5 and 6), and the 2007 Workshop on Philosophy and Engineering (Steen 2007a, parts of which are used in Chapter 6). This research project began with a bet. The bet was that inviting Hugo Letiche (Professor of Meaning & Organization, University of Humanistics) and Jan Buijs (Professor of Management of Innovation, Delft University of Technology) to act as supervisors would create synergy. I am happy that this bet was successful. I remember occasions on which I was listening to discussions between the two professors, triggered by their curiosity about the other's approach. I also remember occasions on which they both asked me questions that made me feel confused. I would like to thank them for coaching me during this journey. Their teamwork enabled me to draw from the research tradition of the University of Humanistics and to defend my thesis at Delft University of Technology. I would like to thank my parents for always encouraging me to follow my curiosity. When I was a child, I would often take apart and examine a machine that was working perfectly, then find that I was unable to put it back together again. Your support helped me to grow into a person who is confident enough to begin and complete this research project, a task that is not unlike taking apart and examining a machine that was working just fine. Finally, I would like to thank Yvon. There are many things for which I would like to thank you, but here I would specifically like to thank you for supporting my research project and, at the same time, reminding me about other parts of life that also deserve attention. 243 About the author Marc Steen (born 1967, Haarlemmermeer) studied Industrial Design Engineering at Delft University of Technology (MSc in 1991 and PDEng in 1996) and Marketing (NIMA-B and NIMA-C). He currently works at TNO Information and Communication Technology (Delft) as a consultant and project manager, specializing in human-centred design and innovation management. Prior to this, he worked at Productcentrum TNO (Delft), at Education Centre Dar-ul-Hikmat (Lahore, Pakistan), as a self-employed industrial designer and engineer (Amsterdam), at the department of Industrial Design Engineering at Delft University of Technology, at Philips Consumer Electronics (Eindhoven), and at KPN Research (Leidschendam). From 2004 until 2007, while working at TNO, he participated in the parttime PhD programme 'Humanization of Organization' of the University for Humanistics. In 2006 he was awarded first prize for an essay on open innovation entitled 'Open for end-users' in a competition organized by the Dutch Advisory Council for Science and Technology Policy. More information on Marc Steen and texts that he has written and cowritten can be found on the Internet, see: http://www.marcsteen.nl.