Feedback by modulator – Ronald van Tienhoven

Deliverables handed in: Several small cardboard boxes with prints glued on the inside as illustrations of the central statement
A short statement titled ‘The Downfall of Nuance’.

There is one phenomenon that I miss in your statement, and that is Seduction. The reason certain aspects or properties of a given product are not revealed has to do with the dimension of mystery that entrepreneurs, marketeers, and/or producers consciously create a product’s image and reputation based on carefully revealing or ‘hiding’ certain aspects or parts of the product. Behind the veal the true product waits to be discovered by the user/consumer. Without wanting to generalize too easily, I think most users/consumers are quite able to get the information they want or need in order to fully assess the quality of a given product.
Although nowadays many times designers play a role in marketing or branding a product, it is quite a complicated process many people are involved in – in that respect the designer is one among many other stakeholders.
The boxes you showed during the presentation were somewhat simple – therefore the presentation content-wise didn’t have much impact.

Module Feedback form (DOC)

Reflection on the feedback

Note that the prints were not glued to the inside of the boxes, they were made in one piece. After all, the ‘inside’ of a product can’t be separated from the outside – they are inextricably linked.

Feedback by modulator – Koert van Mensvoort

As a replacement of the regular module, Emar conducted a one week mini-internship in which he worked along on a project on bio-customization.

I appreciated the resourceful work you conducted and the poster you created of the bio-customization process. Your input has been helpful to the larger project context you were working in.

Module Feedback form – Mass-Bio Customisation

Reflection

Mass Bio-Customisation is the commercial production of custom, personalised goods out of materials of animal origin. In this module, I developed the fictional process of a company manufacturing shoes from stingrays. Customers can design their own shoes by deciding the gene composition and the food program of the fishes that are the material source for their pair of shoes.
Eventually, the fictional company will be launched on the internet, complete with background information and interactive design-your-own-shoe applet. The purpose of creating this fictional company is to trigger the discussion about the widening gap between the origin of materials and the products that consumers buy.
People have been using natural resources – I consider wild animals as part of that – since they existed: a hunter would use his catch for food and the manufacturing of tools.
Since a few centuries, the relation between these resources and the end product has become very thin, because of the industrialisation of the manufacturing process. Factories are essentially black boxes that produce goods. If inside they would find a way to create artificial leather with the same characteristics as ‘genuine’ natural leather, we wouldn’t notice it in our shoes. As far as we know, the factory produces shoes, we don’t see the process of turning cows into footwear.

In the fictional stingray-to-shoe industry, the customers get to see the process, they even get to control it. The relation between the origin of materials and the end product is very explicit. Just like with the traditional hunter, but on an industrial scale and using modern technologies.

While this may seem extraordinary, I think the essence is not all that strange: mass-customisation exists, you can design your own shoes and have them delivered to your door. Bio-customisation exists, plants are genetically modified to fit our needs and wishes, animals are bred and fed for the same thing. The novelty (and possibly shock) is in the visibility of all of this. I hope that by confronting people with a fictional scenario that is in line with current societal and industrial developments and making them believe it is real, they start to think a little about their position in these developments. I believe deception is a good way to do this: trigger a response by presenting an objectionable, yet fictional, example.

Feedback by modulator – Jacques Terken

The participants conduct a small experiment on the effect of bandwidth (text only, audio only, audio-video with camera focusing on face vs focusing on workspace) on communicative success in computer-mediated communication. The experiment in conducted in teams of three to four participants. The deliverable is a joint report documenting the experiment and linking it to the concepts that were studied through literature and discussed in the meetings, and an individual reflection.

