This post started out as a reflection of an article I wrote for Johnny Holland titled, “What I bring to UX from Computer Science“. Instead, it ended up being a reflection of my career now as a user experience designer.

When I started out in UX, I used to feel giddy thinking about all the cool methodologies, processes, patterns, practices and tools I could employ. But none of those guarantee any success, so I thought instead about the material of my craft – the craft of experience design. When I was a software engineer, it was obvious the material I needed to master was technology. But I wasn’t so sure about UX, so I started comparing.

You don’t need to be an engineer

Whenever I tell people I worked as a software engineer in the past, I get opposing comments about how that has affected my job as a UX designer. Most designers assume the invaluable insights I must’ve gained from my deep understanding of technology. Developers, on the other hand, always ask if I find my experience a hindrance rather than an aid.

Up till now, I haven’t been able to give anyone a straight answer. The fact is – I don’t think it matters all that much one way or the other. Many UX design problems are varied and complex, such that I’m forced to think on my feet a lot. It’s hard to say how often I consciously draw from my background as an engineer. I’m sure there are lots of benefits from other backgrounds that are applicable to UX work too.

Experience is complex

Another contrast is the fact that I find myself thinking about problems in many different ways than I did before. I spend a lot of time trying to understand the problem in order to design appropriately. When I was an engineer, I was bound to a specific domain. Now, it’s my job to consider the effects of many different things, all at the same time.

I also have an ever-growing list of books to read on a variety of subjects, and many of them I consider crucial to my work. Never in my professional life have I read so intensely and prolifically. I can count with my fingers the number of books I considered important while I was an engineer. It is the opposite with UX.

Hard to define, hard to solve

I’ve observed that despite all the hype about UX on the Internet, only a handful people in the world aspire to be UX designers. What *exactly* do we do? How do we measure the value of our work?

It’s not a surprise that people don’t “get” UX – even us as practitioners spend a long time trying to define it. Engineers never have to worry about that. As an engineer, I was paid to make things work. Now, I get paid to solve all manner of problems involving experience. And what doesn’t involve experience?!

That brings me to my next point.

Alas, experience is what we have to work with

All craftspeople need to understand the material of their craft. Some say the material of our craft as UX designers is the underlying technology, but I disagree – we are not software engineers. Instead, I think the material of our craft in designing for experiences is experience itself.

Just like an engineer using code to give life to software, we use our understanding of experience as material to solve design problems. We observe experiences (research, testing), deconstruct experiences to understand it better (flows, mapping), re-imagine what experiences could be like (brainstorming, prototyping), and communicate it back to ourselves and others.

We are all storytellers

It also seems that the only way to communicate experiences is to tell stories. If that’s true, then the purest form of our craft is storytelling; Professionally though, we’re problem-solvers. So, in many ways, our work involves solving problems by telling stories.

So here’s what I think… the plethora of UX methodologies, processes, patterns, practices and tools we have are useless if we don’t have a good understanding of experiences and how to communicate those experiences effectively in our design solutions.

And maybe that’s why it’s hard sometimes: we take experiences for granted all too easily – our own as well as others’. Rather, we should consider it with greater intent, for it is the material we have to work with most as UX designers.

Update: It’s worth reading Oliver Reichenstein’s excellent take on whether experience can be designed.

Sometime late last year, I offered to organize uxcamplondon 2011 with the support of previous years’ team and a bit of help from my friends. I was determined to see it happen this year after I missed last year’s uxcamp due to an illness. After all, I had learnt a thing or two after volunteering since 2009 – I figured it wouldn’t hurt to try.

But organizing an event for the first time teaches you a lot of things. It’s a very “people” job, one that often requires a certain amount of savvy, timing, and humility. Only then does everything else become “logistics”.

As Cennydd said, the devil is in the details.

