Highlights

My philosophy is 'It's much better to be upset with yourself for having done something stupid than to be upset with a device that made the wrong decision on its own initiative.' (– Andy Ihnatko)

Some microinteractions are practically or literally invisible, and few are the reason that you buy a product; instead, they are usually pieces of features, or the supporting or so-called "hygiene" functionality. For example, no one buys a mobile phone for the ability to turn the ringer off, but it's expected, and, as we've seen, that micro interaction can create all sorts of experiences - for good and bad.

If the microinteractions are poor, the main features, no matter how nicely done, are surrounded by pain and frustration. The design of your product is only as good as its smallest part.

As DeRouchey says in "The history of the Button", "The button meant for the first time the result of the human motion could be completely different from the motion itself."

In the not-too-distant past, the only way to interact with the physical environment was to adjust it manually via a physical control. This changed in 1956 when Robert Adler invented the Zenith Space Commander, the first TV remote control. For the first time, users could control an object from a distance, invisibly.

Everything we see or hear while using digital devices is an abstraction. Very few of us really know what's happening when we use any kind of software or device. Just as examples, you're not really putting a "file" into a "folder" and "email" isn't really arriving into you "inbox." Those are all metaphors that allow us to understand the interactions that are going on.

Even more that with triggers, feedback is the place to express the personality of the product. Indeed, feedback could be said, along with the overall form, to completely define the product's personality.

Microinteractions are an exercise in restraint, in doing as much as possible with as little as possible.

Reduce the product to its essence, its Buddha nature. If you find you want to add another feature to your product, that other feature should be its own product. Many appliances, apps, and devices, including the original iPod, follow this model.

I have always had a soft spot in my heart for the details. I consider details more important than a great draft. Nothing works without details. Details are the essentials. The standard to measure quality by. (– Dieter Rams)

...the pitfall is that you can get lost in the microinteractions and not see the big picture, that all the details won't fit together into a coherent whole when you're finished.

Have the trigger initiate the same action every time. This is so users can create an accurate mental model of how the micro interaction works.

The kind of control you choose can be determined by how much control you want to give.

The goal for microinteractions is to minimise choice and instead provide a smart default and a very limited number of choices.

Don't break the visual affordance: if your trigger looks like a button, it should work like a button and be able to be pushed.

Microinteractions that most people do, most often, should be highly discoverable. Microinteractions that some people do, somewhat often, should be easily discoverable. Microintertactions that few people do, infrequently, should take some searching to find.

It should be noted that our reaction time to sound is after than visual; auditory stimulus takes 8-10 milliseconds to reach the brain but visual stimulus takes 20-40 milliseconds. Reaction time to sound is also faster: 140-160 milliseconds for sound versus 180-200 milliseconds for visual.

Don't make users guess how a trigger works. Use standard controls as much as possible. As Charles Eames said, "Innovate as a last resort."

Because a label becomes one more item to scan and parse, only provide a label if there could be ambiguity. The better practice is to design the control so it has no inherent ambiguity.

Add a label only if it provides information that the trigger itself cannot.

Users shouldn't feel like they have to follow - or worse, memorise - a strict set of instructions to achieve the goal. Instead, what you're striving for is a feeling of naturalness, an inevitability, a flow.

Don't have two similar buttons that act completely different. Objects that behave differently should look differently.

The more options that you give a user, the more rules a micro interaction has to have, and in general, fewer rules make for better, more understandable microinteractions. This means limiting the choices you give to the user and instead presenting smart defaults.

With microinteractions, a good practice is to emphasise (or perform automatically) the next action the user is most likely to take.

Be ruthless in eliminating options.

If you have to present a choice to the user, remember that how you present that choice can affect what is chosen.

If you do need to include text, make sure it is as short as possible. As Winston Churchill so aptly put it, "The short words are the best, and the old words best of all."

Never use instructional copy when a label will suffice.

The first principle of feedback for microinteractions is to not overburden users with feedback.

Showing progress on any critical process, particularly if that process will take a long time.

Don't show redundant visual feedback. For instance, never have a tooltip that mirrors the button label. Any visual feedback must add to clarity, not to clutter. Similarly, don't overdo a visual effect; the more frequent the feedback is, the less intrusive it should be. Don't make something blink unless it must be paid attention to.