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’m noticing a trend here regarding user experience people. They’re geeks, no doubt. They enjoy being part of the solution of a system, especially if it leads to something really enjoyable to use. They’re quite intelligent and are fairly multi-talented. They’re also very nice people. I’ve met a lot of UX people in the past year or so and I’ve not met a single person I didn’t think was amicable in some way or other.

Is UX really making a difference?

I have nothing against user experience people. But I’ve been noticing a trend in the user experience industry – that it looks too self-referential (as though to say that “good UX” is demonstrated by “good UX”). There’s rarely talk about how real people’s experiences were tangibly or directly improved because of X user research or Y design solution (the ones out there now aren’t very convincing). And this is the thing that bugs me, and bugs me a lot – the lack of real world stories about how UX is changing the way products are being built and how it’s actually impacting real users.

Maybe it’s because many user experience professionals work mostly on deliverables that don’t themselves represent the final outcome of the product. Wireframes, personas, hi-fi prototypes, site architectures – they’re kind of back-stagey, iterant, and somewhat disposable. In essence, they’re mostly design tools, but they’re not actually the design in and of itself. No doubt they impact the final outcome, because they shape the process in which the products get built – but there’s very little “actual doing” that other professions can speak of, whether it’s advertising, marketing, management, or engineering.

On the other hand, maybe it’s because of the way user experience people can really get reflective, like drawing on inspiring things such as multitouch tablets or surface computers or geeky font artistry. That’s in contrast to something that’s more generative (and often more straightforward), such as producing reports, writing software, closing a sales deal, or editing a draft of a copy.

Process is not the end in and of itself

Increasingly, it seems that the credibility of a UX designer is based on how well that designer understands the process of doing user-centered design, as opposed to how many successful products have come about as a result of that process. This came to me when Darren Smith told me how he noticed that many UX portfolios have a consistent theme of explaining how well these designers understood the process of user-centered design.

Why don’t designers talk more about how their UX work has resulted in the success of a product? I mean, IDEO does it (and does it very well). Even Apple does it (and does it very well). In fact, I feel all great designers do it.

Is UX an escapist’s career?

I almost feel as if UX is a bit like a “cop-out” job. I know it really isn’t, because there are tons of well-meaning UX people who are really passionate about solving the right problems, and they’re taking risks by challenging the status quo for the sake of the users themselves. But the more I think about it – UX designers almost never begin as UX people themselves – many of them were formerly designers, or software developers, or project managers, etc. who were desperate to be in a position to solve the right problems – and left their “old jobs”.

The good news is that UX places the designer directly in a strategic position to make design decisions on behalf of the product implementers, but the trade off is having less control over implementing the actual guts the product. So, while they’re actually doing the important work of navigating the ship, they don’t actually get to man the deck and run the engine (ok, that was a bad metaphor, but you get the idea).

A compromise?

Because we’re such a small community (compared to other professions), we tend to huddle together and give ourselves pats on the back and talk about all the amazing new things the industry is coming up with, even though there are so few major players in the market. I’d actually prefer it if we mingle with senior management and developers and visual designers and marketers and advertisers and… gasp, real users! I feel we’d make a much bigger impact that way.

There seems to be a growing gap between UX and other professions (which can be a good thing), but at some point we’ll need to establish a set of norms or cultures that communicate the way UX designers can integrate with other bodies of the team to produce successful products.

The sooner we begin this process, the better.

boon :: Nov.21.2009 :: user experience :: 1 Comment »

I’ve been expressing fairly skeptical views about user experience in my previous posts, and it’s partly a side-effect of stuff that I’m still sorting through in my own work and beliefs. Having spent many years building software as a developer, I’ve become overly sensitive of how people perceive technology and how it can be manipulated to influence the experiences of its users.

I’ve always said that anything is possible with software. That statement has a lot of caveats, because it’s still hard to make software do exactly we want it to do. And while there are a ton of developers out there coding in virtually every language, it’s still rare to find good ones who truly understand how to write them well.

The point I’m making is this – software is a moving target. Despite all our efforts to strategize, plan, research and design for the user experience, it doesn’t mean anything if it doesn’t take the practicalities of implementation into account.

