Albero decisionale: Regole ed esempi di guida alla ramificazione

Un albero decisionale è una sequenza di domande in cui ogni risposta seleziona la domanda successiva o una raccomandazione finale. Usalo quando l’azione giusta cambia effettivamente in base ai fatti che il lettore può identificare — non come decorazione per consigli che sono uguali per tutti.

Scegliere la prima risposta a un’esportazione di dati fallita

1. L’esportazione mostra un messaggio di errore?
Sì → Copia il messaggio esatto, poi vai alla domanda 2.
No → Verifica se il job risulta ancora come “In elaborazione”. Se lo è, attendi la finestra di elaborazione indicata; se non lo è, riavvia l’esportazione una volta.

2. Il messaggio dice che l’autorizzazione è negata?
Sì → Chiedi a un amministratore l’autorizzazione all’esportazione. Stop.
No → Riduci l’intervallo di date e riprova una volta. Se fallisce di nuovo, invia il messaggio e l’ID di esportazione all’assistenza. Stop.

L’elemento renderizzato dimostra il contratto essenziale: ogni scelta è distinguibile, ogni percorso avanza e ogni percorso termina con un’azione successiva o un’escalation.

Perché questo elemento è importante

“Dipende” è onesto ma incompleto. Un lettore che incontra questa frase deve scoprire da cosa dipende la risposta, decidere quali condizioni si applicano e ricostruire la raccomandazione dalla prosa. Un albero decisionale rende esplicite queste dipendenze. Trasforma una qualifica vaga in una sequenza delimitata: osserva un fatto, scegli un ramo, poi agisci sul punto terminale.

Questo riduce il carico sulla memoria di lavoro. Il lettore valuta solo le scelte correnti invece di tenere a mente ogni eccezione. Rende anche visibile l’incertezza. Se una persona non può rispondere a un nodo, l’albero può indirizzarla a un controllo, una misurazione o un esperto piuttosto che invitare a un’ipotesi. Questo è particolarmente importante per la risoluzione dei problemi, l’idoneità, la selezione d’acquisto e l’interpretazione delle policy, dove un ramo sbagliato ma fatto con sicurezza può far perdere tempo o creare rischi.

L’estraibilità automatica significa che un crawler, un sistema di ricerca, un sistema di risposta AI o uno strumento di trasformazione dei contenuti può recuperare ogni domanda, le sue risposte consentite e il nodo o punto terminale successivo. La prosa continua del tipo “se questo, forse quello, a meno che…” nasconde queste relazioni nella grammatica. Un albero tipizzato le espone come record con identificatori stabili e target espliciti. Una macchina può preservare il percorso inizio → ha-errore → autorizzazione-negata → richiedi-accesso senza dover dedurre quale paragrafo modifica quale condizione.

Segui le regole di scrittura degli elementi prima di applicare il pattern. Lo scopo ha la precedenza sull’aspetto: una sequenza rimane un elenco di passaggi quando tutti eseguono le stesse azioni in ordine, e un confronto rimane un confronto quando i lettori devono ispezionare le opzioni fianco a fianco. Usa un albero decisionale solo quando una risposta precedente cambia ciò che dovrebbe accadere dopo.

Quando usarlo

Usa un albero decisionale quando tutte queste condizioni sono soddisfatte:

1. Almeno una raccomandazione significativa dipende da una risposta fornita dal lettore o dalla sua situazione.
2. Ogni decisione può essere espressa con scelte osservabili e mutuamente esclusive.
3. Seguire un ramo rimuove le scelte irrilevanti, non si limita a nascondere contesto utile.
4. Ogni percorso termina in un’azione, conclusione, fallback nominato o escalation.
5. L’autore può spiegare perché ogni condizione modifica la raccomandazione.

Gli utilizzi efficaci includono la diagnosi di un sintomo noto, la scelta tra categorie di prodotti, la verifica dell’applicabilità di una policy, la selezione di una via di implementazione e la decisione su quando un processo di routine deve essere portato in escalation.

