User-centred design

Note: I’m going to polish this later, but wanted to get the basics down quickly.

We know that we should do user research for projects. All the user-centred design material says so, we talk about it at conferences, we put it in proposals. We just know that it is a good thing to do.

But when I talk to people about their actual projects, I find that very few people actually do user research. There are many many reasons (no time, no money, already know what users need etc etc etc).

I think that part of the reason it doesn’t happen is also that we don’t have good tools to tell us just how much research to do, and even when it isn’t necessary at all to do research.

In preparing for my Edge of the Web talk, I spent time thinking about that issue, reflecting on some of the projects I’ve worked on in the past and thinking about the factors that led me to push to do research, or to go ahead without.

The factors I came up with are:

• Importance to the business: Just how important is the project/application in meeting organisational/business goals?
• Importance to users: What will happen to users if you mess up. Will they be harmed, or will they just go elsewhere?
• $$: How much is the project going to cost? (i.e. how much will be wasted if you mess up)
• Profile/politics: What sort of profile does your project have? Is there a political implication? (e.g. is the Minister going to get hauled up in Parliament if you mess up. Will your work reflect badly on your industry?)
• Convincing others: How much work will you need to do to convince other people that your ideas are good?
• Existing knowledge: How much (real) knowledge do you have about your users?
• Ability to iterate: Can you make changes quickly if you make a mistake, or is it a one-shot deal?
• Feedback: How easy is it to collect feedback from your users?

Given each of these is a continuum, we can do this:

And then we can think about our projects, and plot where we fall on the dimensions…

Example 1: A personal blog

Example 2: A conference website

Example 3: An e-commerce shopping cart

Example 4: An enterprise-wide core business application

Yet another workshop announcement…

On 7&8 August, I will be teaching a 2-day master class on information architecture and collaborative design, run via Ark Group. The thing that is slightly different about this workshop compared to my IA workshop is that, duh, it includes a lot of collaborative design.

I’m adding more material on user research, design games, usability testing and designing in teams - I don’t usually get to teach these in a one-day workshop. And 2 days allows more hands-on, practical stuff than one, and that is always good.

So if you know someone who may be interested, and can get to Sydney, please pass on the details: Information architecture and collaborative design workshop.

A couple of weeks ago I reworked the business part of my website - I had to move it to a new host and remove some content (and it really needed some polish). So I decided not only to think about re-doing the website, but to re-think what I’m doing with my business.

One of the things I needed to sort out was the types of service I offer - I want to focus narrowly enough in my area of expertise to attract clients who I suit, without looking like so much of a specialist that good people pass over me. So of course I decided to focus on design training, IA and interaction design - these are my core offering, they are what I’m good at, and what I want to be doing right now.

So I had a page on my old website about usability testing (I’m finally getting to the point of the story). I automatically brought it over and added it to my list of services. I did it because I thought it was just something that a business like mine should offer.

But when I came to write the content, and convince you why you should hire me to help you with usability testing, things started to unravel. In writing it, I realised that I actually didn’t want to offer a usability testing service.

I thought about that some and realised why I don’t want to do standalone usability testing:

1. Usability testing is easy to learn and easy to conduct. Yes, really. I’d prefer to teach a team how to do it themselves.
2. Because it is so easy, it really is silly paying my rate to do usability testing. That money would be better used teaching other people to do it.
3. Usability testing really should be an integral part of a user-centred process, and happen informally (and sometimes formally) throughout a project. For most projects, getting an outsider to do this means money, which means it isn’t done as often as possible. Guess what - I’d prefer to teach someone to do it themselves.
4. I hate providing recommendations without knowing the design context, the challenges, the constraints of a project. I have seen too many usability test results that offer dumb, shallow recommendations that aren’t actionable because of the real constraints in a project.
5. I don’t mind running a solid test and providing detailed outcomes with no recommendations; but that’s not worth me spending my time on (I’m a designer and want to design), and not worth you spending the money on.

So lots of people are going to be upset with me about that, so I will acknowledge that there are some caveats:

• Usability testing is easy, but also easy to really stuff up. But for most of the types of tests I get asked to do as a consultant (mid-cyle to pre-release basic validation testing) it is not life or death.
• If you really need to do a detailed research-style study into something, hiring a consultant can be a good investment. I’m talking about fairly shallow validation testing.
• I do believe in the value of usability testing - I’d just prefer to do it on projects where I know the design constraints and issues and where I (or my small, close team) use it to help us tweak a design.

So I now don’t offer a standalone usability testing service - and don’t feel the loss at all. But I will teach others and will test on my own projects…and I’m comfortable with that.

It’s a me too day.

