Introduction

Over the past weekend, I took part in Barcamp London 8. There will be another blog post about the event in general in the near future, but for the moment I’m going to focus on the session I presented there, which was titled “User Experience Design – A Rough Intro”.

In true barcamp style, the presentation was more than a little “seat of the pants”. I didn’t stay overnight as I really don’t function well without sleep, so I started my second day by leaving the house a little before 8am to begin my journey to the venue. At this point, I had no clue what I was going to present. The previous day, a couple of folks had suggested they might be interested in a talk outlining what User Experience Design actually is – so I thought I’d see what I could come up with for that. So when I got on the train, I pulled out my sketchbook and started to scribble some ideas down.

 

Lo-Fi Presentation

At this point, I’m going to leap ahead a bit and mention a decision that I made later on… namely that I wasn’t going to use my laptop at all in the presentation. I’d started out carrying the laptop around on the first day, and found it to be something of a pain in the arse. It’s not a big, bulky laptop… but you still have to shift it about, power it up, put it into standby and generally fight with it. If you wanted to shake somebody’s hand whilst carrying it and a drink, you had to juggle things or find somewhere to put it down. So I decided on Sunday that I’d only get it out if I needed it. Initially, I thought I’d need it for my presentation… and I had been planning on doing some sketches, taking photos of them and then using those photos in my slides.

But then I remembered four things:

First, I hate making slides.

Second, many of the presentation rooms had “visualisers” – which are like a hi-tech version of the old overhead projectors – they’re basically a webcam that points onto an illuminated plinth so that you can put things on the plinth and have them projected onto a screen. This meant that photographing my sketches and building a presentation around them would basically be a waste of time. So the laptop stayed in my bag the whole day – and all I lost were the updates via twitter and lanyrd.

Third: When you use presentation software, you nearly always have to compromise between what you want and what it’ll let you do. You can spend hours trying to convince powerpoint to do what you want. Generally, you don’t need to spend hours trying to get your hands to do what you want – they get pretty close right away thanks to a handy neural interface.

Fourth: Wordy powerpoint is a barrier to communication. People read the screen instead of listening, and then get bored whilst they wait for the slow, boring talky man at the front to catch up with their reading.

So rather than using my sketchbook to come up with some ideas and doodles to put in my presentation… I decided that the sketches would be the presentation. They would be both my slides and my notes – sketching them was my sole preparation.

Sketch One – What is UX Design?

After a bit of fighting with the visualiser, and trying to get my sketchbook to stay open in the right places (the lo-fi equivalent of the inevitable laptop cable swapping and associated “nothing works like you expected” discoveries), I started off with the following sketch:

Sketch of things people say about UX design

When I had this up on the screen, I tried to make two main points:

First – if you ask anybody who’s not a user experience designer to explain user experience design, you’ll get a different answer.

Second – if you ask anybody who is a user experience designer to explain user experience design, you’ll probably get several different answers.

Whilst I was explaining this, I went through the responses in the sketch… so I’ll do that here too:

“Isn’t it just part of design?”

Yes. So’s pretty much everything else. Design is a word with a very broad scope. As an example, it can cover anything from designing fancy gilded patterns on the cover of a wedding photo album, through planning the underlying architecture of a piece of software to deciding how a piece of industrial machinery should be constructed to make the most efficient use of materials.

“Useless. A good web designer does it already”

A good web designer should indeed be doing it already, but it’s not necessarily their main focus, and as such they may not be able to give it the time it deserves. If they can, then that’s awesome and I don’t think you’ll see any good user experience designers complaining!

“Isn’t it just part of product management?”

As with web designers, a good product manager is indeed probably doing a certain amount of user experience design… but again, it’s not necessarily their main focus. They’ll probably be looking at what users want and need, but may well not have the time to get very heavily engaged in how those needs are actually implemented.

“Wishy Washy Nonsense!”

Sometimes it is a bit wishy washy and difficult to pin down. Other times, it’s one of the few forms of design that you can test and apply metrics to. It gets “wishy washy” around the points where you have to start doing something before you can collect data about it…

“Another name for UI design?”

This is another place where there’s a strong overlap – and if you’re working on software or a web application, it’s even stronger. But once again, there’s a slightly different focus – and one I’ll address in a bit more detail later.

“Wireframes?”

It’s quite easy to mistake the outcome of a process for the process itself, and this is a common one. Wireframes are a tool that user experience designers can use to convey ideas to others – but they’re usually a tool that comes quite late in the process. A lot of the time, they’re the first contact developers have with the user experience design process… which is usually a problem, rather than a desired situation for the designer.