So being an organizer, you will replay countless scenarios in your head, but the end result is often surprising. And just as some had predicted, we had a decent turnout (about 60 people – see update), the day went by quite smoothly, sessions were really interesting, and everyone had a pretty good experience through and through.

Some highlights included James O’Brien’s Agile UX talk, Laurian Gridinoc’s session on “reactive documents“, and the repeat of Cennydd’s IA summit wayfinding debut.

I regret not putting enough thought into my own session. That’s a scar I’ll have to bear forever, but the credit certainly goes to the many UXCamp newcomers like Nick Dunlavey and Clarence Lee, who presented some really interesting stuff.

Still, the best part of any UXCamp is the sheer camraderie and partnership you get from the combination of attendees, sponsors, and organizers.  What we may remember best is Jonty Sharples’ venn diagram oddities, finding common ground about UX in the enterprise, Dr. Simone laughing over a pint, Cennydd as a perennial UXCamp favorite, and the crowding of the otherwise quiet local to wind down the day.

Plus I met so many cool new faces on Saturday I stopped worrying whether this year’s camp would be as cool as the last.

And that’s the way it ought to roll.

 

(update: I made an error calculating the percentage of 60% turnout initially by basing it off an outdated list. The number is closer to 75%, or 20 no-shows. It’s still a concern, but not as bad as I originally thought.)

When I attended the first Design Jam last year, no one was really sure what to expect. It was great at the time when I was transitioning careers from being a hybrid dev/designer to full-time UX, as it gave me an opportunity to practice a lot of cool stuff I’d been dying to try out. I did skip the second one for several reasons, but by the time Design Jam 3 came around I was itching to give it another go since full-time UX started to feel quite repetitive.

My primary goal for the day was to keep things simple and to test how my UX skills had developed over the last 6 months. My plan was to avoid pre-selecting specific methods to use and to go with the flow. I wanted to know if I was more aware of the design process, and whether I was able to influence it towards a positive outcome. So, while the first jam was for me to test out UX methods, DJL3 was for me to evaluate my ability to navigate or influence the design process (which I feel is a core part of what UX designers do).

I think that overall, I’m quite okay at facilitating generative activities by prioritizing ideas, chunking activities up into tasks, having a ‘feel’ for the team’s flow and encouraging discussion. I was not so okay with the delivery part of the day when we needed to pull together to make something. With the generative part of the work, all I had to do was organize the information that my team members were freely sharing with each other. But with the delivery part of the day, I wasn’t really sure how to suggest an approach that worked for everyone – almost everyone had a different idea of what needed to be done.

In the end Jason Mesut stepped in and helped us formulate a plan. The mentors made a big difference that day and I was particularly pleased they were handpicked by the organizers to provide teams a balance of domain, team, and design advice.

While I certainly came away with some interesting insights from the day, I spoke to a lot of people who said they weren’t exactly sure what they got out of design jam apart from the fact that it was sort of fun. Some people were expecting to have a kind of workshop-like experience where they would be exposed to UX methods, which they could incorporate into their current work. Some said it would’ve been better to be assigned into teams for skill balance, rather than assigning themselves to teams in a semi-random fashion.

I agree that its impossible to please everyone, but I think that it may be worth reflecting on what attendees really want out of a design jam. For me, it was first a place for me to try out UX methods, and then a place for me to evaluate my design skills. But for others, it may be something completely different.

I wonder if there are patterns that are starting to formulate, seeing that Design Jam is now in its third iteration, that could help shape future iterations of the jam in a new way. So far the formula for a design jam hasn’t really changed very much. On the other hand, maybe all we really need is for design jam to be a testing ground of sorts for multidisciplinary teams to work on something and have fun at the same time.

Either way, I hope and trust that future iterations of design jam exceed the community’s expectations for a UX hack day.

Check out my team’s work here at http://djlon0310.tumblr.com

This year I decided to attend more UX conferences, having fully made the transition into UX for good. The year kicked off with UX Hong Kong (which was amazing), followed by UX Lisbon in May, and just few weeks ago – the DIBI conference up in Newcastle.

