El crecimiento cambia el problema
Una colección pequeña puede sobrevivir casi a cualquier navegación. Con veinte páginas, el lector puede recorrer el menú, los autores recuerdan dónde está cada cosa y los duplicados siguen siendo visibles. Con quinientas páginas, esas ventajas desaparecen. La estructura pasa a ser una función del producto.
La primera regla es no confundir el árbol del repositorio con la arquitectura de información. El repositorio sirve a quienes mantienen las fuentes; la navegación sirve a quienes leen.
Empieza por las intenciones y los tipos de contenido
Enumera por qué alguien abre la documentación: aprender un concepto, completar una tarea, consultar un campo, resolver un fallo o entender un cambio de versión. Después define un conjunto pequeño de tipos de contenido para esas intenciones.
Un modelo de contenido aporta metadatos y estructuras predecibles. A medida que crece el archivo, esa consistencia permite filtros, facetas de búsqueda, validaciones automáticas y plantillas reutilizables.
Mantén estable el nivel superior
La navegación global debe cambiar lentamente. No añadas una sección principal por cada tecnología, equipo o tendencia. Coloca lo volátil más abajo y expónlo mediante etiquetas, colecciones y búsqueda.
Si una categoría podría desaparecer en la próxima reorganización, probablemente no pertenece al menú permanente.
Diseña enlaces, no solo árboles
Los lectores llegan desde buscadores, incidencias, código, soporte y marcadores antiguos. Cada página necesita contexto suficiente y enlaces al siguiente paso probable. Conecta conceptos con tareas, tareas con referencia y errores con recuperación.
Audita antes de que duela
Busca páginas huérfanas, títulos duplicados, enlaces rotos, secciones enormes y etiquetas equivalentes. Revisa las búsquedas que producen malos resultados.
La arquitectura de información no es un diagrama de una sola vez. Es mantenimiento continuo para que las siguientes quinientas páginas no hagan más difíciles las primeras quinientas.
Ejemplo aplicado
Para convertir «Arquitectura de información para una documentación que no deja de crecer» en una práctica real, elige una pieza de documentación que vaya a cambiar esta semana: un procedimiento, una página de versión, un paso de onboarding o un artículo de troubleshooting. Antes de editarla, anota quién la usa, qué evento obliga a actualizarla, quién puede verificar los hechos y qué debe poder hacer el lector al terminar.
Haz pasar un único cambio real por todo el flujo. No rediseñes el sistema completo. Cambia un dato, un paso o una responsabilidad y observa dónde se pierde información. Comprueba:
- si el resultado esperado se entiende sin preguntar al autor;
- si existe un responsable para la próxima actualización;
- si un revisor puede verificar el dato modificado;
- si la página sigue siendo comprensible al quitar material obsoleto.
Una práctica de documentación merece confianza cuando sobrevive al cambio real, no solo cuando se ve ordenada en un ejemplo estático.
Lista rápida de revisión editorial
- El crecimiento cambia el problema. Una colección pequeña puede sobrevivir casi a cualquier navegación.
- Empieza por las intenciones y los tipos de contenido. Enumera por qué alguien abre la documentación: aprender un concepto, completar una tarea, consultar un campo, resolver un fallo o entender un cambio de versión.
- Mantén estable el nivel superior. La navegación global debe cambiar lentamente.
- Diseña enlaces, no solo árboles. Los lectores llegan desde buscadores, incidencias, código, soporte y marcadores antiguos.
