Dark patterns: tipos, ejemplos peruanos, cómo evitarlos
💡 Sobre este dashboard
Basado en el material de clase del Dr. Juan Orlando Salazar Campos — USIL, Facultad de Ingeniería e IA, 2026-1. Todos los casos prácticos están contextualizados en el mercado peruano: apps financieras, plataformas de delivery, portales del Estado y empresas de retail.
Temas › Tema 01
🖼️ Tema 01
Prototipos de Interfaz de Usuario
Tipos de prototipos, propósito del prototipado y cómo elegir el tipo correcto según el contexto del proyecto.
ISO 9241-210FidelidadEvolutivo vs DesechableHorizontal vs Vertical
¿Qué es un prototipo?
Definición oficial y distinción con el boceto
📌 Definición ISO 9241-210:2019
Un prototipo es una representación de todo o parte de un sistema interactivo que, aunque limitado, puede usarse para análisis, diseño y evaluación. Debe ser algo que el usuario pueda entender e interactuar de alguna manera.
⚠️ ¡Un boceto NO es un prototipo!
Un boceto (sketch) es un dibujo a mano que el diseñador crea como parte de su proceso privado. No está pensado para ser evaluado con usuarios. Un prototipo, en cambio, está diseñado explícitamente para ser testeado.
Tipos de prototipos
Dimensiones para clasificar los prototipos según su propósito
Escala de fidelidad
← Baja fidelidadAlta fidelidad →
📄
Prototipo en papel
Dibujado a mano o impreso. Rápido, barato, ideal para exploración temprana. El "probador de papel" simula la interacción.
Baja fidelidad
🔁
Prototipo evolutivo
La misma base de código se expande gradualmente. Se convierte en el producto final. Ideal cuando los requisitos son claros.
Ciclo de vida largo
🗑️
Prototipo desechable
Se crea para un experimento específico y luego se descarta. Permite explorar sin miedo a comprometerse con malas decisiones.
Experimentación
↔️
Prototipo horizontal
Muestra toda la amplitud del producto sin profundidad. Útil para demostrar el alcance completo de las funciones al cliente.
Amplitud
↕️
Prototipo vertical
Profundiza en una funcionalidad específica con alta interactividad. Ideal para testear un flujo crítico con detalle.
Profundidad
🖱️
Prototipo interactivo
Permite navegar, hacer clic e interactuar. Prueba secuencias de páginas e interacciones complejas. Herramientas: Figma, ProtoPie.
Alta interactividad
Propósito del prototipado
1
Definir objetivos
¿Qué aprenderemos con este prototipo?
→
2
Elegir tipo
Papel, digital, evolutivo, desechable
→
3
Crear múltiples
¡Siempre más de un prototipo!
→
4
Evaluar con usuarios
Testing, feedback, iteración
→
5
Aprender y avanzar
Hacia el sistema final
Tabla comparativa de tipos
Tipo
Fidelidad
Costo
Tiempo
Mejor para
Papel / Boceto
Muy baja
Mínimo
1-2 h
Exploración de conceptos, etapas tempranas
Wireframe
Baja-Media
Bajo
1-3 días
Flujos de navegación, arquitectura
Mockup
Alta (estático)
Medio
3-7 días
Aprobación visual del cliente
Prototipo interactivo
Alta
Medio-Alto
1-2 semanas
Testing de usabilidad, demos
Prototipo en código
Muy alta
Alto
2-4 semanas
Validación técnica, beta cerrada
Casos prácticos
Ejercicios contextualizados en el mercado peruano
📱 App de delivery en Lima — Elección de prototipo Identificación
▼
Contexto
Una startup de delivery de comida en Lima quiere lanzar su app en 3 meses. El equipo tiene 2 diseñadores y 3 desarrolladores. No tienen claridad en qué tipo de menú de categorías prefieren los usuarios: ¿scroll horizontal con íconos o lista vertical con búsqueda?
Preguntas:
¿Qué tipo de prototipo recomendarías? ¿Por qué?
¿Qué nivel de fidelidad necesitas para responder la pregunta de diseño?
¿Cuántas variantes crearías y por qué?
✅ Resolución
1. Tipo: Prototipo desechable + comparativo. Como la pregunta es específica (menú horizontal vs vertical), se crea un prototipo desechable por cada variante para descartarla o avanzarla. No se necesita código de producción.
2. Fidelidad: Media-baja. No se necesitan colores finales ni imágenes reales. El wireframe interactivo en Figma es suficiente para que el usuario navegue y decida.
3. Variantes: Mínimo 2 (una por cada opción de menú). Idealmente 3 (agregar una variante híbrida con tabs). Siempre más de un prototipo para comparación.
🏥 Portal ESSALUD — Prototipo horizontal vs vertical Análisis
▼
Contexto
El equipo de digitalización de ESSALUD está diseñando un portal que permita: agendar citas, ver resultados de laboratorio, pagar deudas de seguro y descargar el carnet virtual. Tienen 4 semanas para presentar al directorio.
Preguntas:
¿Usarías un prototipo horizontal o vertical para la presentación al directorio?
¿Y para validar con pacientes el flujo de agendamiento?
¿Por qué usarías tipos diferentes en cada caso?
✅ Resolución
1. Para directorio → Horizontal: El directorio quiere ver el alcance del producto: las 4 funcionalidades. Un prototipo horizontal muestra todas las pantallas principales sin necesidad de que cada flujo esté completo.
2. Para pacientes → Vertical: Para validar el agendamiento, necesitas que ese flujo específico esté completamente funcional: selección de especialidad, disponibilidad, confirmación y notificación. Profundidad total en una función.
3. Porque cada audiencia tiene diferente objetivo: El directorio evalúa estrategia (amplitud); el usuario evalúa experiencia (profundidad).
🏦 BCP Móvil — Evolutivo vs Desechable Diseño
▼
Contexto
BCP está añadiendo biometría facial al login. El equipo debe decidir: ¿construir la funcionalidad directamente sobre la app existente (evolutivo) o crear un módulo separado para experimento (desechable)?
Preguntas:
¿Cuál de los dos enfoques elegirías y por qué?
¿Qué riesgos evita el prototipo desechable en este caso?
✅ Resolución
Respuesta: Desechable primero. Antes de tocar la app de producción del banco (usada por millones), se crea un módulo de prueba separado con la biometría facial. Se testea con 50-100 usuarios. Si falla el reconocimiento en usuarios mayores o con barba, no se afecta la app real.
Riesgos que evita: No contaminar el código estable de producción, no generar errores para usuarios activos, y no comprometer la seguridad de una funcionalidad bancaria no validada.
🎮 Simulador: ¿Qué prototipo necesito?
Ingresa el contexto de tu proyecto y el simulador te recomendará el tipo de prototipo, fidelidad y herramienta más adecuada.
Preguntas frecuentes
¿Es obligatorio siempre tener más de un prototipo?+
No es técnicamente obligatorio, pero sí es una buena práctica. El curso enfatiza que siempre debemos crear prototipos alternativos para poder comparar opciones. Un solo prototipo no permite elegir: solo confirma lo que ya pensabas.
¿Cuándo dejo de hacer prototipos y empiezo el desarrollo real?+
Cuando hayas aprendido lo suficiente para tomar decisiones de diseño con confianza. El criterio no es tiempo sino aprendizaje: cuando las pruebas con usuarios dejan de revelar problemas nuevos significativos, es hora de construir.
¿Figma hace prototipos evolutivos o desechables?+
Figma puede hacer ambos. En la práctica, los prototipos en Figma son desechables: nadie lleva el Figma a producción directamente. El código que escribe el desarrollador es el prototipo evolutivo. La distinción se aplica principalmente al código de software.
¿La fidelidad del prototipo afecta la calidad del feedback de los usuarios?+
Sí. Con prototipos de baja fidelidad, los usuarios comentan sobre flujos y estructura. Con alta fidelidad, los usuarios se distraen con colores, tipografías y detalles visuales. La fidelidad debe ser la mínima necesaria para responder la pregunta de diseño.
¿Un wireframe es un prototipo?+
Depende. Un wireframe estático es más un boceto digital que un prototipo. Un wireframe interactivo (con navegación entre pantallas) sí es un prototipo de baja-media fidelidad, según la definición ISO que establece que el usuario debe poder interactuar con él.
Temas › Tema 02
🔍 Tema 02
Evaluación de Usabilidad
Métodos para evaluar la usabilidad: inspección heurística con las 10 heurísticas de Nielsen y pruebas con usuarios reales.
10 HeurísticasNielsen 1994InspecciónTesting
Las 10 Heurísticas de Nielsen
Principios de Jakob Nielsen (1994) para la evaluación de interfaces
H01
Visibilidad del estado del sistema
El sistema siempre debe informar al usuario lo que está ocurriendo mediante retroalimentación apropiada.
✏️ Barra de progreso en descarga de archivos
H02
Correspondencia con el mundo real
El sistema debe hablar el lenguaje del usuario: palabras, frases y conceptos familiares, no jerga técnica.
✏️ "Enviar al basurero" en lugar de "delete /tmp"
H03
Control y libertad del usuario
Los usuarios cometen errores y necesitan "salida de emergencia" clara para deshacer y rehacer acciones.
✏️ Botón "Deshacer" siempre visible
H04
Consistencia y estándares
Los usuarios no deben preguntarse si diferentes palabras, situaciones o acciones significan lo mismo.
✏️ Siempre usar "Guardar" (nunca "Salvar")
H05
Prevención de errores
Mejor que un buen mensaje de error es un diseño cuidadoso que evite que ocurra el problema.
✏️ Confirmar antes de borrar archivos
H06
Reconocimiento antes que recuerdo
Minimizar la carga de memoria del usuario. Objetos, acciones y opciones deben ser visibles.
✏️ Mostrar historial de búsqueda reciente
H07
Flexibilidad y eficiencia de uso
Aceleradores —invisibles para novatos— permiten al usuario experto realizar acciones más rápido.
✏️ Atajos de teclado Ctrl+Z, Ctrl+S
H08
Diseño estético y minimalista
Los diálogos no deben contener información irrelevante. Cada unidad extra compite con información relevante.
✏️ Eliminar banners publicitarios del flujo de pago
H09
Ayudar a reconocer y recuperarse de errores
Los mensajes de error deben expresarse en lenguaje sencillo e indicar constructivamente la solución.
✏️ "La contraseña debe tener 8+ caracteres" vs "Error 403"
H10
Ayuda y documentación
Aunque lo ideal es no necesitar doc, puede ser necesario. Debe ser fácil de buscar y orientada a la tarea.
Contexto Eres evaluador UX contratado por Interbank. Al revisar el flujo de transferencia, observas que: (1) el botón "Confirmar" aparece sin resumen del monto, (2) no hay opción de "Cancelar" visible, (3) el mensaje de éxito dura solo 1 segundo.
Identifica las heurísticas violadas para cada problema:
Botón Confirmar sin resumen
No hay opción Cancelar
Mensaje de éxito dura 1 segundo
✅ Resolución
1. Viola H06 (Reconocimiento antes que recuerdo): el usuario debe recordar el monto ingresado en pantalla anterior. Solución: mostrar resumen completo antes de confirmar.
2. Viola H03 (Control y libertad del usuario): el usuario no tiene salida de emergencia visible. Solución: botón "Cancelar" siempre junto a "Confirmar".
3. Viola H01 (Visibilidad del estado del sistema): 1 segundo es insuficiente para que el usuario procese la confirmación. Solución: mensaje persistente con checkmark verde por ≥3 segundos.
🛍️ Saga Falabella — Checkout y carrito Análisis
▼
Contexto Durante una prueba de usabilidad en el portal de Saga Falabella con 5 usuarios peruanos, 4 de 5 abandonaron en el paso 3 de 5 del checkout porque: no entendían "¿Confirmar despacho o recojo en tienda?", el formulario pedía RUC para personas naturales, y los errores mostraban "Error en campo #7".
Analiza:
¿Qué heurísticas se violan?
¿Por qué una inspección heurística habría detectado estos problemas antes del testing?
✅ Resolución
Heurísticas violadas: • H02: "Despacho" es jerga logística, no lenguaje del usuario ("Envío a domicilio" es más claro). • H05: Pedir RUC a una persona natural es un error de diseño prevenible con una validación previa. • H09: "Error en campo #7" no ayuda a recuperarse. Debería decir "Ingresa tu DNI de 8 dígitos".
Por qué la inspección habría ayudado: Un experto revisando contra estas heurísticas habría marcado los tres problemas sin gastar el tiempo y presupuesto de reclutar 5 usuarios. El testing luego confirma que el impacto es real.
✅ Checklist de Evaluación Heurística
Marca las heurísticas donde detectas violaciones en la interfaz que estás evaluando. El sistema calculará un score de usabilidad.
Preguntas frecuentes
¿Cuántos evaluadores se necesitan para una inspección heurística?+
Nielsen recomienda entre 3 y 5 evaluadores. Con menos de 3 se pierden muchos problemas; con más de 5, el retorno marginal cae drásticamente (el 5° evaluador ya encontró el 75% de los problemas que encontrará el 10°).
¿Se pueden usar las heurísticas en apps móviles o solo en web?+
Las heurísticas son agnósticas del medio. Aplican a web, móvil, software de escritorio, sistemas embebidos (pantallas de cajeros automáticos, kioscos) e incluso interfaces de voz. Lo que cambia son los ejemplos de aplicación, no el principio.
¿Es lo mismo "usabilidad" que "UX"?+
No. La usabilidad es un componente de la UX: se refiere a la eficacia, eficiencia y satisfacción al usar el sistema. La UX (Experiencia de Usuario) es más amplia: incluye emociones, expectativas, accesibilidad, identidad de marca y la experiencia fuera del sistema (entrega, soporte, etc.).
¿Cuántos usuarios se necesitan para una prueba de usabilidad?+
Nielsen estableció que con 5 usuarios se detectan el 85% de los problemas de usabilidad. Más allá, los problemas se repiten. Para cuantificar o comparar estadísticamente, se necesitan más (20-30+), pero para identificar y mejorar, 5 es suficiente en cada iteración.
Temas › Tema 03
🔄 Tema 03
UX y Procesos de Proyecto
Cómo integrar el diseño centrado en el usuario con metodologías ágiles, Design Thinking y Design Sprint.
Sintetizar hallazgos, personas, journey maps, definir el problema
→
3
Idear
Generar múltiples soluciones, explorar sin juzgar
→
4
Prototipar
Construir representaciones testables de las mejores ideas
→
5
Evaluar
Testear con usuarios, aprender, iterar desde el paso 1
UX + Ágil/SCRUM
Elemento SCRUM
Equivalente UX
Cómo integrarlo
Product Backlog
Investigación de usuarios
User stories basadas en necesidades reales descubiertas en research
Sprint Planning
Definición de objetivos de diseño
¿Qué hipótesis de diseño validaremos este sprint?
Sprint (2 semanas)
Prototipo + evaluación
Diseñar, prototipar y testear dentro del mismo sprint
Sprint Review
Presentación a stakeholders
Mostrar prototipos con feedback de usuarios reales
Retrospective
Aprendizaje de diseño
¿Qué aprendimos de los usuarios? ¿Cómo mejoramos el proceso?
Design Sprint (Google Ventures)
L
Lunes
Mapear el problema y elegir el objetivo
→
M
Martes
Esbozar soluciones individualmente
→
X
Miércoles
Decidir la mejor solución
→
J
Jueves
Construir el prototipo realista
→
V
Viernes
Testear con 5 usuarios reales
🎯 Ventaja del Design Sprint: En solo 5 días se valida una hipótesis que normalmente tomaría meses de desarrollo. Se evita construir algo que nadie quiere.
Casos prácticos — Procesos UX
💳 Fintech limeña — UX + SCRUM Diseño
▼
Contexto Una fintech de Lima con 12 personas usa SCRUM de 2 semanas. El equipo de desarrollo se queja de que "diseño siempre llega tarde". El diseñador entrega mockups el día 10 del sprint y los devs solo tienen 4 días para implementar.
¿Cuál es el problema de proceso en este equipo?
¿Cómo reorganizarías el trabajo de UX dentro del sprint?
✅ Resolución
Problema: El diseño trabaja en paralelo al sprint en vez de ir adelantado. No hay "Sprint 0 de diseño" ni diseño por adelantado (design ahead).
Reorganización: El diseñador trabaja con un sprint de adelanto. Mientras dev implementa el sprint N, diseño está trabajando en el sprint N+1. Los mockups se aprueban al final del sprint anterior, dando a dev los 10 días completos para implementar.
🏛️ SUNAT — Design Sprint aplicado Análisis
▼
Contexto SUNAT quiere mejorar la declaración mensual del IGV para pequeños negocios. Los usuarios actuales abandonan el proceso en el paso 4 de 7. La gerencia propone "rediseñar todo el portal en 6 meses". Un consultor UX propone un Design Sprint primero.
¿Qué ventaja ofrece el Design Sprint sobre rediseñar en 6 meses?
¿Qué pregunta específica validarías con el prototipo del jueves?
✅ Resolución
1. Ventaja: En 5 días se puede validar si la hipótesis de rediseño es correcta antes de invertir 6 meses de presupuesto estatal. Si el prototipo del sprint falla con usuarios, se redirige sin perder tiempo.
2. Pregunta a validar: "¿Si simplificamos el paso 4 (cálculo de IGV) mostrando el monto pre-calculado en base al RUC, los usuarios completan el proceso sin abandono?" — Hipótesis específica, testeable en 1 hora con 5 pequeños empresarios.
Modelo de Madurez UX
Los 5 niveles de madurez de una organización respecto a UX
1
Nivel 1
Ausente
No hay procesos de UX. El diseño lo hace el desarrollador. No hay investigación de usuarios.
2
Nivel 2
Limitado
UX reactivo: se evalúa después del desarrollo. No hay proceso sistemático. El diseño es cosmético.
3
Nivel 3
Emergente
Hay diseñadores UX. Se hacen algunas pruebas. El equipo reconoce el valor del UX pero no es sistemático.
4
Nivel 4
Estructurado
Proceso DCU integrado al ciclo de desarrollo. Research regular. Métricas de usabilidad definidas.
5
Nivel 5
Estratégico
UX es parte de la estrategia de negocio. Cultura centrada en usuario. Decisiones basadas en datos de comportamiento. Aprendizaje continuo.
🇵🇪 Contexto peruano: La mayoría de empresas peruanas se encuentran en los niveles 2-3. Empresas de alto crecimiento como Yape, Rappi o Rímac Seguros están alcanzando el nivel 4.
Preguntas frecuentes
¿Design Thinking y Design Sprint son lo mismo?+
No. Design Thinking es un enfoque filosófico y metodológico amplio (empatizar, definir, idear, prototipar, testear) que puede aplicarse en semanas o meses. El Design Sprint es una implementación específica y comprimida de GV que se ejecuta en exactamente 5 días con un equipo de 7 personas.
¿SCRUM y UX son incompatibles?+
No, pero requieren coordinación. El problema clásico es que SCRUM está optimizado para el desarrollo iterativo, pero el diseño de UX necesita tiempo de investigación y validación que no siempre cabe en un sprint de 2 semanas. La solución más común es que diseño vaya 1 sprint adelante al desarrollo.
¿Qué es una "persona" en UX?+
Una persona es un arquetipo de usuario basado en datos de investigación real (entrevistas, observación). No es una persona real sino una representación que sintetiza patrones de comportamiento, motivaciones, frustraciones y contexto de un segmento de usuarios. Se usa para anclar las decisiones de diseño.
¿DCU aplica solo a interfaces digitales?+
No. El DCU (Diseño Centrado en el Usuario) aplica a cualquier artefacto que las personas usan: mobiliario, vehículos, señalética, servicios físicos. La ISO 9241-210 aplica a "sistemas interactivos" que incluyen hardware, software y servicios combinados.
Temas › Tema 04
⚠️ Tema 04
Errores Humanos y el Diseño
Taxonomía de errores, análisis de causa raíz con los 5 Porqués y diseño de mecanismos de recuperación.
Slips & Lapses5 PorquésCausa raízRecuperación
Taxonomía de errores humanos
Cuatro tipos de error según su naturaleza y origen
Tipo 1
Desliz (Slip)
Error de acción observable: la persona sabe qué hacer pero ejecuta la acción incorrecta. Sucede automáticamente, sin intención.
🇵🇪 Ejemplo: Presionar "Enviar" en vez de "Guardar borrador" en correo corporativo peruano.
Tipo 2
Lapsus (Lapse)
Error de memoria: la persona olvida lo que iba a hacer. El fallo ocurre internamente, no en la ejecución.
🇵🇪 Ejemplo: Olvidar adjuntar el RUC en el formulario de SUNAT porque el sistema no lo recuerda entre sesiones.
Tipo 3
Error basado en reglas
La persona aplica una regla correcta al contexto incorrecto, o aplica una regla incorrecta. El diagnóstico del problema está equivocado.
🇵🇪 Ejemplo: Usar la ruta de "devolución de compra" para cancelar una suscripción (regla equivocada para el contexto).
Tipo 4
Error basado en conocimiento
La persona enfrenta una situación nueva sin reglas ni rutinas. Actúa desde cero con información incompleta.
🇵🇪 Ejemplo: Un adulto mayor usando por primera vez el app de Yape sin experiencia previa con billeteras digitales.
Análisis de causa raíz — Los 5 Porqués
📌 Técnica: Preguntar "¿Por qué?" de forma encadenada, típicamente 5 veces, hasta llegar a la causa fundamental (no al síntoma superficial).
⚠️ Error común: Detenerse en el primer "¿por qué?" y tratar el síntoma como causa raíz. El diseño resultante solo arregla la superficie sin resolver el problema real.
Mecanismos de recuperación de errores
↩️
Deshacer (Undo)
Permitir revertir acciones. El estándar más efectivo de recuperación. Ctrl+Z en desktop, swipe en móvil.
⚠️
Confirmación previa
Preguntar "¿Estás seguro?" antes de acciones irreversibles. Usar solo cuando el costo del error es alto.
💾
Guardado automático
El sistema guarda el estado periódicamente. El usuario no pierde trabajo aunque cierre accidentalmente.
📋
Papelera / Archivo
Los elementos eliminados no desaparecen inmediatamente. Van a un estado intermedio recuperable.
Casos prácticos — Errores y diseño
🏛️ RENIEC — Portal con formularios complejos Evaluación
▼
Contexto El portal de RENIEC para emisión de DNI electrónico tiene un formulario de 12 pasos. En el paso 8, el sistema muestra "Error: datos inconsistentes" y devuelve al usuario al paso 1, perdiendo toda la información ingresada.
¿Qué tipo de error humano provoca esta situación?
¿Qué mecanismos de recuperación implementarías?
Aplica los 5 Porqués para identificar la causa raíz del problema de diseño.
✅ Resolución
1. Tipo de error: Combinación de lapsus (el usuario olvidó o ingresó mal un dato en un paso anterior) + error basado en conocimiento (no sabe qué dato es "inconsistente").
2. Mecanismos de recuperación: • Guardado automático por paso: nunca perder lo que ya se ingresó. • Señalar EXACTAMENTE qué campo tiene el error (no "datos inconsistentes" genérico). • Permitir navegar hacia atrás sin perder el estado.
3. Los 5 Porqués: ❓ El usuario pierde sus datos ← ❓ El sistema reinicia al paso 1 en error ← ❓ La validación solo ocurre al final ← ❓ El arquitecto de software no recibió requisitos de UX ← ❓ No hubo participación de diseño UX en la etapa de arquitectura ← 🎯 Causa raíz: UX no participó desde el inicio del proyecto.
🛵 App de delivery — Pedido con dirección incorrecta Análisis
▼
Contexto Una app de delivery limeña recibe 200 reclamos semanales de pedidos enviados a la dirección incorrecta. El 60% son direcciones del trabajo que el usuario guardó como "Casa".
¿Qué tipo de error (slip, lapse, basado en reglas) cometen los usuarios?
¿Qué decisión de diseño provoca el error?
¿Cómo lo rediseñarías?
✅ Resolución
1. Tipo: Desliz (slip) + lapsus. El usuario selecciona "Casa" automáticamente (hábito) sin verificar. El sistema no le recuerda qué dirección está seleccionada.
2. Causa en el diseño: El resumen del pedido no muestra la dirección de entrega de forma prominente. El usuario asume que está enviando a casa.
3. Rediseño: • Mostrar dirección de entrega en grande en el resumen ANTES de confirmar. • Agregar "¿Este es tu destino?" con mapa mini + confirmación con un toque. • Si el GPS detecta que el usuario está en una ubicación diferente a la seleccionada, preguntar: "¿Enviar a tu ubicación actual o a la guardada?"
🔍 Simulador: Análisis de los 5 Porqués
Ingresa un problema de UX real o ficticio y el simulador generará un análisis encadenado de causa raíz. Útil para ejercitar el pensamiento analítico.
Preguntas frecuentes
¿El diseño puede eliminar todos los errores humanos?+
No. Los errores son inherentes a la cognición humana. El diseño puede minimizarlos (prevención) y facilitar la recuperación cuando ocurren, pero no eliminarlos completamente. El objetivo es que los errores sean baratos: fáciles de detectar y fáciles de revertir.
¿Siempre se necesitan exactamente 5 "porqués"?+
No. El número 5 es una guía, no una regla rígida. A veces la causa raíz aparece en el tercer porqué; otras requiere 7. Lo importante es seguir preguntando hasta que la respuesta revele algo accionable que el equipo pueda cambiar, no seguir llegando a "el usuario cometió un error".
¿La confirmación ("¿Estás seguro?") siempre mejora la UX?+
No. Las confirmaciones constantes generan "fatiga de alerta": el usuario aprende a hacer clic en "Sí" automáticamente sin leer. Solo usar confirmación para acciones irreversibles con consecuencias serias (borrar una cuenta, enviar datos bancarios). Para acciones reversibles, mejor Undo.
¿Los errores basados en conocimiento son culpa del usuario?+
No. Es una máxima del DCU: "El usuario nunca está equivocado". Si muchos usuarios cometen el mismo error de conocimiento, el problema es del diseño, no del usuario. El diseño debe anticipar las limitaciones cognitivas y el nivel de expertise del usuario objetivo.
Temas › Tema 05
💼 Tema 05
Diseño en el Mundo de los Negocios
Estrategias competitivas, innovación incremental vs radical y las obligaciones morales del diseñador.
EstrategiaInnovaciónÉtica del diseñoCompetitividad
Fuerzas competitivas en diseño
Las tres dimensiones en las que el diseño puede competir
💰
Precio
Diseño que reduce el costo percibido o real del producto. Simplicidad que elimina funciones innecesarias que encarecen el desarrollo.
Yape vs transferencias bancarias
⭐
Características
Diferenciación por funcionalidades únicas o experiencias que la competencia no ofrece. La feature es la ventaja.
Pago QR en todo el Perú
🏆
Calidad percibida
El diseño crea la percepción de superioridad. Un producto idéntico se percibe mejor si la experiencia de uso es más fluida.
BCP Premium vs banca digital
Innovación: Incremental vs Radical
Dimensión
Incremental
Radical
Definición
Mejora progresiva de lo existente
Crea una categoría o mercado nuevo
Riesgo
Bajo
Alto
Inversión
Moderada
Alta
Impacto en UX
Mejora flujos existentes
Rediseña la experiencia completa
Ejemplo peruano
Yape agrega pagos QR internacionales
Yape mismo (pagos sin cuenta bancaria)
Tiempo al mercado
Rápido (semanas-meses)
Lento (años)
Obligaciones morales del diseño
🌍
Responsabilidad social
El diseño que llega a millones de personas tiene consecuencias sociales masivas. Considerar grupos vulnerables.
♿
Accesibilidad
Diseñar para todos, incluyendo personas con discapacidades visuales, auditivas, motoras o cognitivas.
🔒
Privacidad por diseño
Proteger los datos del usuario como valor predeterminado, no como opción. Privacy by default.
🌱
Sostenibilidad
El diseño digital tiene huella de carbono. Considerar el impacto ambiental de las decisiones tecnológicas.
Casos prácticos — Negocios y diseño
💳 BCP vs Yape — Estrategia competitiva en UX Análisis
▼
Contexto Yape tiene más de 14 millones de usuarios en Perú y su app tiene un NPS altísimo. El BCP, banco que creó Yape, ahora ve cómo su app bancaria tradicional pierde preferencia entre jóvenes.
Comparativa de fortalezas competitivas
Facilidad de uso
Yape 95
Facilidad de uso
BCP 60
Funciones avanzadas
Yape 40
Funciones avanzadas
BCP 95
Confianza percibida
Yape 80
Confianza percibida
BCP 90
Analiza:
¿En qué fuerza competitiva (precio, características, calidad) gana cada app?
¿Qué tipo de innovación usó Yape para disrumpir?
✅ Resolución
1. Yape gana en calidad percibida (fluidez, simplicidad). BCP gana en características (más funciones bancarias). Ambas compiten en precio (gratuitas).
2. Yape fue innovación radical al principio: creó el mercado de billeteras digitales sin cuenta bancaria en Perú. Hoy sus actualizaciones (QR internacional, cobros para negocios) son innovación incremental.
🧠 App de bienestar mental — Diseño con ética Diseño
▼
Contexto Una startup peruana desarrolla una app de meditación y bienestar mental para universitarios. En la reunión estratégica, el CEO propone: (1) notificaciones push cada 2 horas, (2) gamificación con racha diaria que se pierde si fallas un día, (3) acceso premium para las funciones más efectivas.
¿Qué decisión de diseño viola obligaciones morales?
¿Cómo rediseñarías respetando la ética?
✅ Resolución
1. Notificaciones cada 2h generan ansiedad (opuesto al propósito). La racha que "se pierde" crea culpa y estrés en usuarios vulnerables. Ocultar las funciones más efectivas tras paywall es éticamente problemático para una app de salud mental.
2. Rediseño ético: • Notificaciones: solo a la hora que el usuario elige, máximo 1/día. • Gamificación compasiva: la racha se "pausa" en días difíciles, no se rompe. • Modelo de precios: las funciones básicas de bienestar son gratuitas; las funciones de seguimiento avanzado son premium. Los criterios de salud mental no pueden estar detrás de paywall.
📊 Simulador: Estrategia de Innovación
Selecciona un tipo de innovación y un sector de mercado peruano para ver un caso de análisis estratégico con decisiones de diseño.
Preguntas frecuentes
¿La innovación radical siempre es mejor que la incremental?+
No. La innovación radical tiene altísimo riesgo y muy bajo porcentaje de éxito. La mayoría de empresas exitosas combinan: innovación incremental para el negocio actual y un portfolio pequeño de apuestas radicales. Google Maps es incremental; Google Street View fue radical.
¿El diseñador tiene responsabilidad si su producto causa daño?+
Sí. El diseñador tiene responsabilidad profesional y moral. No es excusa decir "solo seguí instrucciones del cliente". Los diseñadores de tabacaleras, redes sociales adictivas o interfaces que extraen datos sin consentimiento son cómplices del daño causado. Las organizaciones de diseño (IDEO, AIGA) tienen códigos de ética.
¿Cómo se mide el impacto del diseño en los negocios?+
Métricas comunes: NPS (Net Promoter Score), tasa de conversión, tasa de abandono de flujo, tiempo de completación de tarea, costo de soporte por sesión (si la UI es confusa, los usuarios llaman más). Empresas como Forrester Research cuantifican el ROI del diseño en miles de empresas.
¿La accesibilidad es solo para personas con discapacidades?+
No. La accesibilidad beneficia a todos. Los subtítulos en video nacieron para personas sordas pero son usados por millones en ambientes ruidosos. El alto contraste diseñado para baja visión ayuda en pantallas bajo luz solar. El diseño accesible es buen diseño para todos.
Temas › Tema 06
🕶️ Tema 06
Patrones Oscuros en UX
Dark patterns: técnicas de diseño engañoso, tipos más comunes, ejemplos peruanos y cómo detectarlos y evitarlos.
Dark PatternsManipulaciónÉtica UXCostos ocultos
¿Qué son los dark patterns?
🕶️ Definición: Los dark patterns (patrones oscuros) son decisiones de diseño intencionalmente engañosas que llevan al usuario a realizar acciones que benefician al negocio pero perjudican al usuario: suscripciones no deseadas, cargos ocultos, dificultad para cancelar, etc.
Taxonomía de dark patterns
🪤
Cebo y Cambio
Se anuncia una oferta o producto y se entrega otro diferente o inferior cuando el usuario ya invirtió tiempo.
Severidad: Alta
💸
Costos Ocultos
Precio bajo mostrado al inicio; cargos adicionales aparecen solo al finalizar el checkout. Impuestos, "tarifa de servicio", seguros obligatorios.
Severidad: Alta
🏨
Continuidad Forzada
Fácil suscribirse, casi imposible cancelar. El botón de cancelar exige llamar por teléfono o enviar carta.
Severidad: Alta
😔
Confirmshaming
El botón de rechazo usa lenguaje que avergüenza: "No, prefiero pagar más caro" en lugar de "No, gracias".
Severidad: Media
👁️
Privacy Zuckering
Se confunde al usuario para compartir más datos de los que pretendía. Configuración de privacidad laberíntica con opciones predeterminadas que lo comparten todo.
Severidad: Alta
⏱️
Falsa Urgencia
Contadores falsos, "¡Solo quedan 2!" cuando hay miles en stock. Genera presión de tiempo artificial para impedir comparación.
Severidad: Media
Impacto legal y ético
⚖️ Marco legal: La Unión Europea penaliza los dark patterns bajo el Digital Services Act (DSA). En Perú, INDECOPI puede sancionar prácticas engañosas bajo el Código de Protección al Consumidor. Más allá de la ley, los dark patterns destruyen la confianza a largo plazo.
Casos prácticos — Dark patterns
✈️ Aerolínea peruana — Costos ocultos en checkout Evaluación
▼
Contexto Una aerolínea low-cost que opera en el Perú muestra vuelos desde S/79 en su buscador. Al llegar al paso 4 de 5 del checkout, el precio es S/147 (se añadió: "tarifa de administración" S/18, "seguro de equipaje básico" S/25 preseleccionado, "cargo de emisión" S/25).
¿Qué dark patterns identificas?
¿Cómo lo rediseñarías de forma ética?
¿Qué heurística de Nielsen también se viola?
✅ Resolución
1. Dark patterns: • Costos ocultos: S/68 adicionales invisibles en la búsqueda. • Trick question: el seguro está preseleccionado (debes deseleccionar activamente). • Roach motel: difícil de cancelar porque el precio bajo inicialmente crea compromiso cognitivo.
2. Rediseño ético: • Mostrar precio final total desde el buscador: "Desde S/147 (todo incluido)". • Seguro como opción opt-in, no opt-out. • Desglose de cargos transparente en todos los pasos.
3. Heurística violada: H02 (Correspondencia con mundo real — el precio mostrado no corresponde al precio real) y H05 (Prevención de errores — la preselección del seguro induce al error).
📺 Plataforma streaming — Continuidad forzada Análisis
▼
Contexto Una plataforma de streaming disponible en Perú ofrece 30 días gratis. No envía recordatorio antes del cobro. Para cancelar, el usuario debe: ir a Configuración > Cuenta > Administrar > Suscripción > Cancelar membresía > Confirmar por email > Esperar confirmación manual (48h).
¿Qué dark pattern(s) identificas?
¿Cómo impacta esto en la confianza a largo plazo?
✅ Resolución
1. Dark patterns: Continuidad forzada (roach motel) + obstrucción del flujo de cancelación. El proceso de 5 pasos para cancelar vs 1 clic para suscribirse es intencionalmente asimétrico.
2. Impacto en confianza: A corto plazo retienen usuarios frustrados que no cancelan. A largo plazo: reviews negativas, churn masivo cuando el usuario finalmente cancela y nunca vuelve, daño reputacional en redes sociales. Estudios muestran que usuarios manipulados tienen NPS mucho más bajo y recomiendan negativamente.
Demo interactiva: Buen UX vs Dark Pattern
Compara cómo se ve el mismo flujo con y sin dark patterns
✅ Buen diseño
Suscripción mensual · S/ 29.90/mes
Incluye: streaming HD, 2 pantallas, sin anuncios.
📅 Te recordaremos 3 días antes de que termine tu prueba gratuita.
Iniciar prueba gratuita →
No, gracias
❌ Dark Pattern
¡GRATIS por 30 días!(S/29.90/mes después, cargo automático)
⏰ ¡Solo quedan 2 lugares en esta oferta!
¡SÍ, QUIERO MI PRUEBA GRATIS!
No, prefiero pagar precios completos siempre
🔍 Analizador de Dark Patterns
Selecciona un tipo de dark pattern para ver su análisis detallado, ejemplo peruano y cómo evitarlo.
Preguntas frecuentes
¿Los dark patterns son ilegales?+
Depende del país y el tipo. En la UE, el DSA prohíbe explícitamente varios dark patterns. En Perú, algunos están cubiertos por el Código de Protección al Consumidor (publicidad engañosa, prácticas comerciales desleales). Sin embargo, muchos permanecen en zonas grises legales aunque sean éticamente cuestionables.
¿Cómo distingo un dark pattern de un diseño simplemente malo?+
La clave es la intención. Un diseño malo confunde al usuario accidentalmente. Un dark pattern confunde al usuario a propósito para beneficiar al negocio. Si el negocio se beneficia cada vez que el usuario "se equivoca", probablemente sea un dark pattern intencional.
¿Por qué las empresas usan dark patterns si dañan la confianza?+
Porque priorizan métricas de corto plazo (conversiones, ARPU) sobre la relación a largo plazo. Los A/B tests a veces muestran que el dark pattern "funciona" (más conversiones), pero no miden el churn a 6 meses, el NPS o la reputación. Es una decisión de horizonte temporal, no solo de diseño.
¿Cómo reportar un dark pattern en Perú?+
INDECOPI tiene el portal "Mira a Quién le Compras" y permite reportar prácticas engañosas. También se puede reportar via Libro de Reclamaciones digital. Para dark patterns de privacidad de datos, la Autoridad Nacional de Protección de Datos Personales (ANPD) tiene competencia.
Evaluación › Quiz 1
📝 Q1
Quiz 1 — Temas 1 al 3
Prototipos, Evaluación de Usabilidad y UX en Procesos de Proyecto. 8 preguntas con retroalimentación inmediata.
8 preguntas4 opciones c/uFeedback inmediato
Evaluación › Quiz 2
🎯 Q2
Quiz 2 — Temas 4 al 6
Errores Humanos, Diseño en Negocios y Patrones Oscuros. Cierre del repaso completo del curso.
8 preguntas4 opciones c/uResultado final
🎓 ¡Has completado el repaso del curso de UX!
Revisaste los 6 temas, practicaste con casos del contexto peruano y te evaluaste con 16 preguntas. Suerte en el examen. — USIL 2026-1