Jointly, the deliverable and the individual reflection show that you achieved the main objectives of the module.
You were an active participant in the meetings
The report is acceptable. Some comments/feedback:
* You decided to focus the experiment on latency in Computer-mediated Communication, which is an interesting topic, and you formulate two hypotheses (H0 and H1). They should have been named H1 and H2, since the term H0 is usually reserved for the alternative hypothesis of H1, stating that there will be no effect. Furthermore, the hypotheses you propose are not adequately introduced/justified by findings from the literature or theoretical considerations. Finally, you do not motivate why you looked at ‘lying’ as one type of communication, i.e., why it might be interesting to look at lying.
* You do not explain why you use these dependent variables. Also, it is unclear why you use different dependent variables for the two kinds of tasks. This makes comparing the outcomes for the different tasks difficult.
* Apparently due to the way you present the results, you also draw conclusions that are not adequately supported by the results. In particular, you conclude that for functional communication task completion is faster when the video signal is delayed than when no delay was present, but proper presentation of the data would have shown that this applies only in the case of no audio delay.
* The structure of the report can be improved. The introduction is rather weak, and could have been a bit more extensive, establishing a better and stronger connection to the literature and ending with hypotheses. The presentation of the method and the results is rather messy, so that it is difficult to find out what you did precisely and what the outcomes are for the relevant comparisons. E.g., for 2×2 designs, it is advised to use 2×2 matrices and graphs (Audio Delay +/- x Video delay +/-) for presenting results. Also, there are important facts missing, e.g., it is unclear how long the delay was, how an “exchange” is defined, and whether the delay times are included in the task completion times (which for “both delay” would have had a considerable influence on task completion time without saying something about the intrinsic effects on task performance beyond the mere effect of slowing down the rate of interaction).
* The Results section also includes some discussion of the results, so that a more appropriate title for this section would have been Results and Discussion. The Discussion then might have been integrated in the Conclusion section, indicating limitations on the results and conclusions.
* In the discussion you demonstrate adequate understanding of the limitations of the present research.

Module Feedback form

Reflection on feedback

* It was one week, of which 1,5 days were assigned for the report – given more time, the structure and foundation of the statements made in the report would have been better;
* There were indeed several shortcomings in the process, we became aware of that afterwards;
* Because of the limited testing data, we found it difficult to draw valid conclusions. We might have been a little to bold in this.

Reflection on the module

This module gave me an overview of the field of computer supported collaborative work (CSCW), the basics of communication and the psychological and sociological dynamics of collaborative or group work in general. I got insight into the advantages and disadvantages of CSCW-systems, several applications of it and a basic understanding of the ongoing research in this field.
The experiments that we did on distributed video and audio communication showed the influence of latency and sychronicity in such systems. For me, it was remarkable to find out that in the case of personal communication, apparently synchronicity is more important than low latency, yet in functional communication, the latency has more impact than synchronicity (especially the latency of audio).

Both the literature study and the experiments that we did taught me several design considerations and possible pitfalls, such as the aforementioned impact of latency or the importance of workplace studies.

I found it striking that this last aspect, the importance of workplace studies, is highlighted in literature (especially the book on CSCW by Greif), yet it does not seem to be incorporated into the concepts and applications that were developed in the last decade. Much of the ongoing research seems focussed on technological capabilities rather than actual benefits or improvements for people.
Projects are technology-pushed and miss, at least in their presentation, a strong foundation in contextual user investigation.
The evaluations of several of the systems that were not adopted by people give a number of possible causes, most of them focussing on the concepts themselves. None of them that I know about considers the design process itself as a possible cause for the failure of the collaborative system.
The user centered design approach that we are taught here at this faculty might be a good way to design CSCW-systems. To me, starting with the user instead of with today’s technological possibilities increases the chances of designing a successful system.
As pointed out by Greif, bridging the barrier between the contextual studies and the actual design is a challenge, but I think it can be overcome using a more user centered approach.
I think that at this time, there is a gap between the ongoing research on CSCW and currently desired, accepted and used systems in everyday life. The potential of CSCW is clear and has already proven itself to some extent. I think that by taking a more user-centered view on the subject, killer-apps can be designed.

Feedback

Deliverables handed in: experimental dynamic simulation in processing, reflection.

Your simulation showed how the use of sound resulted in clear added value. Observations in reflection are correct. It is hard to find the right balance between parameters if the system is programmed. When there are no humans in the loop the system contains no “common sense”.

