Pensar como el Usuario al Diseñar Interacciones

El Problema

Cuando la IA escribe interacciones, a menudo organiza la interfaz en el orden de la implementación en lugar de en el orden del usuario: primero coloca los controles según la estructura de datos que tenga, y ubica los botones según qué función se haya escrito primero. El resultado:

El botón "Guardar" de un formulario largo está en la parte superior; el usuario llega al fondo y tiene que volver a buscarlo.
"Eliminar" está justo al lado de "Guardar", con el mismo color y tamaño.
La función más usada está oculta en el segundo nivel del menú "Más...", mientras que una configuración poco usada ocupa el lugar más visible de la barra de herramientas.
Con una sola opción, primero hay que seleccionarla para poder hacer clic en "Siguiente".
Para cambiar un nombre: haz clic en "Modo edición" → cambia → haz clic en "Aplicar" → haz clic en "Guardar" → aparece un diálogo de confirmación "¿Estás seguro de que quieres guardar?".
Crear algo nuevo requiere tres pasos en un asistente, cuando lo único que necesitas es escribir un nombre.
Los botones dicen "Enviar", "Ejecutar", "Aceptar" y el usuario no sabe qué pasará al hacer clic.
Cuando ocurre un error, aparece un mensaje como "Operación fallida" y todo lo que habías escrito se borra.

Cada uno de estos problemas por separado no es fatal, pero juntos crean la sensación de que "esto no es nada intuitivo".

Primer Paso: Definir Claramente para Qué Viene el Usuario

Antes de empezar, escribe (aunque sea mentalmente):

Quién lo usa: ¿un novato que lo usa por primera vez o un experto que lo usa a diario?
Las 1 a 3 tareas más comunes: estas deben ser las más rápidas y visibles.
El camino ideal para cada tarea: desde que abre el programa hasta que la completa, ¿cuántos pasos necesita como mínimo?

Organiza el diseño de la interfaz según este orden, no según la lista de funciones, los campos de la base de datos o los módulos del código.

Segundo Paso: Dónde Colocar los Botones y Accesos

Principio	Cómo hacerlo	Contraejemplo
La operación debe estar cerca del objeto sobre el que actúa	Los botones de edición/eliminación en una fila deben estar en esa fila; las operaciones de una tarjeta, en la tarjeta misma	Primero seleccionar una fila y luego ir a la parte superior de la página para buscar "Editar"
Colocar según la posición en el flujo de finalización	El botón de envío de un formulario debe estar al final del formulario; los botones de un diálogo, en la parte inferior	El botón "Guardar" de un formulario largo en la parte superior
La frecuencia determina la visibilidad	Las funciones más usadas se muestran directamente; las de uso ocasional, en un menú; las de uso muy raro, en la configuración	Funciones comunes ocultas en un menú de segundo nivel
Una interfaz debe tener una sola acción principal	La acción principal se destaca con un estilo llamativo; las demás, con un estilo secundario	Cinco botones azules igualmente llamativos
Separar las operaciones peligrosas	"Eliminar" debe tener un color diferente, estar en una posición alejada o dentro de un menú	"Eliminar" y "Guardar" uno al lado del otro y con el mismo aspecto
Seguir las convenciones de la plataforma	En Windows, los botones de diálogo están en la esquina inferior derecha, "Aceptar" a la izquierda de "Cancelar"; en macOS, "Cancelar" a la izquierda y el botón principal a la derecha; en ventanas modales web, la "X" de cerrar está en la esquina superior derecha	Inventar un orden propio
Para un mismo tipo de operación, la posición debe ser consistente	El botón "Nuevo" debe estar en el mismo lugar en todas las páginas	La posición varía de una página a otra
Los accesos deben estar donde el usuario los busque	Cuando el usuario piensa "Quiero exportar", mira en la barra de herramientas, el menú Archivo o encima de la lista	La opción de exportar está oculta dentro de la página de configuración

Tercer Paso: Eliminar Pasos Redundantes

