Task Analysis and Contextual Inquiry
From CS160 User Interfaces Sp09
Lecture on Feb 9, 2009
Readings
- Principles of Contextual Inquiry. Contextual Design. Chap 3. Beyer & Holtzblatt.
Saung Li - Feb 04, 2009 06:04:20 pm
One thing I'd like to ask is, would the interviewer simply being there influence the way the customer works? For example, would the customer be extra cautious and detailed about doing his work that he deviates from what he normally does? If this is true, then the data the interviewer collects may be flawed. The principle of partnership may partly fix this, but since the customer is drawn by the interviewer to use mostly concrete ideas the customer may do unusual things. The good thing about this is that the customer himself can know more about the tasks that he takes for granted and can help the interviewer come up with design ideas. The interviewer then, must be open-minded so that he isn't biased in the data gathering, emphasizing the focus principle, and then interpreting the gathered facts correctly to suit the users' needs. Using the context principle in which interviewers observe what happens is interesting in that observers have different focuses in mind. Different people notice different things so people need to be more open-minded and look for different things. It would probably help to have multiple people observe to make sure something important isn't left out.
Ling Chen - Feb 05, 2009 11:39:26 pm
When it comes to design, I imagine a designer putting himself in the shoes of the customers. He would try to think like the customer and figure out how best to design a system. I see now that it will never work. After all, then the designer is not the customer and would have been designing for himself instead. What better way to find out what the customer want than to talk and interact with them to extract the information you need? I agree with the author that "when you're watching the work happen, learning is easy." An actual live example always beats hundreds and thousands of pages of theories and concepts. When the designer puts himself in the context of the customer's work, then he can learn about the customer's work structures. The interviewer would have to get the user to "do and tell" at the same time to reveal certain helpful details. Sometimes the structure is simply invisible to the users themselves. When they tell, they abstract and generalize things and tends to leave out the details. It's up to the interviewer to observe their actions and listen to what is left out, and ask questions to fill those holes. I don't imagine this being an easy job at all. Like the author mentioned, we tend to focus on certain aspects of things that interests us. It would probably take much practice to learn to think behind the customer's actions, interrupt to talk about it, and keeping in mind all the intrapersonal triggers to expand our focus. Even after we collected all these useful facts, as the author pointed out, interpretations are also extremely important.
Rohan Dhaimade - Feb 06, 2009 10:46:06 pm
The first point I would have to make is that the when you include something into an environment, the people and things in that environment will change. People will act differently when they are being interviewed. Though, after considering this, I think people at most will just be self-conscious about certain habits. They might not surf the web as much. Even if there is a binding agreement that there would be non-disclosure, acting normally is not going to happen. Another point that I didn't see addressed in the chapter is the fact that people do things differently and how to evaluate that but I guess that would be another chapter. The entire paper though was very good, and it explained how to create the proper environment, a master apprentice relationship with the apprentice interjecting and asking questions. I know when I was asking about things from other people, I have definitely broken many of the rules the article stated. I've definitely too helpful, I now realize that all the helping is contradictory to the goal of understanding how to find out if something works or not. I also wanted to add something onto the paper, posture and position are important. I know that if somebody is staring at me from behind, occasionally taking notes would be uncomfortable. I think creating a less formal relationship and maybe small talk during the transition phase might be beneficial to the relationship. Though, this is just my opinion.
Meiying Li - Feb 07, 2009 10:11:03 am
This reading is basically about interview techniques. The little clue "present tense indicates abstraction" is really interesting since I find myself using present tense when I don't want to tell the exact details.
I have a question about interrupting the customer. The reading says it is good to interrupt since this brings the customer into partnership. But from my personal experience being interrupted usually requires some time to warm up again to return to the original point. It is also possible that the customer may not be able to act like usual while being interrupted too often. How do we balance this?
Chris Thompson - Feb 07, 2009 12:30:25 pm
I liked this reading, although toward the end it started feeling a bit long. But it had some good insights about social engineering. Casting yourself in the role of an apprentice does indeed seem like a great way to get information, because even if it's not a conscious decision people conform to the roles they're presented with all the time. It also encourages them to actually do their work, instead of talk about their work, and the article makes very sure to get the point across that abstract thinking glosses over most of the details you're actually interested in when trying to improve a system's design; all the small little problems or annoyances or unusual quirks the user has. It also opens up the opportunity, and indeed encourages, the interviewer to ask questions about everything of interest in a natural context. I also liked the bit about listening especially well to the subtleties of their responses. If they reply with some hesitation, ask them to clarify. Try to summarize what you think's going on, and if they respond affirmatively but word it slightly differently, pay attention to their wording. In general, probe and observe.
Cuong Ngo - Feb 07, 2009 05:21:17 pm
In order to fully understand the customer, designers should play the role of an apprentice because "the apprentice learns the strategies and techniques of a craft by observing multiple instances of a task and forming his own understanding of how to do it himself." In contrast, the interviewing relationship model "tilts power too much towards the interviewer." For instance, "the interviewer controls what is asked, what is discussed, and how long is spent on a topic." This obviously doesn't get designers any useful data nor does it help with the process of designing the system. The chapter also pointed some common pitfalls, one of which is the expert/novice relationship model. Designers come to the workplace to observe how the customer does his or her work, not to tell them what to do to get their work done. All in all, I found this chapter very interesting.
William Cho - Feb 07, 2009 03:15:02 am
The contextual inquiry method seems to be a great way for designers to gather data from the customers themselves to design systems that improve their workflow. However, it seems tough for the interviewer to keep in mind everything necessary to keep the balance between their relationships, what he needs to observe from the customer and his work patterns, how to coerce the customer into revealing concrete data, and so on. Also, others have pointed out that there may be a difference in how the customer behaves because of the interviewer's presence. Despite that, this model has a lot of strong points, and the reading gave lots of thoughtful ideas on how to approach this method.
Dwijgarg - Feb 07, 2009 08:33:47 pm
This reading is really interesting, as it tells us about the relationship between clients and designers. I find this to be extremely helpful, as the key to building a good product is to fully understand what is being demanded and what can be given. I really liked the breakdown of this process. Context is useful as it allows designers to understand what the customer might need from a first hand point of view. This makes the task of designing the product easier, as designers gain a better knowledge of what the customer needs. Partnership is also important as it forces designers to look at the nitty-gritties, and thus design a complete and thorough product. By building a relationship with the client, the designer gains a full understanding of personality, and thus specific needs as well. Interpretation is something the designer should do after gather all the information in order to make the best possible product with an interface that the client will easily be able to use and understand. And focus will ultimately help the designer understand what the customer's point of view is, and thus make it possible to keep an ongoing and healthy professional relationship until and even after the product's completion.
David Burban - Feb 07, 2009 11:03:36 pm
Essentially, this reading is about how to conduct the perfect interview. The reading goes into detail about the techniques to conduct such an interview, and the clues to look for to improve one's interview skills.
The reading talks about a couple of interview models, including Master/Apprentice model, and the Partnership model. The reason for doing these interviews is to better understand the customer and their daily needs and routines. We should be using some of these techniques when we go and interview our target audience for the project.
Stephanie Shih - Feb 08, 2009 12:56:56 am
The article was useful in showing how to work with people to lead them towards your purposes. It basically did plot out the ideal interview; the master/apprentice parallel was interesting because it showed that an interview was not just about asking questions and getting answers. There needs to be an understanding between the interviewer and the interviewee, one that goes toward the subject at hand and - as the article mentioned - is not a host/guest relationship. However, while the idea of their method seems brilliant, it seems like it'd be a hard process to maintain in practice simply because it's so much to keep in mind and, well, people are people.
Chunwei Lai - Feb 08, 2009 01:19:04 pm
The master/apprentice model is one way for a person to gain understanding of a subject. Sometimes simply watching the task being is enough for one to learn, however sometimes it is quicker to perform and (possibly) fail the task and learn from one's personal experience. The reading mentions that while doing a particular task, one recalls previous activity which I think is important for people to realize so they do not just blindly perform the task. Additionally the reading brings up some tips for the interviewer and interviewee which should be useful for those who are in the process of finding a job.
Shoeb Omar - Feb 08, 2009 04:59:03 pm
I found that this reading was annoyingly redundant but it did have some good points in general. The entire concept of the master/apprentice relationship reminded me of lecture styles in class and made me wonder if perhaps our teachers were more concrete in doing examples along with the class, we'd learn more by observing them in their work. A return to old almost as we'd be like actual apprentices rather than students being lectured to. I think it's interesting because of the point the article made about awareness. People realize what they're doing more when they are actually doing a task rather than describing it. Apprentices can see the actual concrete details of what is going on that are often easily skipped over when just "describing" a task. That is, the details reveal themselves. Thus this idea is a good one for contextual inquiry, "apprenticeship compressed in time" as the article describes it. By really seeing and understanding how a user works, only then can one really gain insight into how to design a better system. And by asking users if a change will improve the way their working while they actually are working, designers can get immediate and extremely relevant feedback. Thus I think contextual inquiry is an extremely important tool to really design better systems.
Colin Downs-Razouk - Feb 08, 2009 06:26:56 pm
One thing that I think should be included with any interview with a user, that the contextual inquiry method does not really account for, is a discussion of how the user learned what he knows. You might interview one user and find that they do not even know how to use the current interface. If that is the case, who taught them the interface? This seems like it would not fit in well with the contextual inquiry method because there is no longer a context for how the user learned what he knows. It might be useful to interview someone while they are learning the interface. This would provide the designer with critical information that they might never be able to get from a longtime user.
Nalditya Kusuma - Feb 08, 2009 06:25:41 pm
The reading covers some interview suggestions to get the best design to help make customer's life easier. The reading explains mater/apprentice model of interview and exploits it--breaking it down to different components and giving out some of good illustrations. It suggests the model because that way the interviewer can understand what the customers do without prior knowledge about their matters, and makes the customers able to explain in details what they usually do concretely not abstract. However, this model brings some redundancy and the reading brings up ways to increase the model's efficiency. They are context, partnership, interpretation, and focus. Overall, the reading is very useful in giving some ideas to group members who have no experience in interviewing customers how to engage with customers.
Anatol Tsang - Feb 08, 2009 06:48:41 pm
The article describes some (hopefully) useful tactics for getting the most out of a contextual interview. In the software engineering class, we learned that one of the project team member is actually from the client, and that client member is there in order to guide the team on how the user will use the end product. However, contextual inquiry is the opposite: a member of the design team becomes the lone member at the workplace of the client. This article brings out many different methods of getting out useful information during this critical time of examining the user. I never realized that allowing the user to walk the interviewer through the work day would provide a much richer interview. Also, the matter of interpretation seems like a tricky topic. If the interviewer is bad at interpretation, maybe this process will not go as well as expected. I guess that the interpretation of the interviewer will be lead to the right track eventually, but bad interpretation seems like it can make the contextual inquiry process more difficult.
Denise Ngai - Feb 08, 2009 06:23:27 pm
The master/apprentice model stood out to me. It stresses the benefits of learning through experience and learning from modeling after something already done; having some type of design structure. The reading states that seeing the work reveals the details and allows one to learn the skill.
"A master does not teach by designing a course for apprentices to take. Nor does a master teach by going into a conference room and discussing his skill in the abstract. A master teaches by doing the work and talking about it while working. This makes imparting knowledge simple."
The above quote relates to a comment above regarding teacher's teaching styles. More examples rather than plain lectures about how to do something or the concepts behind it may be a more effective teaching technique. When a teacher does examples step by step in front of a class, it will be easier for the class to see how the skills can be applied onto an actual example and thus allow the students to learn.
Jason Lo - Feb 08, 2009 05:00:30 pm
I think the article was fairly interesting in the way that it explained a fairly expected route that would be taken to talking to your users, first with an interview, then watching them work and asking/giving suggestions for ideas. This approach is fairly taken for granted, but they analyze how you should go into such an experience and pitfalls you should avoid. I think the article was successful in imparting a tone and behavior to enter instead of giving a list of rules. I thought a weakness of the article is that they don't mention any other techniques or what shortcomings there are to the master/apprentice model and what other models might be better in other areas. Also although the master and apprentice model has some parallels to the relationship between masters and apprentices in the past, it seemed the idea is more of meeting as equals with different purposes more than one person teaching another.
Alan Young - Feb 08, 2009 08:26:21 pm
"Principles of Contextual Inquiry" states that the main idea of contextual inquiry is apprenticeship. Interviewers become the apprentice to effectively study the customer, who should be approached as the master of his/her work. However, it is all done with a balance between too much control by the customers on the apprenticeship model and too much control by the interviewer on the traditional model. Good designers must learn to effectively recognize work structure when interviewing customers and then be able to focus in on important details. I feel that a lot of the tips in the article were interesting because they were subtle, such as nodding, which usually implies that the interviewer understands the situation when he/she should be taking the approach as if everything new, thereby shifting his/her perspective so that there is a greater motivation to learn new things about the customer.
Salman Rahman - Feb 08, 2009 07:51:23 pm
This paper has to be the most useless and un-informing piece of "literature" (using this term loosely) I have ever laid eyes upon. It is as if the authors of this paper were writing a "how-to" guide on human-human interaction for aliens from outerspace. In all honesty, reading this paper was an insult to my intelligence.
The authors talk for 2 pages about what role the design team should have with the customer in the field. I don't understand why Beyer and Holtzblatt needed to expand for so long on such a simple concept. I feel like everything could have been summarized in the following: "Because you as the design team member are trying to get data on how the customer operates in his or environment and how he or she completes tasks, it is best to take on the role of an apprentice learning from a 'master' as opposed to an interview/interviewee relationship. By doing so, the customer doesn't have to think about what he or she does in a context outside of his or her work; rather the customer performs tasks as normal and explains while doing them."
Done. 2 pages saved.
The authors also discuss really mundane and obvious things like the fact that you want the customer to be comfortable with you. They even give the stupid example of if the customer won't feel comfortable around you unless you have had a cup of coffee first, then have a cup of coffee with them.
Thanks B&H!!! Your analysis was so probing and insightful. You should do a dissertation on this because the knowledge you have just imparted upon the world will change the very fabric of our society.
The topic that this paper is discussing is very basic and intuitive. You are trying to learn about how the user performs tasks and interacts with his or her environment so you can make improvements to design. In order to learn as much as you can, you need to prod the customer in the right way in order to extract the information you need from them. To do so, you would be best served by watching them perform tasks as they normally do, occasionally interrupting them to ask why they do something in a certain way, etc. Customers rarely think about the structure of their work so it is up to you as the design team member to extract that information from them.
I just condensed a 14 page document into a paragraph. Sweet.
Sean Ahrens - Feb 08, 2009 09:49:45 pm
I found this reading to be helpful -- and yes, a good deal of the information was intuitive, but I found it helpful that the authors pointed out the guidelines they did. And in contradiction to this, I would say that assuming a master-apprentice is not itself the first thing a novice interviewer would think of. The part of the reading I found most valuable was how to get your customer to talk in the concrete, rather than the abstract -- how to elicit details from real experiences, rather than summaries. A lot of people talk in the abstract as a way to have to avoid the challenging thinking required to recall real details, and having a toolset to get them to do otherwise is quite an advantage. One quirk I noticed in the guidelines is that during the introductory phase, you want to ask them some questions about what they think of their current systems/procedures. This is a bit odd because, as even the reading admits, this will elicit summary experience (which is of little value). But I suppose that sometimes customs (of being polite and doing some small talk) are neccesary even when they provide no actual value to the business purpose at hand.
Carol Chen - Feb 08, 2009 10:12:50 pm
This reading was very educational. I think the authors really drove home the point that the people conducting the interview need to view it from the perspective of an apprentice who has a lot to learn. They also made it clear what the purpose of a contextual inquiry is - to observe how the user completes tasks in his or her natural environment. This past week, I had the opportunity to conduct two contextual inquiries for another class project. From these experiences, I learned how difficult it can be to avoid the interview/interviewee trap and how to minimize tangents in such an inquiry. While philosophical discussion was very interesting too, it was more illuminating for the purposes of our interface design to focus on task-based observations and questions. We also tried our best to ask questions about certain actions immediately, rather than having to go back to the topic several minutes later. It seems that inquiring immediately garnered more thoughtful and confident responses about the subjects' thought process. We minimized the potential discomfort caused by our being too nosy by preparing the subjects ahead of time for what to expect and which roles my group members would fulfill. The authors of the reading hit the nail on the head in every case; I felt well prepared to dive straight from theoretical reading into real life contextual inquiry. The act of actually conducting such contextual inquiries turned out to be a very valuable learning experience.
Mark Dhillon - Feb 08, 2009 10:06:35 pm
I found the section on Focus to be pretty interesting. It's not a revolutionary idea by any means, but I think it is really true. At first I was taken back by the author's statement about focus being unavoidable, but upon further reflection it makes perfect sense. While this seems like a problem, the author describes setting a "project focus" in order to start every member of the team off at the same point. I was particularly interested by the notion of expanding one's focus, and how the little judgments like when the customer says something you don't know or when he or she does something completely unexpected tends to get looked over. I thought that was a really interesting obstacle that can get in the way of deft design. Great job.
Alexander Cho - Feb 08, 2009 10:27:37 pm
This reading proposed a very detailed model of how to effectively obtain data used for designing helpful technologies for a workplace by conducting interviews in a very specific way and interacting appropriately with its many nuances. I never knew gathering information could be so complicated and how seemingly little things like the relationship roles established could affect dramatically the way the interview goes. I found the snippets of interview examples quite helpful and it allowed the information to be more concrete rather than too conceptual. I found the varying responses to indirectly say "no" quite humorous and easy to relate to. Overall I agree with the strategy presented, the master/apprenticeship and partnership model. I hope to apply this to our project for the most informative feedback on our product.
Ian Hildreth - Feb 08, 2009 11:05:22 pm
When first reading this article I think back to psychology - specifically behavioral psychology. One of the important ideas is that a person who knows he or she is being watched, or is performing in some experiment, will change their behavior to meet the goals of the study (whether consciously or subconsciously), so wouldn't the consumer being watched by an interviewer not truly perform in an unbiased manor? In general though I liked how the article broke down gathering information and giving different techniques to having an objective interview. The master / apprentice model is a good reminder of how important it is to see your design in work to actually know the completeness of your interface, and implies that the most natural design will be the most elegant.
Sean Hansen - Feb 08, 2009 11:29:04 pm
It will take some work on our parts to figure out how to adapt the information in the reading to what we'll be doing in the course. We'll be presenting the user with something new, and it'll be hard to settle into a master/apprentice relationship when the master has no idea what he's doing. However, although the article may have been a bit prescriptive, we can still apply the principles. Say we're doing a run-through of the ui using sketches with a user. I think that in order to use the principles from this reading, we'll need two interviewers instead of just one so we can get the most out of the exercise. The interviewer guiding the user through the interface is in too much of a position of control in order to get unbiased data; however, the second interviewer can at least foster an air of partnership.
Kevin Huey - Feb 08, 2009 11:23:41 pm
Recall the oft-overused saying for experiencing by "going into one's footsteps." The reading basically tells you to do the same, but instead the interviewer observes and sometimes interacts rather than going through the whole experience by oneself. The onlooker tries to pinpoint each action and the thought processes related to them. Essentially, this is "going into one's footsteps" since the interviewer is really looking at each detail closely and evaluating every aspect of these details.
What really interested me though was that there is a specific relationship you need in order to get the data you want. Pretty much you cannot take the form of any kind of generic role or you will only be perceived in that form, so information will be skewed. This kind of makes sense with regular conversations with people as well. If you know their general personality and interests, you're conversation will be more geared towards those aspects. Sometimes you want to try changing the way that information is exchanged, but it's hard to get rid of the whole complex that's in your mind. So when the reading suggests a great partnership, I would have to agree. The two people will treat each other as equals, or even alike people. There won't be any reservations whatsoever.
Timothy Yung - Feb 08, 2009 11:44:31 pm
The article was both interesting and uninteresting.
Its explanation of the master-apprentice model was interesting because it put into words an abstract interaction between two people. While reading this part, I could relate to it by reflecting on how I often demonstrate or teach things to other people. Even during the discussion of the context, partnership, interpretation, and focus flow, there were some interesting points mentioned such as the recognition of work structures in everyday tasks such as the start of a secretary's day.
However, much of the paper was very uninteresting because they basically put basic human interaction into words. I felt that the context, partnership, interpretation, and focus flow was structuring something that did not need to be structures. Most of it was common sense and could have been derived from the explanation of the explanation of the master-apprentice model.
The interview structure was even less interesting because it was a quick summary of how to conduct an interview. The read wasn't too boring, but it might have been a waste of time.
Andrew Chen - Feb 09, 2009 01:11:59 am
I would like to identify two of what I found were the most important points from the article: the first is that humans love to abstract and generalize, so refocusing the customer on real details and real events is important. Indeed, seeing the actual details in a specific event helps a lot more with designing than a general statement, since many times the basis of good design is eliminating those small, specific annoyances that are never revealed when things are presented generally. For example, saying that "we are in need of a better phone system because our company needs to communicate a lot" doesn't reveal the annoyance of say, the receiver runs out of batteries unexpectedly because it is hard to know whether it has made contact with the base and so is able to charge up. The second point that seemed the most important to me for a designer to learn the exact details of a user's work is not to go in with prejudice, and to actually grab onto paradigm shifts instead of making the user's actions fit the designer's preconceptions. Both of these are quite valuable and practical things to watch out for when doing interviews.
Matthew Can - Feb 09, 2009 01:02:27 am
This reading gave great advice on how a designer should approach a customer interview. The designer's primary goals in the interview are to observe the customer performing his tasks and to interpret why the customer does things the way he does. This is not at all like the kind of interview one typically thinks of. The reading provided useful tips on how to break out of traditional interviewer/interviewee relationships. For example, consider how useful the principle of partnership is. This may seem kind of obvious, but that's probably only in hindsight after having done the reading. Truthfully, most people probably stick to a formal relationship during interviews and this stifles the natural flow of the watching and probing process. The principle of context also seems obvious, but it is easy to forget the importance of sticking to ongoing work and concrete data. I have done user interviews in the past for group projects and I realize that I had done things all wrong. I'll definitely be referencing this reading and using the process of contextual inquiry when I conduct interviews with members of the target user group for this class project.
Adam Kauk - Feb 09, 2009 01:36:11 am
That was a very interesting reading. I would be interested in maybe applying those principles of problem profiling to other areas of life. Sometimes I have a conversation with someone and it feels too much like an interview or prescripted. Maybe I could say, "Alright, lets do something that one of us does all the time. For example, I could teach you something or you could teach me something." Then that would be the basis for building friendship rather than abstract conversations all the time.
I like the idea of focus because it shows that we need to limit ourselves in order to actually accomplish something. By only focusing on one or a few areas, interviewers allow themselves to go more deeply into an area and help themselves find actual solutions, rather than focusing on everything and not going deep enough to find any solutions.
Derek Liu - Feb 09, 2009 01:28:15 am
This article is indeed intuitive and presents a lot of knowledge that we already know, however, I found it useful to have these things spelled out for me in a very understandable way. One particular passage I found interesting was "People sometimes don't even remember how to do their jobs themselves; instead, they depend on the environment and the things in it to tell them what to do." I found this more to be an insight on how people rely more on conditioning when it comes to mundane tasks such as filing rather than actual brainpower. This creates an unawareness when it comes to how we do our jobs every day and creates a sort of routine for how people do their jobs. As UI designers, we have to take this into account and that people may not always give an accurate description of how they do their work or even how they use a particular piece of software because much of it is simply routine and mental conditioning.
Chao Michael Zhang - Feb 09, 2009 01:45:53 am
Like all of the other readings we've done for this class, this reading provided very practical advice and guidelines for doing something very ordinary. From my software engineering class last semester, we learned about interviewing for requirements in general, but the relationship perspective of interviews is something I had never heard or considered before. I am still not so sure the distinction between the different "relationships" is as clear or important as the article makes it out to be, but I may learn otherwise once we begin interviewing users for our project. A question: what are other possible relationship models that could be used? Are any of them possibly more effective than those presented in this reading?
Yin-Zen "Johnny" Hwang - Feb 09, 2009 02:08:20 am
This piece of work seems to be a meta-meta-cognition. in other words, it seems to be thinking about how other people think about thinking. "if a customer leans back and stares at the ceiling, he is almost certainly abstracting." -- eh sure if you say so. i guess i just abstract differently. i look straight ahead past everything else to abstract. "The goal of partnership is to make you and the customer collaborators in understanding the work." -- i'm not understanding this sentence at all. what's going on? so master-apprenticeship doesn't help me understand what's really going on? but the gist of all this reminds me of sociology methodology in gathering data, and those readings were a headache to go through. too much specific method, not enough of a general idea of why we're doing it this way or that.
Moonway Lin - Feb 09, 2009 02:03:48 am
The master/apprentice model sounds promising, but it only works well for situations where the user
- knows what he's doing (knows how to operate a GUI);
- isn't involved in a complex task where he wouldn't want to be interrupted by an interviewer constantly; and
- isn't easily affected by the thought of being watched constantly
That said, I think it's unsurprising that high-quality UIs/products out there all have seen some kind of user input. For example, Windows Vista suffered from lackluster sales and reception, and Microsoft has worked to rectify this by offering public betas of Win 7 that include feedback forms and surveys. (Obviously, on such a large scale, it becomes impractical to interact with each user on a one-on-one basis, but it's still user input.) When UIs are designed for small target audiences, speaking with users directly and allowing them to sound off is even better. Sometimes, the designer's mind becomes detached from the user's, and hence it's necessary to get a second opinion.
Timofey Titov - Feb 09, 2009 01:50:25 am
This article supports IDEO's principle of "getting physical". Seeing the work process, learning it and talking to actual users provides hands-on experience. It allows the designer to identify with the user. I also think that the actual meeting with users makes the designer more responsible and attentive to his/her own duties. The article presents a dilemma - on one hand you don't have to fully understand the work performed by the user, but on the other hand you should avoid summaries and pay attention to details which can turn out to be important for interface design. We can also see that even though there exist general interface rules, UI is still group and task specific.
Raymond Young - Feb 09, 2009 02:16:30 am
I really enjoyed this reading because it felt very real. The methods of contextual inquiry are concrete, and I can see how once a contextual inquirer becomes good at what they do, their designs will have higher success rates. This is because the interviewer is facilitating user-designed products for user-defined problems. By observing patterns among workers in a particular environment, one can see the common obstacles or areas of inefficiency, and design around making the environment flow more smoothly. It seems that the approach described in the article would unveil obvious and commonly encountered problems since one thing the interviewer is doing is consciously looking for paradigm shifts. This goes back to many of our previous readings in that so many things can be designed better. We have gotten so used to having to work around bad designs that the inefficiencies and difficulties of every day life become hidden to us. Proper contextual inquiry keeps unsticking and revealing pitfalls that have become, to most people, just "the way things are". In this way, it facilitates designs that are more streamlined to natural tendencies which are common across the targeted user group.
Kevin Nakahara - Feb 09, 2009 02:25:20 am
I definitely think the idea of "apprenticing" with a customer as a means of design could work very well. Obviously, however, the designer would have to take care to pick a customer suitable to being shadowed. The customer should probably be an average member of the target clientele, and should be instructed to act normally while having the designer do exactly what the customer wants. That way, since people often see things as "my way or the highway," the apprentice would probably take on very similar characteristics to that of the customer, and would be best able to interpret the results of the apprenticeship and focus on the most important aspects. To make it system work better, it'd probably be best to have a design team of 5 or so to go out to do the same thing with different customers. After the apprenticeship, the designers with the most "outlier" customers would be determined, and would not work on the project in order to focus on a product best suited for the focus group.
This concept also reminded of the extreme programmming method where a professional customer is brought in to aid software developers. That seems to be the complete opposite concept of this one, although they seem pretty similar to me.
Shendy Kurnia - Feb 09, 2009 03:34:25 am
It is an interesting reading. In designing user interface on a tool, I have been just counting on some existing similar tool. I assume the existing tool must be quite 'understanding the user'. However, this reading gives me a lot of new insight. It teaches me how important (and not time wasting) to be there and go through what the user does. I definitely agree on the statement in the reading about sharing the interpretation will not bias the data. I think the common problem with designing blindly is that the designer will see that his/her design is obviously easy to use, but in fact, it confuses user.
Adit Dalvi - Feb 09, 2009 03:38:26 am
The entire reading focused on how to conduct an interview. The article describes the master/apprentice model in great detail and highlights why this model is ideal to use for interviews. It compares this model to others like interviewer/interviewee, guest/host and others and it shows that the master/apprentice model is ideal for conducting an interview. As designers, it is important for us to know how to conduct an interview with customers correctly so as to obtain the required data for improving our designs. It is important to talk to the users, watch them working and asking for feedback. All of this must be done in a correct way so as to obtain the correct data from the users and the article uses the master/apprentice model to bring this to light.
Jeffrey Patzer - Feb 09, 2009 04:15:58 am
The most interesting idea I found this article to present was how to interact with a user in their work environment effectively. I understand that this was the main point of the article, but I had never truly processed the idea of how to actually talk to a user about their job and how they use a program. I just assumed you go and ask them questions about their work or tape them working. It never entered my mind that one should approach the user as a master and consider yourself an apprentice. Although this concept is simple and powerful, it was not obvious. The article did a great job of describing how one should be an apprentice, but also try to keep a certain power in keeping the user on track when doing their work. I think that the best part of this article was that it really educated the designer on how to go about information gathering, which can at times be undervalued and not done thoroughly enough.
David Jiang - Feb 09, 2009 02:39:21 am
This was a very interesting read. It was very informative and taught me, step-by-step how to conduct good, successful customer interviews. Some of the key points included starting off with the master-apprentice model. This means that the customer is the master and knows all about the his/her job and the interviewer (apprentice) is here to observe everything in great detail to learn about what the master does and exactly how he/she does it.
There are also the four principles of Contextual Inquiry.
-CONTEXT: Go to the workplace of the customer and observe everything that the master does.
-PARTNERSHIP: Interact and speak to the customer while he/she is doing his/her job so you can get a better sense of what he/she is doing, WHILE he/she is doing it.
-INTERPRETATION: Fine out why the customer does what the customer does.
-FOCUS: Challenge customer ideas and concepts that do not make sense to you. Make sure everything is intuitive and one must be able to think outside the box.
Chang Su - Feb 09, 2009 04:37:05 am
The chapter described interesting and useful, albeit potentially very expensive, approaches in understanding client situation and needs. It also offered very apt advice on how NOT to conduct a client study. But as someone noted above, I am not certain that the reading could be adaptively applied to the course. Unlike common designers, who design things to help a target user group with a task or agenda that the latter is concerned with, we are designing a GWAP with an agenda that we care about, be it to produce data that is of use to us, or to educate the user regarding an issue. Therefore there is no user need to speak of, only user interest. The techinques described in the chapter are thus not very useful at all.
Phiroath Chan - Feb 09, 2009 04:42:57 am
The most interesting part for me was the part about partnership. Whenever I think about interviews i think of someone of higher rank asking me questions to see if I'm qualified for that job. That being said i think interviews are not an easy thing to do. The interviewer has full control in this context and your job is basically in their hands. So when partnership was brought up in this reading i found it interesting. The goal of partnership is to make the interviewer and the customer collaborators in understanding the work the customer does. I believe this is a great way to work to together and overcome some of the other relationship models mentioned in the reading. Traditional interviewing relationship puts full control in the hands of the interviewer. The reading also mentioned apprenticeship, but now full control is in the hands of the customer. These are both problematic because if the interviewer has all the control the data might not be accurate and if the customer has full control then the interviewer might not get enough data. In Conclusion, I believe that using a partnership-based relationship will truly benefit both sides.
Eric Hernandez - Feb 09, 2009 04:26:07 am
An interesting aspect of this article was that of relationships. Treating someone like a child often elicits in the person rebellion, as if they are a teenager. Their listing later in the chapter about the many relationship types and their pros/cons in workplace observation was something that I have never read or even heard about, but is very useful to consider. The overall structure of Contextual Inquiry seems very efficient for getting to know the customer. Switching from probing to watching, taking in all of the processes the customer goes through and finding the overall structure, should definitely be the focus on any such workplace observation. Especially important, as mentioned in the chapter, is probing the customer when the customer takes a seemingly strange action. Although not explicitly spelled out in the book, this action could be the result of bad user interface design that could be improved.
Victor Lum - Feb 09, 2009 05:07:20 am
I found it interesting that B&H say that the best way to conduct an interview with your target users is do it in a way that is very non-traditional. All the ideas in the article sound simple, but I've never thought about conducting an interview that way. The whole master-apprentice but partners thing was something that's so different than what I normally consider an interview. Especially for the designer, who's supposed to be the expert, it seems odd that he's the one who actually needs to do most of the learning, and the people who use the stuff he designs are the ones he needs to learn from. But I guess if you think about it, that's the way it should be. And asking questions when things come up while working makes a lot of sense too. I can tell from experience that a lot of the things I do, I don't really think about, I kind of just do. And if asked about it, I usually don't really know what to say.
Szu-Chun Mao - Feb 09, 2009 06:52:23 am
This reading gives us a good sense of an understanding of how users think and tells us the importance of interpretation in contextual inquiry. It shows different ways to interview people; however I think overall, the content and strategies in this article is somewhat too simple. Most of the materials in this reading can be understood with common sense. I like the master/apprentice analysis, however I think it’s hard to use this model and apply in the real world to be that useful.
Prahalika Reddy - Feb 09, 2009 07:30:16 am
This article was very clear about what observational techniques are most effective and I agree with the points the writer makes about contextual inquiry. I understand the benefits that are to be gained from using the master/apprentice model. It is a great idea to observe a customer in his own environment and doing what he would normally do. It is the best way to actually observe him naturally, without forcing him to consciously think about his actions as he relays them to the interviewer. When designing a user interface, instead of listening to the user talk about how he would use the product, it is much easier and more beneficial to watch him use it, and see what mistakes he makes, which parts are the easiest to navigate, etc. This is exactly what the master/apprentice model is.
I also think that reading this article will be very useful when we talk to users about our group projects. We now have a clear understanding of how to structure our studies of the user.
Siddharth Shah - Feb 09, 2009 07:39:22 am
This reading dragged on for much longer than needed, but the overall message was an important one. I like how they listed the various other models that don't work (interviewer-interviewee, expert-novice...) and said what was wrong with each. They decided on the master-apprentice model, and I think that works well. However, I am curious about how employees might change their behavior if they knew they were being watched. Personally, I do think that they would pay more attention to their work with a design team member standing right there watching them. In this case, you would be designing for when they are more focused, but not on the average day when they are just grinding through the day. A hidden camera would get rid of this obstacle, but then again, cameras can't interrupt to ask questions, and they can't even see everything that's going on. Overall, then, I think the design team member being there and interrupting and really understanding what is going on is an extremely important part of the design process.
Aaron Hong - Feb 08, 2009 11:45:11 pm
The reading is quite interesting, but I found most of it to be common sense. Everything Beyer & Holtzblatt said is pretty intuitive, but what was particularly useful is the discussion on how to walk a customer through a retrospective account. It is a line of questions that I found to illuminate a lot of information with little effort. With these nitty gritty details, you can really see what part of the work can be made efficient through technology, who needs help, and where to keep looking.
Sum Sum Wong - Feb 09, 2009 09:46:33 am
The reading is actually an interview's guide because it focused on how can we conduct a good costumer interview in order to improve our design. The four priciples of contextual inquiry suggested in the reading includes, context, partnership, interpretation and focus. I found out that the context part is the most interesting one among the four. As suggested by the reading, interviewers should "go to the customer's workplace and see the work as it unfolds" in order to get the most accurate data(avoid summary and abstration). The reason for doing this is explained by "The Master/Apprentice Model" that "even if the master were a good teacher, apprenticeship in the context of ongoing work is the most effective way to learn". Beside that, the interpretation part also look interesting to me. It is more like a study of psychology of customer.
Bernardo de Seabra - Feb 09, 2009 10:52:31 am
In the chapter "Principles of Contextual Inquiry" the authors cover an important phase of the interface design: understanding what the user needs in order to work effectively. In summary, the interface designer must physically spend time with the people that are going to be using the system in order to understand their work and how they execute it. In order to accomplish this the interface designer will have to interview the user. This interview is a very different process from a regular interview. The interface designer has to play the apprentice role in the master/apprentice model in order to extract the best and most accurate information. In this model the user executes his daily tasks as he would normally do but now the interface designer observes his actions carefully. Whenever the interface designer is not clear about the reasoning about any aspects of the behavior of the user he interrupts and discusses what is going on. During this process the interface designer can also learn about events in the past related to current events. After this phase of the process is finished the next step is also an important one: interpreting the data. Since the data acquired during the interview process is not good by itself, it has to be contextualized and interpreted. Once this data is interpreted the interface designers can focus on particular points of view as they now have a better understand of what they are dealing with. Overall, this process is a partnership between the interface designer and the user as their relationship is important for the success of the project.
Sean Kim - Feb 09, 2009 11:14:17 am
Before reading this article, I usually think that the user interface is just needed to focus on how it can be more useful and easy. I had thought that it can be achieved by lots of experiences. But actually it can be more easily done from understanding a people. And I also believe the four principles of contextual inquiry; Context, partnership, Interpretation, and focus, help to manage the object to achieve the more understandable for people. An alternating between watching and probing for partnership in the principles was the beneficial point to me.
Anjana Dasu - Feb 09, 2009 12:40:13 pm
This article really underscored the human aspect of human computer interaction. I thought the idea of establishing an alternative relationship dynamic with a user was interesting. The author advises us not to enter into an expert-novice relationship with users, so that by doing so, we effectively distances ourselves from an interface we have played a role in designing. I think this is very important, so that we don't trivialize the user's experience by say something like "It's easy-- you just do this <seemingly simple to us but complicated to the user action>." This might be an easy role to fall into when you are involved in the design and implementation of a product. At the same time, however, the author does not make the unreasonable demand that we refrain from forming and voicing our design suggestions. He says we should bounce our ideas off the users in order to evaluate, refine, and if necessary reformulate them [the ideas]. The author also warns against the interviewer/interviewee relationship, and instead proposes the apprentice approach. The interviewer should be unobtrusive, in the sense that he should not tell the user what to do or pose point-blank questions; instead, he must follow the user closely and adapt his/her questions to the user's behavior. This made me think of the interviewer's behavior a sort of interface-- as we interact with the user, we should position ourselves in an effective/efficient but also comfortable and unobtrusive way.
