Árbol de decisión: Reglas y ejemplos de orientación por ramas

Un árbol de decisión es una secuencia de preguntas en la que cada respuesta selecciona la siguiente pregunta o una recomendación final. Úsalo cuando la acción correcta cambie genuinamente según los hechos que el lector pueda identificar—no como decoración para un consejo que es el mismo para todos.

Elige la primera respuesta ante una exportación de datos fallida

1. ¿La exportación muestra un mensaje de error?
Sí → Copia el mensaje exacto, luego ve a la pregunta 2.
No → Verifica si el trabajo aún aparece como “Procesando”. Si es así, espera el plazo de procesamiento indicado; si no, reinicia la exportación una vez.

2. ¿El mensaje dice que el permiso está denegado?
Sí → Solicita permiso de exportación a un administrador. Fin.
No → Reduce el rango de fechas y reintenta una vez. Si falla de nuevo, envía el mensaje y el ID de exportación al soporte. Fin.

El elemento renderizado demuestra el contrato esencial: cada opción es distinguible, cada camino avanza y cada camino termina con una acción siguiente o una escalación.

Por qué es importante este elemento

“Todo depende” es honesto pero incompleto. Un lector que encuentra esa frase debe descubrir de qué depende la respuesta, decidir qué condiciones aplican y reconstruir la recomendación a partir de la prosa. Un árbol de decisión hace explícitas esas dependencias. Convierte una calificación vaga en una secuencia acotada: observa un hecho, elige una rama, luego actúa según el punto final.

Esto reduce la carga de la memoria de trabajo. El lector evalúa solo las opciones actuales en lugar de tener en mente cada excepción. También hace visible la incertidumbre. Si una persona no puede responder un nodo, el árbol puede dirigirla a una verificación, medición o experto en lugar de invitarla a adivinar. Esto es especialmente importante en la solución de problemas, elegibilidad, selección de compra e interpretación de políticas, donde una rama equivocada pero segura puede costar tiempo o generar riesgo.

La extractabilidad por máquina significa que un rastreador, sistema de búsqueda, sistema de respuestas de IA o herramienta de transformación de contenido puede recuperar cada pregunta, sus respuestas permitidas y el siguiente nodo o punto final. La prosa continua de “si esto, quizás aquello, a menos que…” oculta esas relaciones en la gramática. Un árbol tipificado las expone como registros con identificadores estables y destinos explícitos. Una máquina puede preservar la ruta inicio → tiene-error → permiso-denegado → solicitar-acceso sin inferir qué párrafo modifica qué condición.

Sigue las reglas de redacción de elementos antes de aplicar el patrón. El propósito tiene prioridad sobre la apariencia: una secuencia sigue siendo una lista de pasos cuando todos realizan las mismas acciones en orden, y una comparación sigue siendo una comparación cuando los lectores necesitan inspeccionar opciones lado a lado. Usa un árbol de decisión solo cuando una respuesta previa cambia lo que debería suceder después.

Cuándo usarlo

Usa un árbol de decisión cuando se cumplan todas estas condiciones:

1. Al menos una recomendación significativa depende de una respuesta proporcionada por el lector o su situación.
2. Cada decisión puede expresarse con opciones observables y mutuamente excluyentes.
3. Seguir una rama elimina opciones irrelevantes en lugar de simplemente ocultar contexto útil.
4. Cada ruta termina en una acción, conclusión, alternativa nombrada o escalación.
5. El autor puede explicar por qué cada condición cambia la recomendación.

Los usos sólidos incluyen diagnosticar un síntoma conocido, elegir entre categorías de productos, verificar la aplicabilidad de una política, seleccionar una ruta de implementación y decidir cuándo un proceso rutinario debe escalarse.

Los casos casi válidos deben permanecer en formas más simples:

• Una recomendación con varias razones: usa prosa explicativa ordinaria. Ninguna respuesta cambia el resultado.
• Un procedimiento fijo: usa pasos ordenados. Las ramificaciones dentro de cada paso dificultan ver la ruta principal.
• Opciones que los lectores deben comparar según criterios compartidos: usa una tabla comparativa. Un árbol puede recomendar una opción después de la comparación, pero no puede reemplazar la evidencia.
• Un cuestionario de personalidad: las preferencias pueden superponerse y la puntuación puede ser acumulativa. Eso es un modelo de evaluación, no un árbol exclusivo.
• Una lista de segmentos de audiencia: usa un selector de perfil cuando los lectores simplemente eligen su rol y reciben contenido paralelo.
• Un cálculo complejo: usa una calculadora cuando se combinan varias entradas numéricas. Convertir rangos en docenas de ramas pierde precisión.
• Un embudo de ventas disfrazado: si cada ruta recomienda el mismo producto, el árbol crea una ilusión de diagnóstico. Indica la recomendación y sus límites directamente.

