What Is Interaction Design

Okay, I'm making this page because Dan seems to want to know what interaction design is, Costin keeps accusing me of not being an interaction designer on the basis that I don't do UsabilityEngineering, and AlanCooper never provides even a description of what interaction design actually is in TheInmatesAreRunningTheAsylum.

First, a couple of facts,

Interaction design is to software "design" what chemistry is to alchemy. Interaction design is a deliberate act to systematically produce a complete set of concepts for a problem domain with clear and concrete goals in mind.
These goals are usually contrary to programmer values. An interaction designer explicitly analyzes the value of each interaction and comes up with very different results than those assumed by programmer-designers. Those results include:
- User choice is a cost, not an added value
- Extended functionality is a cost, not an added value
- The value of choice and functionality comes from their being in common usage.

After a bit of thought, here's what I've come up with:

Interaction design:

: the process of analyzing interactions in a system to synthesize concepts that minimize undesirable interactions and maximize desirable interactions.

Everything else follows.

For instance, once you insert the user as a concept in the system and define "learning concept X" as an undesirable interaction, it becomes imperative to minimize:

the total number of concepts
the number of unnatural concepts

It also becomes obvious why user choice and functionality are costs and not benefits. And also why using a function once in a blue moon isn't sufficient to make it a net positive.

Now we need to turn our minds to what interaction design is not.

Interaction design is not the building of models, the finding of Patterns or the construction of rules. Interaction design is the production of designs and designs aren't models. Designs are systems of concepts that work together to produce a whole. And concepts aren't rules nor lists of rules, though rule-using people (technical experts) might misunderstand them to be since both rule-using and concept-using people share the same language.

What is design good for? And how does it achieve it?

Design works by finding and sometimes making the concepts associated with whole lists of rules. Once they're found, those concepts can be rearranged and modified at will, and often entirely eliminated. Once this is done and the design is retranslated back into a model, the model will have been radically reorganized from its previous version and anything unnecessary in the model will have been eliminated. The reorganized version will be simpler to implement, more reliable, easier to use, easier to learn, easier to maintain and all around better. It might even have features which weren't conceived of before.

And none of this can be done by simple inspection of the model or even thorough use-case analysis of it. The closest thing to design in the programming context is refactoring.

Having an idea what interaction design actually is now, it becomes obvious that no programming can occur before interaction design is substantially complete. There's nothing to program until the interaction design organizes the problem domain into a set of coherent concepts.

The position that one should just start programming and let the problem domain organize itself is Intuitionism pure and simple.

The position that one can rely directly on the users to synthesize the concepts in their problem domain is blatantly stupid and counterfactual.

-- RichardKulisz

Your arguments have appeal, and I was about to agree with you (I thought) by pointing out that I think interaction design is to programming as building architecture is to carpentry, but then I saw your parenthetical comment above. I'm a programmer, so I guess my brain is too small to grasp it. In the interests of cerebral expansion, could you provide a trivial, but usable example of the outcome of an interaction design process? Something that I can use to either (a) produce a detailed design; or (b) produce code? Or, if I've completely misunderstood "interaction design", then please indicate what is produced, and how you expect it to be used. I had high hopes that InteractionDesignExamples would enlighten me but, alas, no. More conceptual armwaving, I'm afraid, just won't do.

I want to see what I'll be coding to (or whatever to) when I finally accept my lowly role in the IT foodchain and submit to the future legions of talented interaction designers schooled in the Kulisz Way. Something simple will do. If you were a building architect, I'd probably ask you to design a shithouse or a garden shed. What's the software equivalent to a shithouse? A better Calculator, maybe? What would the "interaction design" document (I assume there'll be a document, yes?) for a software-based calculator be?

-- DaveVoorhis

God, those words are sweet Mr. Voorhis.

FYI, the problem with building architecture in practice is that it's 99.999% concerned with the building code. Programmers have this unrealistic expectation that building architecture is represented by FrankLloydWright and ChristopherAlexander, but it isn't.

Now, when you say "something I can use to produce a design" I get the nasty suspicion that you actually mean model.

