Animazione funzionale UI nel 2026: la checklist prima del rilascio

L'animazione funzionale dell'interfaccia è un movimento che svolge un compito: conferma un'azione, mostra un cambio di stato, accompagna l'attenzione da una zona dello schermo all'altra. Non è decorazione, non è cifra stilistica. Quando il movimento ha un compito, l'utente quasi non lo nota. Quando non ce l'ha, sente l'attrito anche senza saperlo nominare.

Questo articolo è la checklist che applichiamo a ogni prodotto che rilasciamo nel 2026. È opinionata. Presuppone che tu sappia già scrivere una transizione CSS e che tu abbia un design system in cui mettere il motion.

Perché conta più nel 2026 di quanto contasse nel 2022

Tre cose sono cambiate.

Primo, lo European Accessibility Act è entrato in vigore il 28 giugno 2025, e il motion è uno dei rilievi più frequenti negli audit. I disturbi vestibolari riguardano una fetta significativa della popolazione adulta: circa il 35% degli adulti dai 40 anni in su ha sperimentato qualche forma di disfunzione vestibolare. Animazioni che scalano, traslano o fanno parallax possono provocare nausea, vertigini e mal di testa a questi utenti.

Secondo, la calm UI non è più una posizione di nicchia. Apple, Atlassian e IBM hanno tutte pubblicato linee guida sul motion negli ultimi 18 mesi che riducono le durate di default e spostano il movimento espressivo su momenti specifici. "Meno ma meglio" si applica.

Terzo, il budget per frame non è diventato più generoso. 60fps significa ancora 16,66ms a frame. Le proprietà che il browser anima a basso costo (opacity, transform) sono le stesse di cinque anni fa. Le proprietà che costano un layout o un paint (width, height, top, left, margin, padding) restano costose. Nulla di nuovo. Continua a essere ignorato.

Cosa fare

1. Durate brevi e contestuali

Material Design 3 fissa 200ms come riferimento standard per le transizioni a livello di componente e 300ms per le transizioni fra schermate. Le Human Interface Guidelines di Apple stanno nello stesso intervallo. La regola che seguiamo:

• Micro-interazione (hover, focus, toggle): 100 a 200ms.
• Cambio di stato di un componente (apertura modale, drawer, dropdown): 200 a 300ms.
• Transizione di pagina intera: 300 a 500ms, solo se porta significato.
• Sopra i 500ms deve giustificarsi.

Un movimento che l'utente attiva trenta volte a sessione sta sotto i 150ms. Un movimento che vede una volta sola ha più spazio per essere letto.

2. L'easing è un verbo, non un'atmosfera

Ogni curva di easing ha un compito:

• ease-out per gli elementi che entrano in scena. Parte veloce, si assesta. Sembra reattivo.
• ease-in per gli elementi che escono. Parte lento, accelera. L'utente ha già deciso.
• ease-in-out per il movimento fra due stati dello stesso elemento.
• linear solo per progressi indeterminati e movimenti continui (spinner, loader).

Devono vivere come token nel design system (--ds-easing-enter, --ds-easing-exit, --ds-easing-standard), mai inline nel componente.

3. Animare solo opacity e transform

Le proprietà composte dalla GPU restano stabili a 60fps perché saltano layout e paint. La lista è corta: opacity, transform (translate, scale, rotate) e filter con cautela. Usa transform: translateY() invece di animare top o margin-top. Usa transform: scale() invece di animare width e height. La differenza si vede su un Android di fascia media, non sul Mac con cui costruisci la pagina.

4. Rispettare prefers-reduced-motion alla radice

Il WCAG 2.1, criterio 2.3.3 chiede che il motion attivato da interazione si possa disattivare, salvo quando è essenziale. La risposta meccanica è una regola nello stylesheet globale:

@media (prefers-reduced-motion: reduce) { *, *::before, *::after { animation-duration: 0.01ms !important; animation-iteration-count: 1 !important; transition-duration: 0.01ms !important; scroll-behavior: auto !important; } }

Copre la maggior parte dei danni. Per parallax non essenziali, video di sfondo in autoplay e reveal di grosse dimensioni, aggiungi anche un controllo JavaScript con matchMedia('(prefers-reduced-motion: reduce)') prima di montare l'animazione. Portare la durata a zero fa comunque girare il listener: non annulla il lavoro JS.

5. Ogni animazione deve essere interrompibile

