Interaction Design: Simplify It

27th March 2009
All posts

Twitter is all abuzz (atwitter?!) about @bokardo’s post on “his blog: Demystifying Interaction Design“. To summarize, here’s the opening quote: “If interaction design isn’t about influencing behavior…then what exactly are you doing?”

@bokardo goes on to say, “Good design elicits the right behavior, poor design does not.” The word elicit implies “manipulation”, but design isn’t about control: It’s about creating a clear conduit of communication between a user and data. It’s about clearing away all the extraneous information so the user can interact with her data in the most efficient way possible.

The answer

Indeed! I think there actually is an answer here. Design doesn’t influence behavior: It facilitates it.

Interaction Design is much simpler than this, and I think much less about manipulating user behavior. No one can understand what Interaction Designers do (and designers in general) because we’re so unclear about it. Even I’m unclear about it when I try to discuss it to the uninitiated.

Let me clarify with an example

A beautiful Ducati motorcycle without its handlebars is simply an unusable hunk of candy-apple-red Italian craftsmanship. Do the handlebars control the user in the way they are designed? No. Can the user control the motorcycle without them? No. One requires the other to realize its true purpose with the interaction.

In my view, the motorcycle designer(s) merely facilitated this interaction. Of course this connection has developed over many years; starting with the invention of the bicycle, but the same idea can be applied to software: Interaction Designers champion the users, not the software.

Eliciting responses doesn’t factor in. Allowing interactions to happen smoothly, does.

What is software, really? Organizing a user’s data. The user must access this data with an application. That’s it! Those are the two components that software handles. The data can be images, videos, medical records, music, email (text), currency transactions, VOIP, and so on and the equation is still the same.

Interaction Design connects users to their data (I’m quoting myself on Twitter, here).

Why is this concept so hard for us Interaction Designers to communicate? It’s as if Interaction Design is like the human brain that cannot describe itself, it can only observe the world. Like a psychologist who cannot self diagnose.

Users want to be connected to their data

It seems behavior is important, but it’s just a subset of the larger issue (ie. the simpler fact) that users want to be connected with their data. Applications facilitate this. Interaction Design is in between. I don’t think I need to draw a diagram on this one but here goes:

Data <--> UI/IxD <--> User

There. Problem solved. Now if we could only communicate this to the world at large and get a response more concrete than, “What’s an Interaction Designer, that sounds interesting?”. Groan.

(Photo credit:


Nathaniel Flick

I'm a Front End Web Developer passionate about usability. My primary specialties are HTML5, CSS3, SCSS, LESS, and jQuery and I am very familiar with Foundation and Bootstrap frameworks. I've worked on top of and with Rails, Python, and back end frameworks.

  • Francis

    I googled “define:elicit” and got some interesting definition – my favourite (in this context) was:

    “To evoke, educe (emotions, feelings, responses, etc.); to generate, obtain, or provoke as a response or answer; To draw out, bring out, bring forth (something latent); to obtain information from someone or something; To use logic to arrive at truth; to derive by reason; deduce; construe”

    I like the “(something latent)” – I don’t take “elicit behaviour” as getting users to do what they don’t actually want to do, more to do that which will actually achieve their aims. For example, if the user wants to delete a tweet, you want him to click on the “dustbin” icon, you want to “elicit” that behaviour.

    I think your definition does apply, but at a more general level. I like the “elicit” definition as being more specific.

  • Nathaniel

    Francis, thanks for the comment!

    I think he sets the tone for his opinion in his first sentence, which I quote at the beginning of my article:

    “If interaction design isn’t about influencing behavior…then what exactly are you doing?”

    He’s taking the tack that “elicit” means “influencing behavior” and I don’t think that’s true. While I agree Elicit is a bad word, with many contexts, I do believe @bokardo chose his definition and used it as a premise.

  • Andy Polaine

    You make a good point, but I’m not sure it really steps out of the influencing/controlling behaviour argument in any way. Facilitating behaviour is simply a euphemism for influencing it in this context. Or, to put it another way, the process of facilitating behaviour is part of a larger process of influencing behaviour.

    Also, it’s way to narrow to confine interaction or software design as connecting a user with their data. Many interaction design projects are about connecting people to people and nothing to do with software.

  • Nathaniel

    Andy, good point about the people to people connection, though one could say that’s still about data, the sending of bits and bytes over a cable…that’s a case I hadn’t considered.

    Facilitating behavior isn’t influencing it, it merely allows it to happen more efficiently. To say we’re influencing behavior of the user is to put the cart before the horse. Why do we write software? To fill a need, usually, that users have with their data. Our interaction design doesn’t cause this need.

    Other interaction design projects (wish you had mentioned some but I’ll try to dredge them up from my memory) also depend on data, or “information” if you will, which I still feel isn’t something we, as interaction designers, influence or elicit in any way. We’re trying to make it easier for communication to happen. We step into the background so the people we’re connecting can interact.