- Ethnographic is a descriptive and not prescriptive discipline. An ethnographic study of how people shop in shops will tell you about how people shop in shops,Message 1 of 140 , Jun 11, 2008View SourceEthnographic is a descriptive and not prescriptive discipline. An ethnographic study of how people shop in shops will tell you about how people shop in shops, it will not tell you how people will shop online from home.The context has changed. Ethnographic studies can be used to support and be an inspiration for ideas. But working software that you could test in real people homes would be far more valuable.
To give an example Malinowski (the founder of Ethnography) in his book the Sex Lives of the Savages describes how people collect Yams as sign of wealth. He does not explain why they collect Yams, in particular, instead of for example coconuts, or if they would accept an American GI jacket in exchange of Yams. An Ethnographic study can not be used to predict human behaviour.
I have heard of ethnographic studies been used in an iterative way for the design of air traffic control systems in the uk. This was used because the programmers and the controllers time was valuable, so the Anthologist took the role of the customer. The study was used as way of explaining to the developers the working methods of the ATC.
The study is published somewhere....
JamesOn Tue, Jun 10, 2008 at 11:45 PM, carl myhill <carl@...> wrote:
(having a bit of trouble posting...)2008/6/10 carl myhill <carl.myhill@...>:[Ron Jeffries]I meant that Agile Software Development is about software
development. It begins when the project begins, with software pretty
much that day. If someone wants to spend time dreaming or designing
or such prior to authorizing the software project, that is, in my
opinion, outside Agile.I struggle a bit with this one and it seems quite fundamental. If I wanted to design a new shopping cart I would do what IDEO do, I would go to several supermarkets and watch people using shopping carts and see what real world problems they have. I'd do a bit of ethnography up front to try to drill into people's needs. I would do this, not 'just before the next development meeting' but as a phase of work before the development starts. I'm not talking about 'dreaming' or anything else, I'm talking about talking to people and observing behaviour.I would not take the approach that you seem to be suggesting of just going about developing some new shopping cart in the absence of the ethnographic phase. That would seem to be a very dangerous path. If you just build something and then 'seek validation' it's tricky. Suppose you build a new shopping cart and take it to a focus group and people sit around talking about it and push it backwards and forwards. They'll probably tell you they like it, after all, you are sitting there in the same room all proud of what you've done - what kind of feedback are you really going to get? It seems to me that this is exactly the right way to build a fun toy which does not serve any need - like a Segway. I bet focus groups loved the Segway but how many people have bought them?Is it wrong to have an ethnographic phase up front rather than starting development on day 1?CarlPS There is an excellent ABC News Article available on DVD called The Deep Dive, which shows how IDEO really did approach the redesign of a shopping cart
User Experience Design
- ... I agree totally. Ethnographic user research should aim at understanding the user THROUGH understanding how they work today. The aim is not to justMessage 140 of 140 , Jun 25, 2008View Source
> But I am against research just been done at the before the project starts and then that is it, andI agree totally. Ethnographic user research should aim at understanding the user THROUGH understanding how they work today. The aim is not to just replicate the way they work today.
> totally against design been fixed before the project starts.
> The challenge is that the research is descriptive and not predictive, and is often used in a
> prescriptive manner. I have been involved in some projects where there has been the assumption that
> the consumers behaviour remains fixed.
Here's an example taken from my contextual inquiries with translators.
We noticed that NOT ONE OF THEM used collaboratively built linguistic resources like ProZ, Wiktionary and OmegaWiki. That's not necessarily to say that collaboratively built resources would not be useful to them and that you should not build them. It may be that collaboratively built resources have just not made it into their world right now.
However, the CI observation gives us many useful information about how a collaborative resource should be built to serve the needs of translators. For example, we noticed that translators at least pay a lot of lip service to "trustworthy sources". So you know that with a collaborative resource where pretty much anybody can write content, you are up against a perception of lack of trustworthiness. At the same time, we noticed that when translators can't find a solution in trusted resources (ex: the terminology database of the Gov of Canada), they have no qualms about looking in less trustworthy resources, for example by doing a search on the internet. So, it could be that translators will be willing to use collaborative resources if they have more coverage than "trusted" ones. As the translators use the resource more and more, they will notice that they quality is high, and may get over the lack of trust barrier.
But all of that is of course hypothetical. They are hints that help you narrow down the search space. But a case like this, those hints are particularly important, because a wiki cannot be tested with individuals. It can only be realistically tested with a large community. It's like the WWW. You couldn't test the concept of the WWW without having a network of millions of interlinked pages already (although you could test the concept of a web browser on individuals). So, the only way to realistically test a wiki is to deploy it and see what happens. So the turnaround time for validating your decisions is longer. Hence the importance of having good a-priori data to guide your initial choices. Of course if you deploy something and it doesn't work, you should listen to what the community is telling you through their actual use of the real thing.
> There is research that uses sweeping statements like from Broadbent and Cara's NEW ARCHITECTURES OFI agree that behaviour which is specifically tied to technology can change rapidly, hence the need to conduct this type of research continuously.
> INFORMATION Paris 2002.
> "During the past four years, we have carried out hundreds of observations of people using the Web."
> which leads them to a conclusion that
> Most light users have very stereotypical behaviours: after six months of usage of the Internet they
> stop even trying to do searches through a search engine and consult systematically the same six or
> seven sites.
> Broadbent and Cara's observations tell us about the time before google.
However, CI will also yield information that is pretty much independent of technology. For example, we have noticed that translators do not blindly trust ANY sources (even official ones like Gov of Canada terminology database), and will systematically consult at least two different resources to resolve any given translation difficulty. The only exception to that is when the translator hast the proper translation at the tip of his tongue, and uses lookup in a single resources to remember it. I'm being told that this behaviour was there already when translators used paper dictionaries only.
> My argument is that any new product changes the user behaviour, and therefore you need to get the newYes, you should do that.
> product in front of the user as soon as possible, so that you can feed back the users behaviour back
> into the next iteration.
> Research needs to be carried out before so that you can set up the goals of the project, and theYep.
> stories. It needs to be done during development so that you can feed back the user behaviour back
> into the product, and then after to find out when you need to make the next version.