UX de producto centrada en tareas
Comienza con la situación del usuario y el resultado previsto. Los sistemas de diseño existentes, la investigación y los diseños proporcionados son evidencia; no los reemplaces con un panel genérico. Lee patrones y contraejemplos para el tipo de tarea relevante, no todos los patrones.
Antes de construir una pantalla
Para cada rol/tarea principal, identifica el desencadenante, la información ya conocida, las decisiones a tomar, el resultado de finalización y la ruta de recuperación. Separa los flujos de trabajo específicos de cada rol cuando sus decisiones difieran; comparte pantallas cuando la tarea y el contexto coincidan genuinamente.
Produce un flujo compacto y un diseño de baja fidelidad proporcional al cambio. Para cada estado de región visible:
- ¿Qué decisión o acción del usuario lo necesita ahora?
- ¿Es primario, detalle contextual o innecesario en esta vista?
- ¿Qué requisito, fuente o decisión de diseño explícita lo justifica?
Usa esto para seleccionar información, no para generar más copia de producto. No agregues automáticamente tarjetas de resumen, gráficos, banners, filtros, navegación, explicaciones de IA o paneles de “próximamente”. Una métrica pertenece cuando alguien toma una decisión relevante con ella. La procedencia técnica puede pertenecer cuando sea necesaria para juzgar la frescura o validez; los registros de depuración y el estado de implementación generalmente pertenecen a los registros de desarrollo.
No minimices a ciegas. Mantén las instrucciones de accesibilidad, errores significativos, contexto esencial, divulgaciones requeridas y consecuencias de decisiones. Una acción principal es un valor predeterminado útil, no un límite arbitrario de un botón. Evita ocultar acciones importantes detrás de menús genéricos únicamente para reducir los controles visibles.
Estado e interacción
Modela los estados relevantes: inicial, carga, vacío, error, éxito, edición/no guardado, resultado desactualizado y restricciones de permiso. Usa solo los estados que el producto necesita. Asegura que las entradas seleccionadas y los resultados mostrados se refieran al mismo contexto. Preserva el trabajo del usuario en errores recuperables. Elige acciones explícitas donde los cambios silenciosos sorprenderían al usuario.
Al seleccionar una superficie de edición o cambiar diseños con estado, lee selección de patrones de interacción. Elige edición en línea, un diálogo o una página dedicada según la complejidad de la tarea, frecuencia, necesidades de contexto y espacio disponible; no uses un modal simplemente para ocultar un error de diseño. Verifica la posición antes/después, el desplazamiento y el foco de los controles significativos. La divulgación intencional puede mover contenido; los saltos incidentales o los objetivos que desaparecen necesitan corrección.
Usa los tokens, componentes, lenguaje y convenciones de accesibilidad del proyecto. Inspecciona una referencia proporcionada a través de una herramienta compatible disponible; la falta de Figma MCP no es por sí misma una razón para detenerse. Nunca etiquetes un diseño no inspeccionado como coincidente. No introduzcas una nueva biblioteca de componentes solo para un cambio pequeño.
Verifica los nombres y descripciones accesibles en todos los estados válidos/error/recuperados, no solo la visibilidad visual y el foco. Un mensaje oculto aún puede exponerse cuando es referenciado por una descripción accesible; conecta el texto de error solo cuando el error aplique.
Revisa el flujo renderizado
Usa una herramienta de navegador o aplicación disponible para realizar la tarea desde su punto de entrada real. Inspecciona la estructura en busca de etiquetas y controles, y las capturas de pantalla renderizadas en busca de jerarquía, recorte, espaciado y estados visuales. Las comprobaciones automatizadas de accesibilidad o DOM por sí solas no prueban la calidad visual o de usabilidad.
Para comprobaciones responsivas, confirma las dimensiones reales del viewport del navegador e inspecciona la imagen capturada final. Recortar una captura de pantalla, cambiar el ancho de un elemento o verificar el desbordamiento horizontal por sí solo no es una prueba de viewport equivalente. Si la herramienta no puede establecer o verificar el viewport, marca esa cobertura como no verificada. Concilia la captura de pantalla con el resultado informado: el contenido faltante, el ajuste inutilizable o las acciones invisibles no se pueden llamar una aprobación visual simplemente porque una comprobación del DOM pasó.
Para cada hallazgo registra: reproducción → comportamiento observado → impacto en el usuario → corrección más pequeña y útil → reverificación. Etiqueta la inferencia por separado de la observación. Prefiere eliminar, mover, consolidar o mejorar los valores predeterminados antes de agregar explicaciones. No repitas una revisión aprobada a menos que los cambios o las preocupaciones restantes lo justifiquen.
Si el acceso al navegador no está disponible, revisa la evidencia de código/diseño y marca la UX en tiempo de ejecución como no verificada; continúa con el trabajo independiente. No fabriques capturas de pantalla, clics o validación de usuario. La revisión del desarrollador o agente no es un estudio de usuario.