Hoy, así en bonito, os presento cuatro cosas que han sido el motivo de varios «oh, ¡jo*er!» míos. Y son nada más ni nada menos que los clásicos que se me han olvidado diseñar unas cuantas veces. He decidido sacarlos en el blog porque sé que no soy la única a quien le sería útil un recordatorio así🤝
Casos, cuando aún no hay datos
Lo importante es mostrar que está pasando algo
La palabra clave aquí es «aún». Necesitamos indicar al usuario que la información se está cargando y que en nada aparecerá en la pantalla. Mientras tanto, le proponemos: una animación, skeleton loading, spinners infinitos o de progreso. Algo que cuadre con el caso dado, pero nunca una pantalla vacía.
¿Puede que todo fluya y la persona nunca vea este spinner? Sí, igual que puede haber un delay y este spinner será lo que evite que la persona se frustre y/o abandone la interfaz.
Casos, cuando no hay datos
‘Empty state’ de toda la vida
Si los datos que van a aparecer en la interfaz son dinámicos, es muy posible que se nos olvide poner un Empty State. Yo misma me he enrollado tantas veces con los propios elementos de la UI que lo de «¿qué pasa si no hay nada?» ha llegado un tiempo después.
Casos, cuando hay demasiados datos
Scroll hasta el infinito y más allá…
Cuando estás diseñando una lista, un dashboard, etc., con 3, 5, 10 elementos, todo parece encajar. Pero, ¿qué pasa si hay un montón de datos? Por ejemplo, si la lista ha crecido hasta 100 o 1000 elementos. Es un caso que hay que pensar en detalle, ya que poner un solo elemento como un Empty State no será suficiente.
Primero, hay que pensar en cómo presentar la cantidad de datos: ¿será un scroll infinito o lo dividimos por paginación? Luego, ¿cómo ayudamos al usuario a navegar entre todo esto? ¿Se puede añadir un filtro, un input de sort, una forma de elegir elementos que quiera tener siempre a la vista?
El tema de los datos es muy importante de tratar, y aquí una gran parte depende del equipo de ingeniería, que tiene que explicar al diseño cómo funciona el sistema: cuánto tardan en cargarse los datos, cuánta cantidad hay o puede haber, etc.
Casos, cuando hay un error
«Hoy no hay imagenes para tí»
Esto se podría llamar un caso con asterisco. Pero también me ha pasado. ¿Qué mostramos en pantalla cuando algo ha ido mal y tampoco es un caso de loading o Empty State? Pues se puede pensar en un tipo de aviso, activo o pasivo, una CTA para hacer otra cosa, etc. Pero siempre es bueno avisar, sobre todo si algo no ha ido bien y está claro que el usuario no podrá usar la interfaz como se espera.
En este apartado, también añadiría otro clásico muy simple: las páginas 404. Si estamos diseñando algo en el entorno web, ya sea una aplicación o una landing, es importante considerar si el proyecto requiere una página 404 personalizada en lugar de mostrar la que viene por defecto en WordPress o en otro sistema similar. Aunque son elementos sencillos, es fácil pasarlas por alto.
_______________________
Todos estos detalles no se ven cuando estás trabajando con unos cuantos elementos de ejemplo. Por lo que debe convertirse en un hábito muy fuerte o, al menos, en una simple checklist de casos «adicionales» al diseño principal.
Y lo de siempre, es imprescindible comunicarse con el equipo de ingeniería y tener muy claro cómo se procesan los datos, cuánto tardan en salir a la pantalla y qué errores pueden ocurrir con más probabilidad.
En caso de duda, aprovecha esta lista para no olvidar. Yo también lo haré🤭
