Some designers think User-Centered Design (UCD) is a “philosophy”—one to be developed and nurtured throughout an organization, from the ground up.

It’s not.

First, a little perspective on UCD and its friends. UCD, Activity-Centered Design (ACD), Goal-Directed Design (GDD), the unfortunately named “Genius Design” (GD), and others have many things in common, but they also have very real differences. These approaches are defined through their goals and their deliverables. Through their pros and cons. Through their areas of overlap (of which there are many). And through the ways they fit into typical development processes (Agile, for example).

All of these approaches have a common goal—to create valuable, useful, and usable (and hopefully even enjoyable) products and services for customers.

But beyond this commonality, practitioners of each approach take a different path to achieving that goal. With UCD, the design effort is, obviously, centered on users (what they need, what they want, etc). With ACD, the design effort is centered around a user’s whole activity. In GDD, the design effort is centered around a user’s goals. While these approaches have a lot of overlap, the differences are mainly in the practices and deliverables.

With UCD, a practice is to perform user research and a deliverable is a set of persona descriptions. With ACD, a practice is activity research, and a deliverable is a breakdown of the activity’s tasks, actions, and operations. And so on.

On any given project, we can mix and match practices and deliverables quite a bit, and ultimately, it really doesn’t matter to managers how success is achieved or what the approach is used or what it’s called, as long as it is successful and repeatable.

But other departments within a company have different purposes, different methods, different processes and practices and deliverables. Yes, they should still be focused on customers, but they achieve this in very different ways than a designer. The Accounting department, for example, should be very focused on customers, but it would defy logic to use UCD practices in an Accounting department.

Hence, User-Centered Design is not a philosophy. It’s an action. It’s an approach.

So what is the organization-wide philosophy to be developed and nurtured?

“Focus on the customer”.

Simple as that. And it doesn’t matter how you do it, as long as you do it.

There are 2 things every team can do right now to improve their chances of producing great results.

1. Designate a design dictator.

We all know that design-by-committee leads to subpar results. “Building consensus”, as many designers so eloquently put it, is just another way of saying that the team is willing to make and accept inferior decisions. Consensus is the death of greatness.

To fight against this, find your leader, give her the power to make final decisions, and then surround her by a team and make her use it.

Behavioral psychology research has shown that the leaders who achieve the best results are the ones who involve their teams in their decisions. In fact, teams produce better results than even the best problem-solver can produce working alone.

When a leader goes to a team for discussion, a wider range of expertise, insight, and effort is in place, and more people are available to perform tasks. A person doing this alone has to perform all the tasks sequentially, and must rely only on her own knowledge and insights.

Teams generate more ideas, and enable the best ideas to bubble up to the top, but good leadership is vital to bringing those ideas to life. Give one person the authority to make the final decision, and make sure that person considers the ideas and insights of the other team members when making it.

2. Designate a Devil’s Advocate.

When like-minded people get in a room together, they tend to have like-minded ideas. But very often, the best way to validate decisions is to have them challenged.

For each project, put someone in place to do exactly that. Simply by questioning decisions and presenting opposing viewpoints, the Devil’s Advocate (or “DA”) can help the team validate ideas, or push the team to find better ones.

When a decision is bad, the DA can cause the team to recognize problems and come up with new ideas. Even when a decision is the correct one, a DA can point out something no one thought about and prevent an impending mistake.

Any team can implement these two ideas without spending a dime, and all the teams who do can expect better results than even the best problem-solver can achieve on his own.

Yesterday, Jared Spool (UIE) posted a fantastic article about the subtleties of interaction design. And he was dead on.

Great interaction design isn’t just about task flows, features sets, and layouts. It’s about all those tiny details that make each and every interaction understandable and (hopefully) enjoyable. These are the things that lead to a great user experience.

In any given moment, a user’s goals can change. One moment can be about determining the purpose of a site and getting oriented. The next can be about learning more via a screencast. The next can be about signing up. And so on.

I’ve always thought about these moments, and these micro-level goals that affect how a person moves through an application. And I’ve always tried to design each moment to the best of my ability.

In case you missed it, my new book, Designing the Moment, was released about a month or so ago. It’s a collection of 31 stories from real design projects that illustrate how to think through each one of these moments and design for them.

Learn more about it here, or pick up your own copy. I hope you enjoy it.

User research is held up by many as the almighty method for uncovering user needs and the undeniable path to great user experiences.

This, of course, is a crock.

Here are a few of the justifications I’ve heard, and my responses.

1. It’s been argued that user research is not a cost—it’s an investment.