Every conference has its own strengths and general vibe. After getting advice from some seasoned conference attendees, it was a matter of choosing the conferences that would suit me best. For me, UX Hong Kong was a perfect start, as it was a fairly intimate conference where I got to meet some really interesting people and give me a taste of what a UX conference feels like.

May came around and it was as people had prophesied – UX Lisbon turned out to be a big UX party – food, fun, sights and Don Norman. Plus a stellar cast of UX rock stars made it promptly a trip to remember.

Then, just when I thought I had exhausted my remit for conferences, I made an impulse purchase to attend DIBI a few months later after finding out that Jared Spool and Jeffrey Zeldman were speaking.

At this point you’re probably wondering why I keep attending so many conferences, and what have I really benefited from them?

Well for one, I don’t really attend conferences to learn new skills or even pick up on future trends. The real reason I attend conferences is to absorb the intangible benefits of being around people who influence and care about this industry.

Some people call this networking, but that’s such a lame word. I prefer to call it a ‘community of practice‘, based on the work done by Jean Lave and Etienne Wenger, where a profession evolves and develops around groups of people with shared interests.

There are several reasons why this is important with regards to conferences.

Watching our industry evolve in real time

UX as an industry is still taking on form, shifting and moulding from a primordial soup of different disciplines, practices and vernaculars. Thus we constantly draw upon the work of highly influential people who have done the good job of piecing together these otherwise separate domains. Each practitioner represents a specific sphere of influence, but this again is constantly changing in and outside the context of work.

Conference settings allow for ‘change’ conversations to happen between experts, practitioners of varying levels, students, and casual observers. It is during these moments that we collectively work out our perspectives, beliefs, and approaches as a community.

As with all new industries, the main challenge isn’t about solving problems from what we already know as a community, but about how to tackle issues from what we collectively don’t know.

You can only get this kind of thing by working it out with other practitioners, and conferences are great places to do that.

Engaging with the wider conversation

There is a tendency of assuming something had been codified after it has been published in some form or practiced more widely – the more popular, the more ‘permanent’ its effects. It’s far better to understand the wider conversation that is taking place between influencers, and the work that goes on between them.

At DIBI, speakers like Inayaili de León, Jeremy Keith, Faruk Ates and Jeffrey Zeldman all made references to the history and progression of digital (publishing, web, devices, teams…) to establish the context in which we *ought* to think about digital. So although they each delivered different talks, their overall message was the same – that the web has now matured and a huge re-thinking is in order.

Missing the wider conversation is really about missing the plot entirely, because the wider conversation (in the case of DIBI) explains why we had the web in the first place, how it has become what it is today, and where is it trying to get to. Skip that, and all you get is a dumbed down instruction book on how to code HTML5. That’s not what you come to a conference for.

Understanding UX across horizons

Conferences like UX Hong Kong and UX Lisbon are great for meeting an international crowd. Everyone has a different story to tell about how they got into UX and it varies per country, locale and city.

I think this is important since we’re increasingly designing for a far wider audience now. This isn’t just about solving design problems, but also about how clients in different countries perceive the value of UX, and how designers adapt their practices to the local culture and market demands.

This challenges us to rethink our own approaches – are our designs really fit for purpose? Is there such a thing as a universal design language? How do we ensure that we communicate design effectively across borders and cultures?

Being human

Conferences shouldn’t feel sterile and mechanical but it occasionally does. No one’s really at fault but it does take a lot of empathy, hospitality, encouragement, patience and candidness for attendees to feel welcome and in good spirits.

By all means, organizers should consider hygiene aspects such as the registration process and fun stuff like the schwag bag, but I think it comes down to the fact that practitioners are making a sacrifice to be with other practitioners, regardless of rank, background, specialism, principle or agenda.

