Interaction

It has been a long time since I’ve done a user interview. Months. I felt so out of touch, and I was desperate to get back into user research.

When I finally succeeded in recruiting a participant a few days ago, I was elated. Okay, so it was someone I met on the London IA Ning group, but nevermind – she had still some experience in a domain I was keen on doing some research in.

I based my interview method roughly on the interview method outlined in Holtblatt’s Rapid Contextual Design book, which I was also reading for this month’s UX book club. Unfortunately, the book describes an interview method that’s suited more for researching existing corporate processes, which didn’t quite fit the work I was doing – understanding a completely new domain for which there wasn’t an existing application for. Thus, I focused the interview strategy on understanding the subject area – shared ownership.

Here’s an outline of the questions I roughly had in my head (I didn’t prepare a script, because I wanted it to be more open and conversational):

• How did you get into car sharing?
• What motivated you to do it?
• Can you explain the process of what’s involved? (activities)
• What tools/devices/media did you use/consume in your tasks and activities?
• Can you tell me the various social aspects about the whole thing, if any?

Actually, this is a pretty bad list of questions. When I was going through the data, I realized that I had missed out some very important questions, like -

• were there any problems you experienced in any way? how? why?
• can you explain to me in detail (about a particular activity)?
• how often did you schedule the use of a car? why?
• asking questions about the user’s technical abilities and expectations
• a storyline of a typical scenario of a common activity
• what did you enjoy most about using the service? why?
• what activity was particularly easy/user-friendly to perform? why?

I could probably go on, but the thing was – I used this interview as an opportunity to fail, because I needed to learn from my failures and reveal my blind spots. Of course, I didn’t try my best to fail – I tried my best to do the interview, but I needed to know how I could improve.

This became more apparent when I went through and talked my colleague through the things I learned during the interview. This is where more than one person in a research process can be extremely useful. One of the key things we looked for were gaps in the research – things we failed to address during the interview or research sessions. This helps planning for subsequent interviews and research.

I learnt in this exercise that interviews in user research isn’t just about learning about users (which is like ethnography). In fact, it’s more about problem solving, except that the user may not even know he or she is experiencing a problem. When problems aren’t obvious, it can seem very hard to convince yourself that there are problems to solve, but problems always exist. There’s always something you can do to make a user’s life better.

boon :: Jan.30.2010 :: research :: No Comments »

My very first attempt at incorporating a user-centered design approach in my software development project was, in many ways – an important start for me, career-wise. It’s because of that project that I am where I am now – I would certainly not have been accepted into the MSc, which subsequently opened a lot of doors for me in the UX industry here in London.

But, despite all that, that project was a failure from a UCD and “business” perspective. Firstly, the interface felt too much like Flickr. Then, our team was fairly novice so our interview data wasn’t very promising. This caused the personas to feel sort of half put together. The end result was somewhat lacklustre – in some ways, we could’ve delivered the same thing by getting inspiration from other websites and not having to use Cooper’s Goal-Directed Design.

However, to stop there would be to completely miss the point.

Introducing UCD – the first round might not count

I insisted on using a UCD process not because I wanted to deliver something spectacular, but because I wanted the team members to see the value of a UCD process. Or, perhaps more accurately, it was mainly just me who was keen on seeing the value of a UCD process (and to see if I could do it).

This is where I think a lot of projects tend to reject UCD – when they can’t see any results.

It’s easy to run a company with an “efficiency” mindset – it’s sort of built into the status quo. Everyone is reluctant to change – not just management. So, I didn’t just have problems with my line manager – I had problems with my team members. (thankfully, my interviewees were really helpful). No one except for myself was really looking to see this succeed.

So, of course – how could I expect it to succeed?

The process reveals not so much results, but opportunities

The effort of building applications is often a team effort – not just one UX person calling the shots. But valuable lessons can still be gleaned from UX failures, much more than they can from plain old technical failures – mainly because that additional perspective from the user is so raw and tangible that it almost creates some kind of “why haven’t we done this earlier” response?

When team members get thrown into a UCD process – they don’t realize the potential “failure” of the outcome, they look at the process and the value of that access to users they finally get – something they never used to have in the past. Suddenly, they realize it is possible to build applications based on user research, user feedback, and purposeful design.

Developers and designers all need to realize that there are many ways to build an application, and sometimes it makes sense to learn a new tool so that the right one can be used for the right job. Introducing UCD to a conventional software team can sometimes help them gain ideas to make things better.

I took those lessons I learnt from the failure with me, because you never unlearn an experience like this. You just get better. And now I realize just how much more UCD is like craft than science.

boon :: Jan.27.2010 :: development, user experience :: No Comments »

Ethnography involves a lot more work than user experience design, because it involves deeper immersion, more personal commitment, a greater willingness to learn from one’s own observational failures, and the ability to work across cultural boundaries.

