Partire dalle decisioni, prima delle schermate
Descrivi in una frase la decisione di ogni fase. Scegliere un personaggio e organizzare le scene sono decisioni diverse anche quando entrambe usano una griglia. Se una fase contiene scelte scollegate, serve una gerarchia più chiara o un confine diverso tra i compiti.
Il risultato è una piccola mappa di decisioni e dipendenze. È uno strumento di progettazione, non l’ipotesi che tutti seguiranno sempre lo stesso percorso.
Cosa succede quando cambia una scelta precedente?
Immagina un creator che cambi narratore dopo aver rivisto le scene. L’interfaccia deve spiegare se la modifica vale solo per le generazioni future o invalida anche i contenuti già prodotti. La regola deve essere vicina all’azione, prima della conferma.
Per ogni ritorno a uno step, annota input modificato, output coinvolto, lavoro conservato e prossimo intervento necessario. Le caselle senza risposta spesso rivelano una regola di prodotto ambigua.
- Cosa cambia subito?
- Cosa resta valido?
- Cosa deve essere generato di nuovo?
- Si può rivedere o annullare prima di sostituire un risultato?
Come si rende comprensibile l’attesa?
Dai un nome all’operazione in corso. Se il sistema non fornisce una percentuale attendibile, evita di presentarla come avanzamento esatto. Uno stato di elaborazione è più fedele di un contatore animato scollegato dal completamento.
Rendi riconoscibili successo ed errore anche quando si torna allo step. Una notifica temporanea aiuta nel momento del completamento, ma non può contenere tutte le informazioni necessarie a riprendere il lavoro.
Mantenere il recupero dentro il compito
Per ogni errore individua l’azione più piccola che permetta di recuperare. Un nuovo tentativo deve avere un ambito chiaro; la richiesta di modificare un input deve indicare quale. Conserva il lavoro modificabile quando le regole del prodotto lo consentono.
Una live region con priorità polite può annunciare cambiamenti di stato senza spostare il focus. Usala per aggiornamenti significativi, evitando un flusso continuo di annunci. Il riferimento MDN descrive il comportamento della funzionalità.
Verificare un percorso di andata e ritorno
Completa una fase, vai avanti, torna indietro, cambia un input e prosegui. Ripeti dopo un errore e su uno schermo stretto. Registra cosa è visibile, non solo ciò che l’applicazione conserva.
L’obiettivo è rendere prevedibili le conseguenze. Il percorso in avanti resta incompleto se rivedere una scelta lascia dubbi sul lavoro ancora utilizzabile.