Se un utente può cliccare un pulsante, l'animazione che parte dopo il clic non deve bloccare il clic successivo. Transizioni bloccate, modali che ignorano l'escape durante l'apertura, dropdown che si rifiutano di chiudersi finché l'apertura non finisce: sono i casi più frequenti. La correzione è strutturale: è lo stato che guida l'animazione, non il contrario. Se lo stato torna a chiuso mentre l'apertura è a metà, l'animazione deve fare marcia indietro dal frame corrente, non aspettare.

6. Portare il motion nel design system come token

I token di durata (--ds-motion-duration-fast, --ds-motion-duration-base, --ds-motion-duration-slow) e i token di easing (--ds-motion-ease-out, --ds-motion-ease-in, --ds-motion-ease-standard) stanno sullo stesso livello di colore e spaziatura. Atlassian, IBM Carbon e Material 3 pubblicano tutti il loro livello di token. Copia la struttura se il tuo design system non ce l'ha.

7. Animare per comunicare lo stato, non per intrattenere

I tre compiti che il motion svolge legittimamente in un'interfaccia di prodotto:

• Feedback: confermare la pressione di un pulsante, il flip di un toggle, un salvataggio andato a buon fine.
• Continuità: mostrare da dove arriva un nuovo elemento, così l'utente non deve rileggere lo schermo.
• Gerarchia: richiamare l'attenzione sull'unico elemento che è cambiato, poi quietarsi.

Se un'animazione proposta non fa uno di questi tre lavori, va tagliata.

Cosa non fare

1. Parallax che parte a ogni scroll

Sfondo e primo piano che si muovono a velocità diverse durante lo scroll sono il trigger vestibolare più citato negli audit. Raramente aggiungono significato. Se il sito marketing insiste, mettilo dietro un prefers-reduced-motion: no-preference.

2. Animare width, height, top, left o margin

Innescano un layout. Il layout costa circa 6 a 14ms sui dispositivi di fascia media e ricade su ogni discendente. Perderai frame. Usa transform.

3. Sei cose che si animano insieme

Quando più di due o tre elementi si muovono contemporaneamente, l'utente non capisce più cosa risponde alla sua azione e cosa si muove per atmosfera. Scegli l'unico elemento che conta. Muovilo. Lascia fermo il resto.

4. Spinner di caricamento decorativi su azioni sotto i 300ms

Se l'azione finisce in 150ms, lo spinner aggiunge latenza, non rassicurazione. Mostra direttamente lo stato di successo. Tieni gli spinner per operazioni che richiedono davvero tempo, e per qualsiasi cosa sopra il secondo preferisci uno skeleton o una progress bar inline.

5. Reveal scroll-triggered con scale o pan automatici sull'hero

I reveal cinematografici alla prima visita sembrano un pezzo da portfolio, non un prodotto. Falliscono anche il WCAG 2.3.3 se non li proteggi. Il costo-beneficio è pessimo: 100ms di wow percepito per la piccola quota di utenti non colpiti, fastidio fisico per gli altri.

6. Curve di easing custom che non combaciano col sistema

Un cubic-bezier(0.4, 0.0, 0.2, 1) su un componente e un altro sul componente accanto è il modo in cui un prodotto comincia a sembrare "strano" senza che nessuno sappia indicarne la causa. Usa ovunque le stesse tre o quattro curve.

7. Motion che non puoi spegnere in sviluppo

Se il team non può disabilitare le animazioni mentre fa debug di un componente, quell'animazione è di intralcio a ogni test da tastiera, a ogni screenshot diff, a ogni audit di accessibilità. Aggiungi un flag a livello root (variabile d'ambiente, query param o toggle nei DevTools) che spegne il motion in tutto il sito. Lo userai ogni settimana.

Il riepilogo

• Durata micro-interazione: 100 a 200ms.
• Cambio di stato di un componente: 200 a 300ms (intervallo Material 3 e HIG).
• Transizione di pagina: 300 a 500ms, solo se porta significato.
• Easing in entrata: ease-out. Sembra reattivo.
• Easing in uscita: ease-in. L'utente ha deciso.
• Proprietà da animare: solo opacity e transform.
• prefers-reduced-motion: rispettata alla radice, con un guard JS per il motion pesante.
• Interrompibilità: sempre. È lo stato che guida l'animazione, non il contrario.

Leggi questa lista con un ingegnere senior prima del primo sprint di qualsiasi prodotto. I bug di motion che emergono in seguito sono quasi sempre le voci saltate qui.

Sul blog: Calm UI nel 2026: via dalle acrobazie dell'animazione e Design accessibility-first dopo lo European Accessibility Act.