Micro-Interactions: Design the State Change

A payment button changes to a spinner. The request times out, but the spinner keeps turning. The user cannot tell whether to wait, try again, or check their bank account.

The animation is smooth. The interaction is broken.

A micro-interaction is not a decorative moment around a click. It is the small contract that tells a person what action is available, whether the system accepted it, what changed, and how to recover when the change does not complete.

Design the state transition first. Motion, sound, vibration, and visual polish can then explain that transition. They cannot replace it.

Write the interaction contract

Start with a state model rather than a motion study.

For one user action, record:

• Intent: what the person is trying to make true;
• eligibility: when the action is available and why it may not be;
• trigger: pointer, keyboard, touch, voice, shortcut, or system event;
• acknowledgement: evidence that the system received the request;
• pending state: what remains possible while work continues;
• outcome: the authoritative state after success, partial success, or failure;
• recovery: retry, undo, correction, escalation, or safe exit;
• persistence: whether the state survives refresh, navigation, another device, or another actor.

That contract exposes questions a prototype can hide. Can the request be submitted twice? Can the user leave? Does “saved” mean accepted locally, stored by the service, or visible to collaborators?

For consequential actions, define the source of truth. A green check rendered by the client is not proof that a server accepted a payment, permission change, or deletion.

The broader system-design guide covers authoritative state, invariants, failure recovery, and observability.

The micro-interaction should tell the truth about that system in language the user can act on.

Make availability legible before activation

Feedback begins before the action. People need to recognise what can be used, what state it is in, and what consequence activation may have.

A control can be visually prominent and still be ambiguous. “Continue” may submit data, start a paid plan, move to a reversible preview, or close a step that cannot be reopened.

Name the consequence when it matters. Keep destructive and committing actions distinguishable from navigation.

If a control is unavailable, decide whether disabling it is useful. A disabled button with no explanation creates a dead end.

Sometimes it is better to keep the action available and explain the missing requirement after activation. Sometimes the requirement can be stated beside the disabled control.

The choice depends on whether the user can resolve the condition now.

Do not encode state in colour alone. Combine colour with text, shape, iconography, position, or another signal appropriate to the interface.

The WAI-ARIA Authoring Practices button pattern describes keyboard activation and the aria-pressed state for toggle buttons.

The guide is non-normative accessibility practice, not a complete component specification. Its useful boundary is clear: a custom visual element does not acquire button behaviour or state semantics merely because it looks clickable.

Acknowledge receipt without claiming completion

After activation, show that the request was received. Do not use the same signal for receipt and completion.

For a local toggle, acknowledgement and completion may be effectively one state change. For a network request, upload, approval, or payment, they are different events.

Use language that preserves the difference:

• “Saving…” describes work in progress;
• “Saved on this device” defines a local boundary;
• “Submitted for review” names the new workflow state;
• “Payment confirmed” should appear only after the authoritative confirmation;
• “We could not confirm the payment” is safer than “Payment failed” when the outcome is genuinely unknown.

Optimistic interfaces can be valuable when operations are low-risk, reversible, and likely to succeed. They become deceptive when the product shows a durable result before it can preserve or reverse that result safely.

State the rollback behaviour before choosing optimism. If the request fails after the interface moved on, where will the user see the correction? What work might they have performed on a false premise?

Design the pending state as a usable state

“Loading” is not one condition. The product may be waiting for a network, processing locally, queued behind other work, awaiting another person, retrying, or unable to determine the outcome.

The pending state should answer the questions that affect behaviour:

• Is work still progressing?
• Can the user continue elsewhere?
• Is it safe to repeat or cancel the action?
• Will the result arrive later?
• What input or dependency is blocking it?
• Where can the result be found after leaving?

Avoid inventing precision. A percentage is useful only when the system can measure meaningful total work.

A looping indicator is more honest than a fabricated progress bar, but it still needs an escape or explanation when delay becomes material.

Preserve input where possible. A failed form submission should not make the person reconstruct valid work because one field or service failed.

Do not trap focus in a status indicator. People should be able to inspect the message, continue permitted work, or reach recovery actions using their input method.

Announce status without stealing control

Visual change is not enough for people who do not see the changed region or who are focused elsewhere.

WCAG Success Criterion 4.1.3 on status messages requires status messages to be programmatically determinable.

This enables assistive technologies to present the message without receiving focus. The Understanding document is informative, and its scope is status messages rather than every content update.

The aim is awareness without unnecessary interruption. That does not mean every state change belongs in a live region.

Announcing hover decoration, every validation keystroke, or repeated background progress can create noise. Prioritise state changes needed to understand the result or continue the task.

Focus movement is a separate decision. Move focus when a new context genuinely requires immediate interaction, such as a modal dialog or a blocking error summary designed for that pattern.

Do not move focus merely to make an update noticeable. Unexpected focus changes can disorient keyboard and assistive-technology users and can interrupt input already in progress.

WCAG Success Criterion 3.2.2 on input says that changing a control’s setting should not automatically cause a change of context unless the user was advised beforehand.

That criterion concerns predictable behaviour, not a ban on dynamic interfaces. The product must distinguish changing a setting from intentionally activating a control that submits, opens, or navigates.

