Flow — Especificaciones para Web Apps de Diagnósticos

01 — Principios

Experiencia de Diagnóstico

Las web apps de Flow guían al usuario a través de un proceso de reflexión estructurado. Cada decisión de diseño debe reducir fricción y generar confianza.

Principio	Aplicación
Progreso visible	El usuario siempre sabe en qué paso está y cuánto falta. Barra de progreso + indicador de steps.
Una acción por pantalla	Cada step del diagnóstico presenta una sola pregunta o grupo de preguntas relacionadas.
Feedback inmediato	Validación en tiempo real, microanimaciones en transiciones, estados de loading claros.
Resultados accionables	El dashboard de resultados no solo muestra data — ofrece interpretación y siguientes pasos.
Accesibilidad primero	Contraste AAA en textos, focus visible, navegación por teclado, labels semánticos.

Contexto: Las web apps de Flow se usan principalmente para diagnósticos de Employee XP, Leader XP y Service XP. El usuario promedio las completa en 8-15 minutos.

02 — Arquitectura

Layouts de Aplicación

Tres layouts base cubren todos los contextos de las web apps de diagnósticos.

Layout 1 — Wizard (Flujo de preguntas)

Barra de progreso

¿Pregunta del diagnóstico? Opciones de respuesta

← Anterior | Siguiente →

Zona	Especificación
Contenedor	`max-width: 640px` centrado. Foco total en la pregunta.
Progreso	Barra horizontal + "Paso X de Y" + porcentaje.
Navegación	Botones "Anterior" y "Siguiente" fijos al bottom en mobile.
Pregunta	Tipografía `font-size: 24px`, `font-weight: 600`.

Layout 2 — Dashboard (Resultados)

Zona	Especificación
Sidebar	`width: 240px`, background `var(--almostwhite)`, colapsa en mobile.
Contenido	Grid de `2 columnas` para metric cards, `1 columna` para gráficos full.
Metric cards	Score + delta + label. Altura consistente `min-height: 120px`.
Header	Nombre del diagnóstico + fecha + botón "Descargar PDF".

Layout 3 — Landing de entrada

Employee XP Diagnostic Descripción del diagnóstico · ~12 min

[ Comenzar diagnóstico → ]

Regla: La landing debe comunicar: qué es el diagnóstico, cuánto tarda, y qué obtendrá el usuario al completarlo. Un solo CTA prominente.

03 — Tipografía

Escala Tipográfica para Apps

Escala más compacta que las presentaciones. Optimizada para lectura en pantalla y escaneo rápido de información.

Rol	Tamaño	Peso	Uso
Display	`32px`	700	Score principal del diagnóstico
Heading 1	`24px`	700	Títulos de sección en dashboard
Heading 2	`20px`	600	Subtítulos, nombres de dimensión
Heading 3	`16px`	600	Labels de metric cards
Body	`15px`	400	Texto de preguntas, descripciones
Body Small	`13px`	400	Hints, captions, metadata
Caption	`11px`	600	Labels de ejes, tooltips, badges
Metric	`48px`	800	Números grandes en dashboard

✓ Correcto

Usar Lato 400 para texto de preguntas. Comfortable, legible, no fatiga en formularios largos.

✗ Incorrecto

Usar pesos light (300) para texto funcional. Reservar 300 solo para displays decorativos grandes (+32px).

04 — Color

Paleta de Aplicación

El contexto de web app requiere una paleta funcional que comunique estados, prioridades y feedback.

Colores base

Background

#f7f5f3 cream

Surface

#ffffff cards

Text Primary

#0f2c24 charcoal

Text Secondary

#768782 secondary

Colores de estado

Success / Primary

#3beb64 green-500

Warning

#f0a730 warning

Error / Danger

#e84545 error

Info

#3b82f6 blue

Info blue: El azul #3b82f6 es exclusivo de web apps para estados informativos y links. No se usa en presentaciones ni en la marca principal.

Semáforo de scores

Sistema para comunicar rangos de performance en los resultados del diagnóstico.

