Nothing, as long as you approach UCD (User-Centered Design) as an over-arching philosophy and general framework for considering people in the design of a product, in addition to all the other concerns. Held lightly in the mind as a “mode of thought”, UCD can be very useful in helping those who are engineering-centric or accounting-driven to broaden their perspectives and take into account other priorities and values as well as the mainstay of features and profits. In other words, the priorities of people, the actual users of the product, become a primary focus with the other critical issues. Of course, there is no one “end all, be all” UCD definition, or method, or diagram, or pledge of allegiance, or anything like that. It’s all exceptionally diverse with multiple flavors used by different companies/designers, but bound by an overall premise: people matter.
In my view, UCD is really just about taking the product’s users into account, balanced with business and technical concerns, along the lines of the rhetorical balance. Interpreted through the lens of shaping an effective argument, UCD activity should really be a deliberative process of discovering the right balance of trade-offs, constraints, priorities, and values when collaborating with product managers, engineers, marketers, and other participants in a highly complex product development process.It’s not about the primacy of one “UCD method” versus another “UCD method”, or the centrality of a specific user research deliverable over all else (much of which should be taken with many grains of salt anyway) and taken as “starter fodder” to have something to work with.
However, there is great discussion in various circles about the semantics of the term, with focus on the actual literal meaning of the specific words (e.g., user centered design) as being exclusive of business and technical concerns. It’s a fair point to argue as many do on ixda for instance…perhaps creating more confusion along the way :-) As purely a label, it just seems to me that UCD has become a de facto, commonplace, accepted phrasing used in conversations with business and technology leaders. The phrase has gained traction across the high-tech industry, design academics, new design graduates, and so forth. There’s a general gist of what’s meant by it that most people grasp well enough. That’s mainly why I have accepted the label and simply moved on; besides, I’m too busy designing to worry about what to call the damn thing :-) The bottom line is that designing something involves multiple centers regardless; the trick is how to balance them altogether…
What we need to be clear on is what UCD is NOT:
- UCD is not simply “giving what the user wants”; designers are NOT short-order cooks and most folks have no idea what they truly want (beyond vague phrases like “make it simpler, easier, intuitive, get rid of all the buttons, bigger icons, etc.”), or have difficulty expressing their desires accurately
- UCD is not a commodotized recipe for an “easy to use” design; just like any design activity, there’s iteration, fast-failure, re-visiting issues, and yes mistakes do happen!
- UCD activity and decision-making should not be ignorant of other concerns (business, technical, etc.)
- UCD is not a panacea that will fix all problems; product design problems are often way more complicated than simply “what’s best for the user”, often requiring inputs and trade-offs with various departments, teams, professionals, etc.
- UCD is not an exclusive, guaranteed approach. It is one approach to design that is best taken with several grains of salt, and perhaps better when mixed with other approaches (Activity-oriented, “Genius”-oriented, etc.)…The master designers know how to tactfully blend, which comes with years of experience of course.
What’s still perplexing for many folks is how to account for supposedly “non-UCD” successes like the iPod, iPhone, Dyson, Michael Graves collection at Target, etc. (Although you can argue that people were considered at the forefront of the designers’/engineers’ minds, just not in a regimented, exclusively method-centric fashion). Perhaps what’s needed is a better understanding of UCD thought & practice framed as just one part of a much greater (and complex) product development effort, as I suggested above… More on this soon.