Enumera cada paso de la tarea principal y pregúntate:

¿Se puede eliminar? ¿El usuario debe tomar una decisión en este paso? Si no es así, elimínalo.
¿Se puede establecer un valor predeterminado? Si el 90% de las personas elegiría lo mismo, selecciónalo por defecto. Recuerda la última elección del usuario.
¿Se puede fusionar? ¿"Editar → Aplicar → Guardar" podría convertirse en editar directamente, autoguardar o un solo guardado?
¿Se puede posponer? El registro, la configuración detallada, los campos opcionales: ¿se pueden preguntar cuando el usuario realmente los necesite?
¿Se puede inferir automáticamente? Lo que se pueda deducir del nombre del archivo, el contexto o los datos existentes no debe pedirse al usuario.

Pasos redundantes comunes:

Redundante	Cómo cambiarlo
Operaciones reversibles con mensaje "¿Estás seguro?"	Ejecutar directamente y ofrecer "Deshacer" (como los toasts de Gmail); solo pedir confirmación para operaciones irreversibles y de gran impacto
Diálogo de confirmación que dice "¿Estás seguro? [Aceptar] [Cancelar]"	Escribir las consecuencias y el objeto: "¿Eliminar 3 archivos? Esta operación no se puede deshacer. [Eliminar] [Cancelar]"
Con una sola opción, tener que seleccionarla	Seleccionarla automáticamente o saltarse ese paso directamente
Un "modo edición" separado	Editar directamente
Un asistente de varios pasos para una sola cosa	Un campo de entrada + un botón, o creación en línea
Después de cambiar la configuración, hacer clic en "Aplicar" y luego en "Guardar"	Una sola acción, o que sea efectivo al instante
Después de una operación, saltar a otra página y el usuario tiene que navegar de vuelta	Permanecer en el mismo lugar y actualizar en el sitio
Tener que volver a llenar la misma información cada vez	Recordarla o rellenarla automáticamente

Cuarto Paso: No Añadir Cosas que el Usuario No Ha Pedido

La IA tiende a "hacer de más": el usuario pide un botón de exportar y termina con un menú desplegable de formato de exportación, historial de exportaciones, página de configuración de exportación; el usuario pide una pequeña herramienta y termina con una barra lateral, un menú de configuración, un selector de tema, una página "Acerca de", un centro de ayuda y accesos a funciones "próximamente".

Cada función, menú o acceso adicional que añades es algo más que el usuario tiene que entender y saltarse, y la entrada a la tarea principal se vuelve más difícil de encontrar. Todo en la interfaz compite por la atención del usuario.

Antes de añadir algo, pregúntate:

¿El usuario lo pidió? Si no lo pidió y no es esencial para completar la tarea principal, no lo añadas.
Sin esto, ¿el usuario se quedará atascado? Si no, no lo añadas.
¿Tiene solo una opción, o casi nadie lo cambiaría? Entonces no necesitas un elemento de configuración ni un menú desplegable. Usa un valor predeterminado razonable.
¿Está vacío, sin implementar, o es un "tal vez se use en el futuro"? No pongas accesos placeholder, botones grises con "Próximamente" ni menús que no hacen nada al hacer clic.

Ejemplos de cosas innecesarias comunes:

Innecesario	Cómo cambiarlo
Una herramienta con solo una o dos funciones que tiene barra lateral + navegación superior + menú de configuración	Una sola interfaz que muestre las funciones directamente
Selector de tema, cambio de idioma, configuración personalizada que nadie pidió	No hacerlo; añadirlo cuando sea necesario
Una página que podría ser una sola, dividida en "Inicio / Panel / Acerca de / Ayuda"	Una sola página
Una misma función con tres accesos (barra de herramientas, menú contextual, página de configuración)	Un solo acceso donde el usuario tenga más probabilidades de buscarlo; se puede añadir un atajo de teclado aparte
Accesos placeholder de "Próximamente", "Funciones avanzadas", tarjetas de estadísticas vacías	Eliminarlos
Cada valor convertido en un elemento configurable	Establecer valores predeterminados buenos y exponer solo lo que el usuario realmente cambiará

