What is this thing you call UCD?

UCD

Whenever arguments about User Centred Design (UCD) get started, in my experience, it’s due to a lack of definition. What is UCD? What do you actually need to *do* to be able to claim that you’ve used a UCD process or philosophy or methodology?

Good question.

I borrowed the diagram about from the Flow website. It’s not very pretty, but it does outline the general process that a UCD flavoured project will take.

Now… you don’t need to do every one of the activities listed here in order to be ‘UCD Compliant’, but you will need to take user input at each one of the points shown in this diagram – Research, Concept, Design, Implementation and Launch.

That is pretty much what defines a UCD project – it involves *real* people who are actual or potential users of your product, and it involves people at each of these points, allowing you to check and iterate your design at each stage of the project.

Let’s examine a few scenarios:

I do user centred design, I think about users all the time when I design.

This is not UCD. Thinking about users is very different to actually meeting them, talking to them, watching them interact with your product, or exist in the space for which your product is designed. UCD is more than just thinking about users.

I am a talented designer, and I know this domain. I don’t need to use a UCD process. I can make a good guess about what the right design is and then test that design, rather than doing all that research at the beginning.

This is frequently UCD in disguise. You see, you *can* re-use your research from project to project. If you are are designer who knows all about a particular client, or design problem, or subject area, or type of product this is very often because you’ve been through the UCD process to acquire that knowledge in the first place.

I don’t have time for all this UCD malarchy. It takes too long.

One of the great things about the UCD methodology is that it can ‘squeeze to fit’. You don’t need to do all the exercises for each step. You can improvise each activity to fit the resources, time, budget that you have available for the project. UCD gurus including Jakob Nielsen and Deborah Mayhew both advocate getting as much as you can from each step, using the methods and means most appropriate to the project.

But, don’t throw out any of the steps. That way trouble lies.

All lifecycle tasks will always apply, but they can be expanded and contracted depending on the requirements, characteristics, and resources of a particular project.

Deborah Mayhew, The Usability Engineering Lifecycle.

So, when I’m talking about User Centred Design (and, in particular, asking for reasons why people might not choose to use it) … that’s what I’m talking about.

How’s that fit with your idea of UCD? About right? Any objections?

Chatting with Bill Moggridge – Part Two – What Interaction Designers can learn from games

Microphone Man

Here’s the second part of my chat with Bill Moggridge.

You might remember that I was lucky enough to have the chance to talk with him about his new book, Designing Interactions and that he was happy for me to record the chat and share it with you. Here’s Part One in case you missed it! (update: you can get part three here too!)

As you can see from my microphone stand pictured above, I am a very professional correspondent and go to any length to ensure good sound quality.

(Clearly this is a blatant lie… I’m working on it!)

Anyway – in this second part of the chat we spend some time talking about designing games and what interactions can learn from games design. Interesting stuff.

(Duration: 5.49)

IA Summit 2007 – Where does IA fit in the design process?

IA Summit Logo

One of the great things about being in this hemisphere is that it makes it all the more easy for me to get to some of the conferences I’ve been dying to get to for ages. March this year is going to be very exciting because I’m going to both SXSW and the IA Summit.

Anyone else heading in that direction? I’m looking forward to putting some faces to some names!

I’m also very excited to be participating in a panel at the IA Summit. Chaired (and organised) by Peter Boersma, and featuring amazing people like Peter Merholz, Livia Labate, Larisa Warnke and Josh Seiden (and me!), we’re going to be discussing where in the design process information architecture fits.

Some of the questions that Peter says he’s going to ask include:

  • When should IAs be part of a design team?
  • How do IAs work together with other design team members?
  • How do you communicate your design process to clients?
  • How do you measure improvements in your design process?

 I have a few opinions… but I’d be really interested to hear how you’d field these ones!

 

why bother calling if you call so late?

Don’t get me wrong… it’s not that I don’t want to work with you. I’d love nothing more to help make sure that your design is great and people love to use your product.

It’s just…  by the time you get to the part in your project plan that says ‘Usability Testing’, there’s not much I can do. You’ve left things too late.

Sure, I know. That’s when you do the usability testing, isn’t it? In that mad rush when you’re trying to get everything coded up and launched. I know, because it usually means that we don’t get much time to do the testing, and it’s usually not with the finished product.

And, you know… that probably would be ok, if we’d have done some testing earlier on in the piece.

OK, so you might not call it testing. You might call it research. Or you might just call it putting some ideas in front of people who might be using your product in the future and seeing what they think.

No, we don’t need your finished product before we can test. Not at all. We’ve tested with scraps of paper in the past and discovered we were heading down the wrong path altogether. We’ve learned a LOT about how our design should work even with some ugly wireframes.

And the great thing is that scraps of paper and wireframes cost nothing… compared to the amount you’ve invested in getting to the ‘Usability Testing’ line item on the project plan.

Compared to the amount you’ll probably have to spend if you want to implement any of the things we’ll probably learn if we do that testing now.

Of course… between you and I…. we know that’s probably not going to happen anyway, is it. There’s no time for changes. There’s a launch date fast approaching, and hardly enough time to finish the work you have already.

We’re just ticking a box here, aren’t we. With the best of intentions.

It’s a shame tho’. We could have been a good team.

We could have got to a kick butt design, one that we *knew* would work. We could have stopped all this coding and re-coding. We could have had good strong answers to questions that the business was asking. We could have taken so much of the guesswork out of it.

We could have been launching this thing with out the sneaking suspicion we’d be back at the drawing board (literally) in the very near future.

But I’ll tell you what I’ve found, and you tell me that you don’t have time to do anything about it.

And hopefully, next time, we can work together from the beginning.

I think that would be a much better idea.