Interfacce Induttive

UI, UX e Interfacce Induttive: perché sentiamo il bisogno di fare chiarezza

Un chiarimento sul significato di UI, UX, UI design e interaction design, e sullo spazio specifico occupato dalla progettazione delle Interfacce Induttive.

UI, UX e Interfacce Induttive: perché sentiamo il bisogno di fare chiarezza

Ogni volta che proviamo a spiegare che cosa intendiamo per Interfacce Induttive, prima o poi emerge la stessa obiezione.

Esistono già la UX, lo UI design, l’interaction design, l’usabilità, lo human-centred design. Esistono libri, corsi, professionisti, framework e decenni di ricerca. Perché introdurre un’altra espressione? Non stiamo forse cercando di rinominare qualcosa che il mondo del design conosce già molto bene?

È un’obiezione che comprendiamo. Anzi, è anche per rispondere a questa domanda che sentiamo la necessità di chiarire meglio il nostro punto di vista.

Non pensiamo che la progettazione delle Interfacce Induttive sostituisca la UX. Non pensiamo che renda superfluo lo UI design. Non crediamo di aver scoperto improvvisamente l’importanza dei task, del contesto, della semplicità o del carico cognitivo.

Il punto è un altro.

Stiamo cercando di mettere a fuoco un problema specifico che, soprattutto nel software professionale, continua a essere trattato in modo frammentario:

quanto lavoro di interpretazione e decisione viene trasferito dal sistema alla persona che lo usa?

Per spiegare questa differenza, però, dobbiamo prima fare un po’ di ordine tra termini che nel linguaggio quotidiano vengono spesso usati come sinonimi.

La UI non è semplicemente l’aspetto grafico

UI significa User Interface, interfaccia utente.

Il NIST la definisce come il mezzo fisico o logico attraverso cui un utente interagisce con un sistema, un dispositivo o un processo.

Quando parliamo di UI, quindi, non ci riferiamo soltanto ai colori, alle icone o alla forma dei pulsanti. La UI comprende tutto ciò che permette alla persona di percepire lo stato del sistema e di agire su di esso: menu, tabelle, campi, comandi, messaggi, notifiche, feedback, errori, conferme e possibilità operative.

Questa precisazione è importante perché molto spesso, nelle conversazioni sul software, “rifare la UI” finisce per significare cambiare il CSS, modernizzare le icone o rendere più gradevole una schermata.

Tutto questo può essere utile. Ma un’interfaccia più moderna non è necessariamente un’interfaccia più comprensibile. Una schermata può essere elegante e continuare a chiedere all’utente di capire da solo che cosa fare, in quale ordine e con quali conseguenze.

Lo UI design progetta la superficie dell’interazione

Lo User Interface Design è il lavoro attraverso cui quella superficie viene progettata.

Riguarda la gerarchia visiva, la disposizione degli elementi, i controlli utilizzati, la navigazione, la leggibilità, il feedback, la coerenza, gli stati e l’accessibilità. Non è quindi una semplice attività decorativa.

La documentazione Microsoft sullo UI design insiste, per esempio, sulla necessità di comprendere chi siano gli utenti, quali competenze possiedano, quali obiettivi abbiano e quali task debbano completare. Raccomanda inoltre di osservare il loro lavoro reale e di distinguere i problemi effettivi dalle soluzioni immaginate troppo presto.

Questo è un punto sul quale siamo pienamente d’accordo.

Non c’è progettazione induttiva seria senza una buona progettazione dell’interfaccia. Non basta dichiarare che il sistema sarà intelligente: bisogna decidere che cosa mostrare, come presentarlo, che cosa rendere prioritario e come comunicare le conseguenze delle azioni.

La UX è qualcosa di più ampio

UX significa User Experience. E qui la distinzione diventa ancora più importante.

