There's been a huge amount of discussion in the last few years on the topic of User-centered Design (UCD). Many have been saying that it's broken and never worked, that it limits our work as designers, that it is harmful (this is really great read btw).
Harry Brignull wrote a good blog post called "Is user-centered design broken or is it us?" exploring this discussion a bit further and raising some questions. I agree that this is starting to sound a lot like the "Agile is broken" argument that has been around for years. I think that the problem stems from people needing a particular recipe for success and following it down to the letter. I've always said that the Agile Manifesto is non-negotiable, but that how you implement it is really up to you and will and should change according to the circumstances. The same is true for UCD.
UCD is fundamentally about knowing who your end-users are in great depth and detail and using that knowledge to inform your design. It's a problem solving process that requires you to check your assumptions and validate your ideas with real users. The process is basically Think - Make - Create - Evaluate (sound vaguely familiar?) At first you go for divergent thinking and bring a preferably cross-disciplinary group, with users at the heart, to convergence. It's a widely used method, and Harry ponts out, it's a process not a fairy-godmother. Amazingly successful designs do not automatically pop out the other end. Those things take a whole bunch more than just UCD or any other kind of design process.
Frankly, UCD and ACD for that matter, are just common-sense to me. I have no idea why you would want to design any other way if you have the right circumstances for those. We have all been in a scenario where our years of experience and our vast knowledge about some area will mean that we can do "Genius design" and just make the thing already. In this case, I am always 90%+ sure that it will will work because I've done it before in very similar circumstances. Of course, I'll still test. Why would I prolong the process though?
In many other circumstances, I don't know what the outcome should be, because maybe I'm designing software for Alaska crab fishermen. I have never fished or been to Alaska or met any of these kinds people. I wouldn't have the first clue what they needed. In this case UCD serves me well, and so does ACD. It never occurred to me to separate them out and use one over the other. They go hand in hand in my design at least. One inevitably leads to the other. None of the design methodologies are broken, they're just misused and misunderstood.
The biggest misunderstanding I bump into almost every week is the notion that testing with 5 users is enough. It isn't always true, in fact most of the time, it doesn't work. more on that in this post. Saying that because you tested with 5 users and got misleading results, then user testing is broken is sort of the same as saying UCD is broken because you didn't know how to use it.
Personas is another huge stumbling area. Making up personas to try to make your team more emphatic will work to some degree...one could argue that it's not empathy that you're eliciting but sympathy mind you. These Ad-hoc personas can be useful when used with great awareness of their limitations. All too often, they become law and everyone forget that they were made up. Data-driven personas on the other hand are hugely beneficial. They are the result of extensive user research, more likely than not 100's and 100's of user interviews, surveys, data points...all distilled into one persona, or a library of personas. Which way you slice the personas is really crucial. Don't slice by role, characteristic, or demographic...look for the patterns that are emerging from your research. This is the catch, you'll only be able to se them when you have enough research. Personas aren't broken because most teams don't have them, have no idea how to use them or can't see the point in investing in the research.
Those who are really great designers are amazingly creative problem solvers, and are so familiar with all the tools and methods, that they instinctively know what to use and when. They supplement that with a double whammy of experience and talent, and don't get hung up on process. In fact, they deviate all the time. They're good enough that they know how to and when to break the rules.
Are there senior designers out there using one design methodology and never diverting from it, doing the same thing every time they are confronted with a design problem? I don't know, but it sounds pretty dumb to me.
Not everything requires a hammer. If all you have is a hammer, then you better learn to use it in unconventional ways.