Review

A nice short book on microinteractions. The tiny moments that make all the difference when you build a product. One of the reasons I love product management is the contrast between big and small. Thinking expansively about vision and strategy, whilst also getting into the weeds and sweating the small details that make something feel great to use.

This is a great reference book, and it has some frameworks and lists that I return to.

Key Takeaways

The 20% that gave me 80% of the value.

• A micro-interaction is a contained product moment that revolves around a single use case
  • A small tiny piece of functionality, that does one thing

Details aren’t just the details, they are the design.

Charles Eames

• The overall experience of a product relies heavily on micro-interactions (the ‘look and feel’)
• In a competitive market, they’re more important. When there’s feature parity, it is the experience using the product that increases adoption and brand loyalty

• An iPhone alarm accidentally goes off in a theater. Apple’s relevant design choices:
  • Muting doesn’t silence sounds you’ve asked for (alarms) only ones you haven’t (calls)
  • Upcoming alarms aren’t shown when you silence your iPhone

• All the basic interactions like scrolling and clicking needed to be designed and engineered
• Electrification and then software changed everything, buttons suddenly became abstracted further
• The anatomy of micro-interactions:

Trigger	Initiates the MI (Micro-interaction)
Rules	Determine how the MI works
Feedback	Illuminates the rules
Loops & Modes:	the meta rules that affect the MI

• A trigger can be user initiated or system initiated.
  • Many MIs begin with the understanding of user need: what the user wants to accomplish
• Rules determine what happens once a MI has been initiated
  • Rules are themselves invisible
• Feedback: anything that you see, hear or feel that helps you to understand the rules of the system is feedback.
  • Can be visual, aural, haptic.
  • Match feedback to the action, to convey information in the most appropriate channel
  • Feedback is the place to express personality of the product
• Loops & modes make up meta-rules. What happens over time with the MIs
  • Do they remain until manually turned off?
  • Do they expire after a while?
  • What happens during an interruption or when conditions change?
  • A weather app might display weather where you are.. but have a separate mode to display weather elsewhere

• Three ways to think about incorporating them into products:
  1. On a case-by-case basis.
  2. Use them to reduce more complex applications
  3. Complex digital products are made up many micro-interactions.

Principles of Triggers

1. Make the trigger something the target users will recognize as a trigger in context
   • Make it look like you can do something, make it engaging
2. Have the trigger initiate the same action every time
3. Bring the data forward
   • The trigger can reflect data contained inside the MI
   • What can you show? What’s the most important thing to show?
4. Don’t break the visual affordance
   • If it looks like a button, it should work like a button, and be able to be pushed
5. The more frequent the micro-interaction is used, the move visible it should be
6. Don’t make a false affordance
   • Looks like a button? Should act like a button.
7. Add a label only if it provides information that the trigger itself cannot

• The components of a trigger include controls, states of controls and text or labels (text or icono-graphic)

Controls

• The kind of control should be determined by how much control you want to give

Action	Example	Control
Single action	Fast forward	Button or gesture
Action with two states	On or off	Toggle switch
Action with several states	Modes on a camera	Dial or set of buttons
Action on a continuum	Adjusting volume	Slide or dial
Complex manual triggers	Form fields	Text fields etc

• Think about minimizing choice:
  • provide a smart default
  • provide a very limited number of choices
• Controls are couples with visual affordances (what users expect can be done)
• The more frequent the micro-interaction is used, the more visible it should be
• Two ways humans become aware of something: stimulus-driven attention/goal-based attention
• Use standard controls as much as possible
• Invisible triggers are often sensor based (sometimes a command key, or mouse movement)
• Invisible controls allow for an emphasis on what is visible (content)
  • Invisibility shouldn’t be a goal, but is it OK to ask, what makes sense to hide given this environment?
• The best micro-interactions have just enough interface but no more

States of controls

• Consider the following states:
  • Default: the idle state with no activity
  • Active: there is an activity working in the background (downloading, syncing)
  • Hover: can use tool-tip-style descriptions, or display relevant data
  • Rollover: signals the cursor is in the right place to engage (with say a text field)
  • On click/tap/process: what happens when a trigger is clicked (expand, disappear, change)
  • Toggle: indicate the current setting
  • Setting: dials and switches can show their current setting
• Labels can name the whole micro-interaction or they can be indicators of state too. The purpose of a label is clarity
• System Triggers
  • Most triggers aren’t human initiated anymore
  • Common trigger initiation conditions:
    • Errors, location, incoming data, internal data, other micro-interactions , other people