Good designers know this. They understand that it’s not that easy to come up with crazy AJAX interactions, maintain cross-browser compatibility, and design for accessibility within a short period of time. This is why good designers and developers earn their stripes by credibility, not by qualification.

Thus, user experience designers and software programmers are basically two sides of the same coin. You can’t have one without the other. Even if you aren’t calling yourself a UX designer, when you’re making decisions about how users should or would interact with the software, the tone of voice the content should have, the color palettes for the styleguide – that’s basically the kind of thing UX designers get paid to do.

At least for now, UX is being used unceremoniously as an umbrella term for all that design, strategy, and thinking towards the overall experience that’s intended. This means that almost everyone has a hand into doing the work of UX, because almost everyone has a stake in that experience.

The sad part to all this is – it all seems too much like common sense. And everyone will have an opinion about design. Worse still, anyone who really likes the idea of doing UX can suddenly start acting like experts on the subject, and come up with seemingly insightful quips which may actually be more damaging than the status quo. Actual UX designers have their work cut out for them, to separate the wheat from the chaff, to bring clarity from confusion, and most of all, to address the real problems at hand.

There’s a fine line to walk between solving real problems and offering what seems like to the average Joe a poignant solution. And I feel that the only way we’re going to get it right is if we spend more time doing the work of solving rather than fussing too much about how it should be done.

Just like how books/events/ideas/etc. can’t guarantee you’ll turn out a good developer, it won’t guarantee you’ll be a good UX designer as well. I don’t care if you’re highly qualified – show me instead how you’ve helped solve real problems for real people, and that will reveal the true marks of a tradesman.

boon :: Oct.16.2009 :: user experience :: No Comments »

Everyone’s hyped up about getting a Google Wave invite. I have one and I don’t see what the fuss is about. Yes, I’ve seen the YouTube video, and yes I’ve watched the Developer Preview video too. It looks great and all, but seriously folks – it’s one complicated thing… next to email.

And this is why Google Wave isn’t about email. The same way computers aren’t (just) about calculators.

What it is is real-time collaborative messaging with historical playback. Which, granted, is very good for real-time anything. Except that real-time in human terms is highly contextual.

Because people have better things to do besides sit in front of their computers all day long, they are much better off carrying Blackberries and having push email rather than collaborative messaging. In my opinion, push email works just as well – because you don’t need to be in front of a computer to communicate with your colleagues.

Wave is also a tool. Meaning that the interface itself is not the message. In order for users to synthesize information, they have to make sense of it in a collaborative sort of way, which means paying attention to whatever is happening in that messaging window, which takes up at most 1/2 of the screen. It looks and feels like, a video player – but for messages. Think of IM on steroids, not email.

Email works because it’s mind-dumbingly easy. And because of that, nobody needs to take 3 week lessons on how to use email – and that includes your grandpa. And because it’s so atomic, it can easily be transported as a message to any other atomic messaging forms – SMS, blog post, forum post, IM chat, whatever.

Waves, on the other hand, are almost asynchronous streams – anyone can start writing content at anytime into a wave, and hope that it doesn’t make a mess of the conversation. Last I checked, people still pay attention to body language and subliminal messages, both of which are devoid in Wave but affects the way people communicate collaboratively and socially together – i.e. turn-taking and all that jazz.

Which part of a wave is atomic? You have to spend effort to calculate and decide. Then you have to find a way of “clipping” that message – and how do you make it portable? Can you cut and paste portions of your wave onto your blog? SMS? can you print it out?

Like email, most of what is published gets fixed in time. But a Wave, is a collection of content played out over time. Just like how photographs put together over time become videos. But with the added complexity of multiple sources of photographs, it becomes more and more difficult to separate and organize content in a Wave.

And that’s why Google Wave is not about email.

Sites and Articles Relevant to this Post:

• It’s Just Fancy Talk
• EasierToUnderstandThanWave

boon :: Oct.13.2009 :: interaction design, technology, tools, web :: No Comments »

I feel really guilty because I’ve been neglecting this blog about interactions, especially when almost everything I do for a living involves designing for interactions.

Instead, I find myself spending more and more time blogging about careers, which in a way doesn’t have anything to do with interaction. Except for one thing – the human condition.

