I don't have time for a long response, but some quick comments: It's interesting that some of the same people saying "UCD is dead" are the same ones saying they don't know what it is and are constantly trying to define it. How can it be dead if we don't know what it is? Seems like a lot of the argument is around semantics and granular definitions instead of the broad concept of what UCD is.
For me, all this simply means there is not a standard way of doing things that is alway repeatable - sometimes UCD is not the right approach and more a visionary design strategy is best. Apple, some Google products, the other products mentioned in discussions here are all examples. However, when the problem is more complex than simple text based search UI, or playing music on a device, then clearly it can be really advantageous to pick the appropriate UCD tools and techniques and use them to one's advantage. It's contextual and making blanket statements about any approach always working or not working seems unwise. You don't always have to do personas to do UCD. And UCD research doesn't have to be this monolithic gigantor of a time and money hog. You can use super cheap and lightweight methods and get great results. Industry leaders who use UCD: Salesforce.com, Autodesk, Google, Amazon.com. Cooper's products, Adaptive Path's clients and products, AA Razorfish. Those firms I believe are examples of great design, and each use some flavor of UCD, as far as I know. I don't think any method should be wholly discarded - as designers we should have a big 'ole toolbox of approaches, and know when and why to use certain ones. UCD is not broken in my opinion. Just my two cents. Great discussions here recently. Jeff On Tue, Jun 24, 2008 at 9:50 AM, Robert Hoekman Jr <[EMAIL PROTECTED]> wrote: > > > > Are there any advocates of the idea that UCD is broken out there that can > > clarify what they see the problem with UCD to be? > > > > I suppose that would be me. > > UCD is filled with problems. 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, > app-specific research any time you 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. > > Even those who often advocate the practices included within UCD, such as > Jared/UIE (who researched the best web teams to see what they have in > common), fully admit that most of the time these things are done wrong, and > done poorly. > > Usability testing has flaws as well, but should still definitely be done > when it makes sense. > > For the record, none of this means a non-UCD designer has no understanding > of human behavior on the web. I've personally sat through hundreds of hours > of usability tests, study psychology in my spare time, constantly engage in > conversations with people about their computing experiences, etc. I just > think that 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 SME on an > activity > without ever talking to another person—particularly when designing web > apps. > > >From there, I rely heavily on metrics—click paths, click stats, > etc.—combined with an iterative design process, to determine how people are > using an app and improve upon it. > > 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, I think > it's safe to say you can indeed create something wonderful by throwing > traditional UCD methods entirely out the window. > > -r- > ________________________________________________________________ > Welcome to the Interaction Design Association (IxDA)! > To post to this list ....... [EMAIL PROTECTED] > Unsubscribe ................ http://www.ixda.org/unsubscribe > List Guidelines ............ http://www.ixda.org/guidelines > List Help .................. http://www.ixda.org/help > ________________________________________________________________ Welcome to the Interaction Design Association (IxDA)! To post to this list ....... [EMAIL PROTECTED] Unsubscribe ................ http://www.ixda.org/unsubscribe List Guidelines ............ http://www.ixda.org/guidelines List Help .................. http://www.ixda.org/help