I casi limite dovrebbero rimanere in forme più semplici:

• Una raccomandazione con diverse ragioni: usa la normale prosa esplicativa. Nessuna risposta cambia il risultato.
• Una procedura fissa: usa passaggi ordinati. Diramazioni all’interno di ogni passaggio rendono più difficile vedere il percorso principale.
• Opzioni che i lettori devono confrontare su criteri condivisi: usa una tabella di confronto. Un albero può raccomandare un’opzione dopo il confronto, ma non può sostituire le evidenze.
• Un quiz di personalità: le preferenze possono sovrapporsi e il punteggio può essere cumulativo. Questo è un modello di valutazione, non un albero esclusivo.
• Un elenco di segmenti di pubblico: usa un selettore di persona quando i lettori scelgono semplicemente il loro ruolo e ricevono contenuti paralleli.
• Un calcolo complesso: usa una calcolatrice quando si combinano più input numerici. Convertire intervalli in dozzine di rami fa perdere precisione.
• Un funnel di vendita mascherato: se ogni percorso raccomanda lo stesso prodotto, l’albero crea l’illusione di una diagnosi. Enuncia la raccomandazione e i suoi limiti direttamente.

Dove posizionarlo

Posiziona l’albero immediatamente dopo che il lettore ha compreso la decisione, il suo ambito e gli eventuali fatti necessari per rispondere al primo nodo. In un articolo di risoluzione dei problemi, inserisci i controlli di sicurezza condivisi e il sintomo esatto prima dell’albero. In una guida all’acquisto, definisci i criteri e l’insieme delle opzioni ammissibili prima di indirizzare i lettori a una categoria. In un contenuto policy, enuncia la regola autorevole e la giurisdizione prima di diramarti attraverso le eccezioni.

Regole esatte di posizionamento:

• Introduci l’albero con un H2 e una frase che nomina la decisione che risolve.
• Metti definizioni, misurazioni e prerequisiti prima del primo nodo; mai fare dipendere un’etichetta di ramo da un termine non definito.
• Tieni le evidenze a sostegno vicine al punto terminale che giustificano, o collega ogni punto terminale a una sezione di evidenze visibile sulla stessa pagina.
• Inserisci un riepilogo dopo un albero lungo in modo che i lettori possano confermare il punto terminale selezionato e capire cosa fare dopo.
• Mantieni l’albero prima dell’invito all’azione finale. L’azione dovrebbe seguire una conclusione, non interrompere la diagnosi.

Un albero decisionale non può essere posizionato direttamente accanto a un altro albero decisionale, a un set di schede persona o a un accordion che nasconde informazioni necessarie per scegliere un ramo. Non deve separare un avviso dalla condizione pericolosa che qualifica, interrompere una procedura ordinata senza un punto terminale esplicito di “ritorno al passaggio”, o apparire prima di un confronto che fornisce le evidenze per le sue raccomandazioni. Non posizionare card promozionali all’interno dei nodi; la pressione commerciale rende difficile fidarsi di un instradamento neutrale.

Anatomia

L’anatomia ha otto parti:

1. Titolo: nomina la decisione come obiettivo del lettore, ad esempio “Scegli una via di recupero dell’esportazione”.
2. Dichiarazione di ambito: indica quali situazioni l’albero copre e quali esclude.
3. Nodo iniziale: fornisce un punto di ingresso inequivocabile.
4. Nodo domanda: chiede un fatto osservabile, non un’opinione contenente più condizioni.
5. Etichette di ramo: forniscono risposte mutuamente esclusive nella stessa categoria logica.
6. Connettori: mappano ogni risposta a un nodo successivo o a un punto terminale tramite ID stabili.
7. Punto terminale: fornisce una conclusione, azione, collegamento a evidenze o escalation sicura e segna visibilmente il percorso come completato.
8. Fallback: gestisce “sconosciuto”, “non si applica nessuno”, dati mancanti o una situazione non sicura senza forzare un’ipotesi.

