Listas de Pasos: Cómo Redactar Instrucciones Paso a Paso
Construye listas de pasos que expliquen cada acción, su propósito, señal de éxito y ruta de recuperación para que tanto personas como máquinas puedan seguir las instrucciones con confianza.
Una lista de pasos es un procedimiento ordenado que lleva al lector desde un estado inicial conocido hasta un resultado verificable. Sus números tienen significado: el paso 2 depende del paso 1, y cambiar la secuencia podría desperdiciar trabajo, crear un error o impedir la finalización. Cada paso explica más que dónde hacer clic. Proporciona la razón, la acción, el estado de éxito y la ruta de recuperación necesarios para seguir avanzando.
Confirma que la secuencia cambia el resultado. Por qué: La numeración promete dependencia, por lo que un orden falso engaña a lectores y máquinas. Acción: Intenta intercambiar dos acciones. Éxito: Al menos un intercambio cambiaría, bloquearía o invalidaría el resultado. Recuperación: Si todas las acciones siguen funcionando, reemplaza la secuencia con viñetas o una lista de verificación.
Redacta el estado de éxito observable. Por qué: Los lectores necesitan evidencia de que la acción funcionó antes de continuar. Acción: Nombra lo que pueden ver, medir, descargar o probar. Éxito: Una persona no familiarizada con el borrador podría decidir si aprueba o no. Recuperación: Si el éxito depende solo del criterio, añade un umbral concreto o un ejemplo.
Añade una ruta de recuperación para fallos. Por qué: Un procedimiento que asume una ejecución perfecta abandona al lector en el primer error. Acción: Indica la corrección más segura, el reintento o la escalada. Éxito: El lector puede regresar al estado esperado sin adivinar. Recuperación: Si no existe una recuperación segura, advierte antes de la acción e identifica quién puede ayudar.
Ese ejemplo real es deliberadamente compacto, pero aún así cumple con el contrato del paso. El resto de esta página define cómo producir el elemento de manera consistente en todos los sistemas de publicación.
Por qué este elemento es importante
Los lectores de procedimientos quieren saber qué hacer ahora, por qué es importante, si funcionó y qué hacer cuando la realidad difiere del camino ideal. «Haz clic en Guardar» solo responde a la primera pregunta. Deja al lector inferir qué confirmación esperar y qué significa un fallo.
La lista de pasos reduce esa incertidumbre creando un ritmo de decisión repetido. Un título imperativo comienza con un comando como «Conectar», «Verificar» o «Publicar». La razón establece relevancia antes de que el lector invierta esfuerzo. La acción proporciona suficiente detalle para ejecutar. El estado de éxito hace observable la finalización. La ruta de recuperación evita que una acción fallida se convierta en un callejón sin salida. Este es el contrato del paso, y cada paso visible debe satisfacer las cinco partes.
La misma regularidad mejora la capacidad de extracción por máquina: la habilidad de un motor de búsqueda, un agente de IA o un sistema de transformación para aislar una instrucción sin perder su función. El orden estable, los títulos descriptivos, los resultados explícitos y la orientación de recuperación acotada permiten que una máquina distinga la instrucción de su verificación.
Los números no crean ese significado por sí solos. Revelan un significado que el contenido ya posee. Cuando la secuencia es genuina, la numeración comunica dependencia a un lector que escanea y preserva la posición para los datos estructurados. Cuando la secuencia es artificial, la numeración crea una falsa promesa.
Cuándo usarla
Usa una lista de pasos cuando el lector deba realizar un procedimiento en orden y cada acción completada establezca el estado inicial para la siguiente. Los usos apropiados incluyen configuración de cuentas, ajustes de software, un flujo de trabajo de análisis repetible, una migración, una secuencia de reparación o un proceso de publicación con dependencias.
No uses una lista de pasos solo porque los números se vean autoritativos. Usa viñetas cuando los elementos sean opciones, ejemplos, ingredientes o características. Usa una lista de verificación cuando los elementos sean puntos de control independientes que puedan verificarse en cualquier orden. Usa una tabla comparativa cuando el lector esté eligiendo entre alternativas en lugar de avanzar hacia un resultado. Usa texto corriente cuando solo haya una o dos acciones obvias y ninguna necesite verificación independiente.
Los casos fronterizos causan la mayoría de los usos incorrectos:
- «Diez formas de mejorar una página de aterrizaje» es un artículo de lista a menos que el elemento 4 requiera el resultado del elemento 3.
- «Antes de publicar, revisa el título, los enlaces, las imágenes y el autor» es una lista de verificación porque el orden no determina la validez.
- «Elige un plan, ingresa los datos de pago y confirma la compra» es una lista de pasos porque cada estado desbloquea el siguiente.
- «Si la importación falla, prueba A, B o C» es una guía de solución de problemas. Se convierte en lista de pasos solo cuando las ramas de diagnóstico deben probarse en un orden definido.
- Una cronología describe lo que sucedió a lo largo del tiempo. No es un procedimiento a menos que el lector pueda realizar sus acciones para alcanzar el resultado indicado.
Ejecuta la prueba de intercambio siempre que la intención no esté clara: intercambia dos elementos adyacentes y pregúntate si el procedimiento sigue siendo correcto. Si cada intercambio es inofensivo, el orden es decorativo y este es el elemento equivocado.
Dónde ubicarla
Una lista de pasos va después de que el lector entienda el resultado y tenga los datos necesarios para comenzar. Coloca un bloque de requisitos previos inmediatamente encima, indicando el estado inicial, permisos, archivos o datos, herramientas, suministros, tiempo y riesgos irreversibles. Omite los campos que no apliquen; nunca escondas un dato requerido dentro del paso 4.
Coloca un bloque de resultado inmediatamente debajo del paso final. Este indica la condición final, el artefacto o estado que el lector debería tener ahora y la siguiente acción sensata. Esto cierra el procedimiento en lugar de dejar al lector inferir que la ausencia de otro número significa éxito.
El elemento puede aparecer una vez como el procedimiento principal en una página de instrucciones, o varias veces como fases claramente nombradas en un tutorial más extenso. Un encabezado de fase debe explicar el resultado intermedio, y la numeración debe continuar entre fases o usar identificadores explícitos como «Fase 2, paso 1». No reinicies silenciosamente en 1.
Una lista de pasos no debe colocarse directamente junto a otra lista numerada con un propósito diferente; un encabezado o una transición debe explicar el límite. No debe comenzar antes de una advertencia que cambie si la tarea es segura de intentar. No coloques una llamada a la acción genérica entre pasos, pongas referencias entre una acción y su estado de éxito, o insertes una tabla comparativa no relacionada en medio del procedimiento. El material de apoyo pertenece al interior del paso relevante solo cuando ayuda a completar esa acción; de lo contrario, colócalo antes o después de la secuencia completa.
Anatomía
La anatomía tiene tres regiones a nivel de colección y cinco regiones repetidas a nivel de paso:
- Requisitos previos: el estado inicial, acceso, herramientas, suministros, tiempo y restricciones importantes.
- Etiqueta de secuencia: un encabezado descriptivo que nombra el procedimiento y su resultado.
- Número de paso: la posición semántica, generada por el renderizador de listas ordenadas en lugar de escrita en el título.
- Título imperativo: una frase liderada por una acción que permite a quien escanea predecir la tarea.
- Por qué: la dependencia, riesgo o beneficio que justifica realizar el paso ahora.
- Acción: la instrucción exacta, incluyendo ubicación relevante, entrada y elección.
- Éxito y recuperación: el estado final observable seguido de la siguiente respuesta segura cuando ese estado no aparece.
- Resultado: el estado final y lo que el lector puede hacer con él.
La leyenda permanece en la página porque las etiquetas son contenido, no decoración. Si el diseño cambia, las mismas regiones semánticas deben seguir siendo identificables sin editar píxeles.
Ejemplos de diseño
La variante predeterminada maneja la mayoría de los procedimientos editoriales. Una variante compacta puede reducir el espacio, pero no puede eliminar los campos del contrato. Una variante asistida por capturas de pantalla combina un paso de interfaz ambiguo con una imagen enfocada. Una variante por fases agrupa un procedimiento largo según resultados intermedios, manteniendo una secuencia general coherente.
Ninguna variante «mínima» puede eliminar las razones o las rutas de recuperación. La presentación puede comprimir espacios en blanco, no el contrato editorial.
Parámetros
Estos parámetros definen el contenido fuente, no la decoración visual opcional. La columna Fuente indica si un valor proviene de un atributo, del cuerpo de un elemento anidado o de su primer encabezado.
| Nombre | Tipo | Obligatorio | Mín/máx | Predeterminado | Fuente | |
|---|---|---|---|---|---|---|
title | Cadena simple | Sí | 3–10 palabras | Ninguno | Primer encabezado en el cuerpo padre | |
variant | Enumeración | No | default, compact o phased | default | Atributo padre | |
totalTime | Duración ISO 8601 | No | 1 minuto a 30 días | Omitido | Atributo padre, respaldado por texto de tiempo visible | |
prerequisites | Bloque Markdown | Sí cuando existe algún requisito | 1–6 elementos; 10–120 palabras | Omitido solo cuando no existen | Cuerpo padre antes de los elementos | |
steps | Colección de elementos ordenados | Sí | 3–10 pasos | Ninguno; objetivo 5 | Cuerpos de elementos anidados | |
step.title | Cadena simple | Sí | 2–8 palabras; 60 caracteres | Ninguno | Primer encabezado en el cuerpo del elemento | |
step.why | Markdown simple | Sí | 10–35 palabras | Ninguno | Cuerpo del elemento | |
step.action | Markdown simple | Sí | 15–70 palabras | Ninguno | Cuerpo del elemento | |
step.success | Markdown simple | Sí | 8–30 palabras | Ninguno | Cuerpo del elemento | |
step.recovery | Markdown simple | Sí | 8–40 palabras | Ninguno | Cuerpo del elemento | |
step.image | Ruta de activo relativa a la raíz | No | 0–1 imagen por paso | Omitido | Atributo del elemento; solo después de que el activo exista | |
supply | Colección de cadenas simples | No | 0–8 elementos visibles | Omitido | Requisitos previos del cuerpo padre | |
tool | Colección de cadenas simples | No | 0–8 elementos visibles | Omitido | Requisitos previos del cuerpo padre | |
outcome | Bloque Markdown | Sí | 15–80 palabras | Ninguno | Cuerpo padre después de los elementos |
La longitud normal por paso es de 50 a 140 palabras en los cinco campos del contrato. Los pasos más cortos tienden a omitir el razonamiento o la verificación; los pasos más largos suelen ocultar varias acciones.
Sintaxis y ejemplos de código
La estructura canónica sigue las reglas de redacción de elementos : el elemento padre contiene las configuraciones de la colección y cada paso repetido es un elemento anidado. Los ejemplos a continuación codifican el mismo fragmento de dos pasos para claridad de mapeo; un procedimiento publicable normalmente debe contener al menos tres pasos.
Directiva Markdown portátil
:::step-list{totalTime="PT15M" variant=default}
## Conectar y verificar la fuente de datos
Requisitos previos: acceso de administrador y el identificador de la propiedad.
::item
### Abrir la pantalla de conexión de la propiedad
**Por qué:** Comenzar desde la propiedad correcta evita que los datos se adjunten a la cuenta equivocada.
**Acción:** Abre Configuración, elige Fuentes de datos y selecciona el identificador de la propiedad mostrado en el bloque de requisitos previos.
**Éxito:** El nombre de la propiedad seleccionada aparece en el resumen de conexión.
**Recuperación:** Si está ausente, confirma el acceso a la cuenta y recarga la lista de propiedades.
::
::item
### Ejecutar la prueba de conexión
**Por qué:** Una prueba exitosa demuestra que las credenciales y los permisos funcionan antes de la primera importación.
**Acción:** Selecciona Probar conexión y espera la respuesta de estado.
**Éxito:** La interfaz muestra «Conectado» con una marca de tiempo actual.
**Recuperación:** Reautoriza la cuenta; si la prueba sigue fallando, copia el código de error para soporte.
::
Resultado: la fuente está conectada y lista para su primera importación.
:::
Mapeo de shortcode de Hugo
{{< step-list totalTime="PT15M" variant="default" >}}
Requisitos previos: acceso de administrador y el identificador de la propiedad.
{{< step title="Abrir la pantalla de conexión de la propiedad" >}}
**Por qué:** Comenzar desde la propiedad correcta evita que los datos se adjunten a la cuenta equivocada.
**Acción:** Abre Configuración, elige Fuentes de datos y selecciona el identificador de la propiedad.
**Éxito:** La propiedad seleccionada aparece en el resumen de conexión.
**Recuperación:** Confirma el acceso y recarga la lista de propiedades.
{{< /step >}}
{{< step title="Ejecutar la prueba de conexión" >}}...{{< /step >}}
Resultado: la fuente está conectada y lista para su primera importación.
{{< /step-list >}}
Esta notación define el contrato del adaptador; los autores deben usar el renderizador registrado del sitio cuando esté disponible. Esta página renderiza su ejemplo real como Markdown semántico y no introduce un nuevo shortcode de Hugo.
Mapeo de bloque de WordPress
<!-- wp:amicited/step-list {"totalTime":"PT15M","variant":"default"} -->
<!-- wp:amicited/step {"title":"Abrir la pantalla de conexión de la propiedad"} -->
<p><strong>Por qué:</strong> Comenzar desde la propiedad correcta evita que los datos se adjunten a la cuenta equivocada.</p>
<p><strong>Acción:</strong> Abre Configuración, elige Fuentes de datos y selecciona el identificador de la propiedad.</p>
<p><strong>Éxito:</strong> La propiedad seleccionada aparece en el resumen de conexión.</p>
<p><strong>Recuperación:</strong> Confirma el acceso y recarga la lista de propiedades.</p>
<!-- /wp:amicited/step -->
<!-- /wp:amicited/step-list -->
La salida de la plataforma puede diferir visualmente, pero cada campo y su significado deben conservarse.
Ejemplos
Bueno: verificar un dominio antes de recopilar datos
- Agregar el registro de verificación. Por qué: El registro demuestra el control del dominio sin exponer las credenciales de la cuenta. Acción: Copia el valor TXT exacto en la configuración DNS del dominio y guárdalo en el host raíz. Éxito: El proveedor muestra el registro en su lista DNS sin comillas adicionales. Recuperación: Si falta, verifica que el campo host use el símbolo raíz requerido por el proveedor y espera la propagación del DNS antes de reintentar.
- Confirmar la propiedad en el producto. Por qué: La confirmación evita que la recopilación comience contra una propiedad no verificada. Acción: Regresa a la pantalla de verificación y selecciona Verificar una vez que el registro sea resoluble públicamente. Éxito: El estado del dominio cambia a Verificado y muestra la hora de verificación. Recuperación: Si la verificación falla, consulta el registro TXT, compáralo carácter por carácter y corrige la entrada DNS antes de otro intento.
- Iniciar la primera recopilación. Por qué: Una propiedad verificada pero inactiva no produce una línea base. Acción: Selecciona Iniciar recopilación y conserva el alcance predeterminado a menos que el proyecto requiera una exclusión documentada. Éxito: Aparece un trabajo en cola con el dominio verificado y la hora actual. Recuperación: Si no aparece ningún trabajo, actualiza una vez; luego captura el dominio, la hora y el mensaje de error para soporte, en lugar de crear duplicados.
Esto funciona porque el orden es real, los títulos son imperativos, los puntos de control son visibles y la guía de fallos es segura.
Malo: mejorar un artículo
- Añadir enlaces internos.
- Reescribir la introducción.
- Revisar la ortografía.
- Añadir ejemplos.
La lista es mala por dos razones. Primero, su orden es arbitrario: la ortografía podría revisarse antes que los enlaces, y los ejemplos podrían añadirse antes que la introducción. Debería ser una lista de verificación. Segundo, cada elemento solo nombra una actividad. Ninguno explica por qué pertenece, hasta dónde llegar, qué cuenta como éxito o qué hacer cuando la verificación falla. Agregar más verbos no solucionaría el desajuste semántico.
Granularidad y anidación
Un paso debe producir un cambio de estado significativo. Varios clics pueden pertenecer a ese paso cuando forman una interacción ininterrumpida y comparten una misma señal de éxito. Por ejemplo, «Elegir CSV, seleccionar UTF-8 y exportar el archivo» es un solo paso si el resultado observable es un CSV descargado. Divídelo cuando un resultado intermedio necesite verificación, un permiso diferente, una espera considerable, una rama de decisión o una ruta de recuperación distinta.
Usa la prueba de la oración: si el título necesita «y» para unir dos resultados, probablemente contiene dos pasos. Usa también la prueba de fallo: si la primera mitad puede tener éxito mientras la segunda falla y cada una requiere una recuperación diferente, divídelos.
El anidamiento se limita a un nivel y tres subpasos cortos. Los subpasos aclaran una acción estrechamente acotada; no crean un procedimiento dentro de un procedimiento. Promueve la secuencia a su propia página cuando tenga requisitos previos separados, más de tres acciones, múltiples capturas de pantalla, más de una rama de fallo, o un resultado que otra página podría usar de forma independiente. Enlaza a ese subprocedimiento, luego mantén el paso padre enfocado en cuándo realizarlo y cómo confirmar su resultado.
Política de capturas de pantalla por paso
Una captura de pantalla se justifica cuando las palabras no pueden identificar el control o el estado de manera confiable. Úsala cuando las etiquetas estén duplicadas, el control esté oculto en un menú, la posición espacial sea importante, la interfaz use un icono desconocido, o el estado de éxito sea visualmente ambiguo. Recorta al área de la tarea, conserva suficiente contexto para la orientación y describe el estado relevante en el texto alternativo y en la prosa cercana.
Omite la captura de pantalla cuando la etiqueta de la interfaz sea única y el estado de éxito pueda indicarse con exactitud. Omite también las capturas de pantalla de acciones rutinarias como seleccionar un botón de Guardar claramente etiquetado, comandos de terminal ya mostrados como texto, o cada pantalla recorrida en el camino hacia una elección significativa. Catorce capturas de pantalla para catorce pasos obvios convierten un procedimiento en una presentación de diapositivas lenta y frágil, y hacen que los cambios de interfaz sean costosos de mantener.
No uses más de una captura de pantalla por paso. Si un paso necesita imágenes de antes, durante y después, probablemente su granularidad sea demasiado amplia. Nunca hagas referencia a un activo hasta que exista, y nunca coloques instrucciones esenciales solo dentro de la imagen.
Marcado de esquema y accesibilidad
El marcado de esquema
es código legible por máquina que describe el significado y las relaciones del contenido visible. Cuando la página realmente enseña un procedimiento completo, la lista de pasos puede alimentar un objeto HowTo de Schema.org expresado como JSON-LD
. El mapeo es directo:
| Campo visible | Propiedad HowTo | Regla |
|---|---|---|
| Título del procedimiento | HowTo.name | Coincidir con el encabezado visible del procedimiento. |
| Duración visible | HowTo.totalTime | Codificar como duración ISO 8601, por ejemplo PT15M; no inventar una duración solo para el marcado. |
| Suministros requeridos | HowTo.supply / HowToSupply | Incluir solo los insumos consumibles mencionados en los requisitos previos. |
| Herramientas requeridas | HowTo.tool / HowToTool | Incluir solo las herramientas mencionadas en los requisitos previos. |
| Pasos ordenados visibles | HowTo.step / HowToStep | Preservar el conteo y el orden exactamente. |
| Título imperativo | HowToStep.name | Coincidir con el título visible del paso. |
| Por qué, acción, éxito, recuperación | HowToStep.text | Preservar todo el significado instructivo visible, no solo la acción de clic. |
| Imagen del paso | HowToStep.image | Incluir solo la imagen visible adjunta a ese paso. |
| Ancla del paso | HowToStep.url | Apuntar al identificador de fragmento estable del paso visible. |
El marcado debe reflejar exactamente el procedimiento visible. Nunca agregues pasos ocultos, combines dos pasos visibles en un solo elemento de esquema, los reordenes ni omitas la guía de recuperación para acortar la versión estructurada. No apliques HowTo simplemente porque una página contenga una lista numerada; la página debe describir un proceso que se pueda completar.
La accesibilidad comienza con un <ol> que contiene un <li> por paso. El número y el orden deben permanecer disponibles para la tecnología de asistencia. No escribas números en los encabezados, porque el texto copiado, los contadores CSS y la salida del lector de pantalla pueden discrepar. Usa niveles de encabezado lógicos, identificadores de fragmento estables, alternativas descriptivas en las capturas de pantalla y etiquetas de texto para éxito y recuperación en lugar de solo color.
Evita los controles interactivos que cambien el orden de los pasos sin anunciar el cambio. Si los pasos se colapsan, el control necesita un nombre accesible y un estado expandido, y el foco del teclado debe permanecer predecible. La salida imprimible y sin JavaScript debe retener el procedimiento completo.
Reglas de redacción
Escribe de 3 a 10 pasos, normalmente de 50 a 140 palabras cada uno. Comienza cada título de 2 a 8 palabras con un verbo imperativo y describe un solo resultado. Explica la razón antes de una acción que los lectores podrían saltarse, reordenar o malinterpretar. Usa un lenguaje tranquilo y directo.
Cada paso debe contener los cinco campos del contrato, aunque el diseño renderizado no necesita repetir etiquetas voluminosas cuando la tipografía las comunique de forma accesible. El estado de éxito debe ser observable: un estado cambia, un archivo existe, un valor cae dentro de un rango indicado, un correo electrónico llega o una prueba pasa. «Todo se ve bien» no es observable. La recuperación debe ser segura, específica y proporcionada; distingue entre reintentar y deshacer, e identifica la escalada cuando el lector no pueda reparar el estado.
No pongas información de fondo no relacionada, llamadas a la acción promocionales, testimonios, un segundo procedimiento independiente o varias ramas de decisión dentro de un paso. Mueve los antecedentes arriba de la lista, la promoción debajo del resultado y las ramas sustanciales a secciones de solución de problemas. No uses «simplemente», «obviamente» o «solo» para una acción que pueda fallar. Nunca prometas una pantalla, etiqueta, hora o resultado que el producto no proporcione realmente.
Tipos de publicación que lo usan
| Tipo de publicación | Uso | Posición |
|---|---|---|
| Guía práctica | Siempre; el procedimiento ordenado es la promesa central de la página. | Después de los requisitos previos y antes del resultado, solución de problemas y siguiente acción. |
| Tutorial | Generalmente; úsalo para cada fase impulsada por dependencias, no para enseñanza conceptual. | Después del concepto necesario para la fase y antes de la verificación de la fase. |
| Página de solución de problemas | A veces; solo cuando los diagnósticos o reparaciones deben ejecutarse en un orden seguro. | Después del síntoma y las comprobaciones de seguridad, antes de la escalada. |
| Página de proceso o lista de verificación | A veces; usa pasos para la parte de ejecución ordenada y casillas de verificación para los puntos de control independientes. | Entre las entradas del proceso y su lista de verificación de revisión final. |
| Contenido de configuración de producto | A veces; úsalo cuando un estado del producto desbloquee el siguiente. | Después de los requisitos de acceso y antes de la confirmación o los siguientes pasos de incorporación. |
El frontmatter postTypes registra estas relaciones para uso en catálogo y validación. Solo las páginas de tipo de publicación registradas en el playbook reciben enlaces; las demás filas describen patrones editoriales compatibles sin inventar rutas.
Lista de verificación de QA
Antes de la publicación, verifica todo lo siguiente:
- Intercambiar pasos adyacentes cambiaría, bloquearía o invalidaría el resultado.
- Los requisitos previos nombran cada estado inicial, permiso, herramienta, suministro y riesgo necesario.
- El procedimiento contiene de 3 a 10 pasos o documenta una excepción justificada.
- Cada paso tiene un título imperativo, razón, acción, estado de éxito observable y ruta de recuperación.
- Cada paso produce un cambio de estado significativo y se mantiene dentro de un nivel de anidación.
- Cualquier subprocedimiento que tenga sus propios requisitos previos o resultado ha sido separado.
- Las capturas de pantalla aparecen solo donde la interfaz o el estado es ambiguo, con no más de una por paso.
- El bloque de resultado indica qué existe ahora y qué puede hacer el lector a continuación.
- La semántica de listas ordenadas, el orden de encabezados, los enlaces a fragmentos y el texto alternativo funcionan sin color ni scripting.
- Las propiedades
HowTo, cuando están presentes, coinciden exactamente con los pasos visibles, el orden, la duración, los suministros, las herramientas, el texto y las imágenes. - Los mapeos de Markdown portátil, Hugo y WordPress preservan los mismos campos y significado.
- Los enlaces y metadatos pasan la lista de verificación de QA previa a la publicación general.
FAQ
¿Cuántos pasos debe contener una lista de pasos? Usa de 3 a 10. Pon una o dos acciones en prosa; agrupa o divide más de diez.
¿Qué hace que una lista numerada sea una verdadera lista de pasos? El orden debe afectar el resultado, y cada paso debe cumplir el contrato de cinco partes.
¿Cada paso necesita una captura de pantalla? No. Agrega una solo cuando las palabras no puedan identificar la interfaz, ubicación o estado de manera confiable.
¿Un paso puede contener subpasos? Sí, a un nivel. Separa cualquier secuencia con sus propios requisitos previos, resultado o más de tres acciones.
¿Cuándo debe convertirse en una lista de verificación? Cuando los elementos se puedan completar en cualquier orden o sean puntos de verificación independientes.
La Lista de Pasos es uno de los elementos de contenido SEO que conlleva tanto comportamiento como presentación. Su calidad se demuestra cuando un lector puede recuperarse de un fallo y aún así alcanzar el resultado prometido, no cuando los números simplemente se ven ordenados.
Más tutoriales en esta sección
¿Listo para ponerlo en práctica?
Revisión gratuita · Prueba de 7 días · sin tarjeta de crédito