SOME REFLECTIONS ON THE IDM PROJECT REPORTS
To not confuse my comments with the examination, and to re-iterate my previous advice that you probably can learn much from each other here follows some thoughts after reading your reports. Although all comments do not apply to all reports, there is something to be learned by looking at many examples of how your peers have tackled the brief. Looking at what things were picked up, what issues fell to the side, where a given project appears strong or weak, etc., you gain important insights into the range of issues and possibilities the brief brings to the table – and what it takes to develop a strong response. Again, what Schön picked up from Dewey when he developed the notion of ‘the reflective practitioner’ comes to mind: “The student cannot be taught what he needs to know, but he can be coached: “He has to see on his own behalf and in his own way the relations between means and methods employed and results achieved,. Nobody else can see for him, and he can’t see just by being ‘told,’ although the right kind of telling may guide his seeing and thus help him see what he needs to see”.
With these comments, I do want to encourage you to read each others reports. I’m sure you will learn a lot.
ABOUT THE METHODS
In general, most projects have an appropriate selection of methods. Especially basic methods for gathering information and inspiration in the early phases of a project are present in most reports. This is an effective way of not only getting started, but also a basic strategy for grounding some key arguments that then will be used when proposing a design. There are, however, a few things to think about here in order to get all the way here.
For instance, quite a few reports confuse what is found with what is assumed. Of course, one might get both observations and ideas out of many information-gathering methods, but it is important to differentiate between them, or else you risk undermining the entire process.
Related to this issue is when you do not use methods to push yourself out of your existing knowledge and/or comfort zone, but rather as support for ideas or assumptions that were more or less there anyway. For instance, if you look closely, it is not that difficult to see the difference between someone going out and seeing something for the first time, and someone just going to get an illustration of something already known. This is not to say that one is faking observation (because this might not even be that obvious to oneself), but rather that you really need to push yourself and the method you are using to the point where it starts saying non-trivial things back to you. You may get far with common sense, but not far enough. And so, whereas most of you select appropriate methods, many of you need to work harder on their execution. ”God is in the details” as Mies van der Rohe put it.
Whereas some methods are more or less like events in the process, other methods require you to move back and forth during the process. Personas, for instance, are like that: to really get something out of personas one needs to keep in mind that while you shape the personas to reflect what is important in the design process, all of their characteristics must be possible to trace back to a specific observation. So, while personas are created, they can only be built using the material obtained during observations, interviews, etc. – to the extent that it should at all times be possible to go back to that original data to make sure one has not confused things. Unless you create and keep such connections, personas easily become worthless as they loose touch with the reality they are meant to represent.
One problem evident in many projects is they are not really finished. For instance, quite a few projects do not come all the way to the point where the design proposal is not only proposed but actually tried in some form. In quite a few cases, even the most simple rapid prototype would reveal basic problems in the proposal – and so even if the basic idea might be interesting, the proposal is easily dismissed for reasons you perhaps could have prevented had you just finished the process. What you need to take away from this exercise is the need to not just start the process, but to plan it from the start to make sure you have the time and resources necessary to finish it.
When it comes to being in control over the time and resources to make it all the way, the initial respect for a large and complex problem may sometimes be an obstacle. Not knowing what to do makes it hard to feel confident making important decisions. This often being the case in design, one simply has to learn to live with it. One key thing is to not let go to impulse of spending ever more time on just doing basic research, thinking that ”once I know everything I need to know I will start designing”. Instead, what you need to do is to think of the entire design process as a matter of learning and finding out more about the problems at hand. The early design proposals are not just tentative solutions, more importantly they are also probes that allow you to test and try ways of framing the problem. Indeed, this is one of the most difficult things in design: how to find a balance between grounding and ground-breaking.
The reports come in a variety of styles, the more informal perhaps being the most common, and most of them are quite easy to read and understand. The format is quite short, and it is interesting to see the different ways you cope with this. Useful and effective strategies seen in some reports include combining the description of early design ideas with existing designs: by at the same proposing one’s own idea, putting it in relation to an existing product, and then critiquing both, you get part of the background/related work, part of the process, and part of the critical analysis in one go.
Even if you choose an informal style of writing, it is important to remember that you are writing for someone, and with a specific purpose. In quite a few reports, the text is more of a continuous flow of ideas, observations, arguments, etc. – which might be fine when documenting a process to remember it oneself. But it does not work very well when trying to convince someone else. When presenting an argument or idea, you need to ground it somehow – and to do this you need to make sure the text has anchor points outside itself. For sure, the reader is interested in how you reason about things, but he or she is also interested in understanding the context of that reasoning – and that you consciously position your work within it.
For instance, many projects propose designs similar products already available. This is perfectly fine, the task was not to come up with something entirely new. What is not, however, is to not acknowledge that that is the case (especially when a few minutes with Google would reveal a range of related design proposals). What you need to do here is to use other examples as reference points, allowing you to be more precise about what it is that your design does and does not. To give an example: if you propose a design based on, say, an augmented or intelligent refrigerator, you probably should say something about why given the more less complete commercial failure of such designs in the past. I’m not saying you need a business plan, but if you are moving against things that are widely known, you need to explain why.
Another way to improve the potential impact of your proposal is to work with the balance between different sections and concerns in the paper. For instance, if half of the text is used just to describe the background whereas the design proposal is just one paragraph towards the end, then the impression is very likely to be that while the background work is there, the rest is more of a sketch. Similarly, even though one has a strong focus on, say, user-centred design in the process, that might still require the occasional remark about other concerns as well. For instance, even when comparing the benefits of two proposals strictly from a users point of view, if they are at the opposites of an investment scale (like post-its vs a new technical platform), you can not completely neglect that such differences will matter.
Finally, I also want to say that you have done a great job! This is no easy thing to do, and it takes practice to do it well. Some of you have come far already, others have more work to do – but in general: well done!