Diseño de estados vacíos: los 4 que toda pantalla necesita

Al terminar esta guía tendrás cuatro estados vacíos escritos para cada lista, tabla y panel de tu producto: primer uso, sin resultados, lista vaciada y error. Cada uno con un título, una sola acción y un mensaje que el lector de pantalla anuncia cuando el estado cambia. Lleva una tarde por pantalla y es el trabajo de activación más barato que existe.

Un estado vacío es la pantalla que el producto muestra cuando no hay datos. El design system de Atlassian lo define como la vista que aparece cuando no hay datos y le dice al usuario qué puede hacer. La segunda mitad de esa definición es la que se cae: se publica un único «No hay elementos» y se usa para cuatro situaciones que piden cuatro respuestas distintas.

Qué necesitas antes de empezar

• La lista de pantallas cuyo contenido viene de una consulta: listas, tablas, paneles, resultados de búsqueda, paneles laterales, feeds de actividad, bandejas de notificaciones.
• Quien escribe el microcopy. Un estado vacío es casi todo escritura: dejarlo solo en manos de desarrollo produce veinte pantallas con «No hay datos disponibles».
• Una decisión sobre ilustraciones, tomada una vez para todo el producto: dibujarlas, comprarlas o no ponerlas. Tres estilos distintos en diez pantallas se notan más que no tener ninguna.
• Un lector de pantalla. VoiceOver en macOS, NVDA en Windows. El paso 6 no se comprueba leyendo código.

Paso 1: inventaria cada pantalla que puede quedarse sin datos

Recorre el producto y apunta cada pantalla que se alimenta de una consulta. Para cada una, hazte la pregunta que el design system Carbon de IBM pone en el centro de su patrón de estados vacíos: ¿cómo se ven las páginas, los tiles, las tablas y los paneles laterales sin contenido? Un producto B2B mediano tiene entre 15 y 40. La mitad no las ha visto vacías nadie del equipo, porque en desarrollo los datos de prueba las tapan.

Dos maneras rápidas de encontrarlas. Apunta una build local a una base de datos vacía y abre todas las rutas. Después consulta producción buscando cuentas con cero filas en la entidad principal: esas personas están mirando tus estados vacíos ahora mismo, y son las que deciden si vuelven.

Paso 2: separa el estado vacío único en cuatro

Los cuatro estados tienen causas distintas, así que piden textos y acciones distintas.

• Primer uso. La cuenta es nueva y esta tabla nunca ha tenido datos. El trabajo es decir qué aparecerá aquí y cómo ponerlo.
• Sin resultados. Una búsqueda o un filtro no encontraron nada. Los datos existen, la consulta los ha fallado. El trabajo es devolver al usuario a los resultados.
• Lista vaciada. El usuario archivó, completó o borró todo. Eso es un éxito, y el texto debe decirlo antes de proponer nada más.
• Error. La petición falló. El trabajo es decir qué falló y ofrecer reintentar.

El error es el caso que más se mete dentro de los otros tres, y el que hace daño de verdad. Una petición fallida mostrada como «Todavía no tienes proyectos» le dice a un cliente que paga que su trabajo ha desaparecido. Separa los caminos dentro del propio componente: una prop variant con cuatro valores cuesta una hora y hace imposible el fallo.

Paso 3: escribe el título en positivo

La indicación de Carbon sobre los títulos es corta y conviene copiarla: escribe el título como una afirmación positiva siempre que puedas. «Empieza añadiendo un activo» se lee mejor que «No tienes ningún activo». Cuando el negativo es inevitable, la palabra «todavía» arregla buena parte del tono.

Tres reglas que valen para cada estado vacío que publicamos:

• El título dice la situación o el paso siguiente en menos de ocho palabras.
• El cuerpo explica qué gana el usuario dando ese paso, no cómo funciona el botón de abajo.
• Nada de disculpas. «Lo sentimos, aquí no hay nada» gasta la atención de quien lee en tus sentimientos sobre una tabla vacía.

Paso 4: una sola acción, puesta donde vive la acción

Una acción principal por estado vacío. Un enlace secundario a la documentación está bien. Un segundo botón es una elección que el usuario no puede tomar, porque nunca ha usado esa función.

Carbon enumera tres formas de presentar esa acción: un botón debajo del texto, un enlace dentro del texto, o una instrucción que señala el control real de la interfaz. La tercera está infravalorada. Señalar el botón «Nuevo proyecto» de la barra enseña dónde vive el control, así que la segunda vez el estado vacío ya no hace falta. Úsala cuando el control está en la misma pantalla, y usa un botón cuando no lo está.

Paso 5: trata «sin resultados» como un problema de recuperación

Es el estado que tiene investigación pública detrás. El benchmark de búsqueda en ecommerce de Baymard Institute encontró que casi la mitad de los sitios no ofrece una salida útil después de una búsqueda vacía: la pantalla se convierte en un callejón sin salida y el abandono sube.