Let’s rephrase that.

Designing a high quality experience for a valuable product, regardless of how you achieve it, is an investment. User research by itself is a cost. If it’s a cost that contributes to the high quality user experience, then it might be worth doing, but it often doesn’t. In fact, it can have a negative affect on the user experience for people outside the researched audience (let’s call them “lost customers”), and even those within it.

2. It’s also been argued that user research leads directly to opportunities for differentiation within a market.

I agree with this, but there are other ways to achieve the same result. Focusing on the activity an application is meant to support (instead of a specific audience), for example, can lead to great insights about new ways to perform the activity, and these insights can provide plenty of market differentiation.

User research is one way to achieve market differentiation, not the only way.

3. It’s been argued that user research can expose features that users do not have an interest in, thereby weeding out the bad stuff and avoiding the fall of a market leader in the face of a clever start-up.

To this I ask: how is it that startups, who typically have no time or money for user research, are able to create products so great that they take over the lead market position in the first place?

4. Finally, it’s been argued that it’s “cheap and easy” to simply discard the past to move forward.

Of course, this argument also falls short.

“The past” is filled with far more examples of products, innovative thinking, and success stories based on activity-centered research, magic, genius, and just plain luck than User-Centered Design can claim even on its best day. UCD is only about 30 years old. “The past” is much, much older.

What’s cheap and easy is the idea that we can dissect a chef’s work and call it a recipe. That we can simply analyze genius and come out with a one-size-fits-all plan for success.

Truth is, you can’t reproduce genius. You can standardize methods in an attempt to help designers achieve good design more consistently, but standardization can mean blocking out the possibility of genius. Too many companies rely on process, on data, on facts and studies and research, and end up with a mistrust of any recommendation not backed up by these things. But a good designer can make a great guess without any of these things, based on experience, skill, knowledge, and talent. Rigid processes don’t account for this possibility.

There’s an old saying that it can be difficult for a man to understand something when his job depends on his not understanding it. It seems many people holding up user research as Divine Truth think their jobs depend on it.

What their jobs actually depend on is the ability to design successful solutions and strategies, no matter how they are achieved.

Perhaps looking for new ways to rise to the challenge is a better response than shutting out any possibility not in line with previous experience.

The question came up again this morning. What’s wrong with the practices normally associated with User-Centered Design (UCD)?

Here’s a list.

• User research is horribly unreliable, either because it’s done poorly, not done to a great enough extent, or focused on the wrong people.
• Focusing on niche groups can mean alienating audiences that could otherwise use the product but weren’t part of the research.
• User research can be horribly expensive and time-consuming, and I have yet to work for or with a web company who was willing to devote an appropriate amount of time to it. Companies with industrial products might be different (Apple is a notable exception, of course), but on the web, things move fast. Since the ability to iterate is built into the web, it makes far more sense, financially, to iterate continually rather than put great effort into research prior to the start of a project.
• User research, as it’s typically done, results in a set of persona descriptions, which are, well, less than useful as project deliverables. Managers care about results. Numbers. They want to see progress, not fictitious character descriptions. They hired you to design, not write movie scripts.
• Far too many people seem to think you have to perform all new, application-specific research any time they start work on a new product.
• Reliance on UCD methods can lead managers to mistrust a designer’s instincts, and instincts are a huge part of design. I’ve seen managers on many occasions ask for all sorts of research-based validation on things that should not need it at all—the usability of a design pattern, the validity of a task flow decision, etc. It discounts the designer’s experience, skill, knowledge, and talent. It turns designers into scientists, and designers don’t make for very good scientists.

I could go on. (In fact, I wrote a series on an alternative for Peachpit.com.)

Even those who often advocate the practices included within UCD freely admit that, most of the time, these things are done wrong and done poorly.

To clear up a misconception, none of this means a non-UCD designer has no understanding of human behavior on the web, or that he blatantly discounts the importance of understanding it. I personally have sat through countless hours of usability tests, study psychology in my spare time, constantly engage in conversations with people about their computing experiences, etc. I couldn’t do my job without a great understanding of people. I just believe it’s far better to focus on activities rather than people.

Yes, this can mean talking to people who perform the activities you’re designing to support, but in many cases, you can become a Subject Matter Expert on an activity without ever talking to another person—particularly when designing web apps.

No method is perfect, but in my experience, UCD has far too many flaws to come even close. And considering there are so many great apps out there designed and built without an ounce of app-specific user research, it’s safe to say you can indeed create something wonderful by throwing traditional UCD methods entirely out the window.