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?
I borrowed the diagram about from the
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?