Tabla de datos o tarjetas: cuándo gana la tabla en una interfaz

Elegir entre una tabla de datos y un diseño de tarjetas es una decisión de densidad: fija cuántos registros se ven a la vez, cuántos atributos se pueden comparar y cuánto esfuerzo cuesta cada comparación. Todas las pantallas de listado de una herramienta B2B, un panel de administración o un catálogo pasan por ella, casi siempre en la primera semana de diseño, y la elección se queda ahí hasta que alguien rediseña la pantalla.

Manda la tarea. La investigación de Nielsen Norman Group sobre tablas de datos explica por qué la tabla gana al comparar: dos valores contiguos se leen juntos, mientras que con tarjetas hay que reubicarse en el espacio cada vez que se pasa de una a otra, y comparar se vuelve lento y costoso. Las tarjetas ganan en otros terrenos, y casi todo el artículo trata de cuáles son.

La respuesta corta

La tabla sirve cuando se comparan registros sobre los mismos atributos, se busca un valor anómalo en una columna, se ordena, se filtra o se actúa sobre muchas filas a la vez. Las tarjetas sirven cuando cada registro tiene su propia forma, cuando una imagen decide la elección o cuando la pantalla es la puerta a unas pocas páginas de detalle. Si nadie sabe decir cuál es la tarea principal de la pantalla, la pregunta del diseño llega antes de tiempo: primero hay que aclarar la tarea.

Tabla y cuadrícula de tarjetas, frente a frente

Ocho criterios resuelven casi todos los casos. En cada uno va primero el formato que funciona mejor.

• Registros en una pantalla: tabla. En un portátil de 1440 por 900, con unos 720 px libres para el listado bajo la cabecera y la barra de herramientas, una tabla con filas de 40 px, la altura por defecto del design system Carbon de IBM, muestra 18 registros. Tres tarjetas por fila de 280 px de alto muestran seis enteros, y la tercera fila queda cortada por el borde de la pantalla.
• Comparar un atributo entre registros: tabla. Los valores están en columna y la vista baja en línea recta.
• Registros con formas distintas: tarjetas. Cada tarjeta admite una altura y una mezcla de contenido diferentes. Las columnas fijas no.
• Imágenes que deciden la elección: tarjetas. La foto de un producto o la vista previa de una plantilla necesitan un espacio que una fila de tabla no tiene.
• Ordenar y filtrar: tabla. La cabecera de columna es el sitio natural para ordenar, y una columna filtrada muestra el efecto de un vistazo.
• Acciones en lote: tabla. Casillas en las filas y una barra de acciones son un patrón asentado, que Carbon incluye como variante de su tabla.
• Zona táctil: tarjetas. Toda la tarjeta puede ser un único enlace, un objetivo más grande que NN/g relaciona con la ley de Fitts.
• Tecnologías de apoyo: tabla, si es una tabla de verdad. El tutorial del W3C sobre tablas explica que las celdas de cabecera marcadas como th dan a los lectores de pantalla el contexto de cada valor. Una cuadrícula de div no les da ninguno.

¿Cuándo gana una tabla a una cuadrícula de tarjetas?

La tabla gana cuando la pantalla sirve a las cuatro tareas que NN/g identifica para las tablas de datos: encontrar registros que cumplen ciertos criterios, comparar datos, ver o editar una sola fila y actuar sobre los registros. Casi todas las pantallas operativas de un SaaS hacen justo eso: facturas, pedidos, usuarios, tickets, despliegues, leads.

Los atributos se repiten en cada registro

Cada factura tiene un número, un cliente, un importe, un vencimiento y un estado. Cuando los atributos se repiten, la cabecera dice cada etiqueta una sola vez y las filas solo llevan valores. La tarjeta repite la etiqueta en cada registro, o la quita y deja que el lector adivine. Cinco atributos en 50 facturas son 250 valores: en la tabla se leen además cinco etiquetas, en una cuadrícula de tarjetas hasta 250.

Se busca la excepción

Detrás de casi todos los listados hay una comparación. Qué pedido va con retraso, qué cliente debe más, qué despliegue ha fallado. Una columna de importes se recorre de arriba abajo de una pasada. Los mismos importes repartidos en una cuadrícula, cada uno en su tarjeta, hay que buscarlos de uno en uno.

El listado crece

NN/g pone la escalabilidad en primer lugar entre las ventajas de las tablas: filas y columnas se añaden cuando cambian los datos. Una tarjeta pensada para cuatro atributos hay que rediseñarla al llegar al séptimo. A la tabla le basta una columna más y decidir dónde va.

Se actúa sobre muchos registros a la vez

Archivar 30 tickets, exportar un mes de pedidos, reasignar un grupo de leads. Seleccionar varias filas, con el recuento siempre a la vista y una barra de acciones, es un patrón de tabla. Las tarjetas también se pueden hacer seleccionables, pero la casilla compite con el clic que abre la tarjeta.

¿Cuándo gana una cuadrícula de tarjetas a una tabla?

NN/g define la tarjeta como un contenedor para unos pocos datos breves y relacionados, una representación corta y enlazada de un único concepto. La definición ya marca el terreno: pocos atributos, un enlace hacia el resto, un concepto por tarjeta.