Unfortunately, there are no trivial examples of interaction design. The idea is a contradiction in terms. In particular, a software calculator has no interesting interactions. Or maybe it does. Let's see for a minute.

Moved to RichardsCalculator

InteractionDesign as described on this page is remarkably similar to how I approach API design. As few concepts as possible, interacting as flexibly as possible. I don't design user interfaces, but I assume that this approach is at least as valid there as it is in designing the interface to a software subsystem.

As such, I don't see this approach as at all radical - in fact, it's in harmony with principles I was taught in the mid-80s by the Department of Electrical Engineering and Computer Science at the University of Connecticut. A good software architect already follows these principles. I would call it domain modelling, but with an emphasis on keeping the model as simple as possible - which of course should be an obvious goal for a designer, since nobody can validly defend unnecessary complexity.

It is not necessarily true that "interaction design" must be essentially complete before programming begins. Programming can also be exploratory. A good domain model, i.e. a selection of a simple, understandable, covering set of concepts for the domain of interest, may not be obvious. It has to be informed both by the domain and a thorough understanding of the target audience and the tools available for implementation. Sometimes, it helps to write parts of the code to see how things will work out.

-- DanMuller

And with the proviso that you are doing interaction design when you're designing APIs, you finally understand what it's all about. Sorry about that, I was going to address your misunderstanding that ID = HCI/UI design but I never got around to it.

As for design = modeling, I get the feeling that it's not that simple. And if it is that simple then modeling is entirely the wrong word for it.

Finally, of course a designer would explore a domain by designing. And of course a programmer would explore a domain by programming. To someone who does plenty of design anyways, it's difficult to argue to favour one over the other. For the everyday programmer .... Remember that BurnTheDiskpacks and PlanToThrowOneAway rarely occurs in practice.

-- RK (presumed)

"Modeling" is a pretty broad term that admits of a wide variety of approaches. My impression is that ID puts an emphasis on certain aspects of modelling that are common but perhaps tend to be underappreciated. Thus ID sounds more like a refinement than a revolution.

The term 'domain modelling' that I used above can be misleading, especially when talking about the design of a software subsystem API. The 'domain' may not correspond to anything in the real world, so the model, or portions of it, may have to be invented from pure imagination. Some portions of a model may exist only to work around limitations of the technology. Take for example the fairly common abstraction of a 'connection' between a client and a server. The connection represents shared state, often primarily for performance reasons, and usually has no correspondence to anything 'real'. It's often the case that models can be simpler when the implementation technology is more sophisticated or more capable - you might for instance be able to do away with the concept 'connection' if the performance savings afforded by shared state are unnecessary. (We see this sort of thing in the history of programming languages; those with higher degrees of abstraction (thus fewer but more powerful concepts) were historically too slow for many applications, but as the hardware and software that interprets programs gets more sophisticated, this becomes less of an issue, and we see C gradually and continually yielding ground in the commercial world to more sophisticated languages.)

This is why I'm skeptical that good design can be divorced from technical expertise. Even with a good knowledge of implementation limitations, it's not always clear without experimentation which aspects of a model will cause problems. Often an iterative approach is useful. Iterative means something different from merely hacking; if one needs to revisit aspects of the model, one does so deliberately, keeping in mind the goals of the model (simplicity, completeness, understandability, flexibility, etc.). I think that the best designs come from people who are good at synthesizing a model and knowledgeable about the available technology; or from teams of people that in aggregate have both kinds of expertise, and work closely together.

PlanToThrowOneAway may not occur as often as it should in practice, but it does occur, and it can be a good practice. Fearless refactoring is another approach - if the model changes, refactoring may be extensive, eventually achieving a similar result. I've used both approaches myself. The latter is usually easier to get away with in a commercial setting.

-- DanM

Okay, one of the problems is that a design never has the kind of detail that a model has, especially not technology-related details. Another problem is DesigningVsModeling holds. Since designing is modeling stuff completely out of your imagination, there is no established problem domain to model, it engages faculties which pure modeling doesn't. There's no a priori reason why a good modeler would be a good designer. There's a lot of overlap but it's far from 100%. -- RK