I find it surreal that I only got back from Hong Kong the morning two days ago, and that it has only been 4 days since UX Hong Kong. Maybe it’s because I feel there’s a lot to digest and I’m still experiencing the conference high, which I think is a good thing. I’ve certainly been in conferences where I’ve felt really deflated, as though the event was a big party and everyone had to go back to their scheduled lives –  it hasn’t been so with UXHK… at least not yet.

Why UX Hong Kong?

UX Hong Kong is the first UX conference (AFAIK) ever held at this scale in Hong Kong. There have been several UX conferences in China (warning: link may be reported as an attack site) and Australia of this sort, but none in Hong Kong until now. I think UXHK, befitting its political and cultural context, sits between the East and the West; and provides a venue for globally-minded, Asia-aware practitioners to meet and exchange views about the state of UX from this Eastern melting pot.

It has managed to attract a diverse list of attendees, such as:

• HK-based practitioners and companies looking to expand and improve themselves
• Foreign companies and freelance consultants interested in Asia as a market
• Foreign and local companies looking to recruit promising candidates
• UX practitioners looking to HK as a potential base (e.g. born in HK but working abroad, dimsum lovers, etc.)
• IxD/design students from HK educational institutions

The conference was organized by Apogee HK (Daniel Szuc, Josephine Wong), a well-respected UX consultancy both locally and abroad.

Talks & Workshops

The format of the conference was a basic presentation-followed-by-workshop format, with four speakers each giving a high-level presentation of a chosen topic to a full audience, followed by a half-day workshop with registered attendees.

I felt the selection of topics were fairly varied, which was good. Steve Portigal focused on the topic of delivering real value from UX research, Rachel Hinman on what I call a-really-good-approach-to-designing-for-mobile,  Steve “doc” Baty and Janna DeVylder on practical means of materializing UX strateg(ies) even/especially without a centralized UX approach, and Gerry Gaffney on the essence of UX and getting to grips with the fundamentals.

I liked the no-nonsense, anti-bullshit approach – I think UX has gotten discredit for being some fluffy stuff because of misrepresentation (uxmovement.com?) and misunderstanding, so I’m happy to say that even experienced practitioners got some real meat from the sessions.

Since I only attended the Experience Strategy workshop, I can only summarize from that experience:

• a strategy is intended for decision making (my take: if you can’t make a decision from a known strategy, it probably isn’t a good strategy)
• deep and broad understanding is required – ask the right questions and then brainstorm the answers exhaustively to build rich models of the context, environment, business needs, etc.
• illustrate the synthesis of those models through visualization tools such as experience maps, storyboards, pain points, and so on – by all means, map those against each other to find correlations and cohesion
• Always, always, always consider the broader context of what users go through – illustrate it, discuss it, map it out – don’t treat it lightly, because it’s easy and common to sidetrack (I made that mistake too, even in the workshop)

Grokking the Event

In all fairness, UX Hong Kong wasn’t a major UX conference. It was intended to be a fairly intimate, practical event for UX professionals, and I think they succeeded very well. I was happy to get to chat with all the speakers during the conference day and the dimsum + informal excursion the following day, plus meeting fellow practitioners from Singapore, Japan, China and other places was exceptionally invaluable. While I love being in London’s amazing UX scene, it was really nice to meet some fresh faces and build rapport with them. At the same time, the event gave me a chance to experience Hong Kong a little bit more than if I was at a typical stay-in conference. Some of us even got a short guided tour of HK culture by Calvin Chan, who was one of the attendees!

I must say, however, that serving fried rice, kai lan with oyster sauce, and roast pork first BEFORE siu mai, har gau, cheung fun, and char siu bao is not very representative of proper HK dim sum… otherwise, I had absolutely no regrets attending UX Hong Kong and would highly recommend attendance and/or re-attendance of next year’s UX Hong Kong 2012.

photo credits: yeungfeifei, szuc

