It seems to me the InteractionDesign community is missing this higher-level concept of their work.

A software system presents a certain amount of help, information and speed to its various end users. It might be designed to be fast and efficient, for example, or warm, friendly and informative. These are the ''personalities'' it presents to the outside world. Most systems present different personalities to different users, depending on those users' backgrounds and needs. Except . . . most designers don't develop the personalities in any deliberate fashion. They simply throw together whatever they have on hand, and the personalities of the system are just whatever happens to come out. -- AlistairCockburn
----

There are probably one or two focal user groups that the sponsors really want to see satisfied with the new system. The team needs to find out who those are, what they need to accomplish using the software, what personality is best suited for each, and be sure they are properly served by the system. They need to detect, write down, and periodically recheck who those are.

JeffPatton illustrates with the example of a chain of retail stores. The cashier uses the system daily, gets familiar with it, and prioritizes for speed in registering sales. The store consultant, on the other hand, won't use the system very often, won't be fluent with its interface, but knowing all aspects of the store's operations, will want to do more functions than the cashier. The cashier wants a fast-and-efficient personality to work with; the store consultant wants an informative-and-helpful one. 

(with apologies for the drive-by ad, here's a para on it from the CrystalClear book):

Before you get too far into designing the system, you need to 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). -- AlistairCockburn
----

I think I agree with what you mean, but I also think you need to distinguish it more sharply from what has gone before, because otherwise, Microsoft's Bob and Paperclip were exactly this.

Not sure if this is related; depends on how you clarify: There is also a ton of current research going into emotional interfaces; adding affect to systems. This is not a bad idea if not taken too seriously, like skinnable interfaces are not a bad idea. But it's an extremely bad idea when taken to extremes, yet many researchers do in fact think this will revolutionize interfaces.

A recent example was a little study that had software apologize profusely when something went wrong. 60% of users reported a sharply better experience under single blind conditions, so it was reported to the media as a huge success and the wave of the future - despite the little note that 10% of the users were highly alienated. But screw them, right?

Once people get used to affect in systems, the placebo effect will wear off, and 100% of users will get pissed at condescending software that pretends to have feelings when it's obvious it doesn't, and at its completely empty politeness.

These researchers haven't stopped to think about parallel situations with humans interacting with humans: if the person you're interacting with in a bureaucracy
is extremely polite and apologetic, but refuses to actually '''do''' anything to help, it's infuriating.

Yet that's the "wave of the future" of affective computer interfaces? Shoot me now.

Anyway, this is more of the sort of thing that I think you want to distance your position from.

-- DougMerritt

----
I'm not saying that "giving the software a lot of personality is a good idea." I'm saying that every application ''has'' a personality, whether it was deliberately designed or not. You cite that "software apologize profusely when something went wrong" - that was a particular choice of personality given to the software. Evidently you don't agree with the one that was given. If you had preferred a terse interface instead, that wouldn't mean that the application didn't have a personality, just that it had a terse one instead of an apologetic one.

It seems to me that InteractionDesigners are fussing over the nature of the personality being given to the application instead of it being an accident. Part of their job, as I see it, is being right in detecting when a terse one vs an apologetic one is appropriate (and yes, the Paper Clip is a projection of personality - and too much of one, as everyone but MS seems to have decided. A less intrusive personality would have been a better design). -- AlistairCockburn

That's part of what I mean: there are in fact some nearly absolute guidelines, such as what you said: less intrusive. It's hard to imagine when highly intrusive might be appropriate. Part of therapy for certain mental conditions, maybe. That is not at all just a matter of an individual designer's tastes for a particular generally-used application, though.

And you're apparently missing one point, when you say "Evidently you don't agree with the one that was given." Look again. The more important point was that some of their own users didn't agree! They themselves said that 10% of the users were alienated. A change is not an improvement unless it's at worst neutral for everyone; you can't just say 10% of the users don't matter.

Interfaces should follow the Hippocratic oath, usually paraphrased as "first, do no harm". Designers '''should not''' have the freedom to pick an interface that "only" harms 10% of the users (including here meaning emotional harm).

More generally, computers should not be deceptive, yet some personalities are deceptive. Profuse apologies are deceptive, for reasons I've already outlined, and this deception will eventually be penetrated by essentially all users.