Plus, I try to stick to conferences that allow me to be myself. And I suppose this is self-selecting that certain conferences tend to attract a certain crowd, but it’s better when people get along.

So, yes – I feel there are good reasons to be a conference junkie – however I think setting the right expectations, picturing the broader context, preparing to meet people, and a dose of humility and empathy can make a big difference in the conference experience and how one is ultimately enriched from it.

There’s a really vibrant UX community here in London, with a diverse range of activities and groups such as book clubs, talks, field trips, mentorship programs and the like. But there’s one type of meetup I’ve particularly gained a lot from, called Start UX.

About a year ago, Joe Lanman had an idea to gather a few people who weren’t officially UX designers but were trying to build it into their work and organizations. At the time, I was working at a startup and I was doing everything from user research all the way to the production code. One of the group’s first members, Jeff van Campen, got me into Start UX along with a few others – Francis Norton, Nick Smith, Rob Enslin, and Basheera Khan, who were all interested in getting UX into organizations and influencing change.

We’ve been meeting informally since then to talk about our experiences (war stories) about getting UX into our work and organizations. I’ve been extremely grateful to have these friends to share with, bounce ideas off, and rant to whenever I needed an outlet, some help or support, even another perspective.

The benefit of having a group of people like this isn’t just about learning from each other, but about challenging each other to do what’s worth doing. It’s like peer-coaching.

A year has passed since Start UX first got off the ground, and even though some of us have moved on to dedicated UX roles, the journey still continues and the relationships have grown more mature and valuable. So, I think the spirit of Start UX is about challenging, encouraging, learning from, and growing with one another – like apprentices in a guild.

I highly encourage other practitioners to start their own version of Start UX. If you’re interested in starting one, here are some loose guidelines that may be useful to you and your group:

• keep the group to about 10-12 people, with each meeting made up of about 5-7 people (not everyone will make it at all times) – this keeps the group more intimate and allow for better sharing and social cohesion
• keep to the same group members, so that the members will really get to know each other and each member’s issues over time
• use google groups or something similar to facilitate discussion online, plan meetups, etc.
• for the meetup: find a spot that’s conducive for discussion, has enough room to support a meeting space, and refreshments
• choosing a meeting topic can help scope discussions (e.g. we had a meeting about deliverables once)

Also, make sure to share it with the wider community. That’s one thing our group has failed to do, but that’s going to change –  starting with this blog post. :)

Jared Spool does it again.

He explains how two important aspects that are key to successful design teams:

• Direct exposure to user observation of team members for at least 2 hours in six weeks

Each team member has to be exposed directly to the users themselves. Teams that have dedicated user research professionals, who watch the users, then in turn, report the results through documents or videos, don’t deliver the same benefits. It’s from the direct exposure to the users that we see the improvements in the design.

• Involvement of strong influencers (execs, project managers, etc.) in direct observation of users

The tipping point came when we found teams where all these other folks were participating in the user research studies. No longer did they assert their own opinions of the design direction above what the research findings were telling the teams. Having the execs, stakeholders, and other non-design folks part of the exposure program produced a more user-focused process overall.

The question is – will we be willing to sacrifice invest in order to ensure this happens to make our designs more successful? It’s a common occurrence everywhere, and we as designers need to stand our ground.

When I was studying the HCI course at UCL, we had a module known as “Design Tools and Techniques” (it’s now been changed/modified to “Design Practice”), which provided an overview of design that looked like this:

1. The Design Problem
2. Requirements, Scenarios & Task Analysis
3. Prototyping
4. Sketching
5. Design Judgements
6. Visual Design
7. Visual Communication
8. Interfaces
9. Personas

If you’re from a design background, you’re probably looking at this and going… WTF? Task Analysis? Interfaces? Personas? What does that have anything to do with design?

