I had a ‘we can afford to try it anyway’ recently.

Build it and they will come!

I imagine that ‘lack of UCD professional on the team’ would be a hinderance to trying UCD.

Good point Derrick.

Some others that I see often are:

a) we don’t have time for UCD, and
b) we don’t have budget for UCD, and
c) the design is already done a.k.a. it’s just a reskin

Anyone got other reasons?

From business sponsors: “We KNOW what the users want.” with an implied “So, why do YOU need to talk to them, pipsqueak. Just DESIGN, already!”

I was recently exposed to clients who lack exposure or understanding of the usefulness of usability and feel like its a waste of time since the deliverables are not “pretty” or easy for them to understand.

@ Joan - yes, that’s a good one! Reminds me of another one I’ve heard many times over the years..

“that’s why I’m paying you, the design expert. You should *know* the right way to design it”

Another one for me has been an almost manic need to ‘validate’ decisions driven by more qualitative UCD research quantitatively somehow. They won’t believe you without tables of data, usually from marketing which is so baked its meaningless anyway. Have found some ways to deal though . . .

I’ve heard “Apple are famous for never doing user testing and they’re really successful”…

It was said tongue in cheek though.

I get the sense that you’re looking for specious reasons why you wouldn’t use UCD for a project, but there are some honest alternatives. Don Norman’s Activity Centered Design (ACD) stands out as a possibility if the domain is already well known for instance. Dan Saffer mentions a few other alternatives in his book “Designing for Interaction.”

1. Lack of faith in the design team’s ability to understand the user. Hate to say it but some companies view designers as “pretty-makers” and developers as cogs in the machine.
2. When the client is always right, and the client doesn’t empathize with the user or care to empathize with the user.
3. Proven track record of success with non-UCD product development strategies. Sometimes it’s just better to build something, test it live and then make changes than it is to sit around and talk about it.

Note: the opinions in this comment don’t necessarily reflect those of the author.

One I’ve heard a lot is, “we’re already doing User Centered Design, we have a focus group scheduled for next Tuesday”
There’s not a very good understanding of the process and that may be the fault of too much bickering in the academic community. After all, why should a company take a chance on an untried method when the practitioners themselves can’t even agree on what names to call their methodology.
See Alan Cooper’s “The Inmates are Running the Asylum” for reasons why companies resist.
As for Apple and their Genius Design, there’s something to be said for that. Not to many Steve Jobs in the halls of power. Had someone from Apple usabilty group give a lecture last year and she ruefully admitted that they could do with some more testing. That said, what I hear from the folks at places like Google is a team of very different skill sets thrown together in the same space with the freedom to try things and experiment works fairly well.
Sometimes I think we get too hung up on trying to find the single system that solves all problems.
I’ve spent many years in the print and advertising design field fighting much the same battle. The jargon was different but the problem always seems to come down to decision makers not having enough knowledge or information to actually make a decision, but not wanting to look too stupid.
It’s a rare manager that has enough condfidence in himself and the people who work for hm to let them get on with their jobs

I think there are two categories of responses to your question, one is ‘don’t know better’ and the other is ‘negative perception’.

‘Don’t know better’ is simple - it’s just ignorance about the benefits of activelly involving users throughout the process. When that’s the case, it’s fairly straightforward to introduce UCD approaches. You just need to know how these work and the context of their applicability and expose that to the powers that be. If it makes business sense, nobody will say no. Unless they fall on the second category:

‘Negative perception’ stems from either past personal experience or experiences and comments from friends or coleagues. The reasons are numerous:

* project went longer than planned because recruiting, testing, analysis, reporting or something else was slow. The problem is not UCD, it’s bad project management.

* project went over budget because there were hidden costs (participant incentives, logistics, etc). The problem is not UCD, it’s bad project management.

* project outcome was subpar because the wrong people were conducting user testing, facilitating user interaction, gathering user input, translating findings, etc, etc, etc. Like anything else, the quality of the input affects the quality of the output. The problem is not UCD, it’s incompetent or inadequate people doing the work.

* project team interaction sucked throughout the process because they didn’t understand the process or how involving users would benefit the project (see category one). The problem is not UCD, it’s that force-feeding UCD is like force-feeding anything, makes you want to throw up - and when you’re sick you get cranky…

Other than these, it’s generally some variation of people bitching about one of these variables.

On the second bullet, I meant bad management overall, bad planning skills and inability to adjust as things move along.

