Microinteractions: The Details That Make the Product

What microinteractions are, Dan Saffer's four parts, and how to design feedback, animation, and error states that do not slow the user down.

info Quick Definition

A microinteraction is a minimal piece of interaction that does a single task: changing a button’s state when pressed, confirming that a change was saved, or showing an indicator while dragging something. Dan Saffer describes it with four parts: trigger, rules, feedback, and loops and modes.

What is a microinteraction and what are its parts?

A microinteraction is not a screen or a full flow. It is the short moment when the user does something and the product responds. In Microinteractions: Designing with Details (O’Reilly), Dan Saffer proposes analyzing it with four parts:

Trigger: what starts it. It can come from the user, such as pressing or dragging, or from the system, such as an incoming notification or a change in the connection.
Rules: what happens when it fires and under which conditions. A “Like” button that only works with an active session has a rule.
Feedback: what the user sees, hears, or feels to know what happened.
Loops and modes: what happens if the action repeats (a loop) and whether the microinteraction changes behavior depending on context (a mode).

Rules are rarely visible. Users learn them through feedback: if the button responds, they understand the rule works; if it does not, they assume the interface is broken. That is why feedback is the most visible part of the work, even though the logic underneath matters more.

Why does this matter for a junior designer?

Because a product is used through dozens of microinteractions, and almost nobody reviews them one by one. A form that does not flag an invalid field until submission, a button that does not change during loading, or a “like” that takes a second to show up are small details, but each one adds friction to every use.

The general reference is system response time. In its usability heuristic on visibility of system status, Nielsen Norman Group asks designers to keep users informed with appropriate feedback, immediately whenever possible. Its response-time limits set three thresholds:

Time	What the user perceives	What to do
Up to 0.1 s	An instant reaction	Showing the result is enough
Up to 1 s	The delay is noticed, but the train of thought is not broken	A simple visual change
Up to 10 s	A wait that still holds attention	Show that the system is working (cursor, activity indicator)
Over 10 s	Attention drifts and the user has to reorient	A percent-done progress bar and a clear way to cancel

Laws of UX adds Doherty’s threshold: the system should respond in about 400 milliseconds for the interaction to feel fluid. It comes from a 1982 IBM study, so treat it as a guide, not a universal rule. When waiting is unavoidable, the page on loading states explains how to show it without annoying the user.

How do you design a microinteraction, step by step?

Define the task and the trigger. Write in one sentence what the microinteraction does and who starts it. If you need two sentences, you probably have two microinteractions.
Write the rules in plain language. If you cannot explain them in two or three sentences, the rule is not clear yet, and it will not be clear to the user either.
Choose feedback by duration. A response under 0.1 seconds can be a color or state change. A wait of several seconds needs a progress indicator or text that says what is happening.
Decide whether to animate and how much. Nielsen Norman Group recommends that cause-and-effect animation start within 0.1 seconds of the user’s action. It also warns that repeated animations become frustrating. Animate to explain a change, not to decorate.
Design the error and loading states before the happy path. The easy version is the ideal case. What makes a microinteraction good is how it behaves when the network fails, the data is missing, or the user repeats the action.

For the rules side, interaction cost can help you decide which steps are unnecessary before you polish the feedback.

When should you NOT add animation?

When the action repeats many times. A menu that opens with a half-second animation feels slow if it opens a hundred times a day. Nielsen Norman Group names this as a source of frustration.
In critical actions. Confirming a payment or deleting data needs clear feedback. A flashy animation can pull attention away from the confirmation text.
When the user has asked for reduced motion. Interaction-triggered animation should be possible to turn off unless it is essential to understanding the information (WCAG 2.2, criterion 2.3.3). WCAG technique C39 uses the prefers-reduced-motion media query to respect that preference. You can also review reduced-motion strategies.

Example

Illustrative example: a “Save changes” button in a profile editor.

Trigger: the user presses the button.
Rules: the button is active only when there are unsaved changes.
Feedback: on press, the button changes to “Saving…” with an indicator. When done, it shows “Changes saved” and returns to its inactive state.
Loop: if the user edits a field again, the button becomes active again.
Error mode: if the network fails, the button shows “Could not save. Retry” and keeps the changes so they are not lost.

Review each part separately. If the button has no error state, the microinteraction is incomplete, even if the demo works perfectly. To go deeper into deciding whether to show a change before or after confirmation, the page on skeleton vs. optimistic UI is the next step.

Related to status feedback is status awareness: users should be able to tell where the system is without guessing.

Common mistakes

Animating for decoration, with no function to explain.
Giving feedback late and leaving the user without a response for more than a few hundred milliseconds.
Designing only the happy path and forgetting error, loading, and empty states.
Repeating a long animation the user will see dozens of times a day.
Ignoring the reduced-motion preference set in the operating system.
Using color alone as feedback, with no text or icon, which excludes people with color blindness.

Sources

Nielsen Norman Group, 10 Usability Heuristics for User Interface Design
Nielsen Norman Group, Response Times: The 3 Important Limits
Nielsen Norman Group, Animation Usability
Laws of UX, Doherty Threshold
W3C, Understanding SC 2.3.3: Animation from Interactions

Frequently asked questions

What is a microinteraction in UX?

It is a minimal, self-contained interaction that does one task, such as changing a button’s state when pressed or confirming that a change was saved. It has a trigger, rules, and feedback.

What are the parts of a microinteraction?

In Dan Saffer’s model there are four: the trigger, the rules, the feedback, and the loops and modes. The trigger can come from the user or from the system.

How fast should an interface respond?

Nielsen Norman Group sets three limits: about 0.1 seconds to feel instant, 1 second to keep the user’s train of thought uninterrupted, and 10 seconds as the limit of attention.

Are animations required in a microinteraction?

No. They should serve a purpose and be possible to turn off. WCAG 2.2 (criterion 2.3.3, level AAA) asks that interaction-triggered animation can be disabled unless it is essential.

What is the difference between a microinteraction and an animation?

An animation is only the visual movement. A microinteraction includes the action that triggers it, the rule that decides what happens, and the result the user understands. The animation is one form of feedback.