The real kick behind designing any interaction is the effect you get when a human being interfaces with it. Whether it’s good or bad – it’s one of those things that turns me on like nothing else – seeing someone actually interact with a dumb thing you actually built and expressing an emotional response from it.

But when I go out and read all the blogs that talk about user experience, interaction design, usability, bla bla bla… so much of it is so arcane that my eyes start focusing beyond the screen into emptiness and my mind begins to chant mindless syllables.

UX is losing its Touchy Feely

What ever happened to all that user magic that Norman used to talk about? The stuff where he’d complain about the affordances of door handles being one way and not the other and talking about how people would get confused and how we ought to design to love and make people feel nice and fuzzy inside. What ever happened to that?

Now, the only thing people end up talking about are new things that were invented two hours ago – Experience Themes? Who writes a blog post titled so arcanely these days? I thought we were much better at copy than a lot of other people.

And look at how much time went into creating this user journey diagram. It’s pretty, but I don’t know what in the world it’s saying. I showed this to some colleagues of mine (folks who actually do “get” UX common sense) and they too couldn’t make head or tail of it. And this came up tops on Google. :-/

No One Understands Us Outside of Us

Why can’t we just stick to simple terms and communicate things clearly and simply? Do our customers, bosses, users, readers, colleagues and friends really know what we mean by all these words we use? It’s funny how we spend most of our time building for these people, but talk in a language that doesn’t make sense to them.

Are we as designers supposed to build things that way – where we act as folks who fix things and have our own codes of conduct, and can never have normal conversations with the people we solve problems for?

UX Designers aren’t really Designers if they’re more Geek than Human

We compare ourselves with engineers and say we’re more user friendly, but there’s no doubt that every UX person I know is a geek in their own way. They just don’t do code, that’s all.

I prefer a person who does code, because it’s one level below the abstraction layer (towards the technology, not away from it). You can’t have a web UX designer without a programmer. The programmer gets to call the shots, because he actually builds the stuff that makes it work. UX designers ought to pay some respect to the engineering community who built the thing in the first place.

A UX person only has my approval only if they really do care for other human beings, and tell me about their stories. Don’t talk to me about methods or crazy terms and phrases, because I can toss that out and use something else that works. Just because engineers have fancy names doesn’t mean UX designers need them too.

Speak English?

Engineers need fancy names because computers can’t speak for themselves. UX designers already have a language they can use that’s already widely available, is extremely portable, and is fairly universal – it’s called English. They don’t need to invent new words to describe the things they do, which by the way, was copied and stolen from other disciplines like psychology, sociology, marketing, management, etc.

To be fair, I’ve had my share of that design-speak. But I’ve gain nothing except credit from other fellow designers who’ve done the same.

If designers can focus on explaining and speaking out what really represents people who use technologies, it would be a lot better for everyone… rather than inventing new languages to use between themselves.

boon :: Oct.07.2009 :: design, user experience :: No Comments »

I’m currently in a team of 3 people working on a redesign of a website. To me, this feels like my first “real” design project, one where I’ve initiated without any requirements for software implementation. Instead, we began to ask ourselves who are our users, and what exactly are we trying to communicate to them?

User-Centred Design – Using What Works For Me

I felt that a lot of “formal” usability methods didn’t help me much, here. I felt somewhat trapped by procedure and process, thinking about best practices for wireframes, personas, user journeys, etc. Having been exposed to too much user experience jargon, I realized that user-centered design isn’t necessarily synonymous with visual design. In fact, each stakeholder seems to have a different understanding of who the user is, even if the differences are slight.

What ended up working for me was to put down the questions I felt the users would ask (while using the interface/application) onto little bits of post-its, and looked for patterns like organizing those questions into related categories. I organized this in several ways:

“User Journey”-type Things and “Site Map”-type Things

One way of visualizing the questions was to list them out in the style of a “user journey”, which were lists of questions laid out in a temporal fashion (e.g. question A leading to question B as a user traversed deeper into the application). This helped me understand which questions to address first, and which to address later. It helped me prioritize my workflow, and make decisions on which interfaces to work on first. It was already obvious that we needed to focus on designing the homepage, but there were other pages that weren’t immediately obvious, such as a page to help users to “learn more” about the product – that page only came about after looking at the questions from the user journeys.