Dónde colocarlo

Coloca el árbol inmediatamente después de que el lector entienda la decisión, su alcance y cualquier hecho que necesite para responder el primer nodo. En un artículo de solución de problemas, coloca las comprobaciones de seguridad compartidas y el síntoma exacto antes del árbol. En una guía de compra, define los criterios y el conjunto de opciones elegibles antes de dirigir a los lectores a una categoría. En contenido de políticas, indica la regla autoritativa y la jurisdicción antes de ramificar a través de excepciones.

Reglas de posición exacta:

• Introduce el árbol con un H2 y una oración que nombre la decisión que resuelve.
• Coloca definiciones, mediciones y requisitos previos antes del primer nodo; nunca hagas que una etiqueta de rama dependa de un término no definido.
• Mantén la evidencia de apoyo cerca del punto final que justifica, o enlaza cada punto final a una sección de evidencia visible en la misma página.
• Coloca un resumen después de un árbol largo para que los lectores puedan confirmar el punto final seleccionado y entender qué hacer a continuación.
• Mantén el árbol antes de la llamada a la acción final. La acción debe seguir a una conclusión, no interrumpir el diagnóstico.

Un árbol de decisión no puede colocarse directamente junto a otro árbol de decisión, un conjunto de pestañas de perfil o un acordeón que oculte información necesaria para elegir una rama. No debe separar una advertencia de la condición peligrosa que califica, interrumpir un procedimiento ordenado sin un punto final explícito de “volver al paso”, ni aparecer antes de una comparación que proporcione la evidencia para sus recomendaciones. No coloques tarjetas promocionales dentro de los nodos; la presión comercial dificulta confiar en un enrutamiento neutral.

Anatomía

La anatomía tiene ocho partes:

1. Título: nombra la decisión como un objetivo del lector, por ejemplo, “Elige una ruta de recuperación de exportación”.
2. Declaración de alcance: indica qué situación cubre el árbol y qué situaciones excluye.
3. Nodo de inicio: proporciona un punto de entrada inequívoco.
4. Nodo de pregunta: solicita un hecho observable, no una opinión que contenga varias condiciones.
5. Etiquetas de rama: proporcionan respuestas mutuamente excluyentes en la misma categoría lógica.
6. Conectores: mapean cada respuesta a un siguiente nodo o a un punto final mediante identificadores estables.
7. Punto final terminal: ofrece una conclusión, acción, enlace de evidencia o escalación segura, y marca visiblemente la ruta como completa.
8. Alternativa: maneja “desconocido”, “ninguno aplica”, datos faltantes o una situación insegura sin forzar una suposición.

Una flecha visual es presentación, no la relación en sí. Los datos fuente deben identificar el destino de cada rama incluso cuando el renderizador dispone el árbol verticalmente en una pantalla estrecha.

Ejemplos de diseño

Cada variante de diseño usa el mismo contrato de nodo y destino. Elige según la estructura de razonamiento y el viewport, no por novedad visual.

Árbol de diagnóstico binario

Cada nodo tiene ramas de “sí” y “no”. Úsalo cuando un hecho sea genuinamente booleano: existe un estado, una prueba pasó o hay un permiso presente. Evita preguntas negativas porque “No” se vuelve difícil de interpretar.

Árbol de selección de opción múltiple

Un nodo ofrece tres o cuatro categorías no superpuestas, como plazo de contrato, entorno o restricción principal. Define los límites de las categorías en las etiquetas; “pequeño”, “mediano” y “grande” son inutilizables sin rangos.

Árbol de calificación escalonada

Los nodos iniciales eliminan rutas no elegibles; los nodos posteriores refinan entre opciones elegibles. Úsalo para políticas, servicios o aplicabilidad de integración. Coloca las condiciones de seguridad y legales descalificativas primero porque las preferencias posteriores no pueden anularlas.

Árbol lineal con salidas de excepción