Emergent Behaviour – module feedback

Reflection

For me, this module was a nice way to get acquainted with the concept of emergent behaviour. Through literature and discussion, I learned the principles, and by trying to create an emergent behaviour system in Processing, I got practical insight into the underlying rules and conditions that are required for such behaviour.
The main thing I learned from trying to create a decentralised system is the importance to simulate. The essence of a system that works through emergent behaviour is that agents respond to their environment and each other, locally. The design of such a system is done top down, but the results should be coming from the bottom up. This, and the high amount of agents makes it hard to predict what’s going to happen. So the only way to design the system is through experimenting – trial and error.
I see the simulation I made together with Remco Magielse as an emergent behaviour playground. Our aim was creating a dynamic simulation rather than thinking about a practical application of emergent behaviour. By doing this, I found out how hard it is to create a basic emergent setup. Even though the rules are simple, the balance between them is very delicate. For example, increasing the line of sight of the agents immediately resulted in more ‘responsive’ behaviour, because the agents reacted more on each other (from further away). In a more practical application (designed with a higher level goal in mind), I think this balance has a strong impact on the success of the system.
Still, I think designed emergent behaviour could work very well in real life applications, as long as a degree of ‘natural’ variation in the behaviour of the system is not a problem. A situation where this might work is with the discussed networked traffic lights.

A personal goal in this module was getting acquainted with Processing. Because of my earlier experiences with Java and other languages, the basics were easy, so I experimented with creating appealing visuals and adding sound to the simulation. Especially the sound added an extra dimension to the simulation. The very first soundset, using existing samples, became rather annoying over time, so I created a new, harmonically coherent soundset myself. I noticed that this increased the engagement of myself and other people with the simulation, somehow giving it more depth. Because of my interest in sound (in) design, I found it nice to see how the sounds influenced the overall experience of watching or playing with the simulation. In a broader context, I think the addition of aesthetically pleasing sound to interactive products can enhance the interaction. I will try to apply this in future designs as well.

Feedback on project team

The layout/setup/form of the report is original and effectively supports/visualizes the relation between the different design activities of each phase and the components of the Reflective Transformative Design Process (RTDP): excellent!

In general, findings, results, guidelines, conclusions are presented as itemized lists. Relation between items (e.g. relative importance) are not always explained. Often text of report describes what happened, but rationale behind decisions is missing. Also, information about the ‘how’ results were achieved / analyzed is often lacking. Link between findings and original design problem (games supporting/enhancing open-ended play) is not always made explicit. I support your conclusion that ‘skating’ already supports open-ended play, but what does that mean? Why? In what way? Formulate your conclusions in terms of different characteristics (dimensions) of (open-ended) play (e.g. what about game rules? How are these rules formed and developed over time? What about learning? Learning in terms of social, psychological, or physical development? Role of feedback? Etc…).

Your final concept (SkateCam) is very promising. Skaters can create new, or enhance existing skate activities with the camera. These activities are not pre-defined; they will emerge. But, did you prove that this will happen. You state “this is not hard to imagine”, but the reader (client) needs more arguments or ‘evidence’ that this will indeed happen.

I miss reflections on how your design proposition relates to the ‘outside’ world ( client, literature, related work, …).

Design process (order of steps) is still rather traditional: analysis, solution generation, evaluation. Good selection of methods, but more discussions/reflection to what is know in the User-Centered Design literature is needed (e.g., contextual interviews/observations as explained in the books by Cooper (Faces) or Preece et al.).

Feedback on my individual reflection

Overall, good individual reflection. Strong reflection concerning the empathy game (obsessions). Too little reflection about design process, e.g., added value user studies, or comparison with other UCD processes.

Reflection