I had a free day to myself today, so I thought I’d laze around the internet looking for interesting stuff and ended up spending the whole day immersing myself with the insane amount of stuff that’s been posted on the interwebs about Interaction 11 in Boulder, Colorado.

After 5 pages of sketchnotes, I’m still not done yet. The sketchnotes have certainly helped me digest and really synthesize the talks – it’s almost like being there, plus I can do background research about the speakers and certain topics at my leisure. I’m so glad that people are putting all this stuff out. If I don’t manage to get to Dublin for Interaction 12, I won’t know what to do with myself.

This is a long overdue post that should have gone out a week ago, but I guess it’s better late than never.

Why?

I’ve been keen on improving my presentation skills (I hear it’s a good thing for UX designers), so I jumped at the chance to present when Lee McIvor announced LightingUX needed some speakers. I’ve given talks before, but it felt a lot harder speaking to my friends from the UX community. I was concerned that my talk wouldn’t be relevant, unique, or entertaining — in the end, I decided all this worrying got me nowhere, and went ahead with the developer-to-UX-designer idea.

I felt some UX folk would benefit from seeing things from a developer’s perspective. I also felt that while there’s much general advice about becoming a UX designer, no one has really shared their experiences publicly. Finally, I wanted to know how other people would respond to my talk in order to improve/learn/synthesize/etc.

How?

It took me about 24 hours in total to prepare for this talk. 5 minutes isn’t a lot of presentation, but it’s good to dive deep during prep. I started out getting philosophical and started brainstorming thoughts about the essence of what made developers different than designers, but that fizzled out quickly because I felt it would be hard to do in 5 minutes. I also scoured the internet looking to see if other people had similar experiences, but that didn’t help me focus my talk very much.

I posted a message on twitter asking what others would like to learn from my talk, and got some interesting responses:

• @myddelton – re: your talk. is it an advantage or disadvantage to know about practical coding constraints when doing UX design?
• @mikejthompson – Do you see your technical knowledge of what’s possible as limiting your creativity or ensuring the relevance of your work?
• @francisnorton – How to avoid the trap of premature commitment? As a coder, I want to start coding; as a designer I need to keep the options open.
• @futureshape – do you still catch yourself thinking of the development impact of what you design? I know I sometimes do
• @ifenn – How has your mindset changed? Do you approach/think about things differently? How?

I knew I couldn’t address everything in a 5 minute talk, so in the end I examined deeeeeep inside my gut and asked myself what it was that made the biggest difference for me, and what were the major paradigm shifts I experienced since doing UX full-time (it’s very different than doing it while being a dev). I came up with this one-pager of prep notes:

My main point was to highlight the fact that what specific things made a difference for me:

• Seth Godin’s AMAL book left an impression that led me to seek out more not-so-tech related stuff.
• About Face 3 – it was practical enough for me as a developer to not just apply it but teach others how to apply it as well (JJG’s Elements didn’t cut it although it’s a good book)
• The UX community – I felt I didn’t do that slide justice. There were specific names I wanted to mention (Alex Baxevanis, Ian Fenn, Tom Coombs, and the StartUX crew) but I felt it would kill the pace of the talk.

With the list of changes a.k.a. the paradigm shift after becoming a designer, I summarized it to these three main points:

• Big Picture thinking – much more holistic as opposed to complex like software architecture, scalability, etc.
• Creative work requires creative methods – learning that the screen is extremely limited, and that the critical part of the process is about thinking, not creating (e.g. wireframing).
• Communicating my work well became a lot more important (though talking code to non-dev people is usually unnecessary and leads to social ackwardness).

The Glue Thinking thing just came to me as a way to summarize the balance between architecture, making things work well, and delight.

Lessons

