Now I’ve posted about the way Contextual Design works, let me now tell you something about what I think of Contextual Design (I want to get this out of my system before I resume learning the materials for the test).

First of all, I think it’s cool. I hear that people actually use this in real companies, on real products, and that this has produced some spectacular results. Furthermore, by doing it myself I find that I really do get a better understanding of the user’s work, and that I really do think differently about product innovation (it is actually “work redesign”, not product innovation). Furthermore, even though the method is costly in times of money and resources, it can easily be adapted to the needs of the design team and the restrictions imposed by the company.

But of course, I wouldn’t be myself if I would be a bit skeptical about this. Why my skepticism? Well, first of all, I think it’s kinda strange that we only learn this method. In reply to my request there was a brief overview in class on other methods with the same goals, but as an Academic person I want to know what other people think the drawbacks, downsides and exceptions are. That way I can get a better understanding and appreciation of the method. But since we have little time, all of it is focused on doing it ourselves without really thinking about it. (This is not entirely true, because we are encouraged to reflect upon the methods and change them to meet our needs. But still there’s this basic assumption that “Contextual Design is the right way to do it”)
This becomes apparent when I hear some of my fellow students say after a three hour focus-setting meeting: “This is so useless, I already knew this!” I think that there’s some hindsight blindness involved here: Of course you feel like you came up with the only reasonable conclusion after 3 hours of modeling and discussing it.
Contextual Design seems to be the right way to do it. But there’s no real evidence that it’s really useful. In empirical user studies you have a hypothesis and you get a clear answer (with measurable confidence) of whether your invention was an improvement, and how much. With Contextual Design, you never know whether your final solution is better than what you would have come up with if you used another method or just common sense (it feels better, but there’s no evidence). An interesting digression: Iris van Rooij pointed me to the fact that if you take a long-run view of hypothesis testing, the same problem occurs.
You could in theory do an analytical study on the “effectiveness of Contextual Design”, by comparing the results of different design teams. The problem, however, then shifts to the flexibility of the method. There is no single way of doing Contextual Design. But are adjustments actual improvements? You never know for sure.

Despite my skepticism, I think that Contextual Design is a very useful method. I really feel that this method has a definite merit, and I think it would be a nice challenge to do some analytical research on this method, clarifying the areas of my concerns.
Furthermore, since this is a method that enforces adequate, human-centered innovation, I think that the Eindhoven University should teach this method to all the students. If you claim that you are the University “Where Innovation Starts“, you should live up to this title!

I stayed up way too late last night to finish my Machine Learning take home exam. But I actually finished and I’m not too tired right now. So let’s get down to business and provide you with some actual content on my blog. Something about the courses I take.
The course that absorbs the greatest amount of my time is definitely Methods for Human-Computer Interaction. I’ll not describe how this course keeps messing with the minds of the poor HCI students; that’ll be something you can read in the next Intermania. Instead, I’ll tell something more about what we learn and what I think about it.

Methods actually consists of two parts: Contextual Design and Usability Evaluation. We just started with the second part so I’ll devote this post to the first part. It’ll even be quite useful for me, since I have a mid-term exam about this part next Monday.

Contextual Design is a data-driven user-centered integrated design process. What does that mean? Well, suppose company X wants to make a new product, an innovation so to speak. Good innovations, as I told before, don’t just “pop up”; there’s a lot of sociological and psychological stuff that has to “work” before the innovation succeeds. Now while Innovation Science looks at this phenomenon from an analytical perspective, Contextual Design takes a design approach. Instead of asking “what constitutes to a good innovation in general?” it asks “what do we need to do in this specific instance in order to make our new product into a good innovation?”.
So what if you really want to make your new… laser printer… into a good innovation… what do you do? Contextual Design says that the first and most important thing to do is find out how people are using existing laser printers. “Cool!” marketing people would say, “Let’s send out the questionnaires!” Well, that’s not how you do it. You cannot get a real insight in how people use products by letting them fill out questionnaires. You have to actually visit users, and observe how they use the product. Don’t focus on the product, but on the work they do with the product. And make sure you get the context of the work too, so the communication that is involved in the work, the organization that the user is in, the physical environment that is his/her workspace. Only this way you can eventually find out what goes wrong, and how your new laser printer can make a valuable contribution to the work.