• System trigger rules:
  • How frequently should this trigger initiate?
  • What data about the user is already known? (could that be used to make this trigger more effective?
  • Is there any indicator the trigger has initiated? Visible state change? After it’s about to happen? Before it’s about to happen?
  • What happens when there is a system error?
• Rules
  • If you can’t easily write out or diagram the rules of a micro-interaction, users are going to find the mental model difficult
  • Unless it’s radically new, users come to micro-interactions with a set of expectations. You can only violate them if you’re offering something of significantly higher value.

Things which are different in order simply to be different are seldom better, but that which is made to be better is almost always different

Dieter Rams

Designing Rules

• Try to create a simplified nontechnical model of how the MI operates with your rules
• Determine what the goal of the MI is – before determining the rules
• The best goals are understandable and achievable. Focus on the goal not the steps.
• Rules shouldn’t feel like rules, or instructions, make them feel natural.
  • How the MI responds to the trigger being activated
  • What control the user has over a MI ‘in process’
  • The sequence in which actions take place and timing thereof
  • What data is being used and from where
  • The configuration and parameters of an algorithms
  • What feedback is delivered and when
  • What mode the interaction is in
  • If the micro-interaction repeats and how often
  • What happens when the micro-interaction ends
• Any object the user can interact with can have at least three states
  1. An invitation / default state
  2. Activated state
  3. Updated state
• Constraints: Rules have to take into account business, environmental and technical constraints
  • What input and output methods are available?
  • What is the type or range of any input?
  • What is expensive?
  • What kind of data is available?
  • What kind of data can be collected?
• Don’t start from zero: What do I know about the user and the context?
• Temporarily increasing the brightness of the screen when showing a QR code.
• Conservation of complexity: All activities have an inherent complexity, there is a point beyond which you cannot simplify a process any further.
• Limit options and choose smart defaults
  • Keep rules to a minimum by limiting options (be ruthless)
• The most prominent default should be the action that most people do most of the time
• For controls choose between operational simplicity and perceived simplicity
  • Operational: gives every command its own control (volume up, volume down, mute)
  • Perceived: a single control does multiple actions (volume slider)
• 4 parts to any algorithm: sequence, decisions, repetitions, variables

Feedback

• Feedback illuminates rules.
• If you push a button two things should happen:
  • the button has been pushed
  • what has happened as a result of that button being pushed
• Feedback should help users build a mental model of the micro-interaction
• Feedback should be driven by need. What does the user need to know?
• Feedback should occur:
  • Immediately after a manual trigger
  • On any system-integrated triggers in which the state of the micro-interaction has changed significantly
  • Whenever a user reaches the edge of a rule
  • Whenever the system cannot execute a command
  • Showing progress on any critical processes
• Feedback is for humans:
  • Something has happened
  • You did something
  • A process had started
  • A process has ended
  • A process is ongoing
  • You can’t do that
• Less is more with feedback. The more methods you use the more intrusive
• Principles of feedback
  1. not to overburden users with feedback
     • what is the least amount of feedback that can be delivered to convey what is going on
  2. the best feedback is never arbitrary
     • it always exists to convey a message that helps users
  3. convey the most with the least
  4. use the overlooked as a means of message delivery
• You can use feedback to inject personality
  • feedback is for humans, so inject some personality
• Animations should be: fast, smooth, natural, simple and purposeful.
  • Maintaining context while changing views (scrolling a list)
  • Explaining what just happened (poof of smoke = item deleted)
  • Showing relationships between objects (animating drag and drop into folder)
  • Focusing attention
  • Improving perceived performance (progress bars)
  • Creating an illusion of virtual space
  • Encouraging deeper engagement
• Foghorn test: is this action important enough that users would want to become aware of it when they cannot see it?
• Three main use cases of haptics
  • Enhance a physical action
  • As an alert when audio isn’t available or undesirable
  • Create an artificial texture or friction on surfaces
• Feedback rules:
  • Contextual changes: Does it change based on known context? (at night)
  • Duration: How long does the feedback last? What dismisses it?
  • Intensity: Intensity. how bright, fast, loud, is the effect?
  • Repetition: Does the feedback repeat? How often?

• Modes are parts of an application in which the app operates differently than usual
  • Often this means doing a certain action does something else when in a particular mode
  • A mode is a fork in the rules
  • Use modes very very sparingly
  • The best reason for a mode is when there is an infrequent action that would otherwise clutter the UI
    • e.g. a settings mode
  • Modes are best avoided because they can cause errors
• Loops: A cycle that repeats for a set duration.
  • Four types of loops:
    • Count-controlled loop: repeats for a set number of times (FOR)
    • Condition-controlled loop: repeats while a condition is true (WHILE)
    • Collection-controlled loop: runs through everything in a set, then stops
    • Infinite loop: begins and never ends until there is an error or somebody shuts it down
  • Open loops do not respond to feedback, they execute and end
  • Closed loops have a feedback mechanism built in and are thus self-adjusting
  • Loops can be used to make sure an action doesn’t go on too long
  • Progressive disclosure or reduction:
    • As users become used to a product, they don’t need as much hand holding, and can be treated as a more skilled user.
    • Progressive reduction → where the MI becomes simpler over time, the user doesn’t need labels for guidance anymore

• How to fix a dull micro-interaction:
  • Should this be a signature moment?
  • Am I starting from zero? What do I know about the user or context?
  • What is the most important piece of data inside this micro-interaction? Can I bring it forward?
  • Would a custom control be appropriate?
  • Am I preventing human errors?
  • Am I using what is overlooked?
  • Can I make an invisible trigger for advanced users?
  • Are the text and icons human?
  • Can you add animation to make it less static?
  • Can you add additional channels of feedback?
  • Ask what happens when the user returns to the micro-interaction the second time?

Remember the small things matter, they always have!