I feedback di notifica sono uno degli elementi essenziali presenti nei prodotti digitali moderni.

Le relative feature in-app non devono limitarsi alla mera segnalazione degli eventi degni di nota, ma devono contribuire a dare piena visibilità dello stato del sistema, a donare predicibilità e riscontro alle azioni che si possono compiere in modo tale che l'utente possa essere sempre indirizzato verso i flussi che gli consentono di conseguire i propri obiettivi senza grossi effort cognitivi.

Il non avvertire cosa può accadere o cosa è accaduto contribuisce a deteriorare l'esperienza utente e a generare frustrazione e insoddisfazione nell'utilizzo dell'applicazione.

Uno degli errori più comuni di uno UX Designer è quello di tralasciare la gestione delle notifiche e dei feedback visivi e tenerne conto unicamente durante la fase finale del design di un'applicazione, considerandoli come requisiti di contorno.

La comprensibilità del contesto

Una fase di design carente porta a produrre deliverables scadenti; spesso si passa in fase di implementazione avendo come unico output un semplice mockup dell'applicazione, che ovviamente da solo non può ridurre il carico di lavoro; una delle domande che spesso gli sviluppatori si trovano a porsi in una situazione del genere è: come si comporta una determinata pagina o componente quando non ha dati o elementi da mostrare?

E' chiaro che disegnare tutti i possibili feedback per ogni singola schermata è uno sforzo immane ed inutile, se si considera la necessità di iterare su di esse.

Ciò che va definito con chiarezza durante la fase di design sono il comportamento dei componenti e i pattern relativi ai feedback adottati nell'applicazione, in questo modo:

• Gli sviluppatori non sono costretti a fare ricorso ogni volta alla documentazione poiché conoscono le soluzioni da adottare in base alla situazione.
• Gli utenti conoscono già il comportamento dell'applicazione e sanno sempre cosa aspettarsi e come reagire.

Il concetto di stato

Volendo rispondere alla domanda iniziale del paragrafo precedente è bene innanzitutto sottolineare che un empty state non è uno stato né di caricamento né di errore.

Prendiamo l'esempio di una lista senza elementi, non in virtù del fallimento di una chiamata alle API, ma perchè l'utente sta utilizzando l'applicazione per la prima volta e non ha mai inserito i relativi dati; questa condizione è importante e va dato un riscontro visivo specifico all'utente, che nel caso prima citato potrebbe (e vorrebbe) inoltre essere guidato nel processo di creazione del suo primo elemento.

In generale deve essere data chiara visibilità di cosa il sistema sta facendo.

Prendiamo il caso dei caricamenti; l'utente deve percepire chiaramente che determinate operazioni non saranno "istantanee", bisogna quindi dare dei feedback mentre sono in corso e quando sono completate, sia in caso di successo che di errore. Le azioni che l'utente potrà intraprendere saranno ancora una volta diverse; un utente non eseguirà mai un pull-to-refresh per aggiornare una lista se gli è stato correttamente notificato che essa non ha contenuti da mostrare, mentre potrebbe essere portato a farlo se gli viene segnalato uno stato di errore.