Don Norman e Jakob Nielsen descrivono la UX come l’insieme degli aspetti che caratterizzano l’interazione dell’utente con un’azienda, i suoi servizi e i suoi prodotti. Sottolineano inoltre che la UI è una parte fondamentale della UX, ma non coincide con essa.

Possiamo avere un’interfaccia visivamente riuscita inserita in un prodotto lento, inaffidabile o incapace di fornire le informazioni necessarie. In quel caso la UI può anche essere ben disegnata, mentre l’esperienza complessiva rimane negativa.

La UX comprende ciò che accade prima, durante e dopo l’interazione: aspettative, comprensione, affidabilità, tempi, supporto, percezione del prodotto, difficoltà incontrate e risultato ottenuto.

Lo standard ISO 9241-210, dedicato allo human-centred design dei sistemi interattivi, definisce requisiti e raccomandazioni per includere la prospettiva umana lungo il ciclo di vita della progettazione.

Anche qui non vediamo alcun contrasto con la nostra tesi. Al contrario, un’Interfaccia Induttiva deve essere progettata e verificata attraverso pratiche human-centred. Non può essere dedotta soltanto da un modello teorico o generata automaticamente da un sistema AI.

E allora che cosa aggiunge la tesi delle Interfacce Induttive?

La domanda che ci interessa è questa:

chi deve ricostruire il significato operativo della situazione: l’utente o il sistema?

Chi lavora ogni giorno con software gestionali, ERP, strumenti amministrativi, applicazioni industriali o piattaforme tecniche conosce bene il problema.

Il sistema presenta menu, moduli, griglie, tab, filtri, pulsanti e possibilità. Spetta poi all’utente capire:

  • quale funzione serva davvero;

  • quali informazioni siano importanti in quel momento;

  • quale azione debba venire prima;

  • quali campi possano essere ignorati;

  • quale sequenza sia corretta;

  • che cosa accadrà dopo una conferma;

  • come recuperare da un errore.

In questi casi l’interfaccia espone il sistema, ma non interpreta sufficientemente il momento operativo.

Nel mio articolo Dalle interfacce deduttive alle interfacce induttive ho definito questo modello come paradigma deduttivo: il software mette a disposizione strumenti e funzionalità, mentre l’utente deve dedurre l’azione corretta.

Non usiamo il termine “deduttivo” per dire che il software sia necessariamente progettato male. Molte applicazioni complesse sono nate in contesti nei quali gli utenti erano specialisti, la formazione era considerata normale e la conoscenza del sistema faceva parte del lavoro.

Il problema è che questo modello ha un costo.

Richiede formazione, memoria, esperienza, attenzione continua e conoscenze spesso non dichiarate. Rende più lento l’onboarding, aumenta la dipendenza dagli utenti esperti e trasforma operazioni quotidiane in sequenze che devono essere ricordate invece di essere comprese.

Un’interfaccia diventa più induttiva quando il sistema utilizza ciò che già conosce — il ruolo dell’utente, il task, lo stato del lavoro, i dati disponibili, le operazioni precedenti e le condizioni correnti — per rendere più chiaro ciò che conta adesso.

Non si limita a dire:

Ecco tutto ciò che puoi fare.

Comincia piuttosto a dire:

In questa situazione, queste sono le informazioni importanti e questo è il passo che probabilmente devi compiere.

Molte tecniche esistono già, ed è giusto riconoscerlo

Azioni contestuali, progressive disclosure, default intelligenti, percorsi task-first, precompilazione e riduzione delle scelte simultanee non sono invenzioni di Inductive Flow.

Appartengono, con nomi e formulazioni diverse, alla storia della progettazione delle interfacce e dell’interaction design.

Anche l’espressione Inductive User Interface ha un precedente importante. Microsoft l’ha utilizzata per descrivere un modello di progettazione orientato a pagine focalizzate su singoli task, con scopi dichiarati chiaramente e passaggi successivi riconoscibili.