Rango	Color	Significado
80–100	● `#2fd954` green-600	Alto rendimiento — fortaleza
60–79	● `#3beb64` green-500	Buen nivel — mantener
40–59	● `#f0a730` warning	Atención — oportunidad de mejora
0–39	● `#e84545` error	Crítico — requiere intervención

05 — Componentes

UI Components

Componentes base reutilizables en todas las web apps de diagnósticos.

Botones

Tipo	Uso	Specs
Primary	CTA principal: avanzar, confirmar, enviar	`bg: green-500`, `color: charcoal`, `radius: 8px`
Secondary	Acción secundaria: retroceder, cancelar	`border: 1.5px border`, `bg: transparent`
Ghost	Acciones terciarias: saltar, ver más	`color: green-600`, sin border ni fondo
Destructive	Solo para acciones irreversibles	`bg: error`, `color: white`
Disabled	Cuando la acción no está disponible	`bg: offwhite`, `color: tertiary`

Metric Cards

Score General

↑ +5 vs anterior

Liderazgo

↓ -3 vs anterior

Participación

92%

↑ +12%

Regla de color en metrics: El color del valor numérico sigue el semáforo de scores. Solo el score general y los scores por dimensión se colorean — los porcentajes de participación siempre van en charcoal.

Steps / Progress

✓

Datos

✓

Cultura

Liderazgo

Bienestar

Resultados

Paso 3 de 5 50% completado

Estado	Estilo
Completado	Círculo charcoal + checkmark green-400. Conector charcoal.
Activo	Círculo green-500 con número. Label bold. Conector gris.
Pendiente	Círculo outline gris con número. Label secondary. Conector gris.

06 — Formularios

Patrones de Formulario

Los diagnósticos de Flow usan principalmente escalas Likert, selección múltiple y campos de texto abierto.

Campos base

Nombre completo

Área / Departamento

Selecciona el área a la que perteneces

Email corporativo

Ingresa un email válido

Elemento	Specs
Input	`padding: 10px 14px`, `border: 1px border`, `radius: 8px`, `font-size: 14px`
Label	`font-size: 13px`, `font-weight: 600`, `margin-bottom: 4px`
Hint	`font-size: 12px`, `color: secondary`
Focus ring	`border: green-500`, `box-shadow: 0 0 0 3px rgba(59,235,100,0.15)`
Error	`border: error`, mensaje en `font-size: 12px`, `color: error`

Escala Likert (5 puntos)

Mi líder directo me da retroalimentación clara y oportuna.

Totalmente en desacuerdo

En desacuerdo

Neutral

De acuerdo

Totalmente de acuerdo

Estado	Estilo
Default	`border: 1.5px border`, `color: secondary`
Hover	`border-color: green-400`, `background: rgba(green,0.04)`
Selected	`border: 1.5px green-500`, `bg: rgba(green,0.08)`, `font-weight: 600`

✓ Correcto

Una pregunta por pantalla en mobile. Máximo 3-4 preguntas agrupadas temáticamente en desktop si son Likert del mismo bloque.

✗ Incorrecto

Mostrar 10+ preguntas en scroll infinito. Genera fatiga y abandono. El diagnóstico debe sentirse progresivo, no abrumador.

07 — Resultados

Dashboard de Resultados

El dashboard convierte data en insights. Cada elemento debe responder: "¿Qué significa esto para mí y qué debo hacer?"

Anatomía del Dashboard

1Score general

Número grande con semáforo de color. Acompañado de delta vs medición anterior y una frase interpretativa.

2Dimensiones

Cards individuales por dimensión (Cultura, Liderazgo, Bienestar, etc). Score + barra + ranking relativo.

3Gráfico radar

Visualización comparativa de todas las dimensiones en un solo gráfico. Overlay con benchmark si existe.

4Insights

3-5 bullets accionables generados del análisis. Cada insight incluye: hallazgo + recomendación + prioridad.

5Fortalezas & Oportunidades

Top 3 fortalezas y top 3 áreas de mejora. Cards diferenciadas con iconografía de green-500 y warning.

6Exportar