Cada registro tiene su propia forma

Un feed de proyectos donde uno lleva imagen de portada, el siguiente una cita y el tercero un gráfico. Una tabla los metería en las mismas columnas y dejaría vacías la mayoría de las celdas. Las tarjetas mantienen el ancho fijo y dejan que la altura siga al contenido.

Se elige mirando

Plantillas, temas, productos, inmuebles, personas. Cuando el usuario elige mirando, la imagen es el atributo principal, y una fila de 40 px no la enseña. Una columna de miniaturas vale para reconocer, es decir, encontrar un archivo que ya conoces. No vale para elegir uno que nunca has visto.

La pantalla es una puerta

La portada de un dashboard, una lista de espacios de trabajo, un catálogo de cursos. Pocos registros, cada uno para abrirlo más que para compararlo. La tarjeta tiene que dar información suficiente para ganarse el clic, y toda su superficie puede ser el objetivo.

¿Qué le pasa a una tabla en el móvil?

El reflejo habitual es convertir cada fila en una tarjeta apilada por debajo de cierto breakpoint. Se resuelve el ancho y desaparece la comparación para la que existía la tabla. La accesibilidad no lo exige. El criterio de conformidad 1.4.10 de las WCAG 2.2, Reflow, pide que el contenido quepa en 320 px CSS de ancho sin desplazarse en dos direcciones, y cita las tablas de datos entre los contenidos que necesitan una disposición bidimensional y pueden desplazarse en ambos sentidos. Cada celda, eso sí, tiene que adaptarse.

Las pautas de NN/g sobre tablas en móvil mantienen la tabla y la hacen usable: columnas con ancho suficiente para leerlas (en una pantalla estrecha caben dos columnas de texto, más si los valores son números), cabeceras fijas, primera columna fija, una señal visible de que hay más columnas fuera de la pantalla y la opción de elegir qué columnas ver. Las filas pasan a tarjetas apiladas solo cuando en el móvil se busca un registro concreto, como un técnico que abre la siguiente intervención. Si en el móvil también se compara, la tabla se queda, reducida a las columnas que esa comparación necesita.

La densidad se ajusta, el formato se mantiene

Muchas veces se pasa a tarjetas porque la tabla parece abarrotada. Contra eso se trabaja con la altura de fila y los espaciados. La tabla de Carbon trae cinco alturas de fila: 24 px para diseños muy densos, 32, 40 por defecto, 48 y 64 px para filas de dos líneas. La altura se elige según lo que contiene la fila, y después el tamaño del texto, el peso y el contraste separan el identificador de los valores secundarios.

Entre los dos formatos está la fila de lista enriquecida: un registro por línea, una etiqueta principal, dos o tres valores secundarios y quizá un avatar. Funciona para registros con pocos atributos cuando importa leer en orden más que alinear columnas, como en los mensajes o la actividad reciente. Cuando los usuarios empiezan a pedir ordenar por uno de esos valores, la lista se ha convertido en una tabla.

Hay dos errores que vuelven, uno en cada sentido. El primero es la cuadrícula de tarjetas para datos que se comparan: facturas en tarjetas, con importe, fecha y estado en una esquina distinta de cada una, de modo que para encontrar las vencidas hay que leerlas todas. El segundo es la tabla para contenido visual: una galería de plantillas reducida a nombres en filas, de modo que para elegir hay que abrirlas una a una. En los dos casos el formato se eligió antes de poner la tarea por escrito.

Cómo elegimos en una pantalla real

Antes de dibujar el listado respondemos a cinco preguntas, en este orden.

1. ¿Cuál es la tarea única de esta pantalla? Encontrar, comparar, actuar, u hojear y abrir. Comparar y actuar llevan a la tabla. Hojear y abrir llevan a las tarjetas.
2. ¿Cuántos registros, en un día normal y en el peor caso? Una pantalla con 8 registros en el lanzamiento y 800 un año después es una tabla desde la primera versión.
3. ¿Los registros comparten atributos? Si los comparten, los atributos son columnas. Si cada registro tiene su propia forma, tarjetas.
4. ¿Una imagen decide la elección? Si la decide, tarjetas, o una tabla con una vista previa grande de la fila seleccionada al lado.
5. ¿Cuál es la tarea en el móvil? Si se compara, se queda la tabla, con cabeceras fijas y menos columnas. Si se busca un solo registro, las filas se pueden apilar.

En los productos que diseñamos, los listados operativos (pedidos, usuarios, facturas, logs) empiezan como tabla, con la densidad ajustada por la altura de fila. Las tarjetas se quedan para galerías, plantillas y los recuadros de resumen en lo alto de un dashboard. La tabla se diseña junto a sus estados vacío, de carga y de error, igual que hacemos con los estados vacíos de cada pantalla.

Una comprobación detecta casi todas las elecciones equivocadas. Escribe como frase la pregunta con la que el usuario llega a la pantalla. Si lleva un "qué" o un "cuál" y un superlativo (qué cliente debe más, qué proceso falló anoche), la pantalla es una tabla.