Lesson learned: progettare per l'IoT

Quando si parla di IoT, e in particolare di smart objects o smart devices, è facile immaginare una versione "ridotta" del design digitale: schermi più piccoli, meno spazio, qualche funzionalità in meno.

Lavorarci, però, cambia completamente le carte in tavola. È qualcosa che abbiamo messo alla prova lavorando su un cronotermostato: uno schermo piccolo, inserito in un oggetto reale, parte di un sistema più ampio.

Un progetto che ci ha reso molto chiaro che quando il design esce dallo schermo, bisogna cambiare approccio.

Il contesto fisico è parte dell'interfaccia

La prima lezione è semplice, ma non scontata. Stiamo progettando un oggetto in uso, non uno schermo.

L'interfaccia deve rispondere a condizioni reali: dove si trova l'oggetto, come viene usato, in che condizioni di luce. Nel caso del cronotermostato, questo si è tradotto in scelte molto concrete. Ad esempio, lo sfondo scuro migliorava la leggibilità in diverse condizioni di luce e riduceva il consumo energetico su un dispositivo che si attiva frequentemente durante la giornata, un aspetto tutt'altro che secondario.

Dettagli che nel web o in un'app raramente entrano nel ragionamento progettuale, qui diventano centrali.

Il termostato è qualcosa che si guarda e si modifica rapidamente, spesso senza fermarsi davvero. È un’interazione veloce, quasi automatica, che lascia poco spazio all’esplorazione. Le informazioni quindi devono essere immediatamente leggibili e le azioni rapide e non c'è spazio per percorsi complessi o per interazioni esplorative.

Progettare per IoT significa quindi progettare per situazioni, non per schermate.

Small screen ≠ mobile

In questo contesto, uno schermo piccolo - e nel nostro caso tondo - non è una versione compressa di un'app. Su dimensioni così ridotte, la navigazione esplicita diventa difficile perché ogni elemento visivo compete con gli altri.

Nel cronotermostato non c'era posto per un menu tradizionale. Inserire un'icona hamburger avrebbe sacrificato informazioni più importanti.

La soluzione è stata spostare il peso dell'interazione sulle gesture: uno swipe per accedere al menu, movimenti laterali per cambiare vista, interazioni dirette sugli elementi principali.

I riferimenti sono stati i dispositivi wearable, caratterizzati proprio da small screen con pattern di interazione propri, dove ogni movimento ha un significato preciso e coerente.

Alcuni di quegli schemi vengono direttamente dal mondo fisico, come la manopola del termostato o la ghiera, e la progettazione digitale ha dovuto trovare il modo di tradurli.

Su uno schermo così ridotto, i pattern del mobile semplicemente non funzionano, ma servono convenzioni diverse, pensate per interazioni rapide e contesti d'uso ben precisi.

Scegliere cosa escludere

Quando lo spazio è limitato, ogni decisione diventa una priorità.

In questo passaggio è diventato evidente quanto fosse centrale lavorare insieme al cliente per mappare le funzionalità esistenti e quelle desiderate, per poi votarle e ridurle.

Il desiderio iniziale era di includere tutto, ma mostrare concretamente cosa succede quando si aggiungono troppi elementi su uno schermo di pochi centimetri è stato il modo più efficace per far capire il problema.

Ogni elemento nella schermata principale era il risultato di una rinuncia altrove. Più informazioni inserisci, più aumenta la complessità. Più selezioni, più l'interfaccia diventa leggibile.

Nei sistemi fisici, la qualità dell'esperienza dipende più da cosa togli che da cosa aggiungi.

Le micro-interazioni diventano sistema

Nel digitale tradizionale, una certa incoerenza nelle interazioni può passare inosservata. In questo caso no. Ogni micro-interazione deve essere chiara, coerente e ripetibile in tutto il sistema.

Un esempio concreto è stato gestire la modifica di ore e minuti. Inizialmente avevamo esplorato un'interazione più originale, sfruttando la forma circolare del display, ed era interessante, ma richiedeva titoli e descrizioni per essere comprensibile, e quello spazio non c'era.

Avremmo potuto usarla in un punto, ma non portarla avanti coerentemente nel resto.
E al di là dello spazio, c'era un'altra perplessità: la ghiera, per quanto interessante, non è un pattern di interazione sufficientemente consolidato da poter dare per scontato che gli utenti la riconoscessero e la usassero correttamente. Quindi l'abbiamo scartata.

Ogni decisione locale deve funzionare globalmente, perché in ambienti vincolati, le micro-interazioni non sono dettagli, sono struttura.

Progettare senza controllo tecnico

Un aspetto meno evidente di questo tipo di progetti è il livello di incertezza tecnica con cui si lavora.

Stavamo progettando un'interfaccia su un hardware indipendente da noi: un dispositivo a mercato, con i suoi vincoli ereditati, senza possibilità di intervenire sul prodotto fisico. La fluidità dello scroll, ad esempio, era incerta fino alla fine.

L’obiettivo è costruire un sistema che funzioni anche in condizioni peggiori, prevedendo fallback e semplificando dove possibile. Nel nostro caso, invece di nascondere e mostrare elementi dinamicamente durante lo scroll, abbiamo optato per CTA ancorate. Meno eleganti, ma sicure.

C'è poi un aspetto più operativo. Verificare che un elemento fosse leggibile nelle dimensioni reali dello schermo richiedeva di simulare manualmente quelle proporzioni in Figma, righello alla mano. Quando progetti per schermi standard, mandi il prototipo sul telefono e lo vedi, ma con oggetti fisici non standard, questo processo si rompe e bisogna trovare workaround artigianali.

Progettare per l'IoT significa progettare per la realtà, non per il best case.

Cosa ci portiamo a casa

Lavorare su oggetti connessi significa, forse più che in altri contesti, progettare davvero. Senza shortcut, senza affidarsi a pattern consolidati, senza soluzioni che funzionano perché le abbiamo già viste funzionare altrove.

Ogni cosa che abbiamo descritto in questo articolo (tenere conto del sistema fisico, scegliere con cura cosa togliere, costruire micro-interazioni coerenti, progettare per i casi reali e non per il best case) è la conseguenza diretta di lavorare in un territorio dove le certezze sono poche e le convenzioni non bastano.

È proprio in questo spazio che si apre un'opportunità: progettare esperienze che non vivono solo sugli schermi, ma dentro oggetti e contesti reali, dove il design può fare la differenza in modo ancora più concreto.

È anche, tra l'altro, uno degli spazi in cui l'AI design e il vibe coding aiutano meno. Quegli strumenti funzionano bene dove esistono standard consolidati da cui attingere, mentre qui siamo dall'altra parte, con meno automazione e più ragionamento.