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.

You Might Also Like:

Book Review and Summary: Think Like an Architect by Hal Box

Get a comprehensive review and summary of the best-selling book "Think Like an Architect" by Hal Box, the renowned architect and educator. Learn about the key principles and practices of design thinking and problem-solving, based on Box's own experience and insights.

andrewclark.co.uk

Book Review and Summary: The Design of Everyday Things by Donald A. Norman

Get a comprehensive review and summary of the classic book "The Design of Everyday Things" by Donald A. Norman, the user experience and design expert. Learn about the key principles and practices for designing products and environments that are intuitive and enjoyable for users.

andrewclark.co.uk

Designing Interactions

This is a collection of interviews that meanders through the history of interaction design. It lacks some structure and isn’t exactly insight dense. I’m interested in the history of computers and the pioneers of early computing - so I found it enjoyable. I wouldn’t recommend if you’re looking for something more practical.

andrewclark.co.uk

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 theatre. 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 windows 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 recognise 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 iconographic)

• 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.
‣
The rules determine:
• 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

• 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 doest 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.
‣
Reasons for using animation:
1. Maintaining context while changing views (scrolling a list)
2. Explaining what just happened (poof of smoke = item deleted)
3. Showing relationships between objects (animating drag and drop into folder)
4. Focusing attention
5. Improving perceived performance (progress bars)
6. Creating an illusion of virtual space
7. Encouraging deeper engagement
• Foghorn test: is this action important enough that users would want to become aware of it when they cannot see it?

• 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!

Deep Summary

Longer form notes, typically condensed, reworded and de-duplicated.

Chapter 1: Designing Micro Interactions

• 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
• They are everywhere (change a setting, get a message, use an appliance)
• They are the functional, interactive details of a product
• They can be
• Dull, forgettable, pleasurable, exciting , engaging, invisible, frustrating, clever, forgotten
• The difference between a product you love and a product you tolerate is often the micro-interactions you have with it.

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

• Experience design is paying attention to the details, as well as the big picture so users have a great experience using the product
• Micro-interactions differ from features in both their size and scope.
• Features are tend to be complex, multi-use-case, time consuming and cognitively engaging
• Micro-interactions are simple, brief and effortless
• E.g. A music player is a feature, adjusting the volume is a Micro-interaction
• Examples
• Connecting devices together
• Adjusting a setting
• Controlling an ongoing process (changing the tv channel)
• Viewing or creating a small piece of content
• Accomplishing a single task
• Often the last thing to be designed. It’s a big mistake to ignore them.
• The overall experience of a product relies heavily on micro-interactions (the ‘look and feel’)
• The design of your product is only as good as the smallest part.
• In early stages of technology, they’re less important
• 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
• Micro-interactions force designers to work simply, to focus on details. To reduce complexity.

• An iPhone alarm accidentally goes off in a theatre. 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

History of Micro Interactions

• Larry Tesler worked on the first WYSIWYG word processor at Xerox Parc (Gypsy for the Alto)
• He worked hard to reduce the modality of the interface, so users didn’t have to switch to a separate mode to perform actions
• He invented copy and paste (previously, it was a clunky process involving different modes and interactions)
• The history of human-computer interaction design is really the history of micro-interactions
• All the basic interactions like scrolling, and windows needed to be designed and engineered
• Alan Kay introduced scroll bars in SmallTalk (it was smooth, pixel by pixel not line by line)
• Apple changed it’s Mac scrolling direction after introducing the iPhone
• From Bill DeRouchey’s talk ‘The history of the button’
• Pre-Electric: buttons were mechanical, cause and effect were clear
• Post-electrification: everything changed, buttons were disconnected from things
• Software: actions become abstracted further

Structure of Micro-Interactions:

• The anatomy of micro-interactions:

Trigger	Initiates the MI (Micro-interaction from here on)
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
• The trigger for silencing your phone, is a physical switch on the side, always available
• 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.
• Prominent and unmissable, or subtle and ambient
• Match feedback to the action, to convey information in the most appropriate channel
• Feedback is the place to express personality of the product
• Feedback can be graphics, sounds, animations etc
• How does it appear, disappear?
• What happens when an item moves? How fast? What direction?
• 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

Turning on a light:

• Trigger: the light switch
• Rule: the light stays on at max brightness until switched off
• Feedback: the light illuminates
• Loops & modes: None

Micro-interactions as a Philosophy