So I'm saying that you need to go further, and have general guidelines: designers should explicitly design personalities, and that we already know they should not be overly intrusive, they should not emotionally harm even a minority of users, they should not be deceptive, they should not be condescending, etc.

This needs to be said because clearly it is not obvious to everyone, even though it is certainly a kind of common sense. Other areas of common sense are, by contrast, much better known, such as that interfaces shouldn't be rude.

Look at human personalities. There is a vast range, but only a small subset of those personalities are appropriate even to be the company receptionist, let alone an official company spokesperson, precisely because personality makes a difference when interacting with the general public.

Same thing with software. It cannot be a matter of "anything goes, as long as it was on purpose" - which I hope you didn't mean, but I think what you wrote could be read that way.

So hopefully none of this contradicts your actual position. -- dm
----
Indeed it doesn't. What I'm positing is that we give apps the equivalent of "personalities", and what those personalities are does matter. I think that the definition and deliberate construction of the multiple personalities that an app shows its various users is what InteractionDesign is about, although those people aren't yet saying that (I'm prompting them.....) -- Alistair

That's not '''all''' of what it's about by any means. Consider the source of your analogy, people's personalities. I mentioned the personality of a company spokesperson. The directors of HR, marketing, and accounts receivable could easily all have the same personality as the spokesperson, yet each clearly has different job functions.

Conversely, although talking about the personality of an interface makes a great deal of sense, if you redefine it to merely mean "all aspects of interaction design" of software, then it forces it to include functional elements that are not an intrinsic part of human personalities, which overextends the metaphor, and removes the effectiveness of the term.

I would say instead that InteractionDesign should '''include''' personality design as one of its components.

It also seems that it would help if you make it clear whether this is an open-ended system, or whether the choices are exactly the two you offer as examples at top of page, and whichever approach you have in mind, to offer some guidelines as to how to choose a personality, rather than leaving it to their individual intuition. InteractionDesigners need to operate within a clear cognitive framework that you establish for them. -- dm

You know, if you're going to have personalities in the system, we should first look at the very most obvious elements of the history of UI design. Especially the developments of user-definable themes from the earlier Unix attitude that every developer gets to chose what kind of torture they'll inflict on the user (Unix is rot13 for Evil).
* Actually, I get "havk" from rot13 of Unix. :-)

Think about it, wouldn't it be great if you had one application that was warm and cuddly to the user and then another application that cursed their name for even running it? Not!
* To date, I believe the evidence is that the goal is to have people curse the name of the developers of '''every''' app, not just some of them.

Just like developers should work against abstract looks and feels so as to leave the choice in the hands of the users, so too should it be for affect.

But this is all bogus since I don't believe that ''well-designed'' software, one with a DirectManipulation UI at its base, has a personality. -- rk

I would've thought that DirectManipulation would show the personality of the NakedObjects within, because I am taking Alistair's central point to be that the human mind anthropomorphize '''everything''' automatically, so we see personality where it does not literally exist; it's just a question of which one we see. -- dm

Except that the human mind doesn't anthropomorphize ''literally'' everything. I think the emphasis on universal abstractions like objects is misleading in this situation.

Yes, it's useful to talk about sending messages to objects as a universal framework. But someone playing BlackAndWhite doesn't think of their "hand" as an object in the system which they are sending messages to. The hand doesn't have a distinct personality, it's a direct extension of the user's will.

In the real world, people don't anthropomorphize simple objects like bricks. They're just ''there''. (Note: higher anthropomorphization is a sign of mental instability and psychocultural backwardness.)

Something only acquires a personality either due to an arbitrary association (eg, a stone in the shape of a human face), or due to massive ''perceived'' complexity. Both are signs of horrible UI design.

We can play the "what kind of abnormal psychopathological personality does Unix have" all we want, it won't tell us a whit about god UI design. -- rk

Ok. But it's only a metaphor, anyway, and any metaphor can either help or hinder communication depending on how it's used. So I don't think Alistair will necessarily find this a fruitless approach; I presume he will wield the metaphor effectively.

Given your comments, it would be interesting to see some studies on when people do and do not perceive personality in computer interfaces. I don't recall any that tested this directly. -- dm
----
I do suspect that most people anthropomorphize a lot, and I know that I anthropomorphize a whole bunch, and I would be interested in how much people perceive personality in computer interfaces, but that's still not what I'm after.

Imagine Pat who is assigned to do the "interaction design" for an app, e.g., the store app mentioned at the top. Pat will uncover that this app will interface with two groups (e.g., of course more). One group will be temporary hire, high-school education, but using it every day in the same way for routine inquiries. The other will be permanent hire, possibly business school or accounting grad, from headquarters, deeply versed in many aspects of the business, and this person will not use the app so often, but will be making complex and in-depth analyses of the store situations.

So Pat has to come up with 2 appropriate interfaces. What I'm suggesting is that just as a database or OO designer will come up with a core model of the domain centered around a few key abstractions, Pat will look for a way to coalesce the 2 different sets of interface characteristics around a couple of key abstractions, so that the app's interface is suitable and consistent (in different ways) for each of those user groups. And so Pat might say (just to pick two out of the air, not that they are the only two): "For the store clerk, we want something simple, easy to use, efficient, not wordy, etc." and "For the HQ analyst, we want something more wordy, more helpful, more comprehensive." If people off the street are going to use it, Pat says, "For the customer, it needs to be exceedingly simple, warm, friendly, forgiving of mistakes, patient, clear, etc."

And these "amount to" descriptions of personalities. Further, that having Pat operate in these terms will help Pat check (a) whether the app's interfaces are consistent in those characteristics, (b) whether those characteristics are indeed suited to those users, and (c) whether the programmers actually put those characteristics into the app.

Hope this is slowly making the original thought clearer -- AlistairCockburn

This is perhaps akin to the idea of "personas" presented in TheInmatesAreRunningTheAsylum. Every system is designed to satisfy a certain user or set of users. This is the "persona" that one must design for. If there's no conscious choice, then the system will be designed to satisfy the programmer, through ease of implementation, cool gadgets, whatever. AlanCooper recommends designating one persona as primary: this is the make-or-break user, the one that the system should be geared to. Oftentimes, this is the most difficult user to satisfy, the one that will give up in frustration the easiest, but it need not be. Sometimes it could be the most lucrative or the one with the most specific feature requests.

Alistair, correct me if I'm wrong so far...

But above, you seem to suggest that the InteractionDesigner abstract the common requirements of the different users, and then that becomes the personality of the system. I'd argue that that's the wrong approach. Programmers work in abstractions. Interaction designers ''have'' to work in concrete terms, with UIs that will directly satisfy the customer. I agree with Cooper, here, that the most important aspect is specificity: personas should have names, faces, and very concrete requirements. And the software should be designed to serve ''one'' persona (the primary) as best as possible. The interaction designer doesn't check for the existence of characteristics: he sits down with the software, plays out the primary persona, and sees whether the interface will satisfy that ''person''.

This doesn't necessarily mean the others will be left out in the cold - I don't know any company that'll throw away part of their customer base of if it can help it. But if the choice is between delivering a mediocre-but-okay product to everyone and satisfying one core group extremely well, the interaction designer ought to go for the single, well-defined group. (The business manager, OTOH, might legitimately decide that it's better to satisfy everyone poorly rather than one group well. But in that case, he shouldn't hire an interaction designer to begin with, because he's better off hiring a bunch of really skilled programmers so he can respond quickly to customer requests.)

I also don't agree with Doug about it being unacceptable to alienate 10% of users. If those 10% are not your core customers, I see no problem with telling them to go elsewhere. If you try to please everybody, you'll just end up pissing off everybody. Then the competitors come in and chop up your marketplace with their better-but-more-narrowly-focused products. -- JonathanTang

This is the worst of statistical fallacies: optimism that the subpopulation you displease will be the correct subpopulation. There is, actually, no reason whatsoever to think so. The correlation could be random - the null hypothesis - in which case, as I said, it is unacceptable to alienate a random 10% of your users. Or you could get unlucky, and you could alienate the very most important 10% of your users. Also, despite RK's apparent agreement below, actually you two are in sharp disagreement here, because there is no reason to think that you have to alienate '''ANY''' of the users. -- dm

Except that the reason you're hiring an InteractionDesigner is so that the correlation is ''not'' random. Your comment above is phrased as "pick an interface..."; from that, I gathered that the designer is making a deliberate choice to say "These users are not important", and not simply shooting in the dark. The whole reason for focus groups, studies, feedback forms, and other human factors research is to make sure that you know which group you're alienating and can make a business decision as to whether it's okay to alienate them.

And yeah, I think I do disagree with RK, because I'm a design relativist. I don't believe that there's one UI that will please ''everyone''. I do believe that there's one correct UI design ''for a given person'' and the others are suboptimal compromises. And I believe that it's possible to create a UI that'll be optimal for ''someone'' (maybe even a group of people) and acceptable to a lot of other people, which is what a business is really looking for. In some areas, it may even be possible to create a UI that's acceptable to everyone, though ideal for no-one (the telephone is one example).

If you're in the 10% that gets screwed over by a design decision, why not launch a competing product that caters to folks like you? Apple has done steady business by catering to the 10% of users that Microsoft alienates. Or maybe it's the other way around, and Microsoft has become huge by catering to the 90% of users that Apple alienates. ;) There's nothing that says one solution must be ideal for everyone. -- jt

I agree [with Jonathan, before Doug's response]. If you start listing a set of abstract characteristics like "Pat" was doing, then there's '''no''' characteristic that isn't obviously a GoodThing. This is made worse by the fact that none of the ones listed are mutually exclusive. If they seem to conflict (eg, terse and wordy), this is merely a failure of your imagination.

If you're going to design to abstracts and you want to do it in a user-configurable principled manner, then you've just set yourself up to inventing a social AI. And there's lots of people that'd be interested in your implementation.

If you're going to design to concrete people, then that's a whole other ball of wax, because ''that'' is doable. At the same time, I'm a design absolutist. I think there's one correct UI design and that all others are broken versions of it. -- rk

I have long suspected this is true, but I've never seen it. -- dm

Meanwhile, I'm happy to design and program for a single, extremely demanding concrete user. Myself. This works since I'm not primarily a programmer and I certainly don't think like a programmer. -- rk
----
There's a time when verbosity is helpful, and a time when it is insulting. Tonight the self-check-out machine at my local grocer instructed me in a loud, clear voice "Please wait while your transaction is processed" while it sent in my debit card request. If this was my first time to use the system (or if I had just moved here from a remote village in Mustang), I might appreciate that audio cue. I've been there dozens of times, though, and used my debit card thousands of times. It should know that I know how to wait for an approval and politely wait in silence with me. -- EricHodges

If you've been there dozens of times, are you likely to stop using it because it talks to you?

The new user is often more important ''because'' they're more likely to give up and walk away. That doesn't mean a business should routinely shaft its long-time customers (many businesses have lost their market presence precisely by making this mistake). It does mean that it's often worth a minor inconvenience to longtime users if it brings in more new users. The exception to this is when the market is mature and there ''are'' no more new users that can easily be won over.

Incidentally, I think this is one of the big problems with CommonLisp. It screws over newbies so that wizards can do great and wondrous things with it. This is great if you're a wizard or have the patience to become one, but it's a death knell for any product trying to become popular. Every wizard was once a newbie, but the vast majority of newbies never make it to wizard status. -- JonathanTang
----
"Except that the reason you're hiring an InteractionDesigner is so that the correlation is not random... If you're in the 10% that gets screwed over by a design decision, why not launch a competing product that caters to folks like you?" quoting jt above

Your response completely baffles me. I cited a recent study where a '''random''' 10% of their users were alienated, '''not''' a targeted subpopulation, and you seem to be persistently ignoring that context, and running off and making a bunch of unwarranted assumptions.

As I have already said, there is no clear reason to think that one need alienate any users at all. You have not contradicted '''that''', but you're acting as if you had. In some places - and then your comment about newbies vs wizards seems to go back into agreement with me. Very puzzling. -- dm

I'm responding to "Interfaces should follow the Hippocratic oath, usually paraphrased as "first, do no harm". Designers should not have the freedom to pick an interface that "only" harms 10% of the users (including here meaning emotional harm)," which seems to be a general statement of principle, not in reference to the specific study. In the specific study, I more or less agree with you; I'd hate to see software that profusely apologizes. But if I were running a business that is trying to sell to the population targeted by the study, I would put aside my personal preferences and do whatever generates the most revenue. Assuming that I felt the designers conducting the study were qualified (and I'd certainly double-check this, as pissing off 10% of users is not something to be done lightly), I would sacrifice the 10% to better please the 60%.

I don't believe that, in the general case, it is possible to satisfy everyone ''better than the competitors'' without alienating some users. In the specific case where it ''is'' possible, of course I'd choose not to alienate users - I don't know any rational person that wouldn't. But the interesting case is the one where it's ''not'' possible, and it's there that I'd rather satisfy a core group well than satisfy everyone poorly.

In the newbies vs. wizards comment, I'm arguing that newbies generally make a better target "core group" than wizards do, if only because there are more of them and every eventual wizard must start out a newbie (and afterwards, has some investment in your product and hence a reason not to switch). This is not a universal though; in a market that's already saturated, it becomes better to target wizards because you're unlikely to attract any newbies. -- jt
----
Backing up to JonathanTang's comments: ''"AlanCooper recommends designating one persona as primary... But you seem to suggest that the InteractionDesigner abstract the common requirements of the different users, and then that becomes the personality of the system."''

Yes AlanCooper does recommend that, but no, I don't suggest that. The operative word here is "personality". This page is called "personalities" (plural). I am a fan of personas, plural, not just one. But that is external to the system, how the system sees the user base. I am talking about how the system '''presents itself''' to the user base. Not what personality it expects to dialog with, but what personality(ies) it presents to them. The interaction is two-way. If AlanCooper is designing a two-way interaction between a persona and a system, he has to have in mind the personality of the system as well as the personality of the persona. Except, here again, plural - each usefully different user set will have its own needs for the interaction, and want the system to present a different personality set. 

So imagine Pat creates three or four personas, for what the ID community calls "focal roles" (I guess that would make them ''focal personas'') And then Pat conjures up what sort of interaction would be suitable for each of these focal personas, and not too surprisingly, they are different in style and tone. The system now shows a different personality to each of these different user groups. -- AlistairCockburn 

To simultaneously respond to both you and Jonathan, this approach need not exclude any subpopulation of users; each might select the interface style they prefer - which is similar to interface skins, as I noted in passing above.

Furthermore, if there '''is''' a need to pick out a specific target audience, and address only their needs, to the exclusion of others (not uncommon for business reasons), then the targeted audience is then 100% of the intended users. CAD products are marketed to CAD professionals, and if it then turns out that 10% of sales go to home users who all hate the interface, that's too bad, but not even vaguely similar to alienating 10% of the '''intended''' audience. So I think Jonathan was inappropriately mixing up "all conceivable users" with "all intended users". Two different subjects. You cannot target e.g. non-computer users, but you should try to accommodate all of the '''intended''' audience, else you lose market share unnecessarily. (And yes, sometimes it's too costly to address everyone, but again, then they drop out of the pool of "intended users", caprice?)

Well, maybe there's still room for misunderstanding. Initially, one just does the best one can to get product on the street and revenue coming in - but even then, aiming for 100% of the targeted audience is desirable if it happens to be possible. Sometimes it is, sometimes it's not. Later, the company will certainly want to increase revenue 10% if possible, and if engineering says "there's no way in hell we will lift a finger for the 10% of users that we are currently alienating; 10% is too small to bother with", then naturally the engineering head who insists on that, or even the entire engineering staff, if necessary, is fired en masse and replaced with people who '''are''' willing to do whatever it takes to expand the number of targeted users, so as to increase revenue.

(And don't think I'm just being dramatic; this actually does happen in the small number of cases where engineering is so foolish as to take that attitude. 10% increase in revenue is very significant.)

So, Alistair, you gave examples of two kinds of interaction personae; do you have further examples, or is that TBD? I would guess that there might only be a small number that are initially identifiable. -- dm

P.S. I commented on a very old and forgotten study about an interface approach that targeted both newbies and experts, and assisted the former in becoming the latter, on ObjectBrowser, beginning at "expert vs beginners" -- dm
----

Doug, I found this on the Yahoo Agile-Usability eGroup: 

''For UIs, the tradeoff is between easy-to-use (experts) and easy-to-learn (novices). They are inversely related in UIs because of the limitations of pixel space. Think of the contrast between two sentences: (1) 'Give me all the help you can!' for novices, and (2) 'Get out of my way!' for experts. The more info you put on the screen to help a novice, the less functionality you can cram in to make it faster for the expert.''

so it seems there are two predominantly different ones. I'll keep my eyes open for others.

[There's not necessarily a contradiction. Interfaces should always be helping novices to, not just do their work, but to become more expert over time, as well. But it's not symmetric; interfaces don't need to help experts become novices!]

[The same interface can, however work for both groups, so long as it provides e.g. unclutter options for experts. This is quite different than presenting this as a simple spectrum of options between the poles "lots of help" and "no clutter". -- dm]

I think unclutter should be done automatically by monitoring actions and gestures performed by the user. When the user has performed a command a set number of times, the menu item starts to fade and get smaller in the same relative place (menus that move around are evil). Of course, this should be reflexive so at a minimum a "show all items" command must be provided. And since this is an operation, it must also be reversible, so an "unshow all items" must be provided. Since the user would be able to see what "unshow all items" does, it would also be possible for them to customize it to ''set'' the visibility of menu items. Damn, I forgot all about the "[continuous] fade learned commands", which must also be reflected upon, but isn't a command so much as an integral part of the ObjectBrowser, which internals are reflected in a different place. Probably the same place where the class bindings (object->plugin) and the glyph bindings (glyph->command) are stored. But then again, sortBlocks (for directories) are also continuous instead of discrete even though they are commands. Which shows that learning and typing must be as easily accessible as sorting, and that everything is some sort of command, even if it's just a lambda with a big table inside. -- rk

Agreed. But there should always be a way to explicitly override such responses, so that comes first. I would also expect that the automatic response would need experimentation and tuning in order to home in on the best approach, and those algorithms should build on the lower level simple on/off mechanisms.

Wait a second, actually on re-reading, I don't think I understand the continuous/discrete comment. -- dm

"create new movie" is a discrete command that's performed at a specific point in time. "sort directories by date order" is something that occurs continuously, something which the GUI does repeatedly without any explicit user input. Push vs poll.

Discrete:
* create object of type X (duplicate prototypical object X)
* move object
* duplicate object
* edit object
* delete object
* fork a process
* announce to everyone on my IM list that I'm present
* and so on and so forth

Continuous:
* sortBlocks (for directories)
* glyph (MouseGestures) lookup hierarchy
* plugin (object type/ class) lookup hierarchy
* trigger on any glyph "announce to everyone on my IM list that I'm present" if last state was absent

----
Alistair, I'm wondering if the Personalities metaphor doesn't encounter some of the same difficulties as the much-maligned XP Metaphor. What problems does it solve, and for whom? I think that a competent interaction designer takes a number of factors into account to arrive at a given design, and that the simplification of these complex data into simple personalities might be questionable in many cases. For example, there are a number of levels at which a system's personality might be considered:
* Overall system
* All tasks for a given user role
* A single task for a given user role

A system might display a given personality at a coarser granularity (e.g. a webmail program might be spartan and efficient overall), while adopting a different one for more specific tasks (e.g. the initial setup might be friendly and helpful).

Total context is the key. A few of the many disparate elements that might comprise it are:
* Task environment
* Cultural norms
* Technological proficiency
* Brand consistency
* Information flow
* User domain knowledge

The tricky part is that these things will often interact in a complex manner, so it pays to consider them at a number of different levels. And once you've got the "what" of the context, you still have to consider the "how" of your solution, which includes layout, flow, color choices, typefaces, etc. All that being said, I do still believe that there could be value in that system-level personality, perhaps as an information radiator for the broader team, or as a guiding factor to the novice ID...

-- ArlenBankston

Good point, Arlen. Actually, I don't know whether it goes that far, and of course I'd be happy if it did. Doug suggests above there may only be two.

The point I'm trying to reach may be much simpler than all the text on this page suggests. Here's what triggers my post. Start from the description of ID from the InteractionDesign and move to a conversation:

"Hi! What do you do?" "I'm an interaction designer, I am concerned with 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)."

That's a mouthful. When someone says that what they do is <long laundry list follows>, it possibly means they don't properly understand the place of what they do.

What I'm proposing is that they say, "I'm an interaction designer, I design the personalities that a system shows its various users."

This is an abstraction of the ID job description, one that I propose fits the bill, and is both short and meaningful. (Since I'm not in the ID field, I am of course aware that this group could reject the abstraction .... but then I think they need to come up with a better one, and not just keep presenting the laundry list.) -- AlistairCockburn

[Hmm, interesting... -- dm]
----
CategoryInteractionDesign