No uses un único estado vacío genérico para tus tablas de datos
La mayoría de las tablas de datos se lanzan con un único mensaje: "No hay datos".
Se ve bien en una revisión de diseño. Genera tickets de soporte en producción.
Una tabla vacía significa tres cosas diferentes. Cada caso requiere un diseño específico, un texto específico y una acción específica.
Estos son los tres casos que debes diseñar por separado:
Primer uso (Aún no existen datos) El usuario es nuevo. Quiere saber qué hace esta tabla y cómo empezar. • El objetivo: Integrar al usuario (onboarding). • El texto: Explicar el propósito de la tabla. • La acción: Proporcionar un botón para crear el primer elemento o importar datos. • Evitar: Un mensaje sin salida como "No hay datos".
Filtro vacío (Los datos existen, pero los filtros los ocultan) El usuario aplicó filtros que devuelven cero resultados. A menudo piensan que la herramienta no funciona. • El objetivo: Ayudar al usuario a encontrar sus datos. • El texto: Indicar explícitamente qué filtros están activos. • La acción: Proporcionar un botón para borrar todos los filtros o editarlos. • Evitar: Un mensaje genérico que ignore los filtros activos.
Fallo de carga (La solicitud falló) El servidor devolvió un error o la red se cayó. • El objetivo: Ayudar al usuario a recuperarse. • El texto: Explicar que la carga falló y mostrar una marca de tiempo o un código de error. • La acción: Proporcionar un botón de reintento. • Evitar: Decirle al usuario "No hay datos" cuando el problema es en realidad un error técnico.
Por qué los equipos fallan en esto:
- Diseñan los estados vacíos demasiado tarde en el proceso.
- Solo realizan pruebas con datos de demostración, por lo que nunca ven el estado vacío.
- Tratan los estados vacíos como casos excepcionales (edge cases).
En realidad, los estados vacíos son momentos de gran impacto. Un buen estado vacío lleva al usuario de cero a obtener valor en cuestión de minutos. Uno malo lo deja confundido y frustrado.
Construye tu componente de tabla para manejar estas condiciones por separado. Diseñarlos ahora cuesta poco, pero ahorrará enormes cantidades de tiempo de soporte más adelante.