De la investigación a la entrega:
construyendo una librería de componentes escalable

El negocio tenía un problema de contenido disfrazado de problema de diseño. Cada campaña necesitaba un layout a medida. Publicar cualquier cosa tardaba una semana. Me contrataron para diseñar la plataforma de asesores — pero arreglar la plataforma sin arreglar la infraestructura de publicación habría colapsado en seis meses. Resolví ambos.

Audité desde los dos extremos a la vez — cómo usaban la plataforma los asesores y cómo la mantenían los editores. La hipótesis era que ambos grupos trabajaban alrededor de los mismos problemas estructurales. Era correcta: la navegación que confundía a los asesores era la misma arquitectura que obligaba a los editores a construir plantillas únicas cada vez que algo no encajaba.

Ocho grupos de stakeholders en producto, ingeniería, contenido, legal y equipos regionales — cada uno con una definición diferente de éxito. El diseño tenía que satisfacer a todos sin convertirse en un compromiso.

Los dos usuarios a los que el diseño tenía que servir simultáneamente

• La publicación se ralentizaba por decisiones repetidas. Los editores tenían que repensar la jerarquía y el layout cada vez, en lugar de componer con bloques conocidos.
• La consistencia se rompía en los límites de las plantillas. Contenido similar se veía y se comportaba de forma diferente según dónde estuviera.
• Las reglas poco claras reducían la confianza. Sin restricciones de componentes, los equipos recurrían a soluciones alternativas.
• «¿Qué puedo construir?» no era obvio. El sistema necesitaba opciones visibles y ejemplos para guiar la creación.

Construí cada componente alrededor de un fallo de contenido que había observado en la auditoría — no alrededor de un tipo de página teórico. Si nunca había visto a un editor trabajar a su alrededor, no obtenía componente. Esa restricción evitó que el sistema se convirtiera en un framework teórico y lo convirtió en algo que el equipo podía usar desde el primer día.

Principios de diseño

• Composable por defecto: páginas construidas con bloques, no layouts a medida.
• Flexible con guardarraíles: los editores personalizan el contenido, no la estructura.
• Estados definidos: estados vacíos, de error y de carga considerados desde el inicio.
• Reconocimiento sobre memoria: variantes con nombre hacen las opciones visibles sin memorizar reglas.

01 — Navegación y estructura

Un sistema que los usuarios no tienen que aprender dos veces

La navegación global, los encabezados de sección y las migas de pan siguen la misma lógica estructural en cada página. Los asesores nunca tienen que reorientarse al cambiar de sección.

Regla editorial: Las etiquetas de navegación están bloqueadas — los editores pueden añadir secciones pero no renombrar los elementos primarios sin revisión de diseño.

02 — Módulo hero de página

Un componente, tres configuraciones válidas

El módulo hero cubre los tres casos reales: páginas editoriales con imagen, páginas de insight con texto y páginas utilitarias con decoración mínima. Cada variante tiene reglas definidas para que los editores no puedan romper el layout.

Decisión de diseño: Las primeras versiones tenían cinco variantes. Los tests mostraron que los editores no distinguían cuándo usar cada una. Consolidar a tres eliminó el error editorial más común.

03 — Mega tabs

Contenido denso dividido en partes navegables

Los asesores necesitan cruzar datos de fondos sin perder el contexto. Las mega tabs dan a cada tipo de contenido su propia superficie manteniendo la orientación en la página.

Restricción navegada: El cliente quería todo en una sola página larga. Los tests mostraron que los asesores perdían la orientación. La estructura de pestañas obtuvo resultados significativamente mejores.

04 — Bloques CTA

Conversión sin ruido visual

Los bloques CTA cubren los cuatro casos reales con layouts restringidos. Los editores no pueden producir CTAs desalineados o con texto partido.

Guardarraíl editorial: Las etiquetas CTA están limitadas a 40 caracteres con validador de campo. Esto eliminó los CTAs rotos que aparecían en el 30% de las páginas del sistema anterior.

05 — Lista de documentos

Recursos que los asesores encuentran y en los que confían

La lista de documentos gestiona descargas únicas, listas curadas y recursos mixtos — todo con la misma estructura visual y campos de metadatos obligatorios.

Hallazgo de investigación: Los asesores citaron fechas de publicación faltantes como razones para no confiar en las descargas. Ambos son ahora campos obligatorios en el CMS.

06 — Bloque de noticias

Contenido de insight que se escanea, no solo se lee

La jerarquía de tarjeta (categoría → titular → fecha → resumen) fue testada con asesores para confirmar el orden de escaneo correcto antes de fijar el componente.

Principio de consistencia: El bloque de noticias y la lista de documentos comparten la misma jerarquía de tarjeta intencionalmente. Los asesores solo aprenden el patrón una vez.

El producto funcionó. Pero el resultado que cambió la forma de trabajar del equipo fue la independencia de publicación — llegar a un punto en el que los equipos de contenido ya no abrían un ticket por cada página nueva. Eso ocurrió a las pocas semanas del lanzamiento.

• Diseña para flujos de trabajo reales, no para vistas de página. Los asesores piensan en tareas y conversaciones, no en URLs — las experiencias deben reflejar cómo trabajan realmente.
• Convierte los eventos en activos digitales. Trata cada evento en vivo como una fuente de artículos, herramientas y artefactos que extiendan su valor mucho después de que haya terminado.
• Historia de marca y UX son inseparables. Sin una narrativa clara sobre quién eres, la arquitectura de información y el contenido siempre se sentirán fragmentados.
• La investigación es una herramienta de alineación poderosa. Reunir a los stakeholders en torno a una visión compartida de los usuarios y sus recorridos puede desbloquear más impulso del que imaginas.