• Three ways to think about incorporating them into products:
1. On a case-by-case basis.
• Identify micro-interaction as you go
• Consider their structure and polish each one
• Create ‘signature moments’ are MIs that are product differentiators, that help create customer loyalty and recognition.
2. Use them to reduce more complex applications
• Make a product about a single micro-interaction
• Micro-interaction as product strategy: your product does one thing and one thing well
3. Complex digital products are made up many micro-interactions.
1. View a product as the result of all the micro-interactions working in harmony
2. The details are the design.
3. Everything’s a detail, everything’s a micro-interaction.
4. A chance to delight

Summary

4. Micro-interactions are the small pieces of functionality that are all around us.
5. Focusing on them is the way to create a superior user experience.
6. The history of micro-interactions stretches back to the first electric devices. Most of the digital standards we’re used to now were once novel micro-interactions.
7. A micro-interaction is made up of four parts:
• triggers that initiate it
• rules that determine how it functions
• feedback that the rules generate
• loops and modes that make up its meta-rules
8. There are three ways of working with micro-interactions:
• look for them and focus on each individually
• reduce a complicated feature to a core micro-interaction
• or treat every feature as a set of linked micro-interactions

Chapter 2: Triggers

9. Introducing touch screen ticket kiosks to the NY subway:
• People hadn’t used them before
• Making each screen do just one task, got people through quicker than trying to save screens
• Turned the entire touchscreen into a trigger / call to action (Touch start to begin, touch start)
• Made a small start button (despite the fact you could tap anywhere on a screen)
10. Manual triggers usually spring from a user want or need (I want to turn on the TV)
• Its important to understand what a user wants/needs to do and when
• That should shape when and where you manual trigger should instantiate
11. Principles of Triggers
1. Make the trigger something the target users will recognise 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
12. The components of a trigger include controls, states of controls and text or labels (text or iconographic)
13. 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 minimising choice:
• provide a smart default
• provide a very limited number of choices
• Controls are couples with visual affordances (what users expect can be done)
• Don’t break the visual affordance
• The more frequent the micro-interaction is used, the more visible it should be

Micro-interactions that most people do, most often, should be highly discoverable. Micro-interactions that some people do, somewhat often, should be easily discoverable. Micro-interactions that few people do, infrequently, should take some searching to find. Adapted Scott Berkun quote

• Two ways humans become aware of something:
• Stimulus-driven attention: It involuntarily attracts our attention (through movement or sound)
• Goal-based attention: we actively turn our attention on items/areas to see if we can find something that meets our current needs
• Narrow focus /field of view to just 1% of what we usually see
• Engage in object recognition → look for familiar shapes ‘Geons’
• Geons: simple shapes (squares, triangles, cubes, cylinders)
• It’s easier to find a target when we’re looking for a single-characteristic
• Once an item is identified, we associate an affordance to it (I can push it)
• The least amount of cognitive effort is the goal. Don’t make a false affordance. Don’t make users guess how a trigger works.
• Use standard controls as much as possible.

Innovate as a last resort Charles Eames

‣
Triggers ranked by how discoverable they are:
• A moving object
• An object with an affordance and label
• An object with a label such as a labeled icon
• An object alone, such as an icon
• A label only, such as a menu item
• Nothing: an invisible trigger
• Invisible triggers
• Invisible triggers are often sensor based (sometimes a command key, or mouse movement)
• Touch screen UIs contain the most invisible controls. Gestures often discovered through the process of trial and error
• Voice input is an example of an invisible control. There are three types:
• Always listening
• Dialogue
• Combined with a control
• 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
• Invisible triggers should be learnable (being learnable beens being nearly universally available, or only available in certain conditions)
• They should be guessable.
• Don’t use invisible micro-interactions for high-priority MIs
14. 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
15. Text or iconographic labels
• Labels can name the whole micro-interaction or they can be indicators of state too.
• The purpose of a label is clarity
• Only provide a label if there could be ambiguity
• Labels should be short, descriptive and clear (’Submit’)
• System Triggers
• Most triggers aren’t human initiated anymore
• Common trigger initiation conditions:
• Errors, location, incoming data, internal data, other micro-interactions , other people
• If a user isn’t initiating them, then it’s good practice to provide ways to control them
• Manual means of managing or disabling it
• Users might want a manual control in addition to a system one. E.g. ‘Sync Now’ to provide assurance
• 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?