“An excuse to pad a CV?”

Alas, much like web design was in the late nineties and early 2000’s, user experience design has become a buzzword. The same way that anybody could say they were a web designer because MS Word had a “save as HTML” button, anybody can say they’re a user experience designer because they know a couple of buzzwords. So the field has a little bit of an image problem at the moment…

What next?

So… having made it clear that if you ask 5 user experience designers what UX design is, you’ll get at least ten answers… I embarked on explaining what user experience design is. You should, by now, understand that a lot of user experience designers will disagree with me. You should also understand that I think that’s just fine.

Sketch Two – Design is a Spectrum

Design is a spectrum - UX Design is a point on that spectrum

There a whole bunch of different forms of design, and they can all fit onto a huge spectrum. That spectrum also includes things that people would argue aren’t design at a
ll, but I’d say are at the very least related fields. The small and non-exhaustive (and not really ordered) list that I came up with for this sketch is as follows:

  • Content authoring
  • User research
  • Ergonomics & athropometrics
  • Cognitive ergonomics
  • Product design
  • Interaction design
  • Graphic design
  • UI design
  • “traditional” web design (which I rambled around a bit, but by which I essentially mean “web design where the designer doesn’t do much UX design).
  • Front end development

This lead me directly on to the next sketch…

Sketch Three – Designers, being fickle beasts, rarely tick just one box!

Circle containing many different design discipines I identify with.

For the next bit, I used myself as an example to show that anybody who considers themselves in any way a designer almost certainly covers more that one point on the design spectrum.

Some of the areas I associated with myself for this sketch were as follows:

  • Industrial design – I’m an industrial designer by training.
  • “Traditional” web design – I did a lot of this in the mid 90s.
  • Interaction design – again, I did a fair bit of this in the mid 90s, but as a distinct thing from web design – they didn’t come together for me until the late 90s/early 2000s.
  • Product design – tied quite heavily to industrial design. It was the “course next door” whilst I did my degree and we shared a lot of modules!
  • Lighting design – I’m an amateur theatre lighting designer, I run the lighting for a local comedy club and I’ve done lighting for several small gigs and events.
  • Theatrical production design – I’ve done a reasonable amount of set and prop design and construction.
  • Interactive fiction design – See many of the other posts on this blog and you’ll get an idea of what I mean!
  • Environment design – Making a physical space convey a mood. This ties in with the theatrical stuff and the interactive fiction stuff.
  • Process design – difficult to quickly pin down – basically, planning and designing ways of doing things.
  • Service design – planning how people will perceive and interact with a service you provide, understanding contact points and how things need to happen between them, etc…
  • Front-end engineering – making things actually work effectively in a user interface, web page, etc…
  • Hardware hacking – I’m an avid (if not very experienced) arduino tinkerer. I’ve also taught people to control custom hardware with software before, as well as teaching them to solder.

The point I was making is that whilst I’m a user experience designer, I also do a whole bunch of other forms of design. I’m far from alone in that – in fact, it’s my belief that anybody who says they’re a designer in just one discipline is probably misguided.

In essence, user experience designers don’t only do user experience design, and people who are not user experience designers may well still do user experience design. It comes down to where you specialise and what you self-identify as, rather than what you actually do. You might not need a user experience designer for user experience to be done… but if it’s not being done, or not being done enough, then a user experience designer means you’re getting a specialist who’ll make sure it gets the attention it needs.

Sketch 4 – Where Do They Focus?

UX design focus on area between user's life and UI, UI design focus on area between user and product backend.

Earlier I mentioned that I’d cover the often misunderstood relationship between UI design and UX design in greater detail… well here it is.

This sketch is intended to show where the two overlap and where they don’t. It comes after the previous sketch because I wanted it kept clear that we’re talking about the roles… not the people who fill them.

The idea is that there are several areas to be focussed on, which are (from left to right):

  • The user’s life, including the following parallel areas:
    • Other things in their life that they want or need to do
    • Other things that they have to spend time on
    • Other people they have to work with
  • The users, of which there are many different types (although contrary to the sketch, it is unlikely that some of them will be small dogs or will have two heads).
  • The users’ interaction with the product (or thing you are designing)
  • The product (or thing you are designing) which breaks down into the following (again, from left to right):
    • User interface
    • Logic
    • Backend (Model, database, etc…)

The Focus of UI design

User interface design focusses most heavily on the areas between the product backend and the user. UI design’s main areas of concern will generally be between the user and the user interface, but it will often need to be aware of and informed by what is going on behind the scenes.

