TEMA 5: USABILIDAD

TEMA 5: USABILIDAD

1. Medida en la que un producto se puede usar por determinados usuarios para conseguir objetivos específicos con efectividad, eficiencia y satisfacción en un contexto de uso especificado

   • EFECTIVIDAD
     • Grado en que los usuarios pueden completar con precisión y completitud los objetivos específicos para los que el producto está diseñado
   • EFICIENCIA
     • Recursos (principalmente tiempo y pasos) que requieren los usuarios para alcanzar sus objetivos con precisión
   • SATISFACCIÓN
     • Percepción subjetiva del usuario sobre la experiencia: comodidad, confianza, frustración, agrado y disposición a volver a usar o recomendar el producto

2. IDEAS PRINCIPALES

   • Aproximación al usuario
   • Amplio conocimiento del contexto de uso
   • Satisfacción de las necesidades del usuario
     • Determinan si el producto es fácil de usar

3. REPERCUSIÓN

   • Reducción de los costes de producción
   • Reducción de los costes de mantenimiento y apoyo
   • Reducción de los costes de uso
   • Mejora en la calidad del producto

4. REGLAS DE DISEÑO

   • PRINCIPIOS
     • 1. FACILIDAD DE APRENDIZAJE
       • 1. PREDICCIÓN
         • Anticipar lo que hará el sistema ante una acción
       • 2. SÍNTESIS
         • Presentar información compleja de forma integrada y comprensible
       • 3. FAMILIARIDAD
         • Metáforas, patrones y convenciones conocidas por los usuarios
       • 4. CONSISTENCIA
         • Uniformidad en diseño y comportamiento a lo largo del sistema
     • 2. FLEXIBILIDAD
       • 1. INICIATIVA DE DIÁLOGO
         • Habilidad del sistema para iniciar o conducir interacciones
       • 2. CAMBIO ENTRE TAREAS
         • Facilidad para interrumpir una tarea, cambiar a otra y volver sin pérdida de contexto ni esfuerzo excesivo
       • 3. SUSTITUCIÓN
         • Hacerse cargo de una tarea humana (automatizarla) o delegarla y reversible cuando sea necesario
       • 4. PERSONALIZACIÓN
         • Ajustar comportamiento, presentación o prioridad según preferencias, rol o historial del usuario
     • 3. ROBUSTEZ
       • 1. CAPACIDAD DE OBSERVACIÓN
         • Percibir correctamente el entorno y las señales relevantes (entradas del usuario, sensores, contexto)
       • 2. CAPACIDAD DE RECUPERACIÓN
         • Recuperación tras fallos del sistema (guardado en la nube, reintentos, restauración de estado, mensajes claros de error y recuperación guiada)
       • 3. TIEMPOS DE RESPUESTA
         • Latencia entre acción del usuario y respuesta del sistema
       • 4. AJUSTE DE LAS TAREAS
         • Habilidad del sistema para adaptar la carga, complejidad o secuencia de tareas según capacidad del usuario o condiciones externas
     • PRINCIPIOS DE MAYHEW
       • 1. CONOCIMIENTO DEL USUARIO
         • Entender quién usa la interfaz (objetivos, habilidades, contexto, frustraciones)
       • 2. COMPATIBILIDAD ENTRE PRODUCTOS
         • Cohesión en el mismo ecosistema de productos (Microsoft, Adobe)
       • 3. COMPATIBILIDAD CON LA TAREA
         • Orden, herramientas, pasos de los usuarios
       • 4. COMPATIBILIDAD DEL FLUJO DE TRABAJO
         • Apoyar la secuencia completa de trabajo (múltiples tareas, estado entre pasos, colaboración)
       • 5. CONSISTENCIA
         • Uniformidad en apariencia, comportamiento y lenguaje dentro del producto
       • 6. SIMPLICIDAD
         • Hacer las cosas lo más simples posible sin perder funcionalidad
       • 7. MANIPULACIÓN DIRECTA
         • Permitir al usuario interactuar con objetos visibles de forma inmediata
       • 8. CONTROL
         • El usuario debe sentir que tiene el control (deshacer, cancelar, salir)
       • 9. WHAT YOU SEE IS WHAT YOU GET
         • Lo que el usuario ve en la edición debe reflejar el resultado final
       • 10. FLEXIBILIDAD
         • Soportar distintos estilos de uso y niveles de habilidad
       • 11. SENSIBILIDAD A LAS ACCIONES
         • Respuesta inmediata y apropiada a cada acción del usuario
       • 12. OCULTACIÓN DE LA TECNOLOGÍA
         • Esconder complejidad técnica y jerga (mostrar sólo lo que el usuario necesita)
       • 13. ROBUSTEZ
         • Tolerancia al error y comportamiento predecible bajo condiciones adversas
       • 14. PROTECCIÓN
         • Proteger datos, privacidad y evitar acciones dañinas (tanto por error como malicia)
       • 15. FACILIDAD DE APRENDIZAJE Y FACILIDAD DE USO
         • Interfaz fácil de entender al principio y eficiente con el uso continuado
     • 10 HEURÍSTICAS DE NIELSEN
       • CUMPLE LAS ESPECTATIVAS
         • 1. El sistema debe reflejar el mundo real
         • 2. Se debe mantener la consistencia y seguir los estándares
         • 3. Se debe proporcionar ayuda y documentación
       • EL USUARIO ES EL JEFE
         • 4. El usuario debe tener control y libertad de uso
         • 5. El estado del sistema debe ser siempre visible
         • 6. El uso del sistema debe ser flexible y eficiente
       • GESTIONA LOS ERRORES
         • 7. Se deben prevenir los errores
         • 8. Se debe promover el reconomiento más que el recuerdo
         • 9. Se debe ayudar a los usuarios con los errores
       • MANTEN LA APLICACIÓN SIMPLE
         • 10. El diseño debe ser estético y minimalista
     • 8 REGLAS DE ORO DE SHNEIDERMAN
       • 1. Esforzarse en la coherencia
       • 2. Permitir que los usuarios frecuentes usen atajos
       • 3. Ofrecer feedback al usuario
       • 4. Diseño de diálogo en el cierre de las tareas (finalización de tareas)
       • 5. Ofrecer mecanismos para la prevención de errores y el control de errores simples
       • 6. Permitir fácilmente retroceder en las acciones realizadas
       • 7. Soporte del control interno
         • Sistema responde ante las acciones del usuario, el usuario siente que tiene el control
       • 8. Reducir la carga de memoria a corto plazo
     • 7 PRINCIPIOS DE NORMAN
       • 1. Usar el conocimiento del entorno
         • Entender al usuario, tarea y contexto
       • 2 Simplificar la estructura de tareas
         • Tareas más frecuentes e importantes fáciles de hacer
         • Dar ayudas para mantener pasos de tareas
         • Automatizar parte de la tarea sin que reste mérito a la experiencia del usuario
       • 3. Hacer cosas visibles
       • 4. Transformación de las acciones a eventos
       • 5. Explotar el poder de las restricciones
       • 6. Diseño frente a errores (prevenir consecuencias desastrosas)
       • 7. Cuando todo lo demás falla, estandarizar
         • Si hay dudas, usar convenciones y estándares consolidados para que los usuarios ya sepan qué esperar
   • ESTÁNDARES
     • Establecidos por organismos nacionales o internacionales para asegurar su cumplimiento dentro de una comunidad grande
     • NORMAS ISO
       • ISO
         • ORGANISMO INTERNACIONAL PARA LA ESTANDARIZACIÓN
       • 1. ISO 9241
         • Define principios y recomendaciones de diseño centrado en el usuario para interfaces y sistemas interactivos
       • 2. ISO/IEC 25010
         • Modelo de calidad del producto software
           • Define características (funcionalidad, fiabilidad, usabilidad, eficiencia, mantenibilidad, portabilidad, etc.) y subcaracterísticas para evaluar la calidad de un producto
       • 3. IEEE 830
         • Guía clásica para la especificación de requisitos de software (SRS)
       • 4. ISO/IEC 12207
         • Estándar de procesos del ciclo de vida del software
           • Procesos, actividades y tareas para gestión, desarrollo, operación y mantenimiento
       • 5. ISO/IEC 29110
         • Estándar de procesos del ciclo de vida del software para pequeñas empresas o proyectos (<25 personas)
       • 6. ISO/IEC/IEEE 29119
         • Conjunto de normas sobre pruebas de software
           • Vocabulario, procesos de prueba, documentación y técnicas para integrar el testing en cualquier ciclo de vida
     • W3C
       • ESTÁNDARES PARA LOS PRODUCTOS EN INTERNET
         • 1. Foco en usuarios, tareas y contexto
         • 2. Involucrar a usuarios durante todo el proceso
         • 3. Proceso iterativo
         • 4. Usar técnicas y artefactos concretos
           • Personas, escenarios, análisis de tareas, wireframes/prototipos, tests de usabilidad con usuarios reales, evaluaciones heurísticas
         • 5. Integrar accesibilidad e inclusión desde el inicio
         • 6. Equipo multidisciplinar y objetivos medibles
   • MARCOS Y GUÍAS
     • MARCOS
       • MDA
         • Separar y conectar el diseño de juegos (lo que hace el diseñador) con la experiencia del jugador (lo que siente el jugador)
         • CAPAS
           • Mechanics
             • Reglas y sistemas formales
               • Datos, algoritmos, parámetros, objetos y acciones que definen el juego a nivel de código o reglas
           • Dynamics
             • Comportamiento emergente cuando las mecánicas interactúan en tiempo de ejecución
           • Aesthetics
             • Experiencias y emociones que el juego busca provocar en el jugador
       • OCTALYSIS
         • 1. Significado épico y vocación
           • El usuario siente que fue elegido para una misión
         • 2. Desarrollo y logro
           • Progresar, superar retos y obtener reconocimientos
         • 3. Potenciación de la creatividad y retroalimentación
         • 4. Propiedad y posesión
           • Sentir que posees algo (inventario, progreso, colecciones) y querer mejorarlo o protegerlo
         • 5. Influencia social y relación
           • Reconocimiento, competencia, cooperación, altruismo, comparación social y pertenencia
         • 6. Escasez e impaciencia
           • Desear algo porque es raro o está disponible por tiempo limitado
         • 7. Imprevisibilidad y curiosidad
           • La incertidumbre y la sorpresa mantienen la atención (recompensas variables, elementos sorpresa)
         • 8. Pérdida y evitación
           • Evitar perder lo ganado o evitar consecuencias negativas
         • Marco de gamificación
       • TAXONOMÍA DE JUGADORES DE BARTLE
         • 4. KILLER (<1%)
           • Players + Acting
         • 2. ACHIEVER (10%)
           • World + Acting
         • 3. EXPLORER (10%)
           • World + Interacting
         • 1. SOCIALIZER (80%)
           • Players + Interacting
       • GAME DESIGN PATTERNS
         • Aproximación para reutilizar el conocimiento sobre diseños existentes buenos
         • Provienen de los patrones de arquitectura
         • Captura las propiedades invariantes de un buen diseño en un determinado contexto a un problema recurrente
         • La implementación específica dependerá de las circunstancias y de la creatividad del diseñador
     • GUÍAS
       • SONY TRC (Technical Requirements Checklist)
       • MICROSOFT XR (Xbox Requirements)
       • NINTENDO LOTCHECK
       • APPLE APP STORE GUIDELINES
       • GOOGLE PLAY POLICIES