- No (immediate) users.
If you’re designing an API, the definitions that allow one piece of software to talk to another, code efficiency, speed, reliability and testability may overrule any concerns users may have. Of course there are hidden users anyway (the programmers that need to use the code), one of the reasons why the Python language (http://www.python.org/) is so popular; it can be fun(!) to read the code sometimes.

I know they think this… “I’m not really a very good designer and I’m protecting my ego”.

Or…

“We do that kinda already and why would we give you some of the budget that’s already been allocated to us anyway!”

People from tech division have argumented heavily, that it doesn’t really matter how well You design and test it because people learn to use it after a while.

I gave an example of how we are used to look after switcher of lights near the door of the room. Tech people thought it can as well be on the other side of the room because people know it’s there after searching it a couple of times.

Umh… right… see you!

Because the project is a marketing/branding device and “use” is not an objective.

Because the usability challenges of the product are easy and obvious.

(These are, in fact, reasonings I’ve agreed with, not rationales I “have to refute”.)

Such a good question and thanks for asking it, Leisa. The answer I’m gonna give is empirical rather than catagorical, meaning it’s something I’ve observed in practice rather than something I believe is inherent to UCD.

Design jobs are typically commissioned by communications and marketing people, who fundamentally believe in style over substance. They’re taught to believe people will buy a bad bargain if the sales pitch presses the right emotional buttons; and it’s necessary self-deception, given how little input and control they have in the design and delivery of the end product.

They replicate this dynamic in projects over which they do have total control — such as website design. User-centred design makes them uneasy, because its ‘trust users’ message contradicts that fundamental tenet of their practice, ‘users are stupid’.

Google Analytics has been a revolution for me, because it speaks in marketing language (viz: ‘conversions’, rather than ’satisfied users’) and compelling visualisations like the heatmap (viz: nobody’s clicking the ‘products’ and ’services’ sub-menus; maybe those should be front-page items?). In the reports section, it’s telling to see what reports Google thinks a Marketer wants to see, as compared to a Webdesigner.

These days I’m inclined to give the client what she or he wants, subject to the gentle but firm invitation to take another look at the project in six months’ time, using Google Analytics and the site to illustrate the importance and impact of integrating user-centred design. How does all that sound?

I would take Livia’s “don’t know better” one step further.

I think there’s a divide between people who are trained to look for an answer (The answer to “what can/should the system do?” is an answer) and people who are trained to look for a question (The answer to “what do the users need / desire?” is a question).

The management and technical people tend to revert away from UCD whenever a possible solution is mentioned, even when the context is a search for the right questions.

It’s only through patient follow-up discussions that it becomes possible to change this mindset, one small working team at a time.

thanks everyone - this is a fabulous set of responses. Just to be clear, I’m not only looking for ‘bad’ reasons (although, by specifically asking for reasons that you have to refute, I can understand that I may have implied that). There are potentially valid reasons for taking a UCD approach with a project.

I have a bunch of other ideas that I’ve received via email that I’ll share with you soon.. and then I’m going to go away and have a big think about all of this and see if I can’t come back with something useful and interesting.

Submissions remain open tho’ - feel free to add more reasons why you or your client or others in chart may not use UCD approach to design.

I would say one reason would be the cost justification, many companies do not understand that conducting user experience research/UCD actually improves the bottom line rather than being an additional cost. I wrote a blog entry about this topic here: http://hcvl.hci.iastate.edu:4489/articles/2007/02/02/on-user-experience-research-budgets

UCD is one facet of a process that helps us deliver a solution i.e. a web site that links the customer needs with those of the business able to fulfil some or all of them. What is important is the output not the input. If we can translate the feature that UCD is into business benefits then companies will see the value. We need to stop focusing on the feature and the process i.e. UCD and highlight the difference between a site built on untested functionality, architecture sketched on a fag packet and trendy functionality. In the fullness of time businesses that focus on the customer and deliver against their needs will rise to the top. UCD is only as good as the people taking and interpreting the research, just because you do it doesn’t guarantee results. We would rather focus on the success of our projects and the business results.

I have spent the last three years designing interactive system as mediators of therapeutic interventions both with people affected by dementia and autistic children. I have tried to apply PD and UCD methods: I can assure you it wasn’t easy. The “therapeutic domain” is an unconventional, delicate and fragile design context that constraint not only what you can study but also how you can study it. There are theoretical, methodological, practical and ethical issues that have to be solved. I’m now trying to write my PhD thesis on it; I have the suspicion that I will never finished it.