For me, the focus of this project was not so much on getting acquainted with the reflective transformative design process, it was more about keeping a very strong focus on the user throughout the process.
I took part in the design class of last semester, where the reflective transformative design process (RTD-process) was thoroughly integrated in the program. During that class, I learned about the underlying theory and applied it in a project. For the design class I already wrote a reflection on the RTD-process, inspired by the lectures of Hummels, Frens and Tomico.
In this user class, the RTD-process seemed more like an external requirement than like an integrated vision that was essentially part of the program. However, I think we did adhere to the RTD-process throughout project Skate with success. In my opinion, the essence of the RTP-process is that at every moment in the design process, the activity that is needed at that particular time should be done. In other words, activities don’t ‘belong’ in a certain phase of the design project; there is no pre-set order. The sequence of activities is determined by looking back on what has been done and then looking forward to what is needed to advance.
Doing multiple pre-planned iterations, for example using the 1-10-100 method, can help structuring the design process while leaving enough freedom to determine the next step based on the insights gained so far.
The pre-planned iterations provide scheduled moments of high-level reflection: at the end of each iteration, the vision and objectives for the next iteration are set, based on the outcomes of the last one. At these moments, the direction of a project can change, because the vision is restated to be in line with the latest developments. Within an iteration, lower-level reflection can help determining the course of action to fulfil the objectives and work towards the vision.

During project Skate, this is how we worked. In each of three iterations, a vision was established, users were involved, concepts were generated and prototypes were built and evaluated. The order of these activities was established through discussion and reflection. In my opinion, these discussions were essential to the process because they help to stay critical about what is and what should be done.

The concept of open ended play was often the topic of discussion within the group. Through the repeated contact with skaters and the skating environment, we learned that skating is open ended play. We felt there was a contradiction in wanting to add open ended play to a context which is already open ended play in itself. I think the direction we took, supporting open ended play as it already took place, has been the right one. With an extremely simple tool, skaters are inspired to discover new ways to interact with each other and with the environment. The emphasis on style and co-reflection rather than measurable achievements leaves the full control with the skaters.
The fact that a finished-looking prototype with high visual appeal was needed to inspire the skaters to think about the possibilities was remarkable, but in a different way than I first thought. It didn’t prove that skaters are superficial people that have to be seduced with visual shine, not at all. It pointed out that I, as a designer, fell into the pitfall of assuming that anybody should be able to think along with a sparsely explained and poorly worked out concept that I invented. It’s like I was disappointed that someone didn’t understand what I was talking about, after uttering only half a sentence.
Because we presented the prototype as being final, it triggered lots of responses from the skaters. Besides lots of suggestions for the development of the concept, it showed the most important aspect: the Skatecam was lots of fun.

Feedback

The feedback on this activity is integrated with the feedback on the User Class as a whole. See the area about project SkateCam – the feedback can be read there.

Reflection

Creating the ‘Junkievision’ empathy game and watching the creations of the other teams was not only fun, but also educational. Learning to understand the user by walking a mile in his/her shoes proved to be very effective. Empathising with people with an addiction, as we did with Junkievision, gave very personal, almost intimate insights into the motivations of an addict. It taught me what occupies the mind of such a person, or at least it made me think that I know what occupies the mind. Because we haven’t checked our ‘simulation’ with someone who knows what it’s like, we can only assume that the Junkievision experience approaches reality.
In any case, this personalised approach could be of great use when designing for extreme users. However, I think two things should be taken into account when doing this. First of all, by empathising with users, we (designers) don’t automatically know what’s best for them. We might have an idea, a belief even, but these are highly subjective. Such an empathy game is not a replacement for other information gathering methods.
Secondly, it might be beneficial to keep some distance to your subject. Oftentimes, getting too involved results in a loss of objectivity, a loss of overview. With Junkievision, this was true in a very literal way; the effects on ourselves were quite extreme. After walking around for almost an hour with the glasses and earpieces, the visual and auditive stimuli made it impossible to concentrate on anything. Eventually, it caused me to stop caring about what happened around me. After the session, my eyes were tired and it was still difficult to concentrate.
I think it is important to consider in advance what the effects might be of such an attempt to create empathy. Most likely, it will create understanding of the user. But it might also change you as a designer, in ways you might not expect. I think Junkievision was on the edge. It did create empathy and thereby understanding of the user, but it also suggested that you could go too far in trying to feel what the user feels.

