Idea principale

Una scadenza di fatturazione futura compare nello scadenzario di un cliente. Eppure non esiste come documento: avrà un'esistenza propria solo nel momento in cui la fattura verrà emessa. Conseguenza immediata — è assente dai risultati di ricerca. L'utente, però, l'ha vista sullo schermo; la cerca, non la trova e apre un ticket.

Non è un difetto isolato, è un'intera famiglia di reclami, trattata caso per caso da anni da un supporto che non dispone di nessuna formulazione della causa. Ogni ticket viene chiuso con una spiegazione improvvisata, e il successivo ricomincia da capo.

L'origine è uno scostamento fra due modelli: ciò che l'interfaccia mostra e ciò che il prodotto manipola come oggetti. Una cosa che l'utente vede è un oggetto per lui, qualunque sia la sua esistenza tecnica.

Perché è importante

Fornisce un'angolazione di ricerca a sé stante: passare in rassegna ciò che l'utente manipola ogni giorno e verificare che ogni elemento esista da qualche parte come oggetto del prodotto. Le schermate riportano così ciò che né il codice né la base segnalano.

Cambia anche il modo di trattare i ticket ripetitivi: una famiglia di reclami senza una causa scritta è il segnale di un modello mancante, non un volume da smaltire.

Sfumature e limiti

Non tutto ciò che compare sullo schermo deve diventare un oggetto: un totale, un raggruppamento di visualizzazione, una riga di riepilogo possono restare viste senza che nessuno ne soffra. Il criterio non è la presenza sullo schermo, è che l'utente abbia bisogno di ritrovare la cosa, di parlarne o di agire su di essa.

E la correzione non consiste per forza nel creare l'oggetto: dare un nome all'ambiguità e spiegarla nell'interfaccia può bastare.

Domande aperte

• Come individuare questi casi senza leggere le schermate una per una, su un prodotto che ne conta diverse centinaia?