ethnography is everywhere

Man on Tube with Time Out

Customer research too expensive? Unless you’re working for an university with stringent ethical requirements to meet – you’re making your job too hard. Ethnography* is everywhere.

Last night, after Girly Geeks, I was on the tube on the way home and beside me sat a man performing a task that I *wish* I could have designed for user testing… except I would never have thought of it. Oh, and I don’t have budget.

I watched him a while. Then I asked him if I could take a photo of what he was doing, and explained why I was interested.

Unfortunately we got to Oxford Circus and I had to get off the tube, otherwise I would probably still be in conversation with this guy about why he sits on the tube at 10.30pm on Tuesday evening circling TV listings in TimeOut.

Once he started talking, he had a big story to tell and a rationale for why he was doing this. Of course, it was all premised on the idea that he was ‘killing time’, but then he got into detailed explanations about the way that his personal video recorder worked and how many programs he could record or watch at the same time, and how he treated programs that he knew he like, to those he was still testing out, to those that were ‘experimental’ (his words).

Research is brilliant at helping us work out what the design problems are and how we might try to solve them. But not all projects have the budget or resources for a formal user research phase. Don’t let that put you off.

Ask the people you work with. Ask the people you live with. Ask people you know to ask people they know. Try to get some of their time and ask them some questions. You’ll be amazed how many are willing to help out for free.

People care about design – even if they don’t know it. And they love to be involved and to make a difference. And they have lots of stories to tell and they love that you’re interested in hearing them, and that you think those stories are important.

And, of course, they are important. And they’re everywhere.

Ethnography is everywhere. If you’re looking for it.

Image: man marking Time Out TV schedule on the Central Line tube last night. Larger image here.

*note: I use the term ‘ethnography’ in that kind of loose way that lots of us in HCI use it. Apologies to *real* ethnographers :)

customer experience: the bad, and the worse


Unfortunately, very average customer experiences are not hard to come across… even from brands that you really want to like… It’s a shame, because sometimes the smallest things can make all the difference. Like… if you’re giving people an automated, machine driven service, then maybe play on what’s good about it – the speed, possibly the accuracy? And compensate for the downside – the lack of personal service. And if humans are providing the service, then *behave* like a human being who is interactive with another human being.

I’m not just an email address you know. I’m a person. And I’m suitably frustrated, concerned, upset by something about your company to be contacting you. I don’t complain much. Perhaps you might take a moment to think about what kind of emotions I might be experiencing and ensure that your response is appropriate to those emotions…. otherwise I might get to thinking you don’t care. If you’ve done something kind of dodgy, then maybe – oh, I don’t know – apologise?!

Good customer experience is very rarely rocket science. It’s usually just a matter of giving a damn and being a little bit thoughtful.

OK, so this is a venting and sharing post. But hopefully it’s instructional and interesting. You be the judge. Or, better still, feel free to vent and share similarly dodgy experiences.

Let’s look at two recent experiences… which will we start with. Bad or Worse?

Continue reading

Attack of the killer Assumptions (and how to overcome them)

assume the position

Assumptions are something we battle in kinds of ways. I know when I was doing more project management, trying to get a handle on project assumptions and documenting them was a necessary challenge. Understanding and documenting assumptions was critical to managing my client’s expectations, and making sure that it was actually possible for me to deliver a project on time and on budget.

These days, I’m more likely to make assumptions about the way that people will understand an interface and what they’ll find easy to use. Even though I continually try to train myself NOT to bring assumptions to the table when I’m designing or testing designs – or at least, to position my assumptions more as hypotheses than as a personal truth.

I often learn as much about my own inbuilt assumptions as I do about how people interact with particular interfaces… even now when we are all conscious of the new challenges created by different kinds of novel interface element, it’s a constant challenge to keep assumptions under control (which is – in my opinion – to make them conscious assumptions).

I’ve been thinking about this subject for a few years now and have asked lots of people along the way about their experiences so it was reassuring to see Kathy Sierra sum up my quandary so succinctly in her recent post on Assumptions (and their use by dates):

The really big problem is the assumptions which are so ingrained that we don’t even know they’re assumptions. They become an accepted Law of Physics, as good as gravity.

