Task Analysis and Contextual Inquiry
From CS 160 Fall 2008
Lecture on 9/10/2008
Task Analysis and Contextual Inquiry
Readings
- Principles of Contextual Inquiry. Contextual Design. Chap 3. Beyer & Holtzblatt.
Discussion Questions
The paper argues for the "master apprentice" model during interviews. It also describes other relationships (like interviewer/interviewee) that interviews can fall into. Discuss the disadvantages but also any potential advantages of other interview models.
Discussions
Please post your critiques/commments on the required readings below. To do that, first login by using your user name and password, then click the "edit" tab on the top part of this page (between the "discussion" page and the "history" page), New to wikis? Read the Wiki editing guide. . Hint - Please put a whole line == ~~~~ == (literally) at the beginning of your submitted critique, so the wiki system will index, sign and date your submission automatically.
Gary Wu 22:15, 9 September 2008 (UTC)
A lot of the points made in the Four Principles of Contextual Inquiry were things I never would have thought about. In the Summary vs. Ongoing Experience section, the fact made about details being lost in summary is definitely very true and something I see myself doing a lot. I thought that the analogy used in the Concrete vs. Abstract Data section, when the customer is leaning back vs. the customer sitting forward, was great. I also agree with the usage of the term collaboration, as opposed to cooperation, in the Partnership section of the reading. I always like to think of collaboration as working in conjunction with your partner, where both people have equal voices. Cooperation is more of a "just deal with your partner" situation that isn't the most efficient and comfortable environment to work in. I guess this correlates with the relationship the interviewer has with the customer as well, since the article talks more about it later on.
Greg Nagel 00:32, 10 September 2008 (UTC)
I like the way Beyer & Holtzblatt integrate the tendancy to design into the interview itself. The key piece of genius is incorporating customer feedback into the interviewer's design ideas. Proposing designs to the customer both helps the interviewer get a better understanding of the customer's work and helps the customer understand the designer's viewpoint, giving the customer a chance to make an insightful design suggestion in context.
Anthony Kilman 01:09, 10 September 2008 (UTC)
This reading totally reminds me of the “outside consultants” from Office Space.
The notion of playing one side of a relationship tends to pull the other party into the relationship is a bit confusing. If the other party is consenting to act in this manner, I believe this statement holds true. But otherwise, it is totally false. For example, if I tell the guy next to me, “hey, I'm going to act like a farmer and you're going to be my chicken...” the guy is going to think I'm insane; not start to cluck incessantly.
There are a lot of valuable points to take away from this reading, but I believe that they could be summed up a bit more efficiently. For example, the partnership role and focus tend to overlap and repeat many of the same ideas. And unless the reader has absolutely no experience in detecting a person's reactions to an idea, much of the examples IMO were a bit unnecessary.
Alan McCreary 01:33, 10 September 2008 (UTC)
The principles that Beyer and Holtzblatt bring up sound very useful. I especially like the idea of keeping everything concrete and steering away from any kind of abstract explanation. What might be problematic, though, is the amount of commitment required by the customer. When describing the structure of a contextual interview, the authors tell us to be very nosy, asking about phone conversations, looking over the customer's shoulder, etc.; they also recommend an interview length of two to three hours. If the system in mind has to be created in a short timeframe, it seems like it would be difficult to find someone who would agree to this kind of lengthy (and a bit annoying, it appears) interview.
Kumar Garapaty 03:36, 10 September 2008 (UTC)
When they first discussed the apprenticeship and master model, I interpreted it as the interviewer should be the master and be the one asking the questions about how they use the design. But acting as an apprentice and trying to understand the way users use the product allows the interviewer to learn much more about the product. I found Focus as the most interesting principle of Contextual Inquiry. Often times a designer narrows down into a particular design concept, when the solution could be broader making the product not as effective as possible. Discussing the chain of thought leading to an interpretation might be the most important concept but a designer might also find new interpretations after the interview. In that case, discussing with the interviewee may not be as helpful because they will not be in the process of performing the task, possibly leading them to wrong conclusions.
Wenda Zhao 03:41, 10 September 2008 (UTC)
The principles encourage developers and users to work closely in order to build a better system. In general, I think it is always hard to know what exactly users want. The principles help developers to reduce the gap between what will be built and what users really want. I especially like the idea that we should treat every user utterance as something important. Because some small opinions can be good for both the system design and user interface sometimes .I think the principles are definitely going to help on finding what users of the system really want.
Haosi Chen 04:20, 10 September 2008 (UTC)
The key of this Beyer & Holtzblatt article is about incorporating customer feedback into interviewer's desian ideas. Presenting what you want to design to the customer would help the interviewer know what the customers really need, on the other hand helps the customer understand what the designer tries to design. This give a chance to the customer to make suggestion's to the design context.
Juanpadilla 04:46, 10 September 2008 (UTC)
The concepts and ideas discussed in the chapter are very good conceptually but I am very skeptical on how they will really apply in the real world. For example, I don't think that in most cases it is realistic that you will get to "interview" the person who is most likely going to be doing that part of the job on the system. More than likely it will be the supervisor, manager or owner who will be doing the job how he/she thinks everyone else should be doing it. If it is the case that the person doing the job is the one that is getting interviewed, then chances are they will be thinking about pre defined procedures rather than how they really do their job in fear of reprimand from the higher ups if they hear how this person miss-followed the prescribed procedures (think the Bobs from office space, mentioned above). In either case, you are not capturing the true design that will be efficient for everyday use.
Buda Chiou 05:30, 10 September 2008 (UTC)
Beyer & Holtzblatt give many example about how to proceed a interview, which make the text very comprehensible. I have got some interview before, and I have also interviewed other people. Originally I was very nervous about getting intervied because I thought being interviewed is like being interrogated, but most interview I got is just like chatting with the interviewer, which made me feel very comfortable. Therefore, I totally agree with what Beyer & Holtzblatt say about the relationship model of interviewer and customer.
Mohammed Ali 05:34, 10 September 2008 (UTC)
The master/apprentice relationship is very efficient in gathering information. This relationship cuts right to the chase. The other models, although not entirely useless, are relationships with limited benefit to the design process. The interview/interviewee model for example is limited because of a few reasons. First, the interviewer does not know what to ask to extract the right information. The questions come from the perspective of the designer, so assumptions and bias get in the way from uncovering vital information. Since the interviewer controls the flow of information and the the interviewee is passive, the whole interview might go in the wrong direction. Second the interviewee may not be clear or complete in their answers most of the time. This is because they will not be able to recall every procedure or every concern they have. They will only be able to answer with summaries, abstractions, and conceptual thoughts and ideas. This will be no way to get the details. This model is helpful though in the beginning to get some initial thoughts and structure for the day and a good way to back out from the details to gain focus into real design issues. The Expert/Novice approach is also not good for some of the same reasons that the interview/interviewee model was not good; that the approach and direction of the design process would be biased and based on assumptions from the designer. Although it is good and polite to consider the space of the customer, being too shy and modest will disable you from getting close and paying attention to detail that may assist in gathering vital information.
Perry Lee 06:12, 10 September 2008 (UTC)
Although I agree that the concepts and ideas discussed in this chapter may appear to be more conceptual than practical, I certainly believe they can be applied in the real world.
While reading Beyer & Holtzblatt's Contextual Design., I was reminded of a software company practice I once heard about. At this company, engineers were periodically sent to the company's call center to resolve customers' problems. After handling a number of calls, engineers were able to better understand the problems that customers have, and with this knowledge, directly address the customers' problems and make substantial improvements to the product. Hearing a problem directly from a customer and being able to communicate with him/her is much more effective than reading a third-party account of a problem (e.g., in a bug report).
Jonathan Fong 06:23, 10 September 2008 (UTC)
The framework that Beyer and Holtzblatt give in this chapter on contextual inquiry is very insightful about human psychology. Task analysis through contextual inquiry is a very non-intuitive way for information gathering, at least in the engineering-type minds that dominate software design. The most efficient way I would have thought to "find out" about a user's approach and opinions is to simply ask, but Beyer and Holtzblatt point out the fallacies of assuming an interviewer-interviewee relationship. One particular fallacy that struck me was that the interviewer will likely "abstract" the answers, and thus, never understand the real experience of the user, causing the product design to be weak. Additionally, I am throughly convinced by their arguments for observing the user in the correct context (much like an anthropologiest); equally important is forming the "partnership" to get buy-in from the user so that he/she knows that the observer has his/her best interests in mind. These concepts sound like what one would learn in a management or organizational behavior class, and I am very glad that as an engineer, we can put such insight to good use to accomplish our goals too.
As Beyer and Holtzblatt already noted, the master-apprentice model is the strongest, but the observer must remember he/she is not a true apprentice. I can foresee that this would be a problem for me; the opportunity to learn about different processes would make me lose focus. (which is probably precisely why there is a big section/emphasis on "focus"! in this reading). Likewise, as a novice in the "expert-novice" model is dangerous. In a way, the observee is an "expert" with valuable knowledge. As long as egos stay "in check", though, I think the user would be more willing to share if given such respect, and the observer should remember that the user is making some sacrifices in participating in the task analysis process.
Jordan Berk 06:35, 10 September 2008 (UTC)
The interview method that is described by Beyer and Holtzblatt results in a lot of interruption of the user's natural flow of work, in my opinion. It seems to be an alternate approach that may rectify this problem is to use a carefully placed video camera (or multiple ones), as mentioned in class, to record the users actions uniterrupted. Meanwhile, the user would still follow their current actions and thoughts outloud. Following the session, the user and designer could go through the tape, and it would be at this point that the designer would ask the pertinent questions, just like they would as described in the text. This way, the user behaves as he/she normally would, and the interviewer still gets to get the same information (or more, through the video evidence).
Vedran Pogacnik 06:58, 10 September 2008 (UTC)
The readings clearly describe the pitfalls in each master-apprentice models. The problem with the explanations themselves is that, although they seem straightforward, I don’t think it can easily be implemented in real life. As one of the sections describes, it is not rare that the master and apprentice switch roles on a particular subject. It seems quite unrealistic that a conversation between two people will follow the interview models, as they are described. As I mentioned before, the lines are often blurred at best, while there are many examples, particularly in a classroom, where there is no master-apprentice relationship. Consider students in the same class. Two students have taken the same classes, and have had similar grades in them. Both of them can talk about the classes without any one of them having a subordinate relationship. The reason why that is possible is that talk doesn’t have the same nature as puzzles- once you solve it, you don’t come back to it. In my eyes, relationship models fail to account for the old-fashioned “exchange of opinions,” which I still consider an inquiry.
MuQing Jing 06:59, 10 September 2008 (UTC)
In an ideal world, it seems like the Master/Apprentice model is the most effective and efficient strategy in regards to creating good designs. However, I feel that once resources and logistics are taken into account, that particular model seems best suited for the initial design phase; later iterations and future support and debugging require a different set of interview models. This is because in the latter stages of the design process, more emphasis should be placed on user feedback directed towards the application and design, rather than be placed onto observation of typical tasks of the "master". In this sense, the interviewer/interviewee method is stronger because you can direct your questions and the conversation flow towards exactly what you want; in other words, it's terrible for making broad design decisions, but essential for making decisions about specific aspects of a particular design. For example, once the initial design direction has been established and a few beta versions of the application has been released, the interviewer/interviewee model is incredibly useful because you would be able to not only garner direct feedback from the user, but you would also be able to direct them to try out other aspects and gauge their response. With a master/apprentice model, you would be limited to merely observing, and not necessarily being able to focus the observations on what you want the users to test specifically.
Jeffrey Rosen 07:13, 10 September 2008 (UTC)
I definitely agree with this practice of observing someone's workflow and designing an application around it. End users tend not to know what they want. If you ask them for design ideas, they may give you something that will optimize their routine in a minor way, but they will probably not think outside of the box and see the real ways to improve their workflow. By observing them, you can see exactly what they are doing and as an outside observer, you can redesign their workflow in ways that the user would not even realize. For example, a "master" might handwrite an address on hundreds of letters and tell you "it would be great if I had printed labels that I could stick to the envelopes instead." As an outside observer, you could think, well, what if you printed the addresses on the envelopes directly? Or, what if you could email them automatically instead of even sending a letter?
KevinFriedheim 07:43, 10 September 2008 (UTC)
Beyer & Holtzblatt do an exellent job of arguing for the master/apprentice model for contextual inquery but they don't seem to side with any other model; only destory their initial model of the master/apprentice, and slowly rebuild it with the idea of eventually forming a sort of partnership with the customer.
Other models that B&H describe are the interviewer/interviewee, the expert/novice, and finally the guest/host model. The major fault with the first is obvious and B&H goes on to explain that to ask too many questions like one would in an interivew, the customer is 1) not working while talking and describing his actions, and 2) he, the customer, is not responding except to answer the questions and nothing more. Thats not to say that some question/answer sessions are not appropriate and counter-productive. I do feel that the three beforementioned models do have some value and should not be entirely ruled out, but if there was one model that should be folloed without question, it would undoubtedly be the master/apprentice model and B&H suggests.
Geoffrey Lee 08:06, 10 September 2008 (UTC)
The master/apprentice model is clearly superior given enough time and resources to go through its routine, and the obvious limitation is that it requires tedious one-on-one interaction. And because the designer's time is a very limited resource, it's difficult to scale this type of approach. On the other hand, the interviewer/interviewee approach often leaves a lot of gaping holes in the data, but it is easy to send out a survey to thousands of participants at once. This benefit can result in data that is less biased towards a single individual. I believe that both of these approaches should be utilized because the master/apprentice model gives you a lot of detailed data, while the interviewer/interviewee model elicits the thoughts of all your customers.
B&H also mention the expert/novice and guest/host models. The expert/novice model doesn't actually get any work done because the time is spent with the designer teaching the customer rather than learning about the customer's problems. And the guest/host model prevents the designer from asking important questions. Neither of these have any advantages in respect to user experience research.
Billy Grissom 08:37, 10 September 2008 (UTC)
I agree with the general idea of this article. It is probably more beneficial in the end to understand the way one works and then build something more relative to the way they do things. The master and apprentice approach may seem a bit odd but I do think that it can prove quite useful in the end. I mean it's better to create something that makes it easier for the customer to adjust too rather than throw them into an environment that is completely different form their everyday norm. I guess what this model really relies on is that everyone kind of has their own way of doing things, and when dealing with customers it's best to understand how they do things in order to make them something that gives them the best experience.
Although I do think the master apprentice relationship is a good idea I do feel like this article dragged on about it far too long. Some of the questions and dialogues between the customer and developer seemed extremely repetitive and unnecessary. I guess that right there is one of the flaws with the master apprentice relationship - you can try to systematize it but in the end I guess you just can't. The whole idea revolves around adjusting to someone's normal way of operating. That being said it's hard to come up with a systematic way to really approach doing that. I guess the best thing you can do is ask questions and simply keep an open mind. I think the book could've summed that up in a much more concise way rather than throwing a bunch of no-brainer examples. But perhaps that is just me.
Stuart Bottom 08:38, 10 September 2008 (UTC)
I like the point made in this text that the interviewer needs to keep a sense of humility while listening to the customer – the interviewer’s job is to document and observe and understand, but not critique. This is a pitfall of the expert/novice model: the designer is not there to redo the customer’s work processes yet. They cannot design an improved solution that incorporates the customer’s existing skills and abilities until they understand them, and that requires a very open-minded and non-judgmental outlook.
On the other hand, the guest/host model promotes this idea of the polite interviewer well (but perhaps too well, if the interviewer feels unable to ask any meaningful questions). The key is to strike a balance, by respecting the customer’s culture and yet still asking pointed questions to document effectively. This final point is a danger of the master/apprentice model: the interviewer cannot be so polite as to feel like a ‘lowly apprentice’ and be unable to ask any questions at all; perhaps a better term would be ‘empowered apprentice.’
Jimmy Nguyen 08:53, 10 September 2008 (UTC)
I agree with the "master apprentice" model, as it can be very indicative of what problems your design structure may consist of. From the user's perspective, they have no idea what the program's logic may consist of, so it would be best to center the design around their logic while steadily guiding them throughout the process. The interview/interviewee model wouldn't be as efficient because if there are severe holes in the design, but, on the other hand, would be more efficient at times in thinking "outside the box", since sometimes guidance from the "master apprentice" model can influence a person's thought. Why not do as many as possible?
Karen Tran 09:38, 10 September 2008 (UTC)
I think that this article is certainly very insightful and observant. The problems identified in this article are things that come up so often in our lives that we don’t pay attention to them anymore. All the relationship models that the article advises to avoid present valid pitfalls/disadvantages that we tend to fall into. I think the interviewer/interviewee and the host/guest relationship models address the same issue. They raise a valid point that the whole conversation with the customer might very much likely turned into a form of “questionnaire to be filled out.” The conversation might start out with really awkward question-answer-silence cycle that the interviewer/interviewee model suggests. As a result, this prompts the designer to be too considerate and to try to make the customer as comfortable as possible. Therefore the designer usually eases the customer into the process with small talks, which he feels trapped in later on because he is too ‘nice’ to change the topic to work. The expert/novice model also presents some valid disadvantages. In order to be ‘considerate’, the designer feels obligated to provide help to the customer when they are stuck. Yet what they are not realizing is that they are experts of the product, so what might seem obvious and easy to them might not be so for customers. They should also remember the fact that their main purpose is to get feedback, not to give an well-presented guideline. But it is also important not to stand back too much because if the customer is really stuck, then both the designer and the customer end up wasting time because they both expect something from each other. This might end up driving the customer away and benefiting no feedback to the designer.
Cynthia T. Hsu 09:49, 10 September 2008 (UTC)
While I definitely agree with the validity of the master vs. apprentice model (it's so much easier to come up with suggestions and alternatives when you are trying to figure out a reason for all procedures instead of receiving a sugar-coated abstraction of why a traditional method works in class), I also agree with many of the previous posters who questioned the practicality of such an approach.
One thing that confused me in particular in this article was the analogy that Beyer and Holtzblatt present on page 44 - "For example, a basic pattern in coding is work on the code, test it, and see the results. Identifying bugs to fix leads back to working to the code. But this pattern holds true not only for code, but for creating analysis and design models and automated tests as well." This led me reflect how closely the iterative design process that we've discussed models basic coding practices - produce then test, produce then test a successively finalized product. However, they later say (pg. 54), "But iterating an existing design can only make small modifications to its structure. That initial structure - the first prototype - was driven by wheatever way of thinking about the work that the designer had when she started." I am skeptical about their claim that their master/apprentice approach will result in "opening the possibility of radical changes in system purpose and structure." It seems more likely that by observing the master in an existing system, the apprentice will learn more about the "craft" - how the particular customer navigates the traditional techniques and tools available to him in his occupation. This feels like a much more like part of the iterative process to me than an initial design starting point.
In particular, many of the problems that we addressed in our serious games proposals were fairly abstract - how to improve memorization, how to motivate an interest in learning math, etc. It's difficult to observe these problems in their context, as they extend over a long period of time and require a lot of reflection that is separated from the experience itself. An elementary school student who struggles with math will not be able to verbalize until he or she is much older what it is about math that bothers him or her. With memorizing vocabulary - there are so many different approaches and many of them are grounded in a long term process, so it is difficult to observe it over time, and also, the underlying principles and approaches are so basic that they genuinely require a novel situation In these instances, I feel like the interviewer/interviewee format might be beneficial for the initial process - this will be a better forum in which the designer might be able to hear the creator's general ideas, and ask about confusing points in the past as desribed in the abstract vs. concrete data (which illustrated that concrete data can be obtained in an interviewer/interviewee setting if done tactuflly). The master/apprentice approach might then be moved to the instance in which a paper prototype has been drafted.
Frank Yang 09:51, 10 September 2008 (UTC)
I was surprised at first when I read that the "master apprentice" model is not commonly used anymore. It seemed like a logical method of learning how the customer works. It is much easier for the customer to simply perform the task than explain the task. And, with such a method, the "apprentice" has a chance to apply his own ideas for improvement while hearing direct input from the customer. However, after thinking about it, it quickly became apparent just how time-consuming such a process was. It would involve a person shadowing the customer at all times and constantly inquiring about each move they do. It would be time consuming for both parties. Other methods, such as the interviewer/interviewee process, seem to be more time efficient, but it also requires the interviewer to be very nosy and the interviewee to be under pressure to attempt to accurately describe his actions. A verbal description will never be any more descriptive than watching the action itself, and will provide far less insight for the designer to work off of.
Hao Luo 10:19, 10 September 2008 (UTC)
Some other models the reading talked about included interviewer/interviewee and expert/novice. The interview/interviewee model is not as effective because there is too much focus on questions and answers and not enough focus on the work itself. Also, the interviewee is more likely to summarize and give abstract answers. The advantage to this, however, is that you can get exactly the information you wanted, whereas if you simply observe, the user might not have touched upon certain areas. The other model, expert/novice, is also not as effective because you are forcing your perspective as the expert on the user instead of exploring what the user is doing. The advantage to this model is that you can help the user out when he gets stuck and as you teach the user what to do, get feedback on how quickly/effectively he learns the system with some simple guidance.
Witton Chou 10:50, 10 September 2008 (UTC)
User feedback is one of the most important parts of designing an interface. It is, after all, a human and computer interaction, so the product would not be great if it didn't suit the user. I do think studying every reaction a user makes is very important. Examining the user's tendencies in context with his interaction with the interface will provide more insight than just asking users for feedback as a reflection. And a combination of examining the user first hand as well as interviewing the user, albeit not too intrusive and painstakingly long, can potentially yield some great feedback as to how to improve an interface design.
Jacekmw 12:21, 10 September 2008 (UTC)
The interesting approach this article takes to user interface design is evident in its advocation of a very in-close interview with the intended customer base to see how the software is used in the customer's daily life, how any issues come up, and finally, how the customer resolves them. We see that while a regular interview won't net much UI information due to the human tendency to summarize experiences and generalize, a day following the user in an apprentice role allows us to see the good and bad sides of a user interface, from the perspective of the people that will be using it. It's surprising that this master-apprentice method is not used more often, though perhaps a mix of methods including this would be better sinmply for the variety of data that this might not present.
Paul Im 13:17, 10 September 2008 (UTC)
The interviewer/interviewee model can end up with no ongoing work. Rather than a conversation that the master guides the apprentice through, the apprentice simply asks the master question after question. The focus is off of the master’s work. In the expert/novice model, the design expert needs to realize that he is working for the novice. If the novice feels as though he should have no input into the design, he will have a more difficult time telling the expert about the aspects of his job. The novice could end up feeling as though he doesn’t need to explain everything to the expert. The guest/host model could make the designer feel too welcomed and too comfortable. These comfortable feelings could cause the designer to feel too complacent and unwilling to get onto the real work. Although this process could help in building the relationship for a partnership, the atmosphere should remain professional.
Kevin Lam 14:32, 10 September 2008 (UTC)
One of the major benefits of the Interviewer/Interviewee model is that the interviewer is able to address the problem at hand in a direct manner. The interviewer doesn't have to make assumptions and can get straight to the customer pain(s). However, by not observing the process the interviewer misses out on potential problems that the project/software/solution can address but aren't seen by the customer. This is caused first and foremost by the fact that the Interviewer/Interviewee model is missing the observation piece offered by the Master/Apprentice model.
The issue with the Expert/Novice approach is that the designer is focused on "teaching" the customer rather than hearing about the customer's actual pains. There is, however, some benefit to this in that if the Expert has extensive experience or knowledge about the subject matter (from having implemented the same solution before or come across the same problem on a previous case), the Expert can provide valuable feedback for the customer.
Given that no two situations or problems are exactly the same, it would seem better for an interviewer to have a toolbox of interview techniques to choose from. Having various techniques at hand allows the interviewer to more easily adapt to the customer's work ethic. If the problem is difficult to describe, perhaps the Master/Apprentice approach will work better than the Interviewer/Interviewee model. Alternatively, if the interview comes across a problem that is pretty standard for most customers, then the Expert/Novice model may work best. All in all, how a designer approaches an interview largely depends on a combination of the context of the problem and the customer's personality. Stuart Bottom touched on a very good point in that it is important to strike a balance between the different interviewing styles.
Shyam Vijayakumar 16:16, 10 September 2008 (UTC)
The reading says to avoid asking a list of questions, which is a sign of an interviewer/interviewee relationship. I completely agree with this, however, I think it would be useful to go into the session with the customer with a list of questions that need to be answered before it is over. It won't be productive to ask these questions one by one, but it might be useful to ask one of those questions as the correct context arises when the customer is doing the work. At the end of whatever is customer is working on, if any of these questions are not answered, then the designer should definitely bring it up again within the context of the work the customer has just done. Thus, this variant of the interviewer/interviewee relationship might have the advantage of incorporating double-checking into the session with the customer.
Mike Kendall 16:27, 10 September 2008 (UTC)
The article talks about why Guest/Host, Interviewer/Interviewee and Expert/Novice aren't the same as Master/Apprentice, but doesn't really say why they fail. I guess that's the point of this writing assignment.
Ironically, Guest/Host sounds close to a real Master/Apprentice relationship, since the Apprentice is supposed to be unobtrusive while they are observing. This isn't optimal because as an (actual) interviewer, there isn't time to just watch as your customer goes through their routine 15 times before you can really understand it. It's more efficient for everyone involved to give the "Guest" more leeway and let them ask questions when appropriate. It is also a problem if the customer starts acting like a host. That problem stems from the Host's responsibilities to make their Guest happy and comfortable, when the customer is supposed to be helping the development of an application, whether or not my coffee is just the way I like it.
The Interviewer/Interviewee paradigm is flawed for the reasons stated in the chapter.. It's just question and answer. There IS a place for question and answer as a part of the Master/Apprentice interview style, as a way to get further details out of the customer, so this paradigm isn't totally junk.
Lastly, there is the Expert/Novice paradigm. The person in control should be the customer. If the customer feels like they are helping you, rather than that you are learning from them by observation, then they will (again) be going out of their way to please you rather than going through their normal routine. I don't really see an advantage to Expert/Novice, right off the bat. Even though you are the expert, it is your job to take in and filter all information relevant to your project, rather than saying "I'm the expert, give me what you think is important to my project."
Yuta Morimoto 16:46, 10 September 2008 (UTC)
How to summarize the customer's behavior is not easy. I think almost all work should be devoted to obtain a understanding of customer's behavior when we want to analyze some task. Beyer & Holtzblatt give many examples about how to proceed a interview or gather information in the procees of user analysis. At the beginning of interview, the concept of "master and apprentice" is seemingly useful, since we almost do not know how customer is acting. Later, we had better interview them about their behavior which is not clear with the method of master and apprentice model.
Antony Setiawan 17:07, 10 September 2008 (UTC)
Principles of Contextual Inquiry explains how the master/apprentice relationship is being used to gather information. In my opininon , although that relationship is hard to be done ideally in the real world, the concept itself is very good and efficient. The other model, interviewer/intervieweee, absolutely doesn't work for me in particular in addition to the limitation of information that can be obtained from it. The interviewer ask a question, get answererd, then silent, and so on. That's clearly not a best practice in gathering information. Expert/novice relationship as it is discussed, makes the "customer so stuck that he will not be able to do any more of the work you came to see." Guest/host relationship might be effective once the relationship has developed into mutual yet intimate relationship.
Xuexin Zhang 17:18, 10 September 2008 (UTC)
The main challenge of Interface design is to find out what the user truly wants. The disadvantage of the interviewer/interviewee relationship model is that it’s very likely to miss some key features of the system since the interviewer didn’t cover those during the interview. However, the interviewer/interviewee model could be very helpful after the prototyping, since the user could provide direct feedback of what they think of the interface.
JoshuaKwan 17:25, 10 September 2008 (UTC)
It turns out that the master apprentice model is extremely useful in CS and I've noticed this during my work at VMware. While teaching a friend how to do something as he watches, I start to mention steps that I wouldn't have thought to mention if I were teaching him from a whiteboard. The same can hold for user interfaces, because a lot of the way we interact with them happens on a very subconscious level. For example, don't many of you sometimes open terminals and just type 'ls' out of habit? That's one example of a UI "nervous tic" that many people have.
The 4 Principles make sure that when you are interviewing using this master apprentice model, you're actually getting the right feedback. I especially identified with the abstract vs. concrete data element. When I'm helping my parents with computers, they say:
Dad: "[our wireless access point SSID] is broken." Me: "so.. does the internet still work? they are running off the same device." Dad: "well, i can't get onto wireless with my mac!" Me: "dad. does the internet work on your [ethernet-connected] PC?" Dad: "I haven't tried! ... Oh, yes. it works."
This reading reminded me of this conversation with my dad that I had recently.
The readings suggest other models that are inadvisable simply because they won't allow the target user (interviewee) to use the program as if you weren't there. That's the key point of doing these interviews. What will they do when you're not advising them every step of the way?
Kai Lin Huang 17:39, 10 September 2008 (UTC)
Other interview models that I have experience in are focus groups and questionnaires. The disadvantage of a focus group is that interviewees are only answering the questions according to their memories or what they believe. This can be inaccurate because interviewees may not be detail enough in answering the questions, and their belief of what they usually do may deceive them. They may actually end up with doing something different from what they tell the interviewers. The advantage of this is the interviewers can get immediate feedback of the questions, and they can also ask detail questions to see whether the interviewees say different things when they answer the same question in different context.
The disadvantage of questionnaires is that interviewees may think for a while and answer something that’s well thought. For behavioral questions, interviewees may not do the same as what they answer in the questionnaires because they have already gone through the mental process before answering the questions. These can be the “right” answers to the questions, but sometimes not as helpful because interviewees can falsely convince themselves that they usually do something in some certain correct ways instead of others.
Mikeboulos 17:51, 10 September 2008 (UTC)
The 4 principles discussed in this chapter helped me understand the roles in the interview, but I think it is harder than it sounds, for example partnership as discussed is hard to establish if the interviewee is very tight, scared to share their work because someone is over their head watching, or they might not do the tricks they do at work so that their boss won't know that they do the work in 5 minutes while billing them fro 5 hours. on the other hand, once the apprentice model is established it is very efficient to find almost everything that is needed for the design, since a step by step will be explained in informal professional manner. one thing that struck me while reading this chapter is that they encourage the interviewer to let the interviewee talk about themselves, this might bring the friendly feeling environment, but it might have bad side effects, some people know when to stop and some people don't, so this might keep going through out the whole interview, and if interrupted might be a turn off, since after all the interviewer triggered this conversation. also making the interviewee to work as if no one is there will be very hard, because of many distractions: 1) Camera if recording 2) near by person (affecting performance) 3) talking while working might affect the sequence of events due to confusion
on the other hand after all of this has been ignored or becomes a background, I think this model will work efficiently. One last thing about feedback, most customers will not like to be asked again after the interview (meaning like a month after ) about the same thing. so when they say "you better get it right" is right.
Bing Wang 18:13, 10 September 2008 (UTC)
The master and apprentice relationship discussed in the reading an interesting analogy as to how designers should learn from consumers. In today's world, that does seem to be true, customer feedback seems really important for a user interface or else they would just not use it. The difference between a good and bad design sometimes differentiates the successes and failures of programs, interfaces and entities. Even though the designers are the experts in their area, but in the sense of the user, they are the apprentice because if no one likes to use the program, it doesn't matter how good the program or the interface is to the expert. Sometimes experts tend to design systems and interfaces that are too complicated yet the users hope for simplicity. I also liked the point regarding receiving surprises and contradictions from users. Many times, designers think that they are the experts and would not yield to criticisms and ultimately designs a system or interface that does not generate enough appeal.
James Yeh 18:55, 10 September 2008 (UTC)
The approach described in the reading is very elaborate, yet seems to be a little rigid in its outlining of the contextual inquiry process. In particular, there are two facets of the author’s perspective that I found made the process less realistic and practical. For one, the contextual interview structure detailed in the reading appears to run under the assumption that the interviewee will remain comfortable and at ease with an interview staring over her shoulder. In reality, while the interviewee is being bombarded by questions from an interview who is supposed to be ‘nosy’, it will be very hard for her to act like she would in a normal work setting. Another point of the reading that I found a little too rigidly defined was the master/apprentice model. More specifically, as others have mentioned, the relationship can be ambiguous and/or change, as both sides will be learning from each other in a typical real-world setting. Asking questions is certainly useful, but the examples described by the author do not seem to apply to every situation in the workplace.
Volodymyr Kalish 20:35, 10 September 2008 (UTC)
I've never imagined that the process of interview can be done in so many different ways. Designers really need to be psychologists (in a way) in order to really understand consumers and how to get out of different situation while still remaining in their act. Also, a great idea that I took from this reading is that there are no stupid or pointless things done by people, since if think something is stupid and pointless - means that we don't see it from the same point of view. And that is exactly what designers must know how to do, to be able to look at anything from anyones point of view. There is another thing that the reading didn't address and that I think is important. Whenever such an interview between a designer and a customer takes place and customer shows how he/she does the work, it inevitably changes the way this work will be done in the future. It is so because many people seek self-improvement and they don't usually see ways they can improve their performance until they explain the process, think about it, show it, and just blindly, monotonously and automatically do their everyday routine - their job.
SaliemThan 10:27, 17 September 2008 (UTC)
Two advantages of the apprentice model: Avoids limiting abstractions generated by the other partner/interviewee/apprentor. Helps to dispel any presuppositions about the expectations of the results.
Interviewer/Interviewee The interviewer has a list of questions that can have subtle presuppositions built in. The interviewee falls into a role where he/she answers as he/she supposes he/she is suppose to answer Even if the questions are carefully put together, and the interviewee takes part without any role expectations, there is still the problem of the interviewee/interviewer might begin making abstractions of things, in essence, conclusions,and you will not have any actual data to back up such conclusions. One possible advantage of settling into this role, might be as a review, some time after a more natural {apprentice} situation was undertaken. After assessments can then be taken to account, and conclusions and abstractions can be made without any interference with the collection of data {carrying out the tasks at hand in a "natural environment"}
Expert/Novice One of the advantages to taking up this situation, as the article mentioned, is to carry out and maintain the data collection. The participant/partner might be at a loss as to what to do, or how to continue, and at that point, it might be wise to offer an avenue to continue data collection/learning The disadvantage is that no data collection will occur because the entire situation will be reversed and so that the partner/interviewee would be collecting the data, and not the interviewer.
Guest/Host Big disadvantage. No surprises, no chances of anything interesting being uncovered in the process of data collection/observations/learning. Having a formal role of a guest creates this restriction. One possible advantage to taking up this sort of situation might be a case where the study was oriented towards the study of guest/host interactions.
