What is this thing you call 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?

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.


Give me one good reason you can’t use User Centred Design in your project… Submissions Open!

I’m collecting reasons that you’ve heard or used as to why you can’t use a proper UCD (User Centred Design) methodology in your project.

Not just ‘yeah, I think about users when I’m doing the design’, but actually involving *real* users in your design process. Doing a proper UCD methodology.

How do you rationalise using UCD in your projects?

How have you heard other people rationalise it?

If you’re a UCD consultant, what reasons do you come up against and have to refute regularly?

Let me have ‘em.

Information Architecture is in the DNA of Design (On Evolving not Dying)

Rumours of the impending death of Information Architecture have been greatly exaggerated, but I think it is true that the Information Architect you were five years ago is very different to what you’ll be in five years time. (In fact, it’s probably very different already).

These rumours seem to have been kicked off by ‘important people in IA’ seemingly rejecting the IA community by moving onto other things – starting a new company, being interested in things that occur off the screen, finding themselves doing more Interaction Design than IA, or more strategic business thinking than sitemapping.

These are important symptoms, but they’re not fatal. It’s more about metamorphosis, adaptation, evolution. And that’s exciting (and just a little scary, sometimes).

As I see it, there are three important trends impacting on Information Architecture practice today – the content and categories we work with, our relationship with our ‘audience’, and our work practices.

Technological empowerment has meant that our audience are now active producers of content and rather than trying to ‘hide’ inactive content, our biggest challenge is often to manage the incoming surge of content in all it’s formats.

We’ve moved beyond just text and images – now audio and video are commonplace content formats for IAs to address.

The rise of search has meant that traditional site structures have become far less relevant to findability, and metadata (in its various forms) is more important than ever.

The semantic web is awakening and wondering what role we’ll play in it’s destiny.

Location, physical space, is becoming a key factor in understanding and defining content more and more often.

Our audiences are actively involved in IA, labelling, categorising, creating content.

Information Architecture is becoming more interactive and dynamic than ever before. Many of the more ‘static’ tools are no longer as useful as they were before. New and different tools are being borrowed from different disciplines, evolved from older tools and methods.

Teams are becoming more cross skilled and agile. A ‘pure’ IA project is becoming rarer. IAs are becoming more involved in strategic decision making, but they’re also getting more involved in interaction design as Rich Internet Applications become more and more prevalent.

The diagram above shows the range of tasks and ‘practices’ that people who identify as practitioners of Information Architecture can and will often cross into. With the exception of Visual Design (which I stay well clear of due to accute lack of talent), I frequently use methods which range across all of the disciplines in this diagram. Similarly, tasks and methods have to be included within multiple disciplines.

Where do Personas and Scenarios live? You can’t exclude them from IA, ID or Research, which all use them frequently. Design does not reside only with Visual Design, but in almost all of these categories in one form or another. Although Research is a discipline of it’s own, most of these disciplines will use research in one way or another to achieve their outcomes/outputs.

Information Architecture is not dying. On the contrary, it is evolving and becoming more enriched as it becomes more inclusive of the various disciplines from which it’s practitioners originate.

Certainly in five years time there may be fewer people with the job title ‘Information Architect’ (and rightly so, if we’re doing more than that), but given the vastness of content that joins the web every day now, and the opportunities and challenges of the semantic web, the need for the skills and understanding of skilled practitioners of Information Architecture are more needed now than ever.

We’ll be very different IAs in a few years time, but I for one think we’ll have a more interesting, challenging and varied role to play, and personally, I can’t wait.

What about you?

Related reading on IA’s Recent Growing Pains

Adam Greenfield: IA or not IA (Don’t miss the comments on this one!)
Christina Wodtke: Why am I so angry?
Peter Merholtz: Tribeless
Joshua Porter: Thoughts on the Impending Death of IA
David Armano: Will IA go MIA?