Tree testing. Come testare l’alberatura di siti e app

Il tree testing è un metodo per testare con le persone l'alberatura di un sistema, utile soprattutto quando non abbiamo ancora un prototipo di interfaccia.

Lettura: 5 minuti

Indice

Siamo nelle fasi iniziali di un progetto, abbiamo definito a grandi linee l’architettura dell’informazione, ma non abbiamo ancora un prototipo, neppure a bassa fedeltà. Oppure disponiamo già di un prototipo o di un prodotto funzionante, ma abbiamo il dubbio se alcuni problemi di usabilità siano riconducibili all’interfaccia o all’architettura dell’informazione. In entrambi i casi ci viene in soccorso il tree testing.

Cos’è il tree testing

Il tree testing è un metodo per testare con le persone l’alberatura di un sistema già esistente o in corso di progettazione: siti web, app, risponditori vocali, ma anche ambienti fisici. Questo tipo di test serve a misurare la trovabilità di un elemento all’interno del sistema. È quindi un metodo per valutare specificamente l’architettura dell’informazione.

Il tree testing è il rovescio del card sorting. Il card sorting chiede alle persone di dare una struttura a un insieme di elementi disorganizzati. Il tree testing viceversa chiede alle persone di trovare un certo elemento all’interno di una struttura data.

Un esempio di tree testing.

Quando usarlo

Il tree testing è utile:

  • per valutare lo schema di organizzazione dell’informazione già nelle prime fasi di un progetto, quando non disponiamo ancora di un prototipo di interfaccia, neppure a bassa fedeltà
  • quando vogliamo capire se un problema di usabilità è relativo all’interfaccia oppure all’architettura dell’informazione.

Questo test è condotto infatti sull’alberatura nuda del sistema, privata di ogni elemento di interfaccia, e permette quindi di valutare esclusivamente l’organizzazione dei contenuti.

Come funziona

Ai partecipanti del tree testing viene chiesto di indicare dove si aspettano di trovare una specifica informazione all’interno di un menu testuale che rispecchia l’architettura del sistema. Questo permette di valutare:

  • se lo schema di organizzazione che abbiamo scelto è valido
  • se il criterio di classificazione funziona
  • se le etichette che abbiamo scelto per sezioni e sottosezioni sono chiare.

Possiamo eseguire il test manualmente usando dei cartoncini, oppure impiegando tool online. Fra i tool, quello che preferisco è Treejack di Optimal Workshop. Preciso subito che non ho alcuna affiliazione con l’azienda, semplicemente ho usato spesso il loro software e lo trovo estremamente efficace, soprattutto nella restituzione dei risultati. Nel sito di Optimal Workshop c’è una demo del tree test sia lato utente sia lato designer.

Optimal Workshop Treejack: visualizzazione dei percorsi degli utenti (pie tree).

Formulazione dei task

Nella formulazione dei task vanno usati un lessico e una sintassi chiari: valgono le stesse regole della scrittura web e della buona scrittura in generale. Quindi: adottare un lessico comune, evitando tecnicismi, sigle, aziendalese ecc.; usare una sintassi piana, prediligere la forma attiva, rispettare l’ordine naturale del discorso (soggetto, verbo, complemento).

Occorre inoltre fare attenzione a non usare parole che possano suggerire un percorso, giusto o sbagliato che sia. Ad esempio parole che ricorrono anche nel menu del test, soprattutto quelle dei primi livelli.

L’aspetto linguistico è il più difficile da controllare: il linguaggio naturale è per sua natura estremamente complesso e ricco di sfumature. Molto spesso ci si rende conto di avere involontariamente “suggerito” un percorso solo quando analizziamo i risultati del test. È bene perciò che più persone del team, con profili e ruoli diversi, rivedano la formulazione dei task.

Browsing vs searching

Il tree test prende in considerazione soltanto il browsing, cioè la navigazione da menu. Questo potrebbe apparire come un limite. In realtà non è così. Browsing e searching sono due diverse strategie di ricerca dell’informazione. Tuttavia, fra tutte le strategie possibili, il searching è quella che richiede maggior sforzo cognitivo, mentre il nostro cervello tende al minimo sforzo.

Il searching è la strategia di ricerca dell’informazione che comporta maggior sforzo cognitivo: è quella che mediamente utilizziamo meno nelle nostre azioni quotidiane.

Per fare una ricerca diretta tramite motore di ricerca, testuale o vocale che sia, dobbiamo essere consapevoli di ciò che cerchiamo e capaci di specificare questo bisogno a parole. Ma in molti casi il nostro bisogno non è perfettamente a fuoco, oppure non siamo in grado di formularlo linguisticamente. Se ad esempio cerchiamo un vestito per un’occasione particolare, sappiamo qual è l’oggetto del nostro bisogno ma potremmo non saperne specificare le caratteristiche.

In breve: il menu non è soltanto uno strumento per muoversi, è anzitutto uno strumento per orientarsi. Serve a comprendere cosa c’è in un determinato ambiente, com’è organizzato, dove mi trovo.

Searching & browsing. Perché non possiamo sostituire la navigazione tramite menu con un motore di ricerca

Tassonomia vs navigazione

Il tree testing è uno strumento per testare la tassonomia di un sistema, non la navigazione. (Uso tassonomia nella sua accezione più ampia, per indicare il modello di organizzazione dell’informazione di un ambiente). Tassonomia e navigazione non coincidono. Sono collegate ma appartengono a due piani distinti: la tassonomia è lo strato profondo dell’architettura dell’informazione – quello semantico; mentre la navigazione è lo strato più superficiale – quello dell’interfaccia.

Differenza fra navigazione (architettura visibile) e tassonomia (architettura invisibile).

La navigazione può riflettere solo in parte la tassonomia soggiacente: le voci di primo livello della navigazione, ad esempio, potrebbero non coincidere con le classi di primo livello della tassonomia. Prendiamo ad esempio il sito Vivino. Il menu principale espone solo alcune delle faccette impiegate nel catalogo: la lista completa delle faccette è visibile solo nei livelli più profondi. Inoltre, il megamenu che si apre selezionando una delle voci del menu principale, nella versione desktop, riporta anche alcune promo. Ad esempio in Abbinamenti compaiono le promo L’abbinamento perfetto per una bistecca, e Scegli il vino perfetto per il formaggio a pasta molle: queste sono scorciatoie, e non andranno inserite nel test.

Il menu principale di Vivino mostra solo alcune di tutte le faccette usate nella classificazione dei vini.
La lista completa delle faccette utilizzate da Vivino.
Il megamenu di Vivino (2° livello) mostra alcune promo che vanno escluse dal tree testing.

Cosa fare allora quando c’è una discrepanza fra navigazione e tassonomia? Anzitutto, se il test è su una nuova architettura e siamo nelle prime fasi del progetto, è probabile che abbiamo solo la tassonomia, e che la navigazione non sia stata ancora definita. In tal caso il problema non si pone. Se invece il test riguarda un sistema già esistente, ricordiamoci che l’obiettivo è analizzare la tassonomia, l’alberatura del sistema. Il menu impiegato nel test deve riflettere le sezioni e sottosezioni della tassonomia, non le voci di menu.

Per approfondire

Il tree test e altre tecniche per progettare e testare l’architettura dell’informazione sono approfondite nel mio libro Sense-making.