Si crees que una función adicional es realmente útil, menciónala como sugerencia después de completar los requisitos principales y deja que el usuario decida si quiere incluirla, en lugar de implementarla directamente.

Quinto Paso: Que el Usuario Sepa en Todo Momento lo que Está Pasando

Texto del botón = verbo + objeto: "Exportar CSV", "Eliminar proyecto", "Enviar invitación", en lugar de "Enviar", "Ejecutar", "Aceptar". Usa las palabras del usuario, no las de la implementación (no escribas "Sincronizar payload", "Disparar job").
Respuesta inmediata al hacer clic: retroalimentación visual en menos de 100 ms; si tarda más de 1 segundo, muestra una barra de progreso o un estado de carga y desactiva el botón para evitar envíos duplicados.
Al completar, avisar: un mensaje de éxito ligero, o que la interfaz muestre directamente el resultado.
Cuando ocurra un error, decir cómo solucionarlo: explicar qué salió mal y cómo corregirlo; mostrar el error junto al campo que lo causa; conservar lo que el usuario ya había escrito.
Estado vacío: guiar al siguiente paso: cuando la lista esté vacía, dile al usuario qué aparecerá allí y dale directamente un botón para "Crear el primero".
Teclado: al abrir un diálogo, el foco debe estar en el primer campo de entrada; Enter para enviar, Esc para cerrar; el orden de tabulación debe coincidir con el orden visual.
No cambiar las cosas de repente: no muevas la posición de un botón mientras el usuario está haciendo clic, ni muestres una ventana emergente que tape el lugar donde está haciendo clic.

Para la línea de comandos (CLI) aplica lo mismo: los parámetros de uso común deben tener opciones cortas y valores predeterminados razonables; las operaciones peligrosas deben pedir confirmación, pero ofrecer --yes; los mensajes de error deben explicar cómo solucionarlo; las tareas largas deben mostrar progreso.

Sexto Paso: Recorrerlo Físicamente

Escribir no es suficiente. Antes de entregar, debes recorrer la tarea principal como si fueras un usuario (para capturar pantallas, consulta background-friendly):

Finge que es la primera vez que abres: sin mirar el código, solo la interfaz. ¿Puedes encontrar en menos de 5 segundos el acceso a lo que quieres hacer?
Cuenta los clics: ¿cuántos clics/entradas se necesitan para completar la tarea principal? Compáralo con el camino ideal que escribiste en el primer paso. Cada paso adicional debe tener una razón.
Recórrelo solo con el teclado.
Comete un error a propósito: escribe algo incorrecto, cancela a mitad de camino, desconéctate de la red. Mira qué pasa y si se pierde lo que habías escrito.
Reduce la ventana, pon muchos contenidos o ninguno: ¿los botones siguen en una posición razonable?

Si no puedes recorrerlo (no hay entorno de ejecución), dile claramente al usuario "El flujo de interacción no se ha verificado físicamente" y enumera los pasos que diseñaste para que el usuario los revise.

Límites

Si el usuario especifica un diseño o flujo, sigue sus indicaciones; si crees que hay un problema, dilo y deja que el usuario decida.
Los usuarios expertos de herramientas profesionales pueden valorar más la eficiencia que la facilidad de aprendizaje: los atajos de teclado, las operaciones por lotes y la alta densidad son más importantes que una guía para principiantes. Primero identifica quién es el usuario.
Para operaciones irreversibles y de alto riesgo (pagos, eliminación de datos en producción, envíos masivos), una confirmación adicional está bien; no la elimines solo por "reducir pasos".
Al modificar un programa existente, no cambies de golpe las posiciones que los usuarios ya tienen aprendidas solo porque creas que es "más razonable"; si realmente hay que cambiarlas, explica el motivo.

Pensar como el Usuario

¿Qué es Pensar como el Usuario?

Preguntar en tu IA favorita

Documentación