Amongst many recent articles about getting rid of the word ‘user’ from our vocabulary, I liked this one from Thomas Vander Wal best. Well written and thoughtful as I expect from him.

The only thing the anti-user articles are missing is a discussion of the linguistic need to define more precisely who we are talking about. User did fill that need - it meant the person using the product. But it has become a four letter word and is often used as a derogatory term.

I have not been replacing it with ‘person’ as this is too generic and often clumsy in a sentence. I replace it with author, website visitor, reader - words that describe not who they are but what they are doing. Works for me and gives me the extra granularity I need when talking about different types of people.

I was thinking tonight about user research in projects, and how I use what I collect.

In the main, I try to get user research from as many sources as possible (interviews, surveys, card sorts, usage stats, emails etc). But I only need a small amount from each source. In doing qualitative analysis, patterns repeat themselves quickly, which means I really only need a small number of responses to inform my design decisions.

But inevitably I collect much more than I need. And the reason I do so is not because I need it to learn, but to defend design decisions. With a bigger bulk of data, I can produce some statistics, as rubbery as I know they are (I was once a statistician), to provide credibility and to support decisions in an easy way.

Based on research for my card sorting book, that’s what many of you are doing as well - trying to get a bulk of responses to convince others that you have made the right decisions. Much more so than just informing yourselves, combining it with other research and making the creative leap.

I don’t know there is an easy way out of this situation. I very occasionally flash my bio if I know this will influence people, but I always feel grubby doing it. I feel that I shouldn’t need to support my decisions with rubbery statistics, but managers don’t have time to understand the detail - statistics are the easy way out that they will believe and let me go about creating good work.

Last May, a meme hit - the musical baton. And I was hit by the meme, and I said “I’m not a big music listener, so don’t expect anything particularly interesting”

I think this was one of the most wrong predictions I could ever make. In the past 3 months, I am more often seen with earbuds in than out, can hardly work without music in the background, and was just caught staring blankly at the computer for 6 minutes while listening to Jeff Buckley’s live version of Hallelujah on pandora.

At the time I said that, I truly believed it. I really didn’t listen to much. I had a small pile of CDs collected over the last 15 years and didn’t do much with them.

What changed? I’m sure this has happened to many people, but my iPod changed my behaviour. Totally and in ways that I just would not have anticipated. I re-found music. I found a way to listen that didn’t mean I had to fuss when I left a room, and didn’t have to think before work what I might be interested in during the day. I also found cheaper music and sites with good ability to find new stuff (and an amazing podcast), which makes experimenting much less risky.

I’m a new person!

But to tie back with what I normally write about here, this is a very important issue for user research. It is a perfect illustration of the fact that humans do not know what they do and absolutely cannot predict future behaviours. User research is a good thing, but sometimes a smart leap in the dark may be better.

Ahhhhh…I’m going to burn in usability hell for that. But I’ll at least go down with great music in my ears.

Amber and I were talking about shopping today - she was telling me that she hopes there will be some kids shops where we are going this weekend. I asked her “what makes a good kids shop”, and she said:

“I don’t know, but I’ll know it when I see it”

This was so interesting to hear. It goes to the core of why a lot of our time is spent discussing (and arguing) about designs. People don’t really know what they want, and generally can’t articulate it. But they sure do know when something isn’t right for them, and when it just is.

I’m having a personal crisis about the use of personas. Here’s how it goes.

I believe in following techniques in the way they were originally intended - it helps us to communicate well, ensures that we are using techniques appropriately in our work and ensures that good techniques do not get watered down until they resemble nothing more than a proforma. Accordingly, I believe that personas are part of goal-directed design and that their strength is in being able to identify underlying goals, not in writing up a cutesy story about our users.

I also don’t believe that the core persona technique is particularly useful in information-rich environments (I do believe that it is highly applicable in interaction-rich environments). I just can’t come up with a useful set of personas for a 20,000 page website. Personal goals may describe the high level interaction with the site and its overall brand, but do little to inform content choices, groupings or navigation.

But I would like to write a short desciption of the type of people who visit a site I’m redesigning (my own!). I’d like it to describe their previous experience, their tasks and the type of information they may need for their task (more scenario-based than goal-based). I only want it to be based on my personal experiences - I’m not going to do formal user research. I just want to do this as part of a reminder to myself about why people are at the site. It sounds just like a lazy application of personas and I guess that’s why people are using them so widely.

Maybe I’ll call it ‘lazy stereotypical visitor description’. No, it needs something more catchy than that. What shall I call it?

I’ve just returned from OzCHI 2004 (which, as it sounds, is an Australian CHI conference). While I was disappointed with some of the papers (there were a number that covered quite old ground), many were interesting, and some were even quite entertaining.