Feedback

My previous assessor, René Ahn, has reviewed the deliverables.
This is what he wrote:

Ir. Klooster and I formulated a C-condition which Emar had to fulfill in order to show he
was able to improve on the mentioned weaknesses. As Ir. Klooster left the department I
am at present the only original assessor that can comment on the way in which Emar
fulfilled his C-condition.

I examined the deliverable that Emar handed in to fulfill these conditions.
These were entirely to my satisfaction. I mainly concentrated on the report as this is the
most important issue for me. I found the rewritten report had improved considerably: it
was far more structured and readable and more importantly I do feel that I was quite able
to understand and appreciate his design process form this report. A strong aspect of the
report is that it is illustrated well, and that it communicates the richness of the process
from which it is derived. I therefore conclude that the C conditions have been fulfilled.

I would like to conclude with some recommendations to Emar:

In several places your report contains enumerations of various types: reasons,
disadvantages, system components, design activities etc. In such cases it often good
practice to use a bullet list to give a reader a clear overview. You can then, later, explain
the various points in more detail.

Another recommendation is to clearly separate the parts of your text where you reflect on
your own activities from the parts that simply describe those activities itself. For a reader
it is sometimes difficult to get a clear view of what you did when the descriptions of these
activities are too often interrupted by considerations and ruminations.

Just tell the reader why you engage in activity, and then tell him what you did.
Then consider your findings, and determine your next step.

Kind Regards

Rene’ Ahn

The full feedback text, including the C-conditions (PDF)

Reflection on the condition work

Largely due to the flaws in the first version of this report, I received a C-(Conditional) verdict in the previous assessment. Along with the explanatory video that I made, this rewritten report aims to fulfill the requirements of the assessment.
Looking back on the process of rewriting the report, I can see now that this was necessary. When critically rereading and reconsidering the report and its structure, I discovered that it showed an overall lack of coherence. The described steps of the design process didn’t logically lead to the next steps, parts connecting different pieces of the story were missing, and the chapter and subchapter headers didn’t explain what the chapter was really about.

In order to improve this, I took several steps:
* I read another student’s research report to learn more about the content, structure and manner of writing;
* Comments were requested from people that read my report;
* I studied guidelines on how to write an academic research report and fitted my project in this format (and vice versa: fitted the format to my project);
* I used index cards to determine the new structure.

After that, I made a plan on what to rewrite, add, remove or modify, making annotations and comments in the margins of the report and using labels and note cards to outline new topics and elements.
Personally, I think this new version is a lot clearer and more coherent than the first version. Seeing this difference made me understand what is probably the reason behind the lack of structure of the first report: my initial approach in writing the draft report.
When writing the draft report, I constantly switched between writing about different parts of the process. I wanted to write everything down as it sprang to mind because I feared I would otherwise forget things. This non-lineair writing style doesn’t have to be a problem in itself as long as there is a phase in the report where the different parts are tied together. I had made an overview of what I thought should be in the report, but I focussed mainly on activities instead of also addressing motivations and logical connections between parts of the process. So, in my case the nonlineair writing style resulted in a segmented report that maybe covered the things I did, but not how these things were glued together.
Maybe I can conclude that I lost the big picture when writing the report.

The approach used for the rewrite has focussed a lot more on this bigger picture. In the future, I will continue to apply the tools and methods used for this rewrite. Not only at the end of the project when writing the report, but also throughout the project to keep track of how the process is structured and steer it in a more conscious and pro-active way.
The transformative reflective design process learned in the design class is a good way to structure the design process. As indicated by Joep Frens, co-inventor of this process, documenting this process can be difficult. I experienced this first hand. Now, this rewrite has taught me some tools to handle the documentation of such a process so that not only I, but also other people can have a clearer overview of the project.