Una freccia visiva è presentazione, non la relazione stessa. I dati sorgente devono identificare il target di ogni ramo anche quando il renderer dispone l’albero verticalmente su uno schermo stretto.

Esempi di design

Ogni variante di design utilizza lo stesso contratto nodo-target. Scegli in base alla struttura logica e al viewport, non alla novità visiva.

Albero diagnostico binario

Ogni nodo ha rami “sì” e “no”. Usalo quando un fatto è genuinamente booleano: uno stato esiste, un test è superato o un’autorizzazione è presente. Evita domande negative perché “No” diventa difficile da interpretare.

Albero di selezione a scelta multipla

Un nodo offre tre o quattro categorie non sovrapposte, come durata contrattuale, ambiente o vincolo principale. Definisci i confini delle categorie nelle etichette; “piccolo”, “medio” e “grande” sono inutilizzabili senza intervalli.

Albero di qualifica a stadi

I nodi iniziali rimuovono i percorsi non idonei; i nodi successivi affinano tra le scelte ammissibili. Usalo per policy, servizio o applicabilità di integrazione. Metti le condizioni di sicurezza e legali squalificanti per prime perché le preferenze successive non possono sovrascriverle.

Albero lineare con uscite per eccezioni

Il percorso principale continua attraverso una sequenza normale mentre rami occasionali escono verso il recupero o l’escalation. Usalo quando la maggior parte dei lettori segue un percorso e le eccezioni sono rare. Etichetta i punti di ritorno con precisione se un’eccezione si ricongiunge alla procedura.

Vista interattiva a una domanda

Mostra un solo nodo corrente alla volta solo quando l’albero completo è troppo denso per il viewport. Includi contesto di avanzamento, pulsanti Indietro, Ricomincia, un riepilogo testuale del risultato e una vista accessibile non interattiva. L’albero sorgente completo deve rimanere disponibile senza recupero lato client.

Parametri

Il genitore possiede l’identità dell’albero e il punto di partenza. I nodi ripetuti possiedono il proprio prompt o contenuto del punto terminale, mentre i record dei rami possiedono le etichette delle risposte e i target.

Un punto terminale non ha rami. Una domanda ne ha almeno due e ogni target si risolve in un nodo dello stesso albero. I dati devono essere aciclici: nessun ramo può portare a un antenato. Un percorso di recupero che si ricongiunge a una procedura dovrebbe terminare con “Ritorna al passaggio 3” piuttosto che creare un ciclo all’interno dell’albero.

Sintassi ed esempi di codice

Tutte e tre le forme descrivono gli stessi record canonici. I renderer possono cambiare il layout, ma devono preservare l’ordine sorgente, le etichette, i target, i punti terminali e il percorso di lettura non interattivo completo.

Direttiva Markdown portabile

:::decision-tree{id=export-recovery variant=binary start=has-error}
## Scegli una via di recupero dell'esportazione

::item{id=has-error kind=question branches="yes:permission-error|no:still-processing"}
### L'esportazione mostra un messaggio di errore?
Scegli dallo stato mostrato nella cronologia delle esportazioni.
::

::item{id=permission-error kind=question branches="yes:request-access|no:retry-smaller"}
### Il messaggio dice che l'autorizzazione è negata?
::

::item{id=still-processing kind=endpoint}
### Verifica la finestra di elaborazione
Attendi fino al termine della finestra indicata, poi riavvia l'esportazione una volta.
::

::item{id=request-access kind=endpoint}
### Richiedi autorizzazione all'esportazione
Chiedi a un amministratore l'accesso prima di riprovare.
::

::item{id=retry-smaller kind=endpoint}
### Riprova con un'esportazione più piccola
Riduci l'intervallo di date una volta; se fallisce, invia l'errore e l'ID di esportazione all'assistenza.
::
:::

