Undo / Redo patterns

Los dialogos de confirmación fallan por habituación: el usuario aprende a presionar "OK" sin leer y el sistema termina dando una falsa sensación de protección. Aza Raskin lo formulo en 2007 con el principio "Never use a warning when you mean undo": las advertencias entrenan a la gente a descartarlas en automático. Para acciones frecuentes y reversibles la mejor experiencia es ejecutar de inmediato y ofrecer deshacer, no interrumpir el flujo con una pregunta que el usuario ya ignora. NN/g lo refuerza: provee deshacer porque algunos errores persisten incluso con el mejor dialogo de confirmación.

El patrón snackbar-undo, popularizado por Gmail, deja corregir un error sin interrumpir el flujo previo: la acción se refleja de inmediato en la UI pero el commit definitivo se difiere mientras el snackbar esta visible. Si el usuario presiona "Deshacer" se revierte; si la ventana expira, el cambio se persiste (soft-delete). Material Design 1 (archivado) específico que un snackbar debe permanecer entre 4 y 10 segundos antes de auto-descartarse. Material Design 3 limita el snackbar a una sola acción: "Descartar" y "Cancelar" no son acciones validas. Una barra o cuenta regresiva visible comunica cuanto tiempo queda para revertir.

Los atajos de deshacer y rehacer son convenciones del sistema operativo con decadas de arraigo: Mac usa Cmd+Z / Shift+Cmd+Z, Windows usa Ctrl+Z / Ctrl+Y. Reasignarlos a otra función provoca confusión severa porque el usuario activa el modelo mental equivocado. Apple HIG es explicito: no debes usar Shift-Command-Z como atajo de un comando ajeno a Deshacer. NN/g recuerda que en escritorio no asumas que el usuario conocera el atajo: el control visible en la UI no reemplaza el shortcut, lo complementa. Expon ambos en el menú Editar con su atajo a la vista.

En apps donde el usuario encadena acciones (editores de texto, diseño, código, hojas de calculo) un único nivel de deshacer es insuficiente. NN/g recomienda: si es probable que el usuario realice muchas acciones en sucesión rápida, soporta multiples Undo y Redo. La profundidad razonable depende del tipo de app; la practica de industria suele estar entre 20 y 50 operaciones, con evicción FIFO de las más antiguas para evitar consumo de memoria. No existe un número canonico de niveles dictado por una fuente primaria: 20-50 es convención, no norma. Un panel de historial visible (estilo Photoshop) hace tangible el stack.

Cuando el comando dice "Deshacer" sin contexto, el usuario tiene que recordar que hizo. Cuando dice "Deshacer Renombrar" el modelo mental es más rápido y confiable. Apple HIG establece que debes anadir el nombre de la última operación deshecha al comando Rehacer; por simetría, también al Deshacer. NN/g recomienda dar feedback visual sobre que cambio como resultado de una acción. Lleva esa precisión también al snackbar de confirmación: en lugar de un "Deshecho" genérico, di exactamente que se restauro.

Una acción destructiva reversible no debe consumarse en el instante del click: marca la fila para eliminación durante la sesión y solo persiste el borrado definitivo cuando expira la ventana de deshacer o el usuario sale. Esta técnica de soft-delete, descrita por UXmatters, convierte "Eliminar" en una operación segura sin fricción previa. La fila puede ocultarse de inmediato con una transición, mientras el snackbar mantiene la ruta de retorno. El borrado físico ocurre en segundo plano solo cuando ya no hay riesgo de arrepentimiento.

Cuando una acción no puede deshacerse (pagos, firmas, eliminación permanente de datos de terceros) o tiene consecuencias legales o financieras serias, el patrón de deshacer no aplica y se requiere un mecanismo de confirmación o revisión previo. WCAG 3.3.4 (Nivel AA) exige que, para páginas con compromisos legales, transacciones financieras o modificación de datos, al menos una de tres salvaguardas exista: reversible, verificada, o confirmada. WCAG 3.3.6 (Nivel AAA) extiende el requisito a todos los envios de formulario. NN/g reserva el dialogo de confirmación para acciones con consecuencias serias que no se pueden deshacer; usarlo en todo lo demas lo devalua.

Si la única forma de deshacer es un gesto (shake en iOS, swipe en Android), los usuarios de teclado y con discapacidad motora quedan excluidos. WCAG 2.1.1 (Nivel A) exige que toda funcionalidad sea operable por teclado, y WCAG 4.1.3 requiere que los mensajes de estado sean determinables programaticamente para que los lectores de pantalla los anuncien sin mover el foco. El toast de deshacer debe llevar role="status" o aria-live="polite", y la acción debe activarse por teclado. NN/g cita el shake-to-undo de iOS como antipatron: es notoriamente subutilizado por lo difícil de descubrir. Manten el foco en la lista, no lo muevas al toast.