I screwed up a little on the 2nd last slide and thought I could’ve done a better ending. I think some people liked the Glue Thinking thing (especially the part about getting users high), so I should’ve played that up a bit more. I think I got a bit too self-conscious towards the end after I realized I’d gone over a little bit at the 3 minute mark. I got a bit sensitive when Cennydd made a remark about “staring at screens” just before he started his talk but I’m sure it was just me.

I was surprised to hear other people got some benefit from the talk. Johanna said she was happy that Design Jam had impacted me (she’s one of the local champions). Martin Belam, who does some really amazing work at the Guardian, came up to me after the talk and shared his comments (and made a blog post too). Others tweeted about the Glue Thinking thing. I was really touched – just the comments made it worth it.

Overall it was a good experience and I’m glad I got the opportunity to do the talk. I’m looking forward to the next opportunity and have a few ideas in mind. It certainly forces you to be critical about your work, and that’s what I like about it – that my work can be validated because it should be validated.

I encourage others to do the same.

p.s. The “drunken robotscape wallpaper paper-prototype mural” and the “epic win dragon” on the first and last slides were the awesome handiwork of reyhan (I forgot to credit him in the slides).

How a developer became a ux designer

The subject of design education, UX careers, and mentoring has been on my mind a lot lately. It wasn’t long ago that I was looking for UX job and I’ve learnt a lot in the process, not to mention the experience I’m gaining on the job right now.

In addition, there’s been a lot of conversation and interest from the UX community in this area – e.g. Jason Mesut’s rant on UX portfolios (sign-in required), Don Norman’s “Why Design Education Must Change“, Mozilla Labs’ first Design Jam event in London and my own conversations with Ian Fenn, Jeff Van Campen and Lane Halley about engaging in and improving Communities of Practice in the UX industry.

Broadly speaking, there are three main issues that practitioners and the industry is experiencing right now:

• The huge gap between research and practice
• Challenges faced by junior and non-UX practitioners seeking to gain employment in UX
• Difficulty for employers to find UX candidates who can articulate and present good design thinking

These issues are complex and extend beyond the point of this blog post, but I think that apprenticeships would be a good way to resolve some of these issues.

Why Apprenticeships – a Case for Situativity

This paper on “learning approaches for teaching interaction design” by Dr. Corina Sas does a really good job of explaining the challenges and possible improvements to IxD instruction. The four main approaches she suggests are interrelated (apprenticeship, constructivism, experiential learning, and situated learning & community of practice), but the gist of it is that IxD (and related UX disciplines) is more craft than science (though the science bit is still really important), and that what’s lacking is a systemic approach to procedural over declarative learning.

This seems to be a common observation elsewhere as well.

In the past few weeks, I’ve had the chance to experience this working alongside a more experienced IA. I was working on a product browser that would sit on the homepage on a site I was redesigning. Through our discussions, we came up with a better way of displaying the products and it was only because the senior IA had given me additional insights that helped me think more creatively about the solution.

I know it sounds really trivial as that insight could’ve come from anywhere, but I gained new IA skills by being a participant in the ”working out” of the solution together through discussion, observation, pen and paper, and our understanding of IA (see situated cognition).

Destroy Perpetuating UX Myths

In Jared Spool’s presentation on “The Dawning of the Age Of Experience“, he explains that design decisions can’t always be interrogated. He used examples of sushi chefs, midwives and chicken sexers who, through experience, just happen to “know” what they’re doing is right or wrong. As practitioners we can sometimes end up using our UX methods as a ‘design crutch’, and end up perpetuating the myth that it’s the right way to do design.

Jared’s research has shown that design decisions can come in five flavors, and that “activity-focused design” (expert reviews, heuristic analysis) and “user-focused design” (contextual research, ethnography) are only two of those. “Genius design” (like chicken sexing, midwifery) happens to be no. 3, and observes that this genius design is “a solid style that often has positive outcomes“.

He too, suggests apprenticeships as a way to get to good design.

Models of Apprenticeships