The Focus of UX design

User experience design focusses most heavily on the areas between the product UI and the rest of the user’s life. UX design’s main areas of concern will generally on how the user interface can make the user’s life better or easier, and so it will need to be aware of an informed by the other things going on in their lives.

How do they relate?

As you can probably guess, these two overlap a lot. User experience designers are likely to also do a fair bit of user interface design, and user interface designers are likely to also do a fair bit of user experience design. That doesn’t mean the two fields are identical, just that they overlap – it’s difficult to be good at one without being at least competent at the other. Hence the confusion.

Sketch Five – UX Tools

A collection of people based and diagram based UX tools

The main reason to put this slide up wasn’t so that I could run through a selection of tools and how to use them (although I did do that), but was instead so I could say clearly that these are all tools, not the end result. Too many people seem to think that because they’ve made some personas and produced some wireframes, they’ve finished doing user experience design. Instead, what they’ve done is produce some tools to convey ideas. If those ideas don’t get followed up on, iterated and carried through effectively to the final product, then what you’ve actually done is waste some effort. The real deliverable for a user experience designer isn’t some diagrams or a report – it’s users having a good and appropriate experience with the product. Tools alone, no matter how useful, won’t achieve that – although they do make it a lot easier to get there when used effectively.

The tools I mentioned were as follows:

  • “People based” tools
    • Personas & Archetypes – These are detailed descriptions of different users you may be designing for. They’re very useful when dealing with product manag
      ers, sales, marketing and senior staff… but often too high level for developers to really sink their teeth into – they have to wade through a lot of detail that’s not immediately relevant before they find the gems that are.
    • Pragmatic Personas – I use these as a tool to bridge from the rich, detailed and high level personas (and any other info we have on users) to user stories and test cases that developers can work with. They can be much more focussed on work that’s ongoing, and provide a link between who a user is, what they need, and what the implementation implications are.
    • User interviews – How else can you get to know your users? Actually, there are other ways, but they’re always at at least one remove – using analytics, or discussions with support or sales. None are as good as actually talking to users, provided you’re aware that the user you’re talking to is a single example and may not be representative of all of them.
    • User testing & analytics – if you have something, and you want to make that something better, running it by real users and seeing how they do is a good idea.
  • Box, Arrow and Squiggle based tools
    • Card sorting – scribbling things on cards or post-it notes, then grouping them based on either predefined or emergent criteria. Very handy tool for producing other tools.
    • Information Architecture – A plan for how content or components fit together. If you’re not careful, this can turn into a rigid sitemap or heirarchy rather than a flexible plan or scheme which will allow for future growth to fit in, resulting in that growth being bolted on to the side or crammed in where it doesn’t really fit.
    • User flows – these are a staple of interaction design, detailing the steps a user should go through to achieve a goal.
    • Concept models – sometimes you need to explain an idea in some detail, and you need other people working on your project to really be able to understand that idea so they can keep calling back to it. Concept models can help with that. (example 1, example 2)
    • More sketches than are probably healthy – if you think of something, sketch it. Seriously. Then you can expose the inner workings of your brain to other people without the need for surgery.

Sketch Six – UX Culture

Various people in an organisation, and the kinds of conversations they might have with a UX designer

The most useful thing for any UX designer is to not be the only person involved in and responsible for the user experience. They might be the only person who focusses on it entirely, but they need a lot of other people to be thinking about it as well. They need to be bouncing their ideas and thoughts off everyone else in an organisation, getting feedback from them. Even more importantly, they need to be making sure that people from different parts of the organisation talk to each other about the user experience.

Whilst the ultimate ideal of user experience design is to have the user experience be the sole concern, reality does have this habit of intruding. Release dates, budgets, implementation concerns, sales and marketing issues,etc… do all exist, and when it comes down to it they are often important – without them the product you’re making might never see market. If users never experience your product, you can’t really call it a successful user experience.

The best situation to be in is one where everyone working on the project is able to raise concerns about the user experience, or the work that maintaining it will entail. If a developer says that what the UX designer is asking for is too expensive, there needs to be a conversation between the product manager, the development team and the user experience person to determine if a compromise can be reached, or if a partial implementation is good enough in this release, with an improved implementation in the next release.

What is most important is that everyone is able to understand how decisions can affect the user experience, and how user experience decisions can affect everything else. With a dedicated user experience designer, you have somebody who’s job it is to make sure those implications are clear and understood, and to facilitate discussions around them so that the people who make the final call can do so in an informed manner.