The graphic design course outline from Central St. Martins makes a bit more sense. I wish we had learnt more about sketching as a thinking tool (not as a drawing tool), about exploration in creative problem solving, about the various modes of working (individual vs. collaborative), about the different ways other designers produced their work as well as the various graphic design areas (photography, typography/letterpress, print, animation, etc.).

However, I actually think that the module hasn’t done much damage. I still see a lot of UX designers use patterns, tools, and processes as a starting point – when we should only be considering those when we’ve fully understood the fundamentals. I sometimes wish we could have sessions where we deconstruct the patterns, tools and processes we’re so used to – just to get at the essence of creative problem solving.

While I don’t discount the value I’ve gained from learning about cognition, affect, organizational psychology, ergonomics… it’s good design that really makes all those skills truly worth something.

And while I’m giving my alma mater a hard time here, I’ve also heard criticisms about CSM being too open and exploratory. Maybe we should get UCLIC and Central St. Martins to trade students for half a year.

That would really mess things up nicely.

I have a problem in that I find it hard to do any kind of work in which I see no point in doing, and this happens a lot with UX documents. Even when I get rewarded for doing it, it’s hard for me to work on something without understanding the purpose and goal of that task in greater context.

Love/Hate Relationship with Documents

While it’s a good thing in design to think holistically and contextually about a solution, it takes up a lot of time and effort – this gets even harder without the appropriate resources to do all the work (researching, ideating, designing, testing, communicating). Spending time “figuring out” a document isn’t really a UX thing, but happens because sometimes I get to the point where I’ve worked my ideas around a design and I need to produce something for it.

So now a large part of my work now involves producing documents. In my previous life as a developer, I did very little of that – mainly because software tends to exemplify the essence of the product/goal, so I didn’t have to explain myself much – the software did all the talking for me. But now, I work in the realm of ideas – and software doesn’t always do a good job of communicating ideas.

UX Documents are Strategy: Influence Decision-Making

I’m quite happy to work with any document, but at some point in time those documents will end up being outdated because they would have served a specific purpose, audience, and time. So, I don’t want to waste a time if I can avoid it. Also, in terms of the kind of business we’re in, the document itself isn’t really the goal – it’s about strategy – a means to make decisions about the final product or service.

But what does that really mean? How do you write a document that helps someone make a decision about a product/service instead of just some mumbo-jumbo wishy-washy fancy-pants thing?

What Can a UX Document Describe?

Well, the more I started thinking about it, I realized I needed to illustrate the obvious and came up with this diagram about what can (not necessary should) go into a UX document. I think the core elements of any UX document can involve:

1. users (or the empathy for)
2. the product
3. engineering or systems (the functioning of a product/service)
4. the business
5. history
6. the future (ideal, goal)
7. building and testing (execution)

The aim of any UX document is to influence the reader to have a mental model of this “overall picture”, so they can make decisions appropriately. Sometimes, they don’t need to see the whole picture, sometimes they do.

The reason we end up producing so many documents because no one document can successfully illustrate the “overall picture”. The problem I face, of course, is which document I should be working on and most importantly, why. So, I mapped Peter Morville’s list of UX deliverables to the diagram above, highlighted each document’s focus based on the seven elements I mentioned above, and ended up with this:

The matrix illustrates a document’s focus, not scope. The reason why I think it’s important to point this out is because of our tendency to start with a template (pre-scoped) and mindlessly “fill in the blanks” and ending up with goo. Understanding a document’s focus allows us to be flexible about what and what not to include in a document, as long as the document effectively communicates what it needs to. In fact, it allows us to be flexible about who the intended reader is – and often times we’re producing the documents for ourselves.

This then frees us to be rigorous about our approach to documentation because:

• we can see how the documentation illustrates the big picture
• focusing, not scoping, helps us avoid writing documents that don’t mean anything

This applies to any kind of fidelity – it doesn’t matter if you’re producing a sketch or a printed poster. The goal of documentation doesn’t change – communicate the big picture appropriately and avoid writing crap.