La documentazione Microsoft osserva, per esempio, che quando non è possibile descrivere una schermata con un titolo chiaro e naturale, probabilmente quella schermata sta cercando di svolgere troppe funzioni. Propone inoltre di distinguere il task principale dalle attività secondarie e di rendere evidente il modo in cui il lavoro può essere completato.

È un precedente che non vogliamo ignorare o nascondere. Al contrario, ci aiuta a mostrare che il problema ha radici profonde.

La nostra tesi, però, prova ad allargare il campo.

Non riguarda soltanto l’organizzazione delle pagine o la navigazione task-oriented. Riguarda la distribuzione della responsabilità cognitiva lungo l’intero workflow: ciò che il sistema osserva, ciò che può inferire, le priorità che può riconoscere, le alternative che può restringere e il livello di controllo che deve lasciare alla persona.

Un chatbot non rende induttiva un’interfaccia

Questo chiarimento per noi è particolarmente importante oggi.

L’intelligenza artificiale può rendere più potente un’interfaccia induttiva, ma non è sufficiente aggiungere un chatbot o un assistente laterale a un’applicazione complessa.

Se l’utente continua a trovarsi davanti alla stessa struttura opaca, agli stessi workflow frammentati e alle stesse decisioni premature, il paradigma di fondo non è cambiato. Abbiamo semplicemente aggiunto un altro modo per chiedere aiuto.

Un’interfaccia induttiva può usare AI, ma può anche basarsi su regole, stati applicativi, dati storici o semplici condizioni di dominio.

Ciò che la definisce non è la tecnologia utilizzata. È il modo in cui il sistema si assume una parte del lavoro necessario per orientare l’azione.

E questo non significa eliminare il giudizio umano. Significa prepararlo meglio.

Il sistema può proporre, ordinare e restringere. La persona deve poter comprendere, correggere, rifiutare e mantenere il controllo.

Il vuoto che InductiveFlow vuole provare a colmare

Non sosteniamo che manchino conoscenze sulla UX o sulla progettazione delle interfacce. Sarebbe un’affermazione difficile da difendere e poco rispettosa verso discipline che hanno prodotto risultati fondamentali.

Ci sembra però che, soprattutto nel software professionale, manchi spesso un metodo esplicito e ripetibile per diagnosticare dove l’interfaccia obbliga l’utente a interpretare troppo e dove il sistema offre troppo poca guida.

È in questo spazio che nasce InductiveFlow.

Vogliamo osservare l’interfaccia non soltanto come layout o insieme di controlli, ma come sistema cognitivo e operativo. Vogliamo rendere visibili i punti in cui l’utente deve ricordare, dedurre, cercare, confrontare o decidere più del necessario.

E vogliamo trasformare questa lettura in indicazioni concrete: che cosa mostrare prima, che cosa rimandare, quali azioni rendere contestuali, dove ridurre le alternative e come accompagnare meglio il task.

Per questo non vediamo le Interfacce Induttive come una disciplina concorrente alla UX.

Le vediamo come una lente più specifica.

La UI è il mezzo attraverso il quale interagiamo con il sistema. Lo UI design progetta quella superficie. L’interaction design ne organizza il comportamento nel tempo. La UX comprende l’esperienza complessiva che ne deriva.

La progettazione delle Interfacce Induttive si concentra su un’altra domanda:

Quanto deve ancora dedurre l’utente, prima di poter finalmente lavorare?

È da questa domanda che vogliamo partire.

Riferimenti

  • NIST, User Interface — Glossary.

  • ISO 9241-210:2019, Human-centred design for interactive systems.

  • Don Norman e Jakob Nielsen, The Definition of User Experience.

  • Microsoft Learn, Designing a User Interface.

  • Microsoft Learn, Inductive User Interface.

  • Riccardo Mariotti, Dalle interfacce deduttive alle interfacce induttive, InductiveFlow Notes.

Commenti

Lascia un commento

Il commento sarà visibile dopo la moderazione.