Chapter 3: 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.
• The rules determine:
• 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
• Generating rules:
• Write down all the general rules you know
• A rules diagram can help you see the rules in a visual way
‣
Rules diagram example

• Think of your micro-interaction as a sentence
• Verbs are the actions that a user can engage (raise or lower)
• Nouns are the objects that enable those actions (the slider)
• The nouns have states - these should be defined by rules
• Nouns should be unique
• Objects that behave differently should look differently
• The best micro-interactions allow users a variety of verbs with the fewest possible nouns
• 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?
• Platform, time of day, noise in the room, how long since the MI was used, is the user in a meeting, is the user alone, the battery life, the location or direction, what the user has done in the past
• Temporarily increasing the brightness of the screen when showing a QR code.
• Use context and previous behaviour to predict or enhance the micro-interactions
• Conservation of complexity: All activities have an inherent complexity, there is a point beyond which you cannot simplify a process any further.
• Work out what type of complexity there is, and decide if better handled by the user or the system
• If it’s calculation or memorisation, use the computer
• Limit options and choose smart defaults
• Fewer rules make for better and more understandable micro-integrations
• Keep rules to a minimum by limiting options (be ruthless)
• More than one major option is probably too many
• The most prominent default should be the action that most people do most of the time
• Removal of choice also removes edge cases.
• Controls and user input
• 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)
• Preventing errors
• Poka-Yoke (mistake proofing): products and processes should be designed so that it’s impossible for users to commit an error
• Reducing choice is seldom a bad practice
• Microcopy
• Labels and instructions are a kind of fixed feedback or feedforward
• Make sure text is necessary for understanding
• Never use instructional copy when a label will suffice
• 4 parts to any algorithm: sequence, decisions, repetitions, variables

Chapter 4: Feedback

• Slot machines are addictive because they provide via feedback intermittent reinforcement of behaviour
• Feedback is a powerful micro-interaction
• 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 doest 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
• Visual feedback
• Most feedback is visual (default to visual)
• If asking the user to make a decision, surface things that are helpful…
• resources, time, effort, unread messages
• Any visual feedback must add clarity not clutter
• Don’t put visual feedback on or over the point of user input
• Animation
• use animation sparingly, it’s powerful
• the best animations communicate something to the user
• Animations should be: fast, smooth, natural, simple and purposeful.
• Three reasons for using animation:
1. Maintaining context while changing views (scrolling a list)
2. Explaining what just happened (poof of smoke = item deleted)
3. Showing relationships between objects (animating drag and drop into folder)
4. Focusing attention
5. Improving perceived performance (progress bars)
6. Creating an illusion of virtual space
7. Encouraging deeper engagement
• Messages:
• Should be short and factual (measure in words not lines)
• Audio
• Two ways to use audio feedback:
• Emphasis: reinforcing user action
• Alerts: indicators of system initiated actions
• Foghorn test: is this action important enough that users would want to become aware of it when they cannot see it?
• Haptics (vibrotactile feedback)
• Three main use cases:
• 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?

Chapter 5: Loops and Modes

• 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
• Modes:
• 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
• Best kept for deviations from the rules that take you away to do a subtask and then return
• Modes are best avoided because they can cause errors
• In micro-interactions there should be no more than one and zero if possible, so there’s no chance of being confused about what mode they’re in.
• If you must introduce another mode, make the transition in and out clear
• Spring-loaded modes: only active when a physical action such as pressing a key is occurring (holding down the shift key to type in capitals)
• The user doesn’t forget they’re in these modes
• One-off modes: when a user starts a mode that lasts for the duration of a single action (copy and paste test selection on iOS)
• 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
• or end a process or even the entire MI
• The Long Wow: is about delivering new experience or features over time instead of all at once, and by doing so building customer loyalty
• 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

Chapter 6: Putting it all together

• Prototyping and documenting micro-interactions
• About communicating an idea. About how something could work
• The most difficult idea to convey, is the overall flow. How all the pieces fit together.
• The overall flow that communicates how the MI should feel
• The best ways to do it:
• Prototype, make a movie, create a frame by frame storyboard
• Orchestrating Micro Interactions
• What relationship does the micro-interaction have with the feature
• Launch it, control it, appear inside it?
• Should it be memorable? A signature moment?
• It can be helpful to have a master list of all the micro-interactions that need to be designed to make a feature work properly

• 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!