For me, assumptions are something that you usually become aware of after they’ve bitten you in the butt. Once they’re known, conscious and documented they’re not so scary… in fact, they’re not scary at all.

It’s kind of like being afraid of the dark… when you can’t see what’s under the bed, you imagine all kinds of hideous things. Once the light is on, you wonder how on earth you let your imagination run away with you so crazily.

Kathy is right – once you’ve recognised your assumptions, you can’t just leave them sitting there. You need to pull them out and re-examine them every now and then and make sure that they’re still as they should be, or update them if you need to. (Or, potentially throw them away as irrelevant).

But here’s my question – what do *you* do to try to expose these really dangerous assumptions? The ones you don’t even know that you have? How do you bring them to light and make them known and not dangerous?

Come on. Help me take out some of these killer assumptions.


Image Credit: Kayaness @ Flickr

when to use drag & drop (some informal research results)

One of the great challenges of Interaction Design these days is that we now have a plethora of new ways to design interaction on the web than we did just a few short years ago. Drag and drop is probably one of the best – creating a sense of empowerment over the interface that can sometimes result in an almost joyful user experience.

Despite the fact that we’ve been designing with drag and drop for a while now, it’s taken this long for me to have the opportunity to do some good solid user testing with users comparing drag and drop with more traditional interaction styles. That is … clicking :)

In the test that were we performing we were (amongst other things) examining the use of drag and drop and clicking to perform two types of tasks: to select objects and place them onto a stage, and to manipulate objects on a stage.

One interface used drag and drop for both tasks. One interface used click to select and drag and drop to manipulate.

When users were interacting with the prototype that used drag and drop for both functions it was common for them to make unsolicited comments about the interface – generally expressions of delight at the responsiveness of the interface and the novelty of the interaction method. Of course, drag and drop is not really so novel – many users are accustomed to this method, and we found that no users (of the 15 we tested) were unfamiliar with the drag and drop method or had any difficulties understanding how they were expected to achieve their task using drag and drop. (The interface did include a small instruction to drag and drop onto the stage).

Some of the tasks, such as removing objects from the stage and understanding how many objects could be dragged onto the stage were not immediately obvious, but through brief experimentation the users were rapidly able to achieve these tasks and exhibited no difficulty. In fact, in many cases they were saying ‘I wonder if I drag this back here will it delete the object’, as they performed the task and were pleased to discover that it worked exactly as they had expected it might.

When users were interacting with the ‘click to select’ interface, there were no such expressions of delight with the interaction, however they also had no difficulty achieving all of the tasks involved in the test.

Later, we asked the users to compare the two interaction experiences and talk about which they preferred and why. Without exception, we found that our test participants preferred the click to select interface over the drag and drop interface – despite the feedback they had given at the time of testing.

They agreed that drag and drop felt ‘fun’, and ‘creative’, but overwhelmingly stated that it was unnecessarily complicated, and that it was just as easy, or easier, to click. ‘Dragging was a drag’ was one of my favourite quotes. :)

On the other hand, users unanimously agreed that drag and drop was an ideal way to manipulate objects in relation to each other (particularly, to change the position of objects in relation to one another).

Based on the results of this testing, the logical findings seem to be that drag and drop is ideal for manipulating the position of objects on a stage, but that when ‘selecting’ objects, simply using click to select is preferable. Even considering that we may be wishing to create an interface that is fun and creative (which was why the full drag and drop approach was originally considered), the inefficiency of this method detracts from the user performing their task. Selecting the objects was considered a preliminary task, and the ‘fun’ part started when users got to manipulating the content.

When thinking of the best examples of drag and drop interfaces (and I think that moving around maps is a great example of this), it is once again the manipulation of objects on a stage and not object selection, that seems to be common.

Of course, it is also important to note that choosing a drag and drop interface also significantly compromises your ability to deliver an accessible interface. This should always be an important consideration when selecting an interaction method.

Designing a drag and drop interface? You could do much worse than refer to the Yahoo! Design Pattern Library where they’ve spent a lot of time thinking about all of the components of the interaction and what you’ll need to consider.

Have you done any testing with drag and drop interfaces? I’d be really interested to hear what you’ve found.