How can we get this thing moving? I think that apprenticeships (or shades of it) can come in different forms, and it’s up to the individual to seek out those opportunities and make the best of it. There are a few ways it could start or take form:

• An Apprenticeship Program where an experienced designer meets with a mentee/apprentice/protege and scopes a project in order to build an end-to-end case study of the individual’s work, which can then be communicated through a portfolio of some sort (as described to me by Lane Halley)
• A self-initiated scope of work/issue/topic by the practitioner alongside a mentor, in order to work towards some career goal (works well for mid-level practitioners who already know the basics and need to address gaps)
• An internship (though I feel internships can be abused, too) for an intense, short project (see Leisa Reichelt’s blog post)
• Internal apprenticeship programs (here’s an example)
• Working alongside senior practitioners in-house (my product browser example)
• Design Jams, but I think this will require some coordination and involvement of expert designers co-designing (rather than advising) with less-experienced designers for it to work well

As the field becomes increasingly multidisciplinary and complex, I don’t see how it works just to work alone and improve as a designer. At the same time, I don’t think we have the luxury of reinventing the wheel all the time, or perpetuating outdated methods and concepts. Maybe one way to formalize this is to improve on the mentorship programs available through the UPA, IxDA and IAI, and encourage more participation and involvment from the community. I just hope it won’t be a case for us of getting to a point and being comfortable that design should be done a ‘certain way’.

I was fortunate enough to get a ticket at the very first Design Jam today. It was put together as part of Mozilla Labs’ work to encourage ‘open design’, and runs in the spirit of developer ‘hack days‘, but mainly aimed at UX designers (the first of its kind?). I’m happy to say the event was successful in generating a lot of conversations, getting involvment from the local UX community and beyond, and getting people excited about UX.

I was looking forward to seeing how other designers approached UX, looking to gain insight and value from other practitioners’ work. Although I expected many more UX people to be involved, there weren’t many experienced UX practitioners who participated. Still, I learnt a lot from my teammates who came from varied backgrounds (dev, research assistant, comms, anthropology, veteran generalist).

Here are some of the positive points from my experience with Design Jam:

1. It’s a whole level of experience doing design itself, as opposed to learning about it from books and events. Design Jam succeeded very well here.
2. There was good diversity of skills – many people I’ve never met before, and certainly had the pleasure to work with. We all learnt how good design could take place with the right conditions and environment.
3. Mentors – having them around provided a real yardstick and that extra polish and validation to our work. I was happy that Leisa Reichelt and Ivanka Majic came along to assist.
4. The space – kudos to City University and the organizers for setting up and providing the space needed to do the work. It was perfect.
5. Equipment, tools, etc. – apart from some minor glitches with the projector, I felt there were enough stickies, post-its, etc. although I did bring along my own design kit (instead of a laptop, like everyone else did).
6. The organizers (@johannakoll, @joelanman, @cyberdees, @bobbywatson, Kate from City Uni) were really helpful, went out of their way to get us coffee, and worked their asses off to make this happen.

I think some improvements can be made in future runs of Design Jam:

1. Incentivize more experienced UX practitioners to participate. I certainly saw many people hungry to learn about UX, and it’s not just about having the ability to create personas, using a UX process or doing user research. An experienced practitioner can make a real difference in how all that gets synthesized.
2. It would’ve been better if we had more time for reflection and learning. I felt there were many people, some of which were new to UX, who could’ve given their thoughts and opinions about their experience. It would’ve been much more valuable to gain those insights during the event.
3. The presentation phase could’ve benefitted from more structure. Having some sort of structure and time limit would encourage teams to focus and deliver a more compelling presentation, rather than a looser format of this-is-is-our-prototype-and-heres-how-we-got-there – keeping in mind that energy levels usually drop fast toward the end of these kinds of events.
4. It became a bit intrusive to edit the wiki while doing groupwork – it meant that occasionally one member of the team had to be disengaged from groupwork to focus on the wiki. While I appreciate the value of real-time conversation and updates, it could’ve been given a bit more thought – maybe allocate time for groups to do that rather than steal away precious group time.
5. For some reason, I feel it’s important to have good wall space do to UX design. There were teams that had to make do without ample space, but I guess no one seemed to complain.
6. It felt a bit harder to work without easy access to coffee (ok this is a bit out of place, but…). Thanks again to the wonderful organizers who went out of their way to get us takeaway coffee from a nearby cafe.

