Diseño de UX para Arquitectos
Guía para que arquitectos diseñen y revisen la UX de los puntos de contacto de usuario que no son UI (API / Configuración / Extensiones). No cubre el diseño de la interfaz gráfica (colores, diseño, etc.).
La UX no se limita a la UI, sino que abarca todos los puntos de contacto entre el sistema y el usuario. Una mala UX en estos puntos es difícil de cambiar posteriormente (porque los usuarios dependen de ello) y reduce la probabilidad de éxito del sistema. Por eso, se decide antes que la implementación.
Procedimiento
- Identificar el punto de contacto: El objetivo puede ser API, configuración o extensiones (o varios).
- Identificar al usuario (Principio 1): Quién, para qué y con qué nivel técnico lo utilizará.
- Leer la guía detallada correspondiente al punto de contacto:
- Configuración →
references/configuration.md - API →
references/api.md - Extensiones →
references/extensions.md
- Configuración →
- Evaluar con los 6 principios (abajo). Si se propone un diseño, incluir una breve justificación basada en los principios.
- Si es una revisión, señalar los hallazgos siguiendo el formato de
references/review-checklist.md. - Si hay puntos en disputa, confirmar con el usuario mediante una hipótesis (AskUserQuestion).
Los 6 Principios de UX
| # | Principio | Punto clave | Por qué |
|---|---|---|---|
| 1 | Comprender al usuario | Conocer objetivos, nivel técnico, modelo mental y flujo de trabajo típico para que funcione como se espera (principio de menor sorpresa) | Los usuarios actúan de manera diferente a lo previsto. Observar y medir es más efectivo que preguntar |
| 2 | Hacer lo mínimo necesario | Ofrecer solo las características necesarias. Adoptar estándares ampliamente utilizados (OAuth, OpenID, etc.) si existen | Todo lo que se ofrece se convierte en deuda. Una vez publicado, se vuelve familiar y difícil de cambiar |
| 3 | No requerir manuales | Hacer que el uso sea evidente y guiar con recomendaciones y pistas | Los usuarios no leen manuales. Si no pueden resolverlo, consideran que el producto es malo |
| 4 | Pensar en términos de intercambio de información | Evitar preguntar > preguntar poco > preguntar de forma fácil de responder. No preguntar lo mismo dos veces | Preguntar es una carga. Se puede reducir mediante suposición, memoria o deducción |
| 5 | Mantener lo simple simple | Eliminar barreras en las primeras operaciones. Proporcionar clientes preconfigurados o ejemplos | Los principiantes abandonan más fácilmente. La primera experiencia determina la retención |
| 6 | Diseñar la UX antes que la implementación | Diseñar la UX antes que la arquitectura, refinándola con retroalimentación | Cambiar la UX después de la implementación es costoso. Retrasar la implementación, profundizar el diseño |
Cómo decidir cuándo preguntar (concreción del Principio 4)
Pensar en orden de prioridad:
- No preguntar: Valores predeterminados razonables, detección automática del entorno, recordar entradas anteriores, deducir de información conocida
- Preguntar poco: Solo lo estrictamente necesario
- Preguntar de forma fácil de responder: Preguntar en términos que el usuario pueda responder sin cálculos mentales, no en términos de implementación interna (por ejemplo: en lugar de "número máximo de entradas en caché", preguntar "límite de memoria para la caché", o derivar los detalles a partir de una selección de modo como "servidor o cliente")
Al devolver resultados o respuestas (Principio 4)
A menos que haya problemas de rendimiento, devolver suficiente información en un formato comprensible para que el usuario pueda predecir el siguiente paso. Si el resultado de una llamada se pasa a la siguiente, minimizar el procesamiento necesario para que se pueda pasar directamente.
Resumen por punto de contacto
- Configuración: La mejor opción es no introducir configuración. La siguiente mejor es la determinación automática y, por último, introducirla con un valor predeterminado razonable. La pregunta es: "¿El usuario tiene mejor contexto que nosotros?" — Solo si la respuesta es "Sí", se debe usar configuración. No ignorar claves desconocidas ni fallos de aplicación; generar un error. Verificar los valores de configuración válidos en el inicio.
- API: El usuario es un desarrollador. La API debe ser fácil de aprender, difícil de usar incorrectamente y siempre debe dejar claro el siguiente paso. Hacer una sola cosa bien. No obligar a escribir código repetitivo. Adherirse a los estándares. Versionar desde el principio. Retrasar la publicación hasta que sea necesaria; primero usarla internamente.
- Extensiones: Esperar hasta comprender profundamente el caso de uso antes de añadirlas (se pueden agregar más tarde mediante refactorización). Hacer una sola cosa bien. Definir entradas y salidas sin exponer la estructura interna. Una vez publicadas, son difíciles de cambiar.
Errores comunes (sospechar durante el diseño o la revisión)
- Falta de experiencia en UX o incorporación tardía de expertos
- Centrarse solo en la UI y descuidar la UX de APIs, configuraciones y extensiones
- Que el líder técnico decida la UX y pida al experto solo ajustes finos de la UI
- Ignorar las propuestas del experto
- Dudar entre dos opciones y optar por la configuración como escape (trasladar el problema al usuario)
Si no hay un experto disponible, indicarlo explícitamente y recomendar involucrar a un experto en UX en una etapa temprana. Sin embargo, no detener el diseño por falta de asesoramiento; ofrecer una propuesta provisional basada en esta guía.
Conexión con el proceso iterativo
- Derivar el diseño del journey del usuario → Aplicar esta guía a cada punto de contacto del journey
- Iterar en cortes → Crear solo los puntos de contacto necesarios en el primer corte (las APIs públicas y las extensiones suelen poder dejarse para después del MVP)
- Diseñar en profundidad y lentamente lo que es difícil de cambiar, e implementar de forma gradual → La UX es un ejemplo representativo. Aprender observando el uso real
Formato de salida
Propuesta de diseño: Breve, en el orden: "Punto de contacto → Perfil de usuario → Propuesta → Principio y razón aplicables → Puntos pendientes".
Revisión: En el formato de references/review-checklist.md.