Better than the papers were the people and discussions, as usual. Someone asked me at dinner “Are you talking work?” - “Hell yes”. Of course we were - client work, university work, how to combine academic and practitioner work, strange ideas, interesting projects, and much, much more.

It was great to get home to my family (and shortly to my own bed), and the 4 days of good conversation will keep me thinking for a while.

I wrote yesterday about an interesting discussion I had with about a development process that has no user involvement, and mused on how it would be possible to create a good system in a situation like this.

I had some interesting comments here, so I thought I might expand on some of my beliefs - it’s good to question your own rhetoric sometimes
Although my post implied that I thought programmers should have some involvement with users, I’d like to clarify that. I think that it is very important that programmers gain an understanding of the user group and their needs. Even if they have a good set of specifications (yeah, right) or a prototype or good design to follow, that understanding will help with many of the small decisions.

However, I do not believe that programmers should be doing the requirements gathering process or the interface design.

Now it’s not that I think that programmers can’t talk to users. I believe that programmers think in a *very* different way to the users (unless they are writing a product for other programmers, and that isn’t terribly common). Programmers are fabulous at solving problems - the cognitive capabilities to create code are similar to those that we use to solve problems. They are so fabulous at problem solving that they see a problem and think of a solution, immediately. What they aren’t so great at is seeing lots of conflicting problems, determining the underlying cause, thinking about it some more, and then designing a solution. That’s an entirely different way of thinking. Every programmer I have ever personally known collapses at this point - conflicting priorities and individual differences frustrate them to no end.

So how do I think it should be done? Requirements gathering and design are one process, not two (which I probably should elaborate on further another day), so should be done by one person (or one team in a big project). The most difficult issues for this person is then communicating the important parts of the requirements or the design to the people who are going to implement it. There are lots of documented methods, many of which I have never managed to get to work. The things that do work for me are:

• involving programmers in some representative user contact
• doing lots of sketches for people who can understand my diagrams
• lots and lots of discussions (not arguments)

Actually, on thinking about it, the thing that works best for me is respect. I show respect for the abilities of people that I work with, and they usually show respect for me. This means that we discuss ideas, problems and solutions rather than arguing about *my* design. I don’t know how you build a methodology on that!

Notes:

• I stole today’s post title from Opposable Thumbs, because it was far better than my original title
• I’m not the first to say this - many people have put it more eloquently than I
• I know lots and lots of incredibly talented programmers, and recognise that they think very differently to the way I think, so this is not an anti-programmer post

User centred design has spoiled me. I cannot conceive of how other people undertake systems design.

I was talking to a programmer today who works for a business who does business software development for a large client. Their process is that the client sends a requirements document, they go back and forth a few times to sort out some detail, and he codes the software or enhancement.

He never, ever sees a user, does not know who they are or what they do. The client has some user contact, but it is limited, and he has never spent time watching how people go about their day to day work. The requirements that are documented are very basic and never describe any more than the bare bones of what they want done.

I simply cannot imagine how this process could create anything even semi-decent. I know from my design experience that to create a good design (not even a great design), I need to understand the context. I need to know what the users already know, what they are doing at the same time as this task, what’s around them. These are the details that provide me with the information to take the magic leap and create a design that works. Without them I’d be making it all up, and there is little chance that it would be right.

Some interesting insights from a day of user research into an intranet:

• People don’t know that links are links if they look like headings. Don’t make links large, bold, blue and not underlined.
• Some people love long lists of relatively random links because they can see everything at once. Some people hate them because they are long, ungrouped and inconsistent in scope and granularity.
• People like flyout menus (despite problems with slipperiness). It is easier to scan and re-scan the items than to think about where something might be.
• You could put the names of your pets in the top level of a flyout menu - people only look at the items underneath anyway.
• People can’t remember what they tried to do that didn’t work, but they remember how it made them feel. The feeling lingers longer than the task.
• People don’t think about why something worked on one system but not another. They only know that sometimes things work and sometimes they don’t. Life is trial and error; hit and miss.

UXNet launched today. They called it a soft launch - soft so they can gain input from the field.

According to the website, UXNet is:

“an organization dedicated to exploring opportunities for cooperation and collaboration among organizations and individuals involved in the field of user experience (UX).”

Looks interesting and has the potential to offer a lot to the UX field, with our wide variety of overlapping disciplines

I was asked today to recommend 2 books that would give someone new to large site design (large organisational web/intranet as opposed to small ‘branding’ site) a good grounding in how to find out what people wanted to use the site for, how to create a usable site, and how to make sure that it would be accepted by management.

What would you recommend?

I’ll tell you what I recommended in a week…

Kevin posted an amazing comment about UCD, card sorting and IA on one of my old posts - go read it.