Use motion to explain causality

Motion can show where an object came from, what it is attached to, whether a layer replaced another, or how an action changed the visible hierarchy.

It should answer a spatial or causal question. If removing the motion leaves the transition equally clear, the motion may be style rather than explanation.

Design the no-motion version at the same time.

WCAG’s Level AAA criterion on animation from interactions applies to motion animation triggered by interaction.

It requires a way to disable that animation unless the movement is essential to the function or information.

The guidance supports prefers-reduced-motion as one technique. Reduced motion is not necessarily zero feedback.

Replace large movement, parallax, zoom, or simulated physical travel with an immediate state change, short opacity change, restrained highlight, or text update. Preserve the information while reducing the motion that conveys it.

Do not assign universal durations to “small,” “medium,” and “important” interactions. Suitable timing depends on distance, device, input, interruption cost, content, and whether the user is waiting repeatedly.

Test perceived continuity and task speed with representative users and hardware. A timing token can create consistency, but it cannot decide what the interaction needs to communicate.

The canonical design-token guide explains how shared values can become governed platform outputs. Motion tokens should encode approved decisions, not conceal untested timing behind names.

Treat performance as part of the meaning

An interaction that drops frames, acknowledges late, or presents states out of order changes the message it sends.

The web.dev animation performance guide recommends favouring transform and opacity for CSS animation and avoiding properties that trigger layout or paint where possible.

That is web implementation guidance, not proof that every transform animation is useful or accessible. It also does not replace measurement on the product’s devices and content.

Inspect more than frame rate:

• input-to-acknowledgement delay;
• long tasks during interaction;
• layout shifts that move the target;
• duplicated actions caused by late feedback;
• stale responses overwriting newer state;
• animation behaviour on lower-powered devices;
• the reduced-motion path;
• recovery after offline, timeout, or interrupted navigation.

Instrument the state machine, not only the click. The sequence requested → accepted → processing → completed tells a different story from a single “button_clicked” event.

Telemetry should also distinguish user cancellation, validation rejection, server failure, unknown outcome, and successful completion. Otherwise the team cannot tell interaction friction from system failure.

Build components around behaviour

A component library should encode the reliable parts of an interaction:

• input and keyboard semantics;
• focus and status behaviour;
• allowed states and transitions;
• disabled and read-only distinctions;
• pending, success, failure, and recovery patterns;
• reduced-motion behaviour;
• event and telemetry contracts.

Do not make every product case look identical. A low-risk preference toggle and an irreversible account deletion may share a button primitive but require different confirmation, pending, and recovery contracts.

Document when the pattern applies, which product risks it does not cover, and how a team can extend it without breaking semantics.

A design handoff should therefore include behaviour and state ownership, not a sequence of ideal screenshots.

Engineers need to know what can happen between the frames and which service event makes each state true.

Review the running product. Static approval cannot expose focus order, late responses, interruption, device performance, or whether recovery survives real navigation.

A fictional permission change

Consider an explicitly fictional team-administration product. An owner removes a member’s access while that member may still have an active session.

A weak interaction removes the row immediately and shows “User deleted.” That message confuses account removal with access revocation and claims completion before downstream services confirm it.

The interaction contract names the action “Revoke access.” It states the affected workspace, warns that active sessions may take time to close, and asks for confirmation because the consequence is material.

After submission, the row remains visible with “Revocation requested.” Other member-management actions stay available, but repeat revocation is blocked.

The server confirms whether access policy changed and whether session invalidation completed. Partial completion remains visible, with a route to retry or escalate the outstanding session work.

No success result is claimed here. The example shows why acknowledgement, authoritative completion, partial failure, and recovery deserve different states.

Review the transition under stress

Run one important interaction through conditions the polished demo avoids:

1. Activate it with keyboard, pointer, touch, and the supported assistive technology path.
2. Slow the network and CPU.
3. Repeat the action before the first response.
4. Return responses out of order.
5. Interrupt navigation or close the view.
6. Reject one downstream step after another succeeds.
7. Enable reduced motion.
8. Reopen the product from another session if state is shared.

The review is complete when the person can still tell what is available, what the system knows, what actually changed, and what they can do next.

That is the standard for a useful micro-interaction. The animation may disappear from memory. The state change should not leave the user guessing.

Sources

• W3C WAI: Understanding Success Criterion 4.1.3, Status Messages — informative explanation of the Level AA criterion; scope: status messages.
• W3C WAI: Understanding Success Criterion 3.2.2, On Input — informative explanation of the Level A criterion; scope: changes of context caused by changing a setting.
• W3C WAI: Understanding Success Criterion 2.3.3, Animation from Interactions — informative explanation of the Level AAA criterion; scope: interaction-triggered motion animation.
• W3C WAI-ARIA Authoring Practices: Button Pattern — non-normative practice for button and toggle-button behaviour.
• web.dev: How to create high-performance CSS animations — web implementation guidance for CSS animation performance.

Read next

• System Design for Product Managers: Make the Promise Operable
• Design Tokens: Build a Governed Interface, Not a Palette
• Design Handoffs: Transfer Decisions, Not Screens