Recuperar es trabajo concreto, no una frase más amable:

• Muestra la consulta que se ejecutó, para que quien lee vea la errata.
• Deja el campo de búsqueda relleno y con el foco, para que corregir cueste una tecla.
• Ofrece lo más cercano que tengas: la misma búsqueda sin un filtro, o la lista completa, con el número de resultados.
• Nombra el ámbito. «Ninguna factura coincide con "acme" en 2024» dice cuál de las tres cosas cambiar.

Las pautas de Nielsen Norman Group sobre las páginas «sin resultados» apuntan en la misma dirección. Los consejos de búsqueda genéricos son lo más flojo que puedes poner aquí: cuando alguien lee «revisa la ortografía», ya la ha revisado.

Paso 6: haz que el lector de pantalla lo anuncie

Un estado vacío que aparece al cambiar un filtro es un mensaje de estado según el criterio WCAG 4.1.3, nivel AA. El contenido cambió sin recargar la página y sin mover el foco, así que hay que avisar con palabras a la tecnología de apoyo.

Qué significa en el marcado:

• La live region tiene que estar en el DOM antes de que cambie el contenido. Montar el contenedor y el mensaje en el mismo render muchas veces no anuncia nada.
• Usa role="status" para el recuento de resultados. Lleva un aria-live="polite" implícito, así el anuncio espera una pausa en lugar de cortar a quien escucha.
• Anuncia el hecho, no la decoración. El mensaje es «Ninguna factura coincide con este filtro».
• Las ilustraciones de los estados vacíos son decorativas, así que llevan un atributo alt vacío, como indica la guía del W3C sobre imágenes decorativas. Carbon recomienda el alt vacío antes que role="presentation", por soporte.

Paso 7: deja la carga fuera del estado vacío

Una pantalla que todavía está cargando no está vacía. Mostrar «Todavía no tienes proyectos» durante 400 milisegundos mientras la petición está en curso le enseña a quien entra por primera vez que el producto no funciona, y pasa en cualquier conexión más lenta que la de tu oficina. Muestra un skeleton mientras la petición está en curso y pasa al estado vacío cuando la respuesta confirme cero filas. Polaris de Shopify separa las dos cosas igual: componentes skeleton para la carga, componente de estado vacío para la respuesta.

Cómo comprobar que funciona

Cinco comprobaciones por pantalla, unos veinte minutos cada una.

1. Crea una cuenta nueva sin datos y abre todas las rutas. Haz captura de cada pantalla vacía que encuentres.
2. Busca una cadena que no pueda coincidir con nada y vuelve a los resultados en un clic. Si no puedes, el paso 5 no está terminado.
3. Borra todo en una pantalla y lee el resultado en voz alta. Tiene que sonar a tarea terminada, no a avería.
4. Bloquea la petición desde devtools. La pantalla debe decir que la petición falló y ofrecer reintentar, nunca «todavía no tienes nada».
5. Activa VoiceOver o NVDA y aplica un filtro que no devuelva nada. Si no suena nada, el paso 6 no está terminado.

Fallos habituales y cómo se arreglan

• El error disfrazado de primer uso. Un solo catch, un componente genérico, y un 500 se convierte en «Crea tu primera factura». Se arregla antes: distinguir un resultado vacío de una petición fallida antes de que el componente se renderice.
• Una acción que el usuario no puede hacer. Una cuenta con rol de solo lectura lee «Crea tu primer proyecto» y no tiene permiso para crear. Comprueba el permiso antes de pintar el botón y cambia el texto por lo que esa persona sí puede hacer, que suele ser pedírselo a un administrador.
• La ilustración cargando con el mensaje. Si al quitar el dibujo desaparece el significado, el texto no está terminado. Escribe el estado para que funcione en texto plano y añade la imagen después.
• El panel vacío. Un panel con ocho gráficos a cero es la peor primera pantalla del software. La alternativa que propone Carbon es el starter content: datos de ejemplo que el usuario explora y luego borra. Cuesta trabajo de producto real, así que resérvalo para la pantalla principal y deja estados vacíos simples en las secundarias.
• Textos escritos una vez y abandonados. Los estados vacíos nombran funciones, y las funciones cambian de nombre. Métetelos en la misma revisión que los textos de onboarding, no en un backlog aparte que no abre nadie.

Con qué conecta

Los estados vacíos son la mitad barata del trabajo de activación. La mitad cara es el flujo que los rodea, que tratamos en UX de onboarding: patrones que reducen el abandono inicial. Si la pantalla que estás arreglando es un panel, las decisiones de densidad van primero: mira diseño de dashboards SaaS. Y el paso 6 es una línea de una lista mucho más larga, que recorremos en diseño accesible tras la EU Accessibility Act.