First off, I have to say I was surprised in the directions this thread took. Not quite what I expected, but it is certainly interesting. Thanks to everyone who is participating. It is great to get different perspectives.
On Tue, Jun 24, 2008 at 2:12 PM, Robert Hoekman Jr <[EMAIL PROTECTED]> wrote: > What makes you think I would do all this complaining without offering an > alternative? > > http://www.peachpit.com/guides/content.aspx?g=webdesign&seqNum=352 > Hi Robert, In the referenced article, you say: "Do you think Google's home page was designed for a specific set of user types?" At *An Event Apart* today, Jeffrey Veen said, essentially, yes--he didn't show personas, per se, but he did show pictures of and described target user types that sure sounded a lot like them. And in fact he said, and I quote, "weaving all that [Google apps] together took a tremendous amount of user-centered design." He mentioned lots of ethnography and anthropology. He showed a really interesting chart that very simply illustrated the reason to do user research--it is waay cheaper to change the (potential) design (i.e., narrow the design options) prior to even designing anything by doing research. He said that you do research to research the risk out of a project and provide a creative base upon which to build the product. [Sounds like Mark Schraad hit on some of the same points in this thread.] (Thanks to Jeffrey for the presentation--it was a high point of today.) I suppose we can all draw our own conclusions from this. At a minimum, it appears that UCD is going strong at Google. You mention the problem of getting unexpected user types on the Web, saying that this invalidates designing for specific types of users (personas). However, there is an adage that says you can't please everybody and that if you try to please everybody, you won't please anybody. In fact, even for the Web (with exceptions, of course), seems like most companies have an expected target audience and no doubt they're somewhere near the mark--you don't design a base camp expecting AARP members to show up and start using it en masse. I'm not really trying to change your mind, FWIW. You seem to have an approach figured out that works for you, and I think that's great. I just kind of wonder if it is necessary to lambast an approach to design that so many successful companies (mentioned by others on this thread) use in order to share what works for you in your experience. I also loved what Will said: "I think there are some great fundementals in UCD that can help make the other 999 products a little less crappy, a little more humane - and the truth of the matter is that you, me, and just about everyone on this list - makes our bread and butter by working on those 999 products." This is so painfully true, from my perspective. I think maybe the folks on this list have a skewed vision of what goes on "out there" on (dare I say) "most" <grin> software projects, i.e., most internal biz apps--not fancy Web 2 or big product shops, which are I think a very small portion of all software being built. Project failures are very high; this is a well-known fact supported by lots of research. A lot of these fail just by taking too long/costing too much, which I think is symptomatic primarily of overengineering, a lack of focus on what is actually important to users and too much focus on fancy, "reusable" architectures that attempt to put non-organic control structures on essentially organic, social problems. Of those that are completed, many are essentially loathed by users because of their terrible, terrible UIs. This is I think symptomatic of the utter and complete lack of empathy on the part of the developers who see UI as something to be slapped on at the end or, worse, auto-generated from a database and a bit of metadata. And it is reinforced by biz interests who don't understand and dismiss the value of some sort of investment in good UX. To address this, the Agile approach has been slowly but surely gaining ground over the last decade or so, and Scott Ambler has been doing research to support that it really is working to reduce project failures. The core principle of Agile is iterative refinement of a design through direct, regular interaction with the stakeholders who are, often, representatives of (if not actually) the users. I see it is a kind of UCD. There's this thing called Domain Driven Design that goes to the next level by strategically focusing dev resources on the critical domain (called core domain) and working towards a common language between the biz and devs (called the ubiquitous language) that is carried through the entire process, including into the code itself. In other words, it aims to greatly enhance communication and reduce or altogether eliminate miscommunication caused by translation between the business and dev. So far, I think it's about the best engineer-developed software design approach. The problem with Agile, even DDD, though, is that they are still not making users a first class concept of their design--they're far more concerned with abstract ideals of domain modeling, business rules, data storage and retrieval, reusability, maintainability, etc. These are all important, though, so I think figuring out a way to inject empathy for users into these has the most promise for the average biz software dev team, with a view towards shifting more into gaining a better understanding of users and their needs as well as iterative prototyping prior to building to reduce cost of change. Certainly, one thing in the article that does resonate with me is the lack of resources issue, but I think that doesn't really invalidate the philosophy, it just changes your techniques, as Charlie said. To me it makes perfect sense to adapt the level of research to the constraints of the project, but centering your design on at least some semblance of a real user is going to be better than just not thinking about the user at all or, worse, thinking of the users as annoying morons which is an unfortunate commonality among the devs who build so many business apps today and in the past. (You have seen the t-shirt that says 'select * from users where clue > 0; results - 0 rows' right? Very popular dev conceit...) Yesterday, Jeffrey Zeldman emphasized the need for empathy in design. To me, that seems to be the core of it. It matters a whole lot less how you get empathy--just get it. User research and, specifically, personas seem to be a great, common sensical, human way to get such empathy. Just spending time with real users will do wonders, as I guess everyone here knows. Dave and others suggest empathy is just common sense for those with a ID or GD background. Good for them! Unfortunately, most software isn't created by such enlightened folk, and, to be fair, I think there are plenty of GDs (at least) who are more concerned with their own artistic expression than getting empathy with users (or devs who need to build their design, for that matter). In the end, I find myself returning to, shall I say, my original hypothesis, which is that UCD is not broken. It is a toolbox of techniques and a general procedural framework for helping product creators gain empathy with their users with a view to building the right thing, the right way. The value it brings over the Genius-Centered Design (GCD [TM]) approach is that of a far greater potential for reliable, repeatable results. It's no guarantee, but it seems to make a lot more sense and show a lot more promise than the other approaches to software design. This is just my conclusion based on my experience, research, and discussions thus far (and is subject to change pending new experience, info, & reasoning). I'm not asking anyone to agree with me; I'm just throwing out my thoughts as food for thought, for what they're worth. And I appreciate that others have done the same. Thank you all again for the stimulating discussion. Now off to get some much needed shut eye! --Ambrose ________________________________________________________________ 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
