Microinteractions

Last week I wrote about affordances in an effort to better learn about an IxD concept. This week? Microinteractions.

I’ll let my reading define microinteractions for us…

Microinteractions are contained product moments that revolve around a single use case — they have one main task. (Source.)

Microinteractions can include turning something on or off, hearing a phone alert, changing the volume, setting an alarm, and so forth. I had two uncertainties about microinteractions before writing this post:

1. I was uncertain about the dividing line between a microinteraction and a task — or a microinteraction and an interaction. At what point does it switch over to micro? Well, from what I have learned, it’s not as clear as that. And, that isn’t even the point really. I dislike arguing semantics and I don’t think I need to here. Because I think it’s the wrong question to be asking. Which feeds into my next uncertainty…
2. I was uncertain about how to add microinteractions into my prototype. Now I’ve learned microinteractions are already there if I have created my task flow well. The reason we talk about microinteractions is not because “omg there’s this hot new thing we have to add to the prototype.” It’s because we want to make even the microinteractions a pleasant interactive experience.

Microinteractions are defined by their size. There’s no hard definition for what their size should be, but think “a single task.” And they are comprised of these four things.

1. Trigger
2. Rules
3. Feedback
4. Loops and modes

A (1) trigger initiates a microinteraction. (2) Rules determine what happens when that trigger is hit and (3) feedback lets us know what’s happening. (4) Loops and modes determine how a microinteraction changes over time, if at all.

So, when your alarm goes off, you hit the snooze button (trigger) and the alarm stops (rules). The sound goes off to let you know the alarm has stopped (feedback). Then 7 minutes later, the alarm goes off again (loops and modes). If you hit ‘off’ instead of ‘snooze’… good for you! And also you won’t experience the “loops and modes” component of the microinteraction.

The most important part of a microinteraction is the feedback. That’s what lets a user know the microinteraction has happened so they can feel satisfied and move on to the next microinteraction. There’s a lot more I could say about how one should design (and not overdesign) these microinteractions for user satisfaction, but that’s beyond the scope of this reflection.

Microinteractions are so subtle we don’t really notice them unless they go wrong. My goal for tomorrow will be to look for microinteractions which are going right. Whenever I do something… what was the trigger? The rules? The feedback?

You should try it too.

Note: This blog was written during IxD week 5.