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…