L’attributo compatto branches utilizza coppie label:target separate da |. Le etichette non possono contenere né l’uno né l’altro delimitatore. Una piattaforma con record di rami nidificati può memorizzare gli stessi valori strutturalmente, ma l’esportazione deve riprodurre la mappatura esplicita etichetta-target.

Shortcode Hugo

{{< decision-tree title="Scegli una via di recupero dell'esportazione" id="export-recovery" variant="binary" start="has-error" >}}
  {{< decision-node id="has-error" kind="question" title="L'esportazione mostra un messaggio di errore?" branches="Sì:permission-error|No:still-processing" >}}
  Scegli dallo stato mostrato nella cronologia delle esportazioni.
  {{< /decision-node >}}
  {{< decision-node id="permission-error" kind="question" title="Il messaggio dice che l'autorizzazione è negata?" branches="Sì:request-access|No:retry-smaller" >}}{{< /decision-node >}}
  {{< decision-node id="still-processing" kind="endpoint" title="Verifica la finestra di elaborazione" >}}
  Attendi fino al termine della finestra indicata, poi riavvia l'esportazione una volta.
  {{< /decision-node >}}
  {{< decision-node id="request-access" kind="endpoint" title="Richiedi autorizzazione all'esportazione" >}}
  Chiedi a un amministratore l'accesso prima di riprovare.
  {{< /decision-node >}}
  {{< decision-node id="retry-smaller" kind="endpoint" title="Riprova con un'esportazione più piccola" >}}
  Riduci l'intervallo di date una volta; se fallisce, invia l'errore e l'ID di esportazione all'assistenza.
  {{< /decision-node >}}
{{< /decision-tree >}}

Questa è la specifica dell’adattatore Hugo, non un’istruzione per imitare l’albero con elenchi nidificati arbitrari. Utilizza solo parametri nominati e richiede che il renderer rifiuti target mancanti, ID duplicati, cicli e nodi domanda senza rami sufficienti.

Blocco WordPress

<!-- wp:amicited/decision-tree {"title":"Scegli una via di recupero dell'esportazione","id":"export-recovery","variant":"binary","start":"has-error"} -->
  <!-- wp:amicited/decision-node {"id":"has-error","kind":"question","title":"L'esportazione mostra un messaggio di errore?","branches":[{"label":"Sì","target":"permission-error"},{"label":"No","target":"still-processing"}]} -->
  <p>Scegli dallo stato mostrato nella cronologia delle esportazioni.</p>
  <!-- /wp:amicited/decision-node -->
  <!-- wp:amicited/decision-node {"id":"permission-error","kind":"question","title":"Il messaggio dice che l'autorizzazione è negata?","branches":[{"label":"Sì","target":"request-access"},{"label":"No","target":"retry-smaller"}]} /-->
  <!-- wp:amicited/decision-node {"id":"still-processing","kind":"endpoint","title":"Verifica la finestra di elaborazione"} -->
  <p>Attendi fino al termine della finestra indicata, poi riavvia l'esportazione una volta.</p>
  <!-- /wp:amicited/decision-node -->
  <!-- wp:amicited/decision-node {"id":"request-access","kind":"endpoint","title":"Richiedi autorizzazione all'esportazione"} -->
  <p>Chiedi a un amministratore l'accesso prima di riprovare.</p>
  <!-- /wp:amicited/decision-node -->
  <!-- wp:amicited/decision-node {"id":"retry-smaller","kind":"endpoint","title":"Riprova con un'esportazione più piccola"} -->
  <p>Riduci l'intervallo di date una volta; se fallisce, invia l'errore e l'ID di esportazione all'assistenza.</p>
  <!-- /wp:amicited/decision-node -->
<!-- /wp:amicited/decision-tree -->

Il blocco genitore WordPress limita i blocchi interni ai nodi decisionali, convalida i target prima della pubblicazione e renderizza lato server un elenco completo o una struttura accessibile equivalente. Le linee di connessione solo per l’editor non costituiscono la fonte di verità.