Another way was to group the questions that were related to one another, and label them as categories. That helped me to visualize the overall site layout, because I absolutely hate building software in the dark – and that includes building on software requirements without understanding the whys to the point I’m convinced of its business and user needs.

At this point, I hadn’t used any formal methods I had learnt from a class, website, or book. It was good that I understood who I was designing for, and I wouldn’t have been able to do this without classes, websites and books – but the formal methods were pretty useless. I just used what worked for me.

We Used Fireworks, but I can’t Recommend it to You

It’s important to note that two of us jumped onto paper and pencil and did wireframe sketches, and then designed a hi-def visual of the homepage on Fireworks (which I now really love) – only because we were three people and we couldn’t quite picture the outcome in our minds. At the same time, we needed our boss to make a decision and he has a lot of emotional attachment to the look and feel of the site, being the founder and all. So it was important to get those designs out.

I don’t think I can recommend the same process to other designers – it really depends what you’re designing for. Those fireworks designs took up several days and a lot of it was thrown out of the window as we iterated from one design to another. But I think that’s necessary in design, sometimes – because the interface is what users will end up seeing and using, again and again.

Sometimes I read articles from other designers and it all sounds really cool and makes you feel that there’s some kind of order or process in the design of an interface. But I find these things hard to use because it’s the designer that makes a difference, not the method. It’s about knowing what you know that works – a process or method can’t save you. They’re just tools.

boon :: Oct.04.2009 :: interaction design, tools, user experience :: No Comments »

I love this idea: http://www.somebits.com/weblog/tech/good/webapps-with-json.html

boon :: Sep.21.2009 :: interaction design, web :: No Comments »

I’m at the start of a new phase of our development, and we’re at the point where we need to generate ideas for our interfaces. I’ve observed that wireframes aren’t always well-received by people who don’t understand them – clients who think they need more color, developers who want to code over it, etc. If the only resolution we have to this problem is educating the public, I think we’re in for a very long ride.

This might be because wireframes aren’t obvious enough to people.

You heard that right – if people are misunderstanding your wireframes for a finished product, or your sketches for a placeholder for a WYSIWYG dev tool like Visual Basic – there’s clearly something inappropriate about the tool’s use.

I believe some of us take wireframes for granted, such that we see no other way of implementing a product. While wireframes work well for some designers, I sometimes think they take up time and that there might be better, faster, more efficient ways to build software.

Also, wireframes aren’t great for super-dynamic AJAX-heavy interactions. And they aren’t great if you want to break out of the 2D mode, and work with more dimensions (how do wireframe a keypress, or an animation, or audio?).

I remember the first time I used tons of wireframes on a project, and ended up realizing that we wasted all that time building hi-fidelity prototypes just because I felt it was the right way to design an application. Time was wasted testing the prototype because we didn’t get THAT much insight out of it, simply because it was so blatantly obvious – we should have just tried it on ourselves before testing it on other users.

I’m probably stepping on some UX no-go zones – aren’t we supposed to test apps on real users, and not ourselves? Well, I think there are some things which are so blatantly obvious you needn’t waste the users’ time to fix or test. Testing via paper prototypes a la Carolyn Snyder isn’t always going to save you time. There are much faster ways to get it done, if you think through it a little.

I’m not advocating against wireframes. I’m just advocating against getting locked down on a specific method – against “methoditis” – you know, when you start believing that one method is better than another just because.

Basically, you might want to re-think wireframes if they:

• confuse the people you’re communicating to
• take up time when something else can be so much faster
• cut down too many trees

Here are some examples or ideas of doing without wireframes:

• http://gettingreal.37signals.com/ch11_Dont_Do_Dead_Documents.php
• http://code.new-bamboo.co.uk/polypage/ (a tool developed by Clearleft and New Bamboo)
• method-acting (see Bill Buxton’s Sketching User Experiences for an example a designer “being” the device)
• plasticine? feel free to add your own examples.

boon :: Sep.21.2009 :: interaction design, tools :: No Comments »