So, in Methods, we actually have to do this ourselves. Yoko, Gabe, Adam and I are investigating a program called iLogos, a tool used by the CMU Philosophy Department to teach students to understand and draw the structure of a (philosophical) argument, so-called “argument mapping”. The program is in its early stages of development, so we could take several totally different directions with it.
But in order to make a valuable product, we need to focus. How? Well, first of all, forget about the program and think about the actual task, the argument mapping. What does it involve? What are the important aspects about this task? Write each of your concerns on a Post-It note, and stick them all onto a whiteboard wall. Then rearrange them and group them so that different aspects of the task emerge. Label the groups, and decide on the groups you want to focus on during the project. Then think of a main question for these foci. This thing that you now have on your wall is an “Affinity Diagram”. The foci we selected and agreed upon with our client were “Learning how to use iLogos” and “Learning how to do Argument Mapping (via iLogos)”. This is very broad, but it rules out digression into extensions of the program into other domains or the investigation of different methods of Argument Mapping.
The next thing to do is the Contextual Inquiry, which is a special type of work-centered interview. We got three students of the Philosophy 101 course to come to the lab so we could observe them doing their homework. A Contextual Inquiry goes as follows: First you do a standard interview on work-related issues, like “what do you think about the homework”, “do you think that argument diagramming helps you to understand the arguments better”, and so on. Then you make a transition to the contextual inquiry part. Here, the user does the work and tries to “think aloud”. The interviewer tries to understand what the user is doing, and will interrupt him/her if anything is unclear. It’s almost as if the user is a master and the interviewer the apprentice. In our Contextual Inquiries (or CIs), we let the user work on the argument diagrams for homework, first on his/her preferred system (which was often pen and paper), and then on iLogos. We video-taped the whole process, and took pictures and digital copies of the end products. We did 3 interviews like this.
Well, and then you have almost 4 hours of video data with potentially useful information about the user’s work. The next step is to analyze these data, and make “work models” out of them. There are five different types of work models. The “sequence model” holds the steps of the task the user is performing (“user puts a premise on the paper”). In our case, it’s the most important model. The “flow model” models the communication between actors in the work environment (“user discusses homework with friends and makes revisions accordingly”). The “physical model” models the layout of the workspace of the user. Since we did our CIs in the lab, this was not a very relevant model. The “cultural model” contains the influences of other actors and organizations (“the teacher wants the user to do the argument mapping in a certain specified way”). Finally, the artifact model shows the objects the user creates or uses during his/her work (“user draft of homework – has to be redone before handing in”). The models are made for each user individually during an “interpretation session”. During these sessions, you come across several breakdowns (“user cannot copy-paste text from the homework into iLogos”), insights (“user always tries to find the conclusion of the argument first”), or design ideas (“make a collaborative version of the software that makes discussion about arguments easier”).
The next step is the step we took Monday and today, which is consolidation of the different user models. Note that we do this stuff on a very small scale, typically you consolidate only after you had CIs with at least 10 different users. The first step of the consolidation is to make a new Affinity Diagram, now based on the breakdowns, insights, and design ideas of the interpretations. In our case, we kind of came up with the same foci, which is an indicator that we don’t have to change our focus for the rest of the process. Then, you make aggregated versions of each model you made. This seems pretty straight-forward, but I found out today that by simply combining the models of different users, you come up with completely new insights and issues.

Well, the next step we will have to take is to inspect our final models and affinity, find where we could improve on the aspects of the work that are in our foci, and decide on an implementation of how to improve on these aspects. This way, we have used real user data to make valuable contributions to the users’ work.

Well, this is pretty much what we do in Methods. Since I now really am becoming tired, I’ll leave my reflections for tomorrow…

There was a really nice picnic this weekend. I didn’t take my camera, but Yoko let me play around with her D50. Our pictures can be found on Yoko’s Picasa page.