Esempi

Esempio corretto

Una guida all’acquisto chiede: “Il dispositivo deve funzionare senza alimentazione di rete?” Sì indirizza verso opzioni a batteria; No chiede: “Rimarrà in una posizione fissa?” Questa risposta indirizza verso opzioni fisse o portatili. Ogni punto terminale nomina una categoria, spiega il vincolo decisivo e invia il lettore a un confronto visibile dei prodotti idonei. “Non sono sicuro” indirizza a misurare la posizione prevista e verificare l’accesso alle prese.

Funziona perché le domande riguardano fatti che un lettore può osservare, i rami non si sovrappongono e ogni risposta rimuove le categorie non adatte. L’albero raccomanda una categoria piuttosto che fingere di selezionare un prodotto specifico senza confronti di prezzo, funzionalità ed evidenze.

Esempio errato

Una pagina software chiede: “Vuoi risultati migliori?” Sia Sì che Non ancora indirizzano a “Prenota una demo”. La domanda successiva chiede se il visitatore apprezza velocità, qualità o risparmio, sebbene la maggior parte degli acquirenti apprezzi tutti e tre. Ogni punto terminale ripete la stessa affermazione sul prodotto.

Fallisce perché le scelte non sono né mutuamente esclusive né modificano la decisione. Le domande raccolgono consenso piuttosto che diagnosticare esigenze, e i rami nascondono un singolo invito all’azione. Sostituiscilo con una proposta di valore diretta e evidenze. Se diverse implementazioni si adattano effettivamente a vincoli diversi, chiedi informazioni su quei vincoli misurabili e permetti un punto terminale onesto come “Questo prodotto non è adatto.”

Markup dello schema e accessibilità

Schema.org non ha un tipo DecisionTree. Non etichettare l’elemento come HowTo a meno che la pagina non contenga indipendentemente una procedura ordinata, e non etichettare i nodi domanda come FAQPage quando le loro risposte sono meramente controlli di ramo. L’albero può aiutare a generare dati di contenuto interni — nodi, scelte, target e raccomandazioni dei punti terminali — ma non alimenta alcuna proprietà pubblica dello schema per impostazione predefinita.

Per l’accessibilità, usa un’intestazione per il titolo dell’albero e un elenco ordinato o nidificato per la forma statica completa. Ogni domanda e punto terminale necessita di testo visibile; i connettori non possono fare affidamento solo su colore, direzione delle linee o posizione spaziale. Ripeti l’etichetta della risposta nella relazione, ad esempio “Se sì, continua a Controllo autorizzazione.” Un lettore di schermo dovrebbe comprendere il percorso senza interpretare un diagramma.

Se l’albero è interattivo, usa pulsanti nativi per le scelte. Esponi la domanda corrente in una regione etichettata, sposta il focus sulla nuova domanda o annunciala tramite una regione live moderata, e fornisci i controlli Indietro e Ricomincia. Non disabilitare lo zoom del browser, non intrappolare il focus e non cambiare una scelta al focus. Preserva il percorso selezionato in testo al punto terminale in modo che il lettore possa verificare come è stato raggiunto il risultato.

Tutti i nodi e i punti terminali dovrebbero arrivare in HTML renderizzato lato server, anche se i nodi inattivi sono visivamente nascosti. Se le prestazioni lo rendono impraticabile per un sistema esperto molto grande, pubblica un’alternativa accessibile completa e tratta l’applicazione interattiva come uno strumento separato piuttosto che come questo elemento di contenuto.

Regole di scrittura

L’obiettivo è il percorso difendibile più breve, non l’apparenza di sofisticatezza.

