La primera vez que alguien entra en tu panel no ve el producto. Ve un recuadro en blanco, un icono de caja y un «Aún no hay nada». Ese segundo decide si entiende para qué sirve lo que ha abierto o si cierra la pestaña. Los empty states UX no son un leftover de diseño: son la primera conversación del producto.
Cero pedidos, cero resultados, cero datos. El vacío no es un bug. Es un estado tan frecuente como el listado lleno, y casi nunca se diseña con el mismo cuidado. El equipo pinta la tabla con filas de ejemplo, el desarrollador deja el fallback del framework y el copy llega el viernes antes del launch.
Este artículo fija un criterio de diseño UX/UI para esas pantallas: qué decir, qué acción ofrecer y cómo no convertir el cero en un callejón. Lo que hacemos en Truman cuando el producto aún no tiene historia.
Empty states UX: el vacío no es un estado menor
En Figma casi nunca se abre el archivo por el empty state. Se abre por la home llena, el dashboard con gráficos y la tabla con doce filas. Eso es el producto soñado. El producto real, el de la primera semana, es otra pantalla: la misma estructura, sin filas, sin gráfico, sin prueba de que el sistema funciona.
El vacío enseña el modelo mental. Si el empty state de «Mis eventos» dice «No hay eventos» y un botón «Crear evento», estás enseñando que el valor empieza cuando el usuario produce. Si dice «Cuando alguien compre, verás aquí las entradas», estás enseñando que el valor llega de fuera. Las dos frases son correctas para productos distintos. La misma frase en el producto equivocado deja al usuario esperando algo que no va a pasar.
En un producto con onboarding, el empty state es la continuación de esa primera sesión. Si el onboarding promete un resultado y el panel siguiente está mudo, has roto la cadena. El diseño de onboarding que reduce el churn no termina en el último tooltip: termina cuando el usuario ha hecho la primera acción que da sentido al producto.
Tres vacíos que no se diseñan igual
Hablar de «el empty state» como si fuera uno solo es el primer error. Hay al menos tres situaciones, y mezclarlas produce copy que miente.
| Tipo de vacío | Qué le pasa al usuario | Qué tiene que hacer la UI |
|---|---|---|
| Primera visita / cero datos | Aún no ha creado ni recibido nada | Explicar + una acción |
| Cero resultados de búsqueda o filtro | Hay datos, pero no en esta consulta | Reset + sugerir |
| Error o dato que no cargó | El sistema falló o el permiso no alcanza | Decirlo y reintentar |
| Lista vacía crónica (producto muerto) | Lleva semanas sin actividad | Reactivar, no felicitar |
| Vacío por rol o permiso | Esa vista no le corresponde | Explicar el porqué |
El cero resultados no es un empty state de bienvenida. Si alguien filtró por «octubre» y no hay pedidos, no le digas «Crea tu primer pedido». Dile que ese filtro no tiene datos y ofrécele quitarlo. El error de red no es un empty state de onboarding: es un fallo. Si los tratas con la misma ilustración de globo, el usuario deja de fiarse del sistema.
El vacío por permiso es el que más se improvisa. Un comercial entra en «Facturación», ve «No hay facturas» y cree que el mes está vacío. La frase correcta es «No tienes acceso a facturas. Pídeselo a administración». El vacío, aquí, es información de roles. No de datos.
Copy, acción e ilustración: el orden que sí funciona
Un empty state bien resuelto tiene tres piezas, y el orden importa. Primero el titular (qué está pasando). Después una frase de contexto (por qué está vacío o qué valor aparece cuando deje de estarlo). Después una acción primaria. La ilustración es opcional. Si el copy no se sostiene sin ella, el copy está mal.
El tono del empty state es tono de marca. Si el producto habla en segunda persona clara en el resto de la interfaz y aquí se pone gracioso («¡Vaya, esto está más vacío que el desierto!»), has roto el registro. La gracia no activa. La claridad sí. Las microinteracciones pueden acompañar el primer éxito —un check, un toast, un cambio de estado— pero no sustituyen a la frase que explica el vacío.
Primera visita frente a vacío de uso
El empty state de día uno y el de día treinta no pueden ser el mismo componente con las mismas strings. El primero enseña. El segundo reactiva o diagnostica.
Día uno: el usuario no tiene historia. Necesita una acción que produzca el primer objeto del dominio —un evento, una lista de invitados, un pedido de prueba. Si esa acción pide diez campos, el empty state es un embudo, no una ayuda. Recorta el primer objeto al mínimo que ya se pueda guardar. El resto se edita después.
Día treinta: si la lista vuelve a estar vacía, o el producto no se usa o el objeto se archivó. «Crea tu primer evento» suena a insulto. Mejor: «No hay eventos activos este mes» y un enlace a archivados, o a duplicar el último. El copy tiene que reconocer que ya hubo actividad.
¿Tu empty state habla como si el usuario nunca hubiera usado el producto, aunque lleve tres meses dentro?
En Klapper el vacío no es decorativo: es un organizador que entra el primer día y no tiene eventos, o un comprador que aún no tiene entradas. No son la misma pantalla. El primero necesita crear o importar. El segundo necesita entender dónde aparecerán las entradas cuando compre. Si unificas los dos mensajes, uno de los dos oficios se siente perdido.
En Weddle el producto vive de que la pareja y los invitados empiecen a aportar. Un muro vacío el día del alta no se resuelve con «No hay publicaciones». Se resuelve con una acción que produce la primera pieza —una foto, un recado, un dato de la boda— y con la certeza de que eso es lo que los demás van a ver. El empty state es onboarding, no un estado de lista.
Cero resultados, cero pedidos, cero datos: el detalle que se olvida
El vacío de búsqueda es el que más daño hace en ecommerce y en paneles con filtros. El usuario ha invertido un filtro. Si la respuesta es un recuadro idéntico al de «aún no tienes pedidos», concluye que el catálogo no tiene lo que busca —o que el buscador no funciona.
Las leyes de UX que aplicas en el resto de la web valen aquí: feedback inmediato, una sola acción primaria, no hacer pensar. El empty state que obliga a reconstruir el filtro de memoria viola las tres.
En listados de datos (informes, analítica, exports), el vacío tiene otra trampa: el rango de fechas. «No hay datos» en los últimos 7 días no significa que el producto no mida. Ofrece cambiar el rango o confirma que la fuente aún no está conectada. Un gráfico en blanco sin eje ni nota parece un bug de implementación.
Cómo lo tratamos en Truman (y qué pedimos en el diseño)
En un proyecto a medida, el empty state entra en el sistema de componentes como cualquier otra vista: variantes por tipo de vacío, copy en el mismo sitio que el resto de strings, y una acción que apunta a una ruta real. No se deja al desarrollador inventar el fallback del v-if.
Pedimos que el prototipo incluya esas variantes. Un Figma que solo muestra la tabla llena es un prototipo a medias. El día del handoff a desarrollo, el vacío ya tiene componente, textos y destino del CTA. Si no, en producción aparece el empty state del kit: icono, «No data», y un hueco que nadie reclamó.
El producto se juzga lleno. Se abandona vacío. Si no hemos diseñado qué pasa cuando no hay filas, no hemos diseñado el producto: hemos diseñado el brochure del producto.
Antes de dar por cerrado un listado, verifica esto
- ¿Tienes variantes distintas para primera visita, cero resultados y error?
- ¿El titular nombra el objeto real (pedidos, eventos, invitados) y no «elementos»?
- ¿Hay una sola acción primaria que abre un flujo que ya existe?
- ¿El vacío de filtro permite quitar los filtros de un clic?
- ¿El copy de día treinta no habla como si el usuario fuera nuevo?
- ¿Un vacío por permiso explica el porqué y a quién pedir acceso?
- ¿Habéis probado el producto con una cuenta sin datos de ejemplo?
- ¿La ilustración se puede quitar sin que el mensaje deje de entenderse?
Preguntas frecuentes sobre empty states y UX
¿Qué es un empty state en UX?
Es la interfaz que ves cuando no hay nada que listar: cero registros, cero resultados o un error que deja la vista vacía. No es un hueco. Es una pantalla con mensaje, contexto y, casi siempre, una acción. Si solo hay un icono y «No hay datos», no está diseñado: está abandonado.
¿El empty state tiene que llevar siempre un botón?
Casi siempre, sí. La excepción es el vacío por permiso o el vacío informativo («Esta vista se llena cuando cierre el mes»). Aun ahí suele haber un siguiente paso: pedir acceso, cambiar el rango, ir a otra sección. Un empty state sin salida es una pared.
¿Se pueden usar datos de ejemplo en el panel vacío?
Sí, si se distinguen de los reales y se pueden descartar. Un listado falso que parece producción enseña mal el oficio y, en más de un proyecto, alguien acaba tratando esos datos como si fueran del cliente. Prefiere un ejemplo claramente marcado o una acción que cree el primer objeto de verdad.
¿Cuándo el empty state es un problema de producto y no de copy?
Cuando la primera acción pide demasiado, cuando el valor del producto no se puede demostrar sin datos de terceros, o cuando hay tres vacíos distintos con el mismo componente. Ahí no se arregla con una frase más amable: se recorta el primer flujo o se separan las variantes.