La ruta principal continúa a través de una secuencia normal mientras que ramas ocasionales salen hacia recuperación o escalación. Úsalo cuando la mayoría de los lectores siguen una ruta y las excepciones son poco comunes. Etiqueta los puntos de retorno con precisión si una excepción se reincorpora al procedimiento.

Vista interactiva de una pregunta

Muestra solo un nodo actual a la vez solo cuando el árbol completo es demasiado denso para el viewport. Incluye contexto de progreso, Atrás, Volver a empezar, un resumen textual del resultado y una vista accesible no interactiva. El árbol fuente completo debe permanecer disponible sin necesidad de descarga del lado del cliente.

Parámetros

El elemento padre posee la identidad del árbol y el punto de inicio. Los nodos repetidos poseen su mensaje o contenido de punto final, mientras que los registros de rama poseen las etiquetas de respuesta y los destinos.

Un punto final no tiene ramas. Una pregunta tiene al menos dos, y cada destino se resuelve en un nodo del mismo árbol. Los datos deben ser acíclicos: ninguna rama puede llevar de vuelta a un ancestro. Una ruta de recuperación que se reincorpore a un procedimiento debe terminar con “Volver al paso 3” en lugar de crear un bucle dentro del árbol.

Sintaxis y ejemplos de código

Las tres formas describen los mismos registros canónicos. Los renderizadores pueden cambiar el diseño, pero deben preservar el orden de fuente, las etiquetas, los destinos, los puntos finales y la ruta de lectura no interactiva completa.

Directiva Markdown portable

:::decision-tree{id=export-recovery variant=binary start=has-error}
## Choose an export recovery route

::item{id=has-error kind=question branches="yes:permission-error|no:still-processing"}
### Does the export show an error message?
Choose from the status shown in the export history.
::

::item{id=permission-error kind=question branches="yes:request-access|no:retry-smaller"}
### Does the message say permission is denied?
::

::item{id=still-processing kind=endpoint}
### Check the processing window
Wait until the stated window ends, then restart the export once.
::

::item{id=request-access kind=endpoint}
### Request export permission
Ask an administrator for access before trying again.
::

::item{id=retry-smaller kind=endpoint}
### Retry a smaller export
Reduce the date range once; if it fails, send the error and export ID to support.
::
:::

El atributo compacto branches usa pares etiqueta:destino separados por |. Las etiquetas no pueden contener ninguno de los dos delimitadores. Una plataforma con registros de rama anidados puede almacenar los mismos valores estructuralmente, pero la exportación debe reproducir el mapeo explícito de etiqueta a destino.

Shortcode de Hugo

{{< decision-tree title="Choose an export recovery route" id="export-recovery" variant="binary" start="has-error" >}}
  {{< decision-node id="has-error" kind="question" title="Does the export show an error message?" branches="Yes:permission-error|No:still-processing" >}}
  Choose from the status shown in the export history.
  {{< /decision-node >}}
  {{< decision-node id="permission-error" kind="question" title="Does the message say permission is denied?" branches="Yes:request-access|No:retry-smaller" >}}{{< /decision-node >}}
  {{< decision-node id="still-processing" kind="endpoint" title="Check the processing window" >}}
  Wait until the stated window ends, then restart the export once.
  {{< /decision-node >}}
  {{< decision-node id="request-access" kind="endpoint" title="Request export permission" >}}
  Ask an administrator for access before trying again.
  {{< /decision-node >}}
  {{< decision-node id="retry-smaller" kind="endpoint" title="Retry a smaller export" >}}
  Reduce the date range once; if it fails, send the error and export ID to support.
  {{< /decision-node >}}
{{< /decision-tree >}}

Esta es la especificación del adaptador de Hugo, no una instrucción para imitar el árbol con listas anidadas arbitrarias. Usa solo parámetros nombrados y requiere que el renderizador rechace destinos faltantes, IDs duplicados, ciclos y nodos de pregunta sin suficientes ramas.

Bloque de WordPress