• Scrivi il titolo come una decisione: “Scegli…”, “Verifica se…” o “Trova il…”. Mantienilo tra 3 e 12 parole.
• Chiedi un fatto per domanda in 5–18 parole. Separa le condizioni unite da “e” o “o” a meno che non abbiano sempre la stessa risposta osservabile.
• Usa da due a quattro rami per domanda e non più di cinque livelli decisionali. Maggiore profondità fa perdere ai lettori il loro percorso e rende i diagrammi mobili ingestibili.
• Rendi i rami fratelli mutuamente esclusivi e collettivamente sufficienti per l’ambito previsto. Aggiungi “Non sono sicuro” o “Nessuno di questi” quando l’incertezza è realistica.
• Usa etichette parallele di una categoria: tutto sì/no, tutti gli intervalli, tutti gli ambienti o tutti i vincoli dichiarati.
• Indica i confini numerici esattamente. Usa “Meno di 50 sedi” invece di “piccola azienda”. Evita intervalli sovrapposti ai valori di confine.
• Dai a ogni punto terminale un titolo di azione di 2–10 parole e fino a 80 parole che spieghino perché segue, cosa fare e quando fare escalation.
• Metti il controllo discriminante più sicuro ed economico all’inizio. Non chiedere misurazioni specialistiche prima di un controllo di stato visibile o di autorizzazione che già determina il percorso.
• Mantieni evidenze, limitazioni e conseguenze visibili. Un albero organizza una decisione; non dimostra che la raccomandazione sia corretta.
• Testa ogni percorso ad alta voce come una frase: “Poiché la risposta era X, continua a Y.” Se quella frase è illogica, il ramo è sbagliato.

Non inserire mai dati personali riservati, diagnosi mediche o legali non qualificate, un prezzo nascosto, un avviso di sicurezza, un modulo a più campi o un’azione irreversibile all’interno di un nodo. Non creare mai un vicolo cieco, un connettore non etichettato, un punto terminale che dice solo “Dipende” o un ciclo che fa ripetere le domande al lettore indefinitamente.

Tipi di post che lo utilizzano

Il frontmatter postTypes definisce l’insieme supportato. La presenza in questa tabella significa che il tipo di post può utilizzare un albero quando i suoi contenuti si ramificano genuinamente; non rende l’elemento obbligatorio su ogni pagina.

Checklist QA

• La pagina contiene una dipendenza reale: almeno una risposta cambia la domanda successiva o il punto terminale.
• Il titolo e l’ambito indicano esattamente quale decisione l’albero risolve ed esclude.
• C’è un nodo iniziale, ogni domanda ha da due a quattro rami e ogni target esiste.
• Le scelte fratello sono mutuamente esclusive, usano etichette parallele e coprono l’incertezza realistica.
• Ogni percorso termina in un’azione, conclusione, fallback o escalation entro cinque livelli.
• Nessun punto terminale è orfano, nessun nodo punta a se stesso o a un antenato e nessun lettore può ciclare indefinitamente.
• Ogni punto terminale spiega perché segue e mantiene evidenze o limitazioni disponibili.
• L’albero non sostituisce una procedura fissa, un confronto affiancato, un calcolo, un avviso o una raccomandazione diretta.
• Tutti i testi e le relazioni sono presenti nell’HTML renderizzato lato server e comprensibili senza linee di connessione.
• Gli utenti da tastiera possono scegliere, tornare indietro, riavviare e raggiungere il risultato con focus visibile.
• I cambiamenti di focus e stato vengono annunciati senza intrappolare il focus o interrompere ripetutamente un lettore di schermo.
• Il rendering su schermo stretto preserva l’ordine sorgente, etichetta ogni connettore e non richiede scorrimento orizzontale.
• Il fallback statico e il risultato interattivo producono gli stessi punti terminali per le stesse risposte.
• Un revisore ha percorso ogni ramo, testato i valori limite e contestato qualsiasi ramo che porti allo stesso risultato.

Domande frequenti

Le domande seguenti coprono scelte implementative che spesso emergono solo dopo che l’albero è stato abbozzato. Il test principale rimane semplice: i rami devono rappresentare fatti che cambiano il risultato, e ogni percorso deve terminare in sicurezza.