Feedback y feedforward: la interfaz que responde y anticipa
El feedback confirma lo que pasó tras una acción; el feedforward anticipa lo que pasará antes de actuar. Qué dice el NN/g sobre estado y tiempos de respuesta.
¿Qué es el feedback y por qué importa?
El NN/g incluye la visibilidad del estado del sistema entre sus heurísticas de usabilidad: el sistema debe mantener informado al usuario sobre lo que está pasando, mediante feedback apropiado y en un tiempo razonable (NN/g: Visibility of System Status). Entre sus ejemplos están un botón que cambia de color y muestra una marca de verificación tras una selección, y un indicador de progreso cuando un proceso tarda un poco más.
El NN/g aclara que estas heurísticas son reglas generales, no guías específicas, y que la respuesta debe llegar lo antes posible, idealmente de inmediato (NN/g: Ten Usability Heuristics). Un formulario que no dice nada después de enviarse obliga a la persona a preguntarse si el clic funcionó. Esa duda produce clics repetidos, y los clics repetidos producen duplicados.
¿Qué es el feedforward?
El feedforward es la información que aparece antes de que la persona actúe y le dice qué va a pasar. Ejemplos: una etiqueta de botón que dice «Eliminar para siempre» en lugar de «Eliminar», una vista previa de cómo quedará un cambio de tema, o un aviso de que una acción no se puede deshacer.
El término viene de la literatura de diseño de interacción, no de las heurísticas del NN/g. Vermeulen, Luyten, van den Hoven y Coninx (CHI 2013) lo presentan como una forma de cruzar el golfo de la ejecución de Norman, la distancia entre lo que la persona quiere hacer y las acciones que el sistema le permite. El feedback, en cambio, ayuda a evaluar lo que ya pasó. Úsalo como una pauta de diseño práctica: antes de actuar, la persona debería poder saber qué va a ocurrir.
¿Cómo se aplican los dos?
Piensa en un flujo de tres momentos: antes de la acción, durante la espera y después del resultado.
- Antes (feedforward): la etiqueta dice el resultado, el icono coincide con la acción, y el riesgo se advierte si es irreversible.
- Durante (feedback): el botón cambia de estado, aparece un indicador de carga o el sistema muestra que sigue trabajando.
- Después (feedback): una confirmación, un mensaje de éxito o un error claro que dice qué hacer.
Para tiempos de espera, el NN/g propone tres límites conocidos. Con 0,1 segundos la respuesta se percibe como instantánea y no necesita más feedback que el resultado. Alrededor de 1 segundo, el flujo de pensamiento sigue ininterrumpido, pero conviene indicar que el sistema trabaja, por ejemplo con un cambio de cursor. Por encima de 10 segundos, la atención se dispersa y se necesita un indicador de porcentaje y la posibilidad de interrumpir (NN/g: Response Times: The 3 Important Limits). Para la discusión sobre el umbral de 400 ms, mira umbral de Doherty.
¿Cuándo NO conviene agregar más feedback?
- Cuando la respuesta ya es instantánea. Una animación de confirmación en una acción que tarda 50 milisegundos agrega ruido.
- Cuando el feedback se repite en cada pantalla. Si todo confirma todo, la persona deja de leerlo.
- Cuando el indicador de progreso no refleja avance real. Una barra que se llena sola engaña, y la gente deja de confiar en ella.
Ejemplo ilustrativo
Ejemplo ilustrativo: una app de transferencias bancarias tiene un botón «Enviar» que, al tocarlo, no cambia nada durante dos segundos. Las personas lo tocan de nuevo y, en algunos casos, duplican la transferencia. El equipo agrega dos cambios. Antes de enviar, el resumen dice «Se enviarán $500 a Ana López hoy» (feedforward). Al enviar, el botón cambia a «Procesando…» en el mismo instante del toque y se deshabilita (feedback). Cuando termina, aparece «Transferencia enviada» con el número de operación. Los duplicados bajan a cero, aunque el tiempo del servidor no cambió.
Si el momento de espera termina en un error, la forma de comunicarlo importa tanto como el feedback: revisa prevención y recuperación de errores y el texto de mensajes de error. Y para decidir si mostrar una pantalla esqueleto o una versión optimista, lee skeleton vs. optimistic UI.
¿Cómo saber si funciona?
Una prueba sencilla: pide a alguien que realice la acción principal sin darle instrucciones y observa el momento en que duda. Esa pausa suele marcar el punto donde falta feedback o feedforward. Si la persona pregunta en voz alta «¿se envió?» o toca dos veces, ya tienes el problema identificado. También conviene anotar lo que dice: si responde «creo que sí», la interfaz no le dio una confirmación suficiente.
Errores comunes
- Dejar al usuario sin respuesta después de un clic.
- Mostrar un spinner sin fin cuando la espera ya superó varios segundos.
- Usar feedback visual como único canal, sin texto para quienes no ven el cambio.
- Poner etiquetas genéricas como «Aceptar» en acciones irreversibles.
- Mostrar una barra de progreso que no corresponde al avance real.
- Confirmar cada acción menor con un mensaje, de modo que los mensajes importantes pasen desapercibidos.
Qué puedes hacer mañana
- Recorre tu flujo principal y anota cada acción que no tenga respuesta visible en menos de un segundo.
- Revisa las etiquetas de las acciones irreversibles y pregunta si dicen exactamente qué va a pasar.
- Elige una espera que supere los diez segundos en tu producto y define si necesita porcentaje, cancelación o ambos.