Diseña los estados del panel que nadie captura en pantalla

Los datos llegan en menos de un segundo y el contenido sustituye a marcadores exactamente del mismo tamaño.

Seis escenarios, tres idiomas y dos implementaciones independientes de una misma especificación, probadas en Chromium, Firefox y WebKit con cada cambio.

Un panel se juzga menos por cómo se ve con datos perfectos que por cómo se comporta cuando esos datos llegan tarde, faltan, fallan o no se pueden ver.

El problema

Los diseños y las demos de paneles casi siempre muestran el caso ideal: los datos llegan al instante, todos los filtros devuelven resultados y cualquier persona puede verlo todo. En producción, los demás estados son habituales, y es ahí donde se gana o se pierde la confianza.

Con qué se encuentran realmente las personas usuarias

Un indicador de carga que nunca cambia, sin ninguna pista de si algo sigue ocurriendo.
Contenido que salta de sitio a medida que cada widget termina de cargar en un momento distinto.
Un gráfico en blanco para un filtro que simplemente no encontró nada, sin ninguna explicación.
«Algo salió mal» ante un problema de permisos, con un botón Reintentar que nunca podrá servir.
Botones de reintento que envían la misma solicitud dos veces, y respuestas tardías que sobrescriben datos más recientes.
Personas que usan lector de pantalla y no oyen nada cuando cambian los datos, u oyen una cola de avisos desfasados.
El foco del teclado que salta al principio de la página cuando desaparece un botón.

Cómo se suele resolver

La mayoría de los equipos llega a estos estados del mismo modo, un atajo tras otro:

El diseño cubre el estado con datos
Las maquetas muestran datos completos. Los estados de carga, vacío y error se dejan para después o se reducen a un indicador y un mensaje genéricos.
Cada componente improvisa
Cada widget añade su propio indicador y su propio texto de error, así que los tiempos, la redacción y la forma de recuperarse cambian dentro de la misma página.
Las pruebas dependen de ralentizar la red a mano
Alguien limita la red del navegador una vez, echa un vistazo y sigue adelante. El comportamiento nunca se documenta, así que se va desviando.
La accesibilidad se revisa al final
Los avisos y el comportamiento del foco se revisan en una auditoría tardía, cuando cambiarlos sale caro.

Ninguno de estos pasos es un error por sí solo. Juntos hacen que nadie se responsabilice de los estados que más ven las personas en condiciones reales.

Cómo ayuda este laboratorio

El laboratorio trata cada estado como un comportamiento de primera clase y especificado, y hace visibles las partes de ese comportamiento que normalmente no se ven.

Una especificación de comportamiento por escrito
Los tiempos (nada durante 300 ms, esqueletos hasta los 3 s, una explicación a los 3 s y Cancelar a los 8 s), los textos, los avisos y las reglas del foco están documentados, así que se pueden revisar y debatir.
Escenarios reproducibles
Cada combinación de latencia, fallo, rol y filtro es un enlace. Quien diseña, quien desarrolla y quien prueba pueden ver exactamente el mismo estado.
Un inspector para lo que las capturas no muestran
Una línea de tiempo en directo muestra cada solicitud y cada cambio de estado, cada mensaje enviado al lector de pantalla y cada movimiento programático del foco.
Una especificación, dos implementaciones
El mismo comportamiento está construido en React y en TypeScript sin framework, y una misma batería de pruebas verifica ambas, así que la comparación es justa.
Tres idiomas, incluido uno de derecha a izquierda
Todo funciona en inglés, español y árabe, con diseños reflejados, formatos numéricos locales y reglas de plural propias.

En qué se diferencia de las herramientas que quizá ya usas

El laboratorio es una referencia, no un sustituto. Estas herramientas son excelentes en lo suyo; la tabla muestra hasta dónde llega cada una.

Herramientas habituales para construir y probar los estados de un panel, y qué cubre cada una
Herramienta	Sirve para	Lo que no te da
Herramientas para desarrolladores del navegador (limitación de red)	Ralentizar o bloquear solicitudes reales para ver qué ocurre.	Una definición de lo que debería ocurrir, estados repetibles que se puedan compartir o una vista de los avisos y del foco.
Mock Service Worker (MSW)	Simular respuestas, retrasos y errores de la API en el navegador y en las pruebas.	Criterios sobre cómo debe responder la interfaz a esas respuestas.
Storybook	Construir y documentar componentes de forma aislada, con una historia por estado.	Las transiciones entre estados a lo largo del tiempo, como una solicitud lenta que acaba en error y luego en un reintento.
Bibliotecas de componentes (esqueletos, estados vacíos y de resultado)	Piezas listas para cada estado.	Cuándo mostrar cada una, durante cuánto tiempo y qué anunciar.
Bibliotecas de obtención de datos (TanStack Query, SWR)	Estado de las solicitudes, caché, reintentos y cancelación en el código.	El diseño de cada estado tal como lo ve la persona usuaria.
Dashboard UX Lab	Una referencia especificada, inspeccionable y comprobable del comportamiento de cada estado, en tres idiomas.	Componentes para producción o una biblioteca que instalar. Úsalo junto con las herramientas anteriores.