Botón de descarga PDF + opción de compartir link de resultados. El PDF debe replicar el dashboard.

Jerarquía de información

Nivel	Contenido	Ubicación
1 — Inmediato	Score general + interpretación en 1 frase	Above the fold, hero del dashboard
2 — Resumen	Dimensiones + radar + fortalezas/oportunidades	Primera sección scrolleable
3 — Detalle	Desglose por pregunta + comparativos + tendencias	Secciones colapsables o tabs
4 — Acción	Recomendaciones + siguiente diagnóstico + contacto	Footer del dashboard

Importante: Los resultados del diagnóstico son sensibles. Nunca mostrar data individual cuando hay menos de 5 respondentes en un grupo. Aplicar reglas de anonimato en el backend y comunicarlo en la UI.

08 — Responsive

Breakpoints & Adaptación

Las web apps deben funcionar primero en mobile — el 65% de los participantes completan el diagnóstico desde su celular.

Breakpoint	Valor	Adaptación
Mobile	`< 640px`	1 columna, nav bottom, botones full-width, 1 pregunta por pantalla
Tablet	`640–1024px`	2 columnas métricas, sidebar colapsada, agrupación de 2-3 preguntas
Desktop	`> 1024px`	Sidebar visible, grid 2-3 col, hasta 4 preguntas por bloque Likert

Reglas mobile-first

✓ Correcto

Botones "Anterior/Siguiente" fijos al bottom de la pantalla en mobile. Touch targets mínimo 44×44px. Likert cards apiladas verticalmente.

✗ Incorrecto

Likert horizontal en mobile (imposible de leer). Sidebar siempre visible. Tablas sin scroll horizontal. Modales que cubren el 100% de pantalla sin forma de cerrar.

            CSS
/* Breakpoints Flow Web Apps */
@media (max-width: 640px) {
  .wizard-container { padding: 16px; }
  .wizard-nav     { position: fixed; bottom: 0; }
  .likert-option  { width: 100%; }
  .metric-grid    { grid-template-columns: 1fr; }
  .sidebar        { display: none; }
}

@media (min-width: 641px) and (max-width: 1024px) {
  .metric-grid    { grid-template-columns: 1fr 1fr; }
  .sidebar        { position: absolute; z-index: 50; }
}

@media (min-width: 1025px) {
  .metric-grid    { grid-template-columns: 1fr 1fr 1fr; }
  .sidebar        { display: block; width: 240px; }
}
        

09 — Reglas

Reglas Estrictas

Checklist obligatoria antes de lanzar cualquier versión de las web apps de diagnósticos.

✓ Siempre

Progress bar visible en todo momento durante el wizard. El usuario nunca debe sentirse "perdido" en el flujo.

✗ Nunca

Permitir enviar un diagnóstico incompleto sin advertencia. Si quedan preguntas sin responder, mostrar resumen antes de confirmar.

✓ Siempre

Guardar progreso automáticamente. Si el usuario cierra el browser, debe poder retomar exactamente donde se quedó.

✗ Nunca

Mostrar data individual cuando un grupo tiene menos de 5 respondentes. Aplicar anonimato y comunicar la razón en la UI.

Checklist de lanzamiento

#	Check	Criterio
1	Accesibilidad	Contraste AA mínimo, focus visible, navegación keyboard, labels ARIA
2	Mobile-first	Probado en iOS Safari + Chrome Android. Touch targets ≥ 44px
3	Performance	LCP < 2.5s, FID < 100ms, CLS < 0.1. Lighthouse score > 90
4	Auto-save	Progreso se guarda cada 30s y al cambiar de step
5	Anonimato	Regla de n < 5 implementada en backend y comunicada en UI
6	Loading states	Skeleton screens en dashboard, spinner en transiciones, optimistic UI
7	Error handling	Errores de red con retry, validación inline, feedback de estado
8	Brand	Solo fuentes Lato, colores del token system, iconos Lucide
9	Export	Descarga PDF funcional, link compartible, preview antes de enviar
10	Analytics	Eventos de abandono, tiempo por pregunta, tasa de completación