AlanCooper, highly paid consultant, sees "Interaction Design" as the solution to the business world's computer problems. ''[Subjective and biased assessment...] It's more and better than "interface design," so please don't confuse it with that. It strikes me as a form of BusinessProcessReengineering. -- JeffGrigg'' I think it may be more about developing a SystemsPersonalities. -- AlistairCockburn ----- Articles: * Official AlanCooper InteractionDesign web site: http://www.cooper.com/ * InfoWorld interview of Alan Cooper, with a brief overview of InteractionDesign ideas - http://staging.infoworld.com/articles/hn/xml/01/06/15/010615hncooper.xml?Template=/storypages/printfriendly.html * "What is Interaction Design and What Does It Mean to Information Designers?" by Craig Marion: http://www.chesco.com/~cmarion/PCD/WhatIsInteractionDesign.html * "Extreme Programming vs. Interaction Design" at Fawcette Technical Publications: http://www.fawcette.com/interviews/beck_cooper/ (See also http://groups.yahoo.com/group/extremeprogramming/message/41234) * Article in which Cooper praises the XP/Agile processes and the Craftsman mindset: http://www.fawcette.com/vsm/2002_12/online/the ---- After visiting the InteractionDesign web site, I can understand why some programmers and engineers might not be favorably disposed towards anything AlanCooper might say. But it also appears that the approach he suggests invites such reactions : he says: "The cleverest code in the world is worth nothing if a program's interface proves an unwieldy barrier to users". It is clear to me that the intention of AlanCooper is to succeed in winning the approval of the "Users". It appears that he considers the HumanMachineInterface as critical to a program's acceptance. Who would be opposed to acceptance and success? Some apparently consider that all projects and products have adopted a SuccessOrientedApproach, and that a FailureOrientedApproach doesn't exist. It depends on the point of view. The owners, designers, and market makers may consider a project or product a success because it works the way they expected it to work and delivers what they promise. On the other hand the users may not like the way the delivery takes place and the difficulty in learning how to make the delivery happen. They may consider the product or project a failure and will fail to vote it successful by expending their gold on it. Users are interested today in products that are better and easier to use than what they used yesterday. Ignore the user or the consumer and you should not be surprised if the users and consumers ignore you. ---- It seems to me that InteractionDesign is just another term for HumanComputerInteraction. Cooper's just trying to make his niche by putting a new face on it. Not that there's anything wrong with that. But hey, I've got a ''degree'' in HumanComputerInteraction, and lemme tell ya, it's nothing special. Correction: On a second look, InteractionDesign also seems to deal with gathering requirements. ''(I haven't read enough about InteractionDesign to be really sure about this, but...)'' It appears to me that InteractionDesign is remarkably like BusinessProcessReengineering: Both try to avoid the problem of "paving the cowpath" by automating existing "broken" or "bad" business practices. Both strive, instead, to analyze the real business requirements behind the "I gotta do this today" requests, and to figure out how to really run the business "properly." Only when you've redesigned the business process to (1) make real sense and (2) take advantage of appropriate automation, will you be able to state the appropriate requirements for computer systems that will help take the business to the highest possible levels of productivity. -- JeffGrigg ''[I think the Wiki comments on the BusinessProcessReengineering page are kinda' misleading too. Don't rely on them; see the references. -- JeffGrigg]'' I agree, my first impression was too narrow. I would ''still'' say that Cooper is basically just looking to create a niche, though. ---- Disagree with much of the current discussion on this page - sorry! People seem to mainly be reacting to '''Alan Cooper's''' version of Interaction Design. Note that all but one of the cited articles relates to him/his firm. But '''his''' definition is not (necessarily) an authoritative one. In fact, as a successful Interaction Designer myself (and one who knows a lot of other practicing Interaction Designers), I would say that his definition is significantly ''broader'' than the mainstream one. When practicing Interaction Designers refer to InteractionDesign, they are typically trying to make a distinction between it and GraphicDesign (or perhaps with some other HCI/Software Development sub-discipline). For example, you would hire a Graphic Designer to design a set of icons or to choose a color palette or to create mockups of an emotionally engaging web page. On the other hand, you would hire an Interaction Designer to map a use case into one or more UserInterface designs (and to describe/document the supported navigation paths among those UserInterface''''''s). In a nutshell: GraphicDesign vs InteractionDesign is just Look vs Feel. Which still allows some people to be skilled at doing both kinds of things. ''Typically'', Interaction Design (in the mainstream sense) is concerned with things like: * High-level task to UI navigation mapping * Low-level task mapping to the design of an individual UI * Control selection (and knowing when a custom control is appropriate) * Selection of appropriate (and platform-sensitive) UI idioms * Promoting design consistency (along a variety of axes) and, more importantly, * ''knowing when and how to safely break it'' While Alan's broader definition is a lot broader and includes: * Business process re-engineering * Analyzing how users do tasks today (or how they might do them differently in future when the new system ships) * Evaluating the system's usability The first two would be better done in the requirements analysis step. However, most projects don't have the resources for a separate usability test team, so a given HCI/Usability person may end up doing both the InteractionDesign and the usability testing. I can see above that at least one person is worried that this (narrower) definition looks too much like "interface design". Funny, I (and most the Interaction Designers that I know) aren't really worried about the redefining of 'interface design' and 'interaction design'. Maybe it IS just a re-naming. But it serves us pretty well in trying make a distinction between the work ''we'' do versus the work of the Graphic Designers. Thanks for listening... ---- Check out Dan Saffer's Definition of Interaction Design: http://www.odannyboy.com/blog/archives/001000.html ---- This is a semi-paragraph from SystemsPersonalities about the relationship between that and InteractionDesign. <<...identify the user roles that the sponsors consider the most important people to fit the application. These are the focal roles. The system will present different "personalities" (fast and efficient, for example, or warm and friendly) to each different role. The designers will accentuate one personality over others, and you want to make sure they accentuate the most important one(s).>> The point is that to me, InteractionDesigners describe their profession by all the little things they do along the way, rather than by a higher-level concept. Programmers do (sometimes) design, and program, and (sometimes) test, and (sometimes) document, but overall they are developing software. Ditto, I think InteractionDesigners are defining and developing the ''personalities'' of the systems --AlistairCockburn ''Gestalt?'' --mt ---- See also: InstructionalDesign ---- CategoryMethodology CategoryInteractionDesign CategoryInterface