This is only a small part of what user experience design attempts to accomplish, and depending on how you apply ethnographic methods in UXD, it can add as much value to a design as it can damage it.

Here’s an ethnographer’s take on how usability tests (usually done after or during implementation/prototyping) and focus groups (typically done during the research phase) may not be of *any* benefit to a user if the cultural context has been completely misunderstood.

“While usability tests and focus groups are useful for specific phases of app development, they aren’t as useful for understanding cultural frameworks and practices because by the time an app is being tested, it already has accumulated so many cultural assumptions along the way in the design process that users are asked to test something that functions in the programmer’s world, not the user’s world.”

- Tricia Wang, “My Suggestions for Making Google’s Services More Relevant for Non-Elite Chinese Users“

While working on my MSc dissertation with Abigail Sellen from Microsoft Research’s Socio-Digital Lab and Jennifer Rode, my previous supervisor from UCL, I learnt how quickly and easily it was to misunderstand the work of ethnography and anthropology. These fields have had a much longer history than the field of user experience has, and yet – they’ve become instantly popular because of UX, and its terms can often be misinterpreted and misused.

I don’t claim to be an expert on the ethnography or anthropology, but having read some classic ethnographic literature (e.g. Clifford Geertz), it’s clear that there’s a lot more going on compared to something like Holtzblatt and Beyer’s “Contextual Design”, though both of the authors have fairly strong academic affiliations.

Designers and UX practitioners need to read beyond commercially popular business and design books if they really want to get at the heart of how to understand cultures, humanity, and people. The fields of ethnography and anthropolgy tend to be more academic and research-focused, and there can be complications over viewpoints between different schools of thought in the related fields – thus it takes time to really go through the literature, but that’s the cost you pay in order to re-skill oneself in the art of understanding people.

boon :: Jan.24.2010 :: ethnography, user experience :: No Comments »

I just stumbled across Cennydd’s post about ‘blaming the designer’, which somewhat reflects my work experiences in the past year. I too, found the “design hell” comic to be humorous, and admittedly counted it as gospel truth initially. Then I forgot about it and like all designers/developers, went back and dealt with the hard stuff and worked until our product was finally launched or finished.

Aim for the finish as a team, not for the journey

And so, a few weeks ago on the eve of Christmas last year, we launched our site live. My client, my boss, was happy with the results and our effort to implement tiny changes at the very last minute, and I admit I’m happy with the outcome myself, despite all the ranting and heated arguments about things like how consistency in design isn’t everything and about not adding more ‘unnecessary’ features. It was satisfying to know that my client was happy – that we had produced something that was ready for launch, live. And I think that’s something all designers and developers need to keep in front of their minds, rather than the course at hand.

The opportunities are in our hands

We live in a world that’s increasingly complex, and we appreciate and learn of each other’s strengths in bits and pieces at a time. To this end, I admit my own shortcomings of not being able to bridge the gap between business, marketing, design and engineering more effectively for my client. I now believe that creative freedom comes with caveats, and it is rare that clients will allow designers all the freedom in the world. It is increasingly becoming the designer’s responsibility to seize the opportunity to educate and collaborate with clients to solve problems ‘the design way’, meeting both design and business goals.

I see this as a major opportunity for creative types – designers, content managers, UX consultants, even developers. This is because clients know they are partly ignorant about design and are willing to hear what we have to say. At they same time, they’re not going to back down on what they know best about business, and we need to be sensitive to that.

Putting things to practice

So how would I react this time around?

I think, for a start, my attitude has to be right. I need to stay positive and not try to put down the ideas that come from clients. I should give credit where credit is due, and understand that not every solution is ideal. In fact, some of them are hacks due to various factors like time or lack of knowledge. As iteration is always possible (especially for the web), this isn’t a big problem. Solutions can always be improved, and it’s best to allow some “hacks” to pass, and learn from it through testing and user feedback.

I also feel documentation is key, and putting things down in black and white makes it easy for everyone in the team to see how the design has progressed from day one. Everything that’s documentable is valuable – wireframes, sketches, screenshots, feature requests, reasons for change, points of argument, etc. While I don’t think everything has to be documented, our team did make use extensive use of tools and artifacts to facilitate communication. So, use them wisely.

Finally, the success of the design should be celebrated at the end of a major phase. I somehow feel the best person to do this is the client, but this doesn’t always happen. In some ways, the client’s utmost satisfaction acts as a major milestone in the outcome of a project. In my case, it was my boss’s satisfaction and decision to launch the site live. He brought in a bottle of champagne and we toasted to the launch on Christmas eve, which helped to finalize a major phase in the project and ease fears that we might be carrying on throughout the holidays.

Whatever it is, we all crave to closure to our efforts, some space to regenerate and look forward to our next big task.

boon :: Jan.08.2010 :: design :: No Comments »