<!-- wp:amicited/decision-tree {"title":"Choose an export recovery route","id":"export-recovery","variant":"binary","start":"has-error"} -->
  <!-- wp:amicited/decision-node {"id":"has-error","kind":"question","title":"Does the export show an error message?","branches":[{"label":"Yes","target":"permission-error"},{"label":"No","target":"still-processing"}]} -->
  <p>Choose from the status shown in the export history.</p>
  <!-- /wp:amicited/decision-node -->
  <!-- wp:amicited/decision-node {"id":"permission-error","kind":"question","title":"Does the message say permission is denied?","branches":[{"label":"Yes","target":"request-access"},{"label":"No","target":"retry-smaller"}]} /-->
  <!-- wp:amicited/decision-node {"id":"still-processing","kind":"endpoint","title":"Check the processing window"} -->
  <p>Wait until the stated window ends, then restart the export once.</p>
  <!-- /wp:amicited/decision-node -->
  <!-- wp:amicited/decision-node {"id":"request-access","kind":"endpoint","title":"Request export permission"} -->
  <p>Ask an administrator for access before trying again.</p>
  <!-- /wp:amicited/decision-node -->
  <!-- wp:amicited/decision-node {"id":"retry-smaller","kind":"endpoint","title":"Retry a smaller export"} -->
  <p>Reduce the date range once; if it fails, send the error and export ID to support.</p>
  <!-- /wp:amicited/decision-node -->
<!-- /wp:amicited/decision-tree -->

El bloque padre de WordPress limita los bloques internos a nodos de decisión, valida los destinos antes de la publicación y renderiza en servidor una lista completa o estructura accesible equivalente. Las líneas de conexión exclusivas del editor no son la fuente de verdad.

Ejemplos

Buen ejemplo

Una guía de compra pregunta: “¿El dispositivo debe funcionar sin corriente de red?” Sí dirige a opciones a batería; No pregunta: “¿Permanecerá en una ubicación fija?” Esa respuesta dirige a opciones instaladas o portátiles. Cada punto final nombra una categoría, explica la restricción decisiva y envía al lector a una comparación visible de productos elegibles. “No estoy seguro” dirige a medir la ubicación prevista y verificar el acceso a tomas de corriente.

Esto funciona porque las preguntas tratan sobre hechos que un lector puede observar, las ramas no se superponen y cada respuesta elimina categorías no adecuadas. El árbol recomienda una categoría en lugar de pretender seleccionar un producto específico sin comparaciones de precio, características y evidencia.

Mal ejemplo

Una página de software pregunta: “¿Quieres obtener mejores resultados?” Tanto Sí como Aún no dirigen a “Reservar una demostración”. La siguiente pregunta pregunta si el visitante valora velocidad, calidad o ahorro, aunque la mayoría de los compradores valoran las tres cosas. Cada punto final repite la misma afirmación del producto.

Esto falla porque las opciones no son mutuamente excluyentes ni cambian la decisión. Las preguntas recopilan acuerdo en lugar de diagnosticar necesidades, y las ramas ocultan una única llamada a la acción. Reemplázalo con una propuesta de valor directa y evidencia. Si diferentes implementaciones realmente se ajustan a diferentes restricciones, pregunta por esas restricciones medibles y permite un punto final honesto como “Este producto no es adecuado.”

Marcado de esquema y accesibilidad

Schema.org no tiene un tipo DecisionTree. No etiquetes el elemento como HowTo a menos que la página contenga de forma independiente un procedimiento ordenado, y no etiquetes los nodos de pregunta como FAQPage cuando sus respuestas son meramente controles de rama. El árbol puede ayudar a generar datos de contenido interno—nodos, opciones, destinos y recomendaciones de punto final—pero no alimenta ninguna propiedad de esquema pública por defecto.

Para accesibilidad, usa un encabezado para el título del árbol y una lista ordenada o anidada para la forma estática completa. Cada pregunta y punto final necesita texto visible; los conectores no pueden depender solo del color, la dirección de la línea o la posición espacial. Repite la etiqueta de respuesta en la relación, como “Si sí, continúa a Verificación de permiso.” Un lector de pantalla debe entender la ruta sin interpretar un diagrama.

Si el árbol es interactivo, usa botones nativos para las opciones. Expón la pregunta actual en una región etiquetada, mueve el foco a la nueva pregunta o anúnciala mediante una región viva restringida, y proporciona controles de Atrás y Volver a empezar. No deshabilites el zoom del navegador, atrapes el foco ni cambies una opción al recibir el foco. Preserva la ruta seleccionada en texto en el punto final para que el lector pueda verificar cómo se alcanzó el resultado.

Todos los nodos y puntos finales deben llegar en HTML renderizado en servidor, incluso si los nodos inactivos están visualmente ocultos. Si el rendimiento lo hace impráctico para un sistema experto muy grande, publica una alternativa accesible completa y trata la aplicación interactiva como una herramienta separada en lugar de este elemento de contenido.

