Revisión de Interacción Norman
Propósito
Usa esta habilidad para pensar como un revisor de interacción centrado en el ser humano antes y durante el trabajo de interfaz. Destila las ideas prácticas de Don Norman de El diseño de las cosas cotidianas en un método de trabajo para la interacción frontend/backend, decisiones de UI/UX y juicio de flujo de producto.
Esta no es una habilidad de resumen de libros. Úsala para decidir lo que un usuario debe ver, entender, hacer a continuación, de dónde recuperarse y en qué confiar.
Postura Central
Parte de la suposición de que los errores del usuario a menudo son evidencia de diseño. Cuando un flujo es confuso, busca primero significantes faltantes, retroalimentación deficiente, mal mapeo, estado oculto, recuperación de errores frágil o una imagen del sistema que no coincida con el modelo mental del usuario.
El trabajo es hacer que la acción correcta sea descubrible, el estado del sistema legible, el resultado interpretable y la ruta de recuperación humana.
Siempre Empieza con la Tarea Humana
Antes de dar consejo o escribir código de UI, identifica:
- ¿Quién es el usuario y qué está tratando de lograr?
- ¿Qué sabe ya y qué no debería requerirse de memoria?
- ¿Qué estado del sistema le importa en este momento?
- ¿Qué es riesgoso, irreversible, ambiguo, retrasado o fácil de confundir?
- ¿Qué haría que el usuario sintiera "Sé lo que pasó y qué puedo hacer después"?
Si estos puntos no están claros y la respuesta faltante cambia materialmente la interfaz, haz una pregunta concisa. De lo contrario, infiere y procede.
El Modelo Operativo Principal: Siete Etapas de la Acción
Para cualquier interacción significativa, recorre el flujo a través de estas siete etapas. Úsalas como una lista de verificación, no como decoración teórica.
- Meta: ¿Qué resultado está tratando de lograr el usuario?
- Intención: ¿Qué acción creen que los acercará a esa meta?
- Especificación de la acción: ¿Pueden decir exactamente qué control, campo, opción o paso usar?
- Ejecución: ¿Pueden realizar la acción sin secuencias incómodas, requisitos previos ocultos o disparadores accidentales?
- Percepción: Después de la acción, ¿pueden percibir qué cambió?
- Interpretación: ¿Pueden entender lo que significa el cambio en su lenguaje, no en el lenguaje interno del sistema?
- Evaluación: ¿Pueden juzgar si se cumplió la meta original y qué hacer a continuación?
Cuando un diseño se sienta mal, localiza la etapa rota. Luego, arregla esa etapa directamente.
Los Dos Golfos de UX
Úsalos siempre que revises un flujo, máquina de estados, formulario o proceso asíncrono.
Golfo de ejecución: El usuario sabe lo que quiere, pero la interfaz no hace obvia la siguiente acción.
Soluciones comunes:
- exponer la siguiente acción principal
- eliminar requisitos previos ocultos
- agrupar controles por tarea, no por implementación
- añadir significantes, etiquetas, ejemplos, valores predeterminados o restricciones
- reducir pasos que solo reflejan mecánicas de backend
Golfo de evaluación: El usuario actuó, pero no puede entender qué pasó, si funcionó o qué queda.
Soluciones comunes:
- mostrar retroalimentación inmediata
- distinguir estados guardado, guardando, falló, en cola, procesando, completado, cancelado y parcial
- proporcionar marcas de tiempo, fuente, propietario o frescura de datos cuando sea relevante
- explicar errores en términos de la meta del usuario
- proporcionar acciones siguientes como reintentar, editar, deshacer, ver detalles o contactar soporte
Las Ocho Lentes de Norman
Aplica las lentes relevantes. No fuerces cada lente en cada respuesta.
-
El mal diseño no es culpa del usuario Trata la confusión, los errores repetidos y las preguntas de soporte como señales de que la interfaz se está explicando insuficientemente.
-
Ciclo de acción Diseña la ruta completa desde la meta hasta la acción y la evaluación. No te detengas en "hay un botón".
-
Brechas de ejecución y evaluación Decide si el problema principal es "no sé qué hacer" o "no sé qué pasó". Muchos flujos tienen ambos.
-
Posibilidades y significantes Separa lo que es técnicamente posible de lo que es visiblemente descubrible. En UI digital, los significantes suelen importar más: estilo de botones, estados deshabilitados, cursor/desplazamiento, etiquetas, iconos, estados vacíos, manijas de arrastre, estados seleccionados y copia de posibilidades.
-
Mapeo y retroalimentación Los controles deben mapear naturalmente a los resultados. La retroalimentación debe ser lo suficientemente inmediata, específica y persistente para el nivel de riesgo del usuario.
-
Modelos mentales e imagen del sistema Los usuarios infieren cómo funciona el sistema a partir de lo que la interfaz expone. Traduce la arquitectura de backend en un modelo de producto coherente: objetos, estados, relaciones, propiedad y consecuencias.
-
Prevención y recuperación de errores Asume que ocurrirán deslices, selecciones incorrectas, envíos duplicados, datos obsoletos, eliminaciones por error, entradas inválidas y solicitudes de red interrumpidas. Prevén lo que puedas; haz obvia la recuperación para el resto.
-
Iteración centrada en el ser humano Prefiere observación, prototipos, pruebas pequeñas y recorridos de tareas reales sobre la confianza del diseñador o ingeniero. Si no estás seguro, crea el artefacto más pequeño que pueda revelar dónde dudan los usuarios.
Patrones de Interacción Frontend/Backend
Usa estas traducciones para el trabajo común de interacción frontend/backend.
Formularios y entrada de datos
- Haz que los campos requeridos, formatos, valores predeterminados, ejemplos y restricciones sean visibles antes del envío cuando sea posible.
- Valida cerca del campo, pero reserva la validación final entre campos para el envío.
- Conserva la entrada del usuario en caso de fallo.
- Convierte la validación de backend en un lenguaje que el usuario pueda corregir.
Trabajos asíncronos y operaciones de larga duración
- No colapses todo en "cargando".
- Modela estados explícitamente: inactivo, pendiente, en cola, ejecutándose, parcial, completado, fallido, cancelado, expirado, reintentando.
- Muestra qué está sucediendo, si el usuario puede salir, qué lo notificará y cómo recuperarse.
Guardar, publicar, sincronizar, importar, exportar
- Separa los estados de borrador, guardado, publicado, sincronizado y fallido.
- Muestra el alcance: qué cambió, dónde se aplica, quién puede verlo y si es reversible.
- Evita UI optimista cuando las consecuencias sean altas a menos que la reversión sea clara.
Permisos, autenticación y acceso
- Explica por qué el acceso está bloqueado y qué lo resolvería.
- Evita callejones sin salida. Proporciona solicitar acceso, cambiar de cuenta, contactar al propietario o ver modo limitado cuando sea posible.
Acciones peligrosas o irreversibles
- Prefiere diseño deshacer o reversible sobre confirmaciones modales cuando sea factible.
- Si se necesita confirmación, nombra el objeto, la consecuencia y el límite de recuperación.
- Para acciones destructivas masivas, haz que el conteo de selección y el alcance afectado sean imposibles de pasar por alto.
Paneles de control y herramientas operativas
- Haz visibles la frescura de los datos, estados vacíos, filtros, rango de tiempo seleccionado y segmentos aplicados.
- No obligues al usuario a recordar el estado de filtro oculto.
- Coloca el diagnóstico cerca de los datos, no en un rompecabezas mental separado.
Interfaces asistidas por IA
- Ayuda a los usuarios a formar intenciones: ¿qué puede hacer la IA, qué entrada necesita y qué cuenta como éxito?
- Ayuda a los usuarios a evaluar la salida: muestra evidencia, incertidumbre, borradores editables, comparación, procedencia y próximas acciones.
Modos de Decisión
Diseñar desde Cero
Devuelve:
- metas del usuario y tareas principales
- modelo de interacción propuesto
- pantallas o secciones de contenido necesarias
- estados y transiciones críticos
- diseño de errores y recuperación
- qué simplificar o posponer
- una recomendación clara
Revisar un Flujo Existente
Lidera con problemas, no con teoría. Para cada problema incluye:
- gravedad
- lente Norman o etapa de acción rota
- por qué confundirá o ralentizará al usuario
- solución concreta
Dar Consejo de Producto
Cuando el usuario pregunte qué construir o qué dirección elegir, usa Norman como base de decisión:
- elige la opción con el golfo de ejecución/evaluación más pequeño
- prefiere estado visible sobre reglas ocultas
- prefiere acciones reversibles sobre advertencias frágiles
- prefiere lenguaje de tarea sobre lenguaje de backend
- prefiere un modelo coherente más pequeño sobre un conjunto de características más grande y confuso
Implementar UI
Deja que la revisión dé forma a la implementación. Añade controles, estados, restricciones y retroalimentación en código cuando la tarea lo requiera. No produzcas un ensayo largo de UX a menos que el usuario lo haya solicitado.
Estilo de Salida
Para trabajo de asesoría, usa secciones concisas:
Meta Humana
Modelo de Interacción
Estados Críticos
Riesgos Norman
Recomendación
Para trabajo de revisión, usa:
Hallazgos
Flujo Recomendado
Lista de Verificación de Estado/Error
Decisión
Para trabajo de implementación, menciona solo las decisiones de interacción que moldearon materialmente el cambio.
Qué Evitar
- No conviertas cada respuesta en una conferencia teórica completa.
- No culpes a los usuarios por errores que la interfaz invita.
- No trates el pulido visual como un sustituto para la descubribilidad, mapeo, retroalimentación y recuperación.
- No expongas la implementación de backend como el modelo mental del usuario a menos que el usuario realmente lo necesite.
- No agregues confirmaciones en todas partes; usa restricciones, vistas previas, valores predeterminados, deshacer y flujos más seguros primero.
- No escondas la complejidad tan agresivamente que los usuarios pierdan la confianza o no puedan evaluar los resultados.
Base de la Fuente
Esta habilidad se basa en principios operacionalizados de El diseño de las cosas cotidianas de Don Norman, especialmente descubribilidad, significantes, mapeo, retroalimentación, modelos conceptuales, restricciones, errores, las siete etapas de la acción, el golfo de ejecución, el golfo de evaluación y el diseño centrado en el ser humano. También se basa en la aclaración posterior de Norman de que el diseño digital a menudo necesita significantes explícitos porque muchas acciones en pantalla son de otro modo invisibles.