> > 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