Some interesting highlights:

• Our levels of do – part of our conceptual map of the user’s re-finding activity.
• Our user research, done on twitter – complete with incentive for willing participants.
• Stephen Anderson’s Mental Notes cards came in handy.
• iPads as prototyping tool and makeshift powerpoint slides.
• Family friendly.
• Makeshift wall.
• Location-based piles.
• Design Jam wiki – thanks to @jeffvancampen.
• Our team, SevenHeaven.

I’m looking forward to the next one! Big applause to the organizers and sponsors (Mozilla, City University, Johnny Holland).

After two months of looking, I’ve finally found an opportunity to work in the user experience field as an Information Architect (my previous role was Lead Developer, although I did quite a lot of UX there as well as in the previous company). It was certainly the right combination of my previous skills and experience along with my interest in UX, as well as a healthy dose of good fortune, that led me to this job.

I think there’s a real challenge here for not-so-UX folks who are on the ‘fringes’ of the UX field and are really keen on building a career in UX. I’ve met many of them – developers, designers, business analysts, producers – many of whom are very well-read and passionate about UX and are looking to really build a solid career in the field. These are people who actually ‘get it’, as opposed to people who just seem to think that UX is just another label that’s been plastered onto another job title for added kicks.

It doesn’t help that UX isn’t as universally accepted as a practice, and individuals who want to practice UX properly will face an uphill climb as they not only have to attempt to do it right but also convince their companies that it’s worth doing in the first place. Some people I know have opted to gain academic qualifications in HCI/IxD/etc. in hopes to increase their value in the UX job market, often in mid-career, sacrificing potential career opportunities and valuable time. When they graduate, they will face an increasingly competitive field, despite claims from companies and recruiters that UX people are always in short supply.

What they really mean is that truly experienced UX practitioners are in short supply, and a growing number of companies and clients who are starting to see the real value of UX are becoming more selective, as UX (as with any other resource) can be seen as a considerable business risk – but with obvious benefits provided they hire the right skills.

I think it’s much harder to hire a UX practitioner, particularly when companies want pretty much the whole package in an individual (user research, interaction design, information architecture, user testing, web standards, accessibility, etc.) – it’s no wonder that seasoned professionals are in such high demand. Seasoned pros have the ability to move back and forth between high-level strategy (concepting) to low-level implementation (deliverables), which makes them perfect for either deep or broad deployment.

To get a foot in the door, junior UX practitioners have the option of seeking out the few companies who understand what it means to build a UX team and know how to utilize a junior UX resource alongside its multidiscplinary teams. This is fine if you’re fresh out of a HCI programme, but is a tricky thing to navigate for someone who’s transitioning into UX from another field, some of whom have been in management/strategic/senior roles.

I think that freelancing and volunteering can provide some solutions to this – what’s important here is the value acquired from the experience of doing the work, rather than the work itself. For example, it doesn’t count that one is able to produce wireframes – he/she must be able to articulate the thinking behind that wireframe and well as the process involved in producing it. Experiential learning is quite important in this field, and Mozilla Labs’ Design Jam event looks to be a step in the right direction, but we need a lot more stuff like this.

This isn’t always obvious, which is an irony as there are now so many UX books out there, you’d think that we would’ve leapfrogged a few decades ahead in time. But we haven’t – UX and its sub-disciplines are often more craft than science, and that takes a lot of focus, dedication, determination, synthesis, learning and collaboration to gain confidence in that craft.

