A microinteraction is a small, focused moment in an app: a user acts or the system changes state, and the interface answers with a brief, contextual response. Done well, these moments tell people what is happening, stop them making mistakes and give the product its character. Done badly, they slow people down. This guide covers what microinteractions are, where they matter most on mobile, and how to design them so they are quick, accessible and consistent.
TL;DR
- A microinteraction is a trigger followed by targeted feedback. Its job is to confirm, guide or prevent an error, not to decorate.
- The highest-value moments are status, confirmation, errors, undo and loading. Start there before adding delight.
- Keep motion quick, never make it the only signal, and respect the device's reduced-motion setting.
- Offer a non-gesture alternative for anything that relies on shaking, tilting or multi-point gestures.
- Let brand personality show in the details, as long as the interaction stays predictable.
Table of Contents
- What microinteractions are, and what they are made of
- Where microinteractions earn their place in mobile apps
- What good microinteractions do for users
- Timing, duration and motion
- Making microinteractions accessible
- Expressing brand personality without hurting usability
- A simple process for designing one
- Common mistakes to avoid
- Our perspective
- Work with us on your app's interaction design
- FAQ
- Sources
What microinteractions are, and what they are made of
The Nielsen Norman Group describes microinteractions as trigger-feedback pairs. A user action or a change in system state sets off narrowly targeted feedback, delivered through small, highly contextual changes in the interface, usually visual ones.
Dan Saffer, who wrote the book on the subject, breaks them into four parts: the trigger, the rules, the feedback, and loops and modes. Here is how each part looks in a real app.
- Trigger: what starts the moment. It can be a tap, a swipe or a form field being completed. It can also be the system itself, such as a new message arriving.
- Rules: what happens once it starts. A payment is either accepted or declined. A pull-to-refresh either finds new content or does not.
- Feedback: what the user sees, hears or feels in response. A button changes state, a spinner appears, or the device gives a short haptic tap.
- Loops and modes: how the moment behaves over time. This covers whether it repeats, whether it changes after the first use, and whether it switches the app into a different mode.
Thinking in these four parts is useful in design reviews. It turns a vague comment such as "this feels clunky" into a specific question: is the trigger unclear, are the rules surprising, or is the feedback late?
Where microinteractions earn their place in mobile apps
The Nielsen Norman Group lists scrollbars, digital alarms, pull-to-refresh animations and email notifications among its everyday examples. Each one gives feedback about an action or a system condition.
It helps to separate the two kinds of trigger. Built In points out that user-prompted triggers include pressing a button, filling in a form or pulling down to refresh. System-prompted triggers include notification badges, chimes and payment gateway responses.
The table below maps common mobile moments to the job they do.
| Moment | Trigger | What the feedback should tell the user |
|---|---|---|
| Pull to refresh | User drags the list down | The app has heard the request and is fetching |
| Send button | User taps send | The message has gone, or is still sending |
| Form field | User leaves a field | The input is accepted, or what to fix |
| Delete or archive | User confirms removal | It has happened, and whether it can be undone |
| Notification badge | System receives new item | Something needs attention, and where |
| Loading state | System is working | The app has not frozen, and a response is on its way |
A recent public-sector example is worth studying. The GOV.UK team writing about its chat feature in the GOV.UK app explained that they considered how messages appear, how elements such as the send button move between states, and how a loading state signals that a response is being generated. None of those details is glamorous. All of them stop a user wondering whether anything happened.
What good microinteractions do for users
Communicate status
People on a phone are often distracted, on a weak signal or holding the device one-handed. A clear status signal removes doubt. A button that visibly registers a press, a progress indicator that moves, and a confirmation that appears where the user was already looking all do the same thing: they answer "did that work?" before the user asks.
Prevent errors and rework
The Nielsen Norman Group notes that microinteractions often convey system status or help users prevent errors, and that they can support undo and prevent rework. This links directly to the usability heuristic of error prevention, which is about removing error-prone situations and offering confirmation steps.
In practice that means inline validation that appears as the user finishes a field rather than after they submit, and a short undo option after a destructive action in place of a heavy confirmation dialogue. Forms used in the field are a good example, where contextual feedback saves users from losing entries. Guidance on offline mobile forms shows how clear saved and pending states stop people redoing work when connectivity drops.
The Home Office's design manual adds a useful touch-specific rule. After a user presses a control, they must be able to cancel the action before releasing. If they move away before lifting their finger or the mouse button, the function should not fire. This is a microinteraction principle as much as an accessibility one: a press is a trigger, and the user should be able to back out of it.
Keep users oriented
Transitions that show where an element has come from and where it has gone help people build a mental model of the app. A card that expands from a list item tells the user they are still in the same context. A screen that simply replaces another gives no such clue. For more on getting these patterns within thumb reach, see our piece on mobile UI patterns and the 5 tap test.
Timing, duration and motion
The guiding rule is simple: microinteractions should never make a task slower. The UK Intelligence Community Design System says that motion used as a micro-interaction should be quick, so it does not distract or delay a task. It also notes that most apps do not need animation or transitions beyond what their component library provides by default.
That second point is worth taking seriously. Start with platform defaults, which users already understand, and customise only where a custom behaviour solves a real problem. A practical checklist:
- Does the motion carry information? If it only decorates, cut it or shorten it.
- Can the user act during it? Feedback should not block the next tap.
- Is it consistent? The same kind of event should always animate the same way.
- Does it work without motion? Colour, text, icon and haptic cues should be able to stand alone.
- Does it repeat? Something charming the first time can become irritating the fiftieth. Loops and modes should account for repeat use.
We do not give millisecond targets here, because the right duration depends on the distance travelled, the size of the element and the device. Test on real handsets, with people who use the app daily, rather than on a design file.
Making microinteractions accessible
Accessibility is where microinteraction design most often goes wrong, because small animated details are easy to ship without testing them on assistive technology. UK government guidance is clear and practical.
- Motion is never the only feedback. The Intelligence Community Design System advises that motion should not be the only way to give feedback, and that apps should respect the reduced-motion setting on the user's device.
- Excess animation can cause harm. The same guidance notes that many people experience headaches, eye strain and anxiety from too much animation, so it recommends using it subtly and sparingly.
- Shake and tilt need an alternative. If something happens when a user tilts or shakes the device, the Home Office manual says an alternative that does not rely on motion must be provided and communicated to all users.
- Complex gestures need a simple route. For path-based or multi-point gestures, users must be told an alternative exists and be able to use the function with a keyboard or a single-point gesture. The same page says user research should inform how that is presented.
- Animations must be controllable. GDS tests mobile apps against WCAG 2.2 levels A and AA, and its monitoring checks whether animations and carousels meet the Pause, Stop, Hide requirement (2.2.2).
- Screen readers and larger text must still work. The GOV.UK Chat team made sure VoiceOver and TalkBack announce the character limit on the text input where enabled, and checked that the input still worked when people increased text size.
A real-world case: in the GDS accessibility audit of the Met Office app, advertisements had to avoid distracting animations that could not be paused. The team responded by building an extra accessible button to dismiss adverts. The lesson applies to any moving element: if it moves, the user needs control over it.
For a fuller walk-through of applying the standard to native and hybrid builds, read our guide to WCAG 2.2 for mobile apps.
Expressing brand personality without hurting usability
Microinteractions are one of the few places where a product's personality shows up in daily use. A confirmation message in a friendly tone, a distinctive loading animation or a subtle celebration after a completed task can all make an app feel like it belongs to a particular brand.
The GOV.UK Chat team gives a good model. They grounded the design in established conversational interface patterns, then added thoughtful touches where appropriate so it felt distinctively GOV.UK while staying intuitive. The order matters: familiar pattern first, personality second.
A few ways to apply that:
- Use your brand's tone of voice in the words that appear in feedback, such as empty states and success messages.
- Reserve expressive animation for moments of genuine completion, not routine taps.
- Keep the underlying behaviour standard so that users never have to learn something new just to enjoy the brand.
Our wider advice on app design tips for engagement covers how these details fit into the overall experience.
A simple process for designing one
- List the moments of doubt. Walk the main journeys and mark every point where a user might ask "did that work?" or "where am I?".
- Define the trigger and rules. Write down exactly what starts the moment and what the system will do, including failure.
- Choose the feedback channel. Pick visual, text, haptic or sound cues, and make sure at least one does not depend on motion.
- Prototype it interactively. Static screens cannot show timing. Build a clickable prototype and try it on a phone.
- Check accessibility. Test with a screen reader, larger text and the reduced-motion setting turned on.
- Measure and refine. Watch real use, gather feedback and adjust. Our guide to mastering app feedback covers how to turn that feedback into design changes.
Teams building the app often need engineering capacity to carry this level of polish through to release. Practical notes on application development tips can help you think about how to deliver responsive, unobtrusive feedback in code.
Common mistakes to avoid
- Animating everything. If every element moves, nothing stands out and the app feels slow.
- Hiding information in motion. An error shown only by a shake or a colour flash is missed by many users.
- Inconsistent behaviour. Two similar buttons that respond differently erode trust.
- Ignoring system settings. Reduced motion, larger text and screen readers are part of the platform, not edge cases.
- Designing in isolation. A moment that looks right in a design file can feel wrong at real speed on a real device.
Our perspective
Microinteractions are where an app proves it has been designed by people who have used it. After more than 300 projects, our experience is that the best ones are the ones nobody mentions: the button that responds, the form that says what is wrong before you submit, the loading state that tells you something is happening.
We treat them as part of discovery, not a finishing touch. When we run strategic discovery and build interactive prototypes, we map the moments where users need reassurance, then test the feedback on real devices before development starts. That is far cheaper than discovering a confusing state after launch.
We are also technology-agnostic. Whether an app is native or cross platform, we recommend the approach that lets the interaction feel right on the device, and we build accessibility in from the start rather than adding it at the end.
Paul
Work with us on your app's interaction design
If you are planning a new app or want to improve an existing one, we can help with every stage: discovery, design, development and deployment, including app design focused on clear, usable interaction. If you already have an app and suspect the small details are costing you engagement, our Mobile App Clinics are a place to start.
To discuss your project, get in touch through Pocket App. For further reading on structured improvement, see our step-by-step UX/UI improvement guide.
FAQ
What is the difference between a microinteraction and an animation?
An animation is a visual technique. A microinteraction is a whole moment: a trigger, rules, feedback and how it repeats. Animation is often the feedback part, but a microinteraction can also use text, sound or haptics.
How many microinteractions does a mobile app need?
There is no target number. Start with the moments where users need status, confirmation or error prevention, and add more only where they solve a problem. Most apps do not need much beyond component library defaults.
Do microinteractions affect accessibility?
Yes. Motion should never be the only feedback, the device's reduced-motion setting should be respected, and gestures need simpler alternatives. Public-sector guidance tests mobile apps against WCAG 2.2 AA, which is a sensible benchmark for any UK app.
Can microinteractions improve retention?
They can support it by making an app feel reliable and clear, which reduces frustration at key moments. They work best alongside sound navigation and content. Our guide on improving app UX for retention sets out the wider picture.
Sources
- Microinteractions in User Experience, Nielsen Norman Group
- Microinteractions: Details Matter, Smart Design
- Microinteractions: A Guide to Mastering the Smallest Parts, Built In
- Designing GOV.UK Chat for the GOV.UK app, Inside GOV.UK
- Gestures and motion, Home Office User-Centred Design Manual
- Motion, Intelligence Community Design System
- Accessibility monitoring: how we test, GOV.UK
- Accessibility audit of the Met Office app, Accessibility in government
- Offline mobile forms
- Application development tips