Reglas de redacción

El objetivo es la ruta defendible más corta, no la apariencia de sofisticación.

• Escribe el título como una decisión: “Elige…”, “Verifica si…” o “Encuentra el…”. Mantenlo entre 3 y 12 palabras.
• Pregunta un hecho por pregunta en 5–18 palabras. Divide condiciones unidas por “y” u “o” a menos que siempre tengan la misma respuesta observable.
• Usa de dos a cuatro ramas por pregunta y no más de cinco niveles de decisión. Más profundidad hace que los lectores pierdan su ruta y que los diagramas móviles sean difíciles de manejar.
• Haz que las ramas hermanas sean mutuamente excluyentes y colectivamente suficientes para el alcance previsto. Añade “No estoy seguro” o “Ninguna de estas” cuando la incertidumbre sea realista.
• Usa etiquetas paralelas de una misma categoría: todo sí/no, todos los rangos, todos los entornos o todas las restricciones indicadas.
• Indica los límites numéricos con exactitud. Usa “Menos de 50 ubicaciones” en lugar de “pequeña empresa”. Evita rangos superpuestos en los valores límite.
• Dale a cada punto final un título de acción de 2 a 10 palabras y hasta 80 palabras explicando por qué sigue, qué hacer y cuándo escalar.
• Coloca la comprobación discriminante más segura y económica al principio. No solicites mediciones de especialistas antes de una verificación de estado o permiso visible que ya determine la ruta.
• Mantén la evidencia, las limitaciones y las consecuencias visibles. Un árbol organiza una decisión; no demuestra que la recomendación sea correcta.
• Prueba cada ruta en voz alta como una oración: “Como la respuesta fue X, continúa a Y.” Si esa oración es ilógica, la rama está mal.

Nunca coloques datos personales confidenciales, diagnósticos médicos o legales no cualificados, un precio oculto, una advertencia de seguridad, un formulario de múltiples campos o una acción irreversible dentro de un nodo. Nunca crees un callejón sin salida, un conector sin etiqueta, un punto final que solo diga “Todo depende”, o un ciclo que haga que el lector repita preguntas indefinidamente.

Tipos de publicación que lo usan

El frontmatter postTypes define el conjunto admitido. La presencia en esta tabla significa que el tipo de publicación puede usar un árbol cuando su contenido realmente se ramifica; no hace que el elemento sea obligatorio en cada página.

Lista de verificación de control de calidad

• La página contiene una dependencia real: al menos una respuesta cambia la siguiente pregunta o punto final.
• El título y el alcance indican exactamente qué decisión resuelve y excluye el árbol.
• Hay un nodo de inicio, cada pregunta tiene de dos a cuatro ramas, y cada destino existe.
• Las opciones hermanas son mutuamente excluyentes, usan etiquetas paralelas y cubren la incertidumbre realista.
• Cada ruta termina en una acción, conclusión, alternativa o escalación en un máximo de cinco niveles.
• Ningún punto final está huérfano, ningún nodo se señala a sí mismo o a un ancestro, y ningún lector puede entrar en un bucle indefinido.
• Cada punto final explica por qué sigue y mantiene la evidencia o las limitaciones disponibles.
• El árbol no reemplaza un procedimiento fijo, una comparación lado a lado, un cálculo, una advertencia o una recomendación directa.
• Todos los textos y relaciones están presentes en HTML renderizado en servidor y son comprensibles sin líneas de conexión.
• Los usuarios de teclado pueden elegir, retroceder, reiniciar y alcanzar el resultado con foco visible.
• Los cambios de foco y estado se anuncian sin atrapar el foco ni interrumpir repetidamente a un lector de pantalla.
• La renderización en pantalla estrecha preserva el orden de fuente, etiqueta cada conector y no requiere desplazamiento horizontal.
• La alternativa estática y el resultado interactivo producen los mismos puntos finales para las mismas respuestas.
• Un revisor ha recorrido cada ruta, probado los valores límite y cuestionado cualquier rama que lleve al mismo resultado.

Preguntas frecuentes

Las preguntas a continuación cubren opciones de implementación que a menudo aparecen solo después de que el árbol ha sido redactado. La prueba central sigue siendo simple: las ramas deben representar hechos que cambien el resultado, y cada ruta debe terminar de forma segura.