I am fortunate that London has a thriving and supportive UX community, which has helped a lot in my career transition. But I am certain there are individuals around the world to whom this would be considered a luxury.

I have more questions than answers to this problem, which I perceive to be a real issue if we really care do about the issues people face with interactive systems. This is why I feel really strongly about mentoring, community, participation, and advocacy if this field is going to really take root and make real progress. The only thing I can consider is to not shy away from this despite being a new entrant (formally) to UX, as ‘new practitioners’ sometimes do.

Maybe I should consider submitting a proposal to the IA Summit as a ‘fresh voice’ – but what will I speak of?

I gave a presentation a few weeks ago at the NordiCHI 2010 research conference, based on some workI did about a year ago about how people use images on the internet. It was a diary study involving nine participants and I sought out to understand the motivations behind their image use activities.

Most of the research that’s been done around images is centered around the technology itself, rather than the behavior. Alas, there’s not much we know about why images are important to people apart from what we can already assume.

The study wasn’t meant to be exhaustive, but it does provide a framework for understanding why we use images on the Internet. Essentially, it comes down to the four categories below:

• Learning/Research
• Being Objects of Communication
• Connecting with Remote Experiences
• Supporting Other Goals

These four categories explain at a very high level why images are important to people, but this alone is not enough. Let’s take a deeper look:

Learning and Research

Images are highly valued for their visual qualities. Without words, you can gain so many insights just by looking at something. However, in my study, I noticed four very clear patterns of image use related to learning/research. And they were all driven by slightly different motivations:

Supporting an interest or hobby: Sometimes images are the best medium to showcase the things that we love so much, from sports to books to photos of interesting pigs.

To satisfy curiousity: Some users did just that – search for photos because they wanted to know what something looked like (what does pelt look like?).

For discovery of new facts: This is when we learn new things just by seeing them and making sense out of the visual information (e.g. learning that there are two types of meat mincers from product photos on Amazon).

For ideas: And this is when we want to get inspired by looking at things in lots of different ways (one participant spent 2 hours looking at birthday cakes on Flickr just to get ideas).

Objects of Communication

Images are not just used for learning. They are artifacts in and of themselves, and are used in many ways to support social interaction. In the study, participants not only used images as ways to communicate (e.g. smileys, showing a photo of something without using the words), but they were also used for social activities, like games (e.g. name-this-person).

We’re extremely natural at collaborating with each other using visual things, as opposed to just words alone. Images weren’t just used as talking pieces – sometimes, they were the message themselves! It was quite funny to see how people loved to use photos to replace words.

Maybe that’s why LOLcats is funny – it’s like having an invisible 3rd person giving an odd punchline.

Connecting to Remote Experiences

Our brains are hardwired to visual and auditory stimuli, so sometimes images (especially really large, high-resolution photos) act as windows to places and experiences we want to connect to –  our memories and our imaginations. The study showed how large photos were used to connect people to physical locations, past experiences, to connecting with friends and family, and even with personalities (e.g. celebrities – Michael Jackson died in about the same time the study was carried out).

Supporting other Goals

One of the most insightful things I’ve learnt is how people use images as sort of a swiss-army knife of the web. It’s used as a replacement for text, for getting past poor text search results, for sorting out navigation in a geographical space.

Alternative Answers: Images can be used to get around the limitations of text, language, and meaning. One participant was searching for an authentic Mexican dish, but Google search is awash with American renditions of the dish, which of course, wasn’t authentic. Google Images to the rescue – she found the recipe she wanted instantly because she knew what she was looking for.

Indexes: Have you ever tried searching for a music album that was a Japanese import, that was only distinguishable by the way the album cover looked? Some search results don’t reveal those things, and sometimes you just want the exact one you saw in the store. Thankfully, most e-commerce sites feature a screenshot of the product, and users do rely on that for efficiency and accuracy.

