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 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?
5 thoughts on “What is this thing you call UCD?”
I’m still digesting the diagram but I wanted to comment on the word ‘malarchy’ — I’m guessing you mean the Irish word ‘malarky’, but on Greek & Latin roots, ‘malarchy’ would mean ‘wrong building’ !! Lovely neologism.
Okay now to the model of UCD. Leisa, what do you think of the ‘getting real’ model proposed by 37Signals, which seems to put Launch before Implementation, getting a Beta version up for users to generate use and usability data?
I know the first scenario well. I think about users all the time, how I hate ’em, what method I’d use to torture and kill ’em. The bastards. They always screw up my designs!
Iâ€™d like to add one: â€œI showed a PowerPoint of screen captures to a room full of users and asked them how they liked it. They said to color the OK button to red.â€ That is not true UCD. User-centered does not mean let the user do the designing. User-centered means you design the product to maximize user performance. The purpose of user input as shown in the diagram is to estimate and measure user performance as you design.
Hereâ€™s another one: â€œMy modal user is a 38-year-old college-educated male IT professional with 15 years of experience with computers who hopes to be promoted to management some day.â€ Fractional credit. User attributes tell only a little about how to design to maximize user performance. Task or activity details count much more. Environmental characteristics matter too.
@ Daniel. Hrm. Perhaps I should dig out the spell checker before posting… :)
Getting Real doesn’t qualify as UCD (by my memory of the methodology… it’s probably time I re-read it), because they don’t do any work to understand who their users are and what they want up front, and although they *do* generate a lot of feedback on their products, the changes they make are still based on what they, 37 Signals, think is best – which doesn’t really equate to the most requested or most loudly requested features.
Some might argue that 37 Signals design for themselves (along the lines of the Apple argument – they only have one persona, Steve Jobs), but I tend to think that once you put your product out into the market, you can’t really run with this argument any more.
37 Signals *do* have a very thoughtful and apparently collaborative approach to their design though. The design of their products (as with Apple) is a key part of their product differentiation. I think that these are the key factors in their success. And, as you’ve mentioned, they do stay close to the people who are using the product, which would give them powerful insight into their users.
All of these things combine to make their design comparatively successful.
good point Michael. It’s not uncommon for people to mistake asking users what colour or where to put things and calling that user centred design.
I don’t like to quote Jakob Nielson too often, but he does have a great response to this one. He says:
‘To design an easy-to-use interface, pay attention to what users do, not what they say. Self-reported claims are unreliable, as are user speculations about future behaviour’.
One thing I’d add to what you’re saying though is that even user performance isn’t quite enough (in my opinion). Maximising and improving the overall user experience is what I think UCD is all about. Performance is certainly part of experience, but there are lots of other more ‘touchy feely’ aspects to experience that I think are really important to product success in the long run.
Comments are closed.