As an Interactive Media Management student and User Experience professional, I have recently read this book to understand better how the details, when well designed, could make products to stand out – or, if poorly planned or missed, to ruin them.
With a smooth and clear writing, the author presents a very structured thinking about how to plan a Microinteraction focusing on the final users, with many different examples of how they impact our experiences – or lives – positively when well designed, or negatively otherwise. It’s almost a Science, but very easy to follow.
This book is an essential guide for any User Experience designer, no matter their level.
The fun examples will show you how poor microinteractions put some users in embarrassing situations and, for sure, will make you relate to some of them, or start remembering a mistake you did that could have put your users in a trap.
Ok, but what the heck is a Microinteraction?
First, let’s differentiate Microinteractions from Features.
Features are usually “complex (multiuse case), time consuming, and cognitively engaging”, the Microinteractions are “simple, brief, and should be nearly effortless”. (pg 5)
Microinteractions are part of a feature. They are good for users to accomplish a single task by interacting with a single piece of data.
Everything we “interact with every day on desktops, laptops, and mobile devices were once novel microinteractions: everything from saving a document to organizing files into folders to connecting to a WiFi network were all microinteractions that needed to be designed”.
Hummmm nice! What I should have in mind when designing a Microinteraction?
Principle: do not start from scratch; instead, use data about users and analyze the context to understand what users want to do.
These are the elements you should tackle to design your microinteractions.
Triggers – initiate the Microinteraction
- Can be initiated by the user (manual) or by the system (defined rules).
- Can be hidden. E.g. swipe left/right.
- Must be recognizable in its context.
- Must perform the same action every time.
- Should show essential information from inside the microtinteraction. E.g. a shopping cart showing how many items have been added to it.
- Its visual affordance must be consistent. E.g. a button should act like a button.
- Should have brief labels when clarity is needed.
Rules – determine how microinteractions function
- Define what should be done and in what sequence.
- Must reflect business, contextual, and technical constraints.
- Should not be complex: controls and options should be reduced to a minimum.
- Should use smart defaults.
- Should have different states for different objects.
- Should prevent errors.
- Must be based in human values.
Feedback – generated by Rules
- Based on the understanding of what users need to know and when.
- Provides personality to the microinteractions.
- Helps to understand the rules of the microinteraction, therefore should not be arbitrary.
- Should be linked to the control or to the resulting behaviour.
- Should be conveyed through the correct channel(s).
- Might change the user context.
- Whenever possible, should be visual. Sounds can be used for emphasis and alerts.
Modes – determine different states
- Should be avoided in microinteractions, because it requires users to relearn the microinteraction.
- If needed, should have their own screens to help reduce errors and frustration. E.g. Settings.
- Spring-loaded modes: only active when the user performs a physical action and returns to the default as soon as the action stops.. E.g. pressing a button, hovering a link. Or, initiated by invisible triggers. E.g. forms autofill.
- One-off modes: gestural and voice microinteractions to issue another command.
Loops – Determine how long the modes will last
- Cycle that repeats for a set of duration, indicated by the rules.
- Open loops: do not respond to feedback; execute and end.
- Closed loops: self-adjusts the feature.
- Should be used with care: make sure to not go on too long processes or end a process/microinteraction.
- Long-loops: for memory, progressive disclose, to reduce microinteraction aspects over time.
Putting all Together
- Prototypes and documentation help to communicate the idea.
- Static screenshots don’t convey states from any context.
- Designing non-stand alone microinteractions: understand its relationship with other microinteractions and the feature.
- Think small: details demonstrate some care and demonstrates humanity.
Testing a Microinteraction
- The overall concept is valuable, but tests are regarding microinteraction’s flow and structure.
- Need a high fidelity prototype.
- Tight links among triggers, rules, feedback, loops.
- Look for understanding: the goal, not just a step in the process; the data from bahaviours and context; the necessary microcopy; timing and flow.
- Use quantitative data as a starting point for improvements.
Confused? Take a look in this Infographic then. (source: microinteractions.com).
Don’t know how to start? Read the book, it’s very insightful! 😉
Details are those small pieces that delight users and could make your product unforgettable. Think about them carefully 🙂
Let’s keep the conversation. Why don’t you share your good or bad microinteraction examples with us?
My favourite: Shazam. I wrote about it already. The whole app is a single microinteraction: tap the button to capture the song > get the music info. Period. Perfect.
What about yours?