Maps and more: Sometimes, maps aren’t enough. Users are smart enough to look for visual cues like landmarks, photos of store entrances, the location of potential parking spaces (StreetView), and so on. Sometimes, if an image doesn’t provide enough information, look for another image.

More than meets the eye

I think we’ve only just begun to understand that behavior, while complex and sometimes idiosyncratic, doesn’t just happen without a reason. The purpose of this study isn’t about predicting behavior – it’s about understanding why something might be likely to happen, so that we can make the right design decisions to anticipate for those behaviors if they do happen.

It’s also about testing our own assumptions about how people use images on the Internet. The model presented here is only a starting point. I believe that as interactions become more complex and multi-modal, this may well change and evolve over time.

Note: here are the slides for the presentation I gave at NordiCHI 2010.

A candidate student for UCL’s HCI programme emailed me to ask some questions about the course, so I’ve decided with his permission to put the Q&A here for the benefit of everyone else. If anyone wants to add anything, feel free to put it in the comments section.

1. What do you think about the experience and knowledge (etc.) that you gained through that course, now almost year after finishing it? Did it help in getting a great and desired job?

I think different students get different things out of the course. What I wanted out of it was some real experience doing ethnographic fieldwork and good exposure to the user experience industry. I got both of that. The course is good, but if you don’t know what to look for, you will most probably not get as much of your worth of fees out of the course.

I would recommend “keeping an eye” on your classmates – especially those who work hard, are active in HCI-related activities outside of class, and have a strong purpose of what they want to get out of the course. For someone who hasn’t had any experience in the real world, it would really benefit to learn from others who have.

I think the course is really good for that because it attracts both new and experienced students alike.

2. I am also concern if I’m doing right choosing that course and rejecting ergonomics at Loughborough. My background is in psychology, I am PC literate but have no idea how to programme (willing to learn though) etc. I also do not have any professional experience whatsoever. Now, obviously HCI is mainly about (as far as I understand) the USER, his experience and performance within various technological settings, so I guess it is more about psychology than Computer Science, but I’m not sure about that. So my concern is: do I actually have any chance of getting a job (HCI-related or ergonomics-related) after this course?

The course is skewed towards psychology and human factors. No programming needed.

However, if you are going to seek employment after the course, some jobs may require a bit of knowledge of HTML/CSS/etc., which are mostly front-end languages. It’s no harm picking it up and getting that extra advantage over someone who doesn’t.

I am currently working in a company where, incidentally, 3 of my friends from the course are working as my colleagues. One of them has strong programming knowledge while the other two don’t. We frequently get into arguments about the way interfaces should be built within the given time constraints, and it’s usually due to misunderstandings about the underlying technology.

However, it’s not a life-and-death thing. I work in a company where we build our own software. Your mileage may vary. I know other students who don’t even touch programming.

3. How many students are there each year? Is it about 30? In the UCLIC 2008 Newsletter you can find this info: “UCLIC’s teaching programme accepts about 30 students per annum, with backgrounds in psychology, computing and design disciplines.”

My year had about 40+ students. This year’s batch had 60+. Two years ago, the numbers were more like 30+. I actually prefer a smaller group. 60 is too much. 40 was just “large enough”.

I don’t know how the numbers are going to be like for this year. I don’t think they can handle more than 60, to be honest. But I’d encourage you to ask this year’s batch to find out more about their experience.

4. How strong is the ergonomic part of the course? Is it more like HCI with “elements of Ergonomics” rather than “Ergonomics”?

Ergonomics is fairly strong. Strong industry links through Rachel Benedyk’s contacts. Good opportunities for projects and hands on experience. The industry is fairly lucrative – you can get to work with Transport for London, air traffic control systems, nuclear power plants, etc etc.

5. Do all students there have a vast professional experience?

In my experience, it has been a mix. The faculty encourage that mix as well – in groupwork and otherwise. Good to learn from other students.

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.

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.