Seis escenarios para explorar

Cada uno abre el laboratorio en ese estado. Todos los escenarios tienen además una guía escrita.

Seis reglas que sigue el laboratorio

Sin esqueleto en respuestas rápidas.
Los marcadores solo aparecen tras 300 ms.
Lento es tiempo, no un estado.
El mensaje cambia a los 3 s; Cancelar aparece a los 8 s.
Vacío es una respuesta, no un error.
Nombra el filtro y ofrece una salida.
Los fallos se explican y se pueden resolver.
Un ID de solicitud, un solo reintento, sin envíos duplicados.
Sin permiso no es lo mismo que fallido.
Sin reintento ante un 403; explica quién puede dar acceso.
Anunciar una vez, mover el foco lo justo.
Solo cuando desaparece el control que tenía el foco.

Para quién es

Desarrolladores front-end
Ver cómo funcionan juntos la gestión de solicitudes, la cancelación, los avisos y la gestión del foco, y leer el código que hay detrás.
Diseño y producto
Usar los escenarios y las guías como lista de comprobación y como vocabulario común para especificar los estados más allá del caso ideal.
Revisión de accesibilidad y pruebas
Reproducir cualquier estado desde un enlace y ver exactamente qué se anunció y adónde fue el foco.

Construido y probado con

Astro
React
TypeScript
HTML
CSS
Node.js
npm
Vitest
Playwright
ESLint
GitHub
GitHub Actions

Rompe un panel a propósito

Ralentízalo, haz que falle, quítale el acceso y observa qué hace una interfaz bien construida al respecto.

Abrir el laboratorio Leer la especificación en GitHub

Tres formas de romperlo

En qué punto está el proyecto

El objetivo: que el comportamiento de un panel sea más fácil de ver, oír y probar que con cualquier herramienta de desarrollo del navegador actual.

Las herramientas de desarrollo muestran las solicitudes y el DOM. No muestran lo que una persona espera, lo que dice un lector de pantalla ni dónde cae el foco del teclado. Este laboratorio se construye en abierto para mostrar exactamente eso, fase a fase.

Hecho
Cimientos
- Una especificación escrita de seis estados de un panel, con sus tiempos
- Dos versiones, en React y en TypeScript sin framework, idénticas píxel a píxel
- Inglés, español y árabe de derecha a izquierda
- Pruebas automáticas en Chromium, Firefox y WebKit
Abrir el laboratorio
Hecho
Comparación lado a lado
- Las dos versiones en una sola vista, con los mismos controles
- Tiempo de arranque y tamaño de descarga, medidos en tu propio navegador
Verlas lado a lado
Hecho
Tecnologías de apoyo reales
- Un guion para lector de pantalla calculado a partir de la especificación y comprobado en las dos versiones en cada cambio
- Tabla de resultados y formulario, abiertos a quien pruebe con NVDA, VoiceOver o TalkBack
- Revisión por hablantes nativos pospuesta: aún no hay quien revise; las sugerencias siguen abiertas
Hacer el guion de prueba
HechoEstás aquí
Ver el tiempo, no solo el estado
- Una línea de tiempo en el laboratorio que puedes recorrer: qué había en pantalla, qué se oyó y dónde estaba el foco en cualquier momento
- Cualquier escenario, o cualquier ajuste personalizado, exportado como prueba de Playwright lista para usar; CI ejecuta cada una de las publicadas
Recorrer una solicitud en el laboratorio
Después
Trae lo tuyo
- Pega la respuesta de tu propia API y mira cómo la maneja cada estado
- Más componentes: formularios, listas y desplazamiento infinito

Ver el estado de accesibilidadLa aportación más útil son los comentarios sobre la especificación: abre una incidencia en GitHub.

Diseña los estados del panel que nadie captura en pantalla

Con qué se encuentran realmente las personas usuarias

El diseño cubre el estado con datos

Cada componente improvisa

Las pruebas dependen de ralentizar la red a mano

La accesibilidad se revisa al final

Una especificación de comportamiento por escrito

Escenarios reproducibles

Un inspector para lo que las capturas no muestran

Una especificación, dos implementaciones

Tres idiomas, incluido uno de derecha a izquierda

Sin esqueleto en respuestas rápidas.

Lento es tiempo, no un estado.

Vacío es una respuesta, no un error.

Los fallos se explican y se pueden resolver.

Sin permiso no es lo mismo que fallido.

Anunciar una vez, mover el foco lo justo.

Desarrolladores front-end

Diseño y producto

Revisión de accesibilidad y pruebas

Construido y probado con

Rompe un panel a propósito

Tres formas de romperlo

Cimientos

Comparación lado a lado

Tecnologías de apoyo reales

Ver el tiempo, no solo el estado

Trae lo tuyo