IxDA BA Mobile 20 julio 2010

  • 1,875 views
Uploaded on

Presentación para diseñadores y desarrolladores de aplicaciones móviles. Definiciones y conceptos esenciales de Diseño de Interacción, Proceso de diseño convergente, prototipado, niveles de fidelidad, …

Presentación para diseñadores y desarrolladores de aplicaciones móviles. Definiciones y conceptos esenciales de Diseño de Interacción, Proceso de diseño convergente, prototipado, niveles de fidelidad, pruebas con usuarios, prototipado iterativo, niveles de consistencia de la interfaz.

Expuesta el 20 de julio de 2010 en el aula magna de la UP, en evento MobileMonday TechTalks con la participación de Axel Meyer, Diseñador en Jefe de la Serie N de Nokia.

More in: Design
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
1,875
On Slideshare
0
From Embeds
0
Number of Embeds
3

Actions

Shares
Downloads
47
Comments
0
Likes
2

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide
  • Partiendo de un requerimiento determinado, que asumimos implicó un análisis previo de la solución (ya sea por nosotros o por otra parte), vamos a analizar cómo se desarrolla el proceso de implementación de esa solución, y qué resultados vamos a obtener como consecuencia de cada tipo de proceso.
  • El proceso lineal es muy sencillo. Recibimos un requerimiento, lo desarrollamos, lo implementamos y lo entregamos. Es lineal, tiene un principio y un fin, y el resultado es lo que se solicitó inicialmente. Pero qué ocurre al final de este proceso?
  • Lo que ocurre al final del proceso, es que generalmente es allí donde se detectan errores de diseño, funcionalidad, interacción y se redefine el scope del requerimiento, pero no los deadlines. Y al implementarse la solución de esos errores utilizando el mismo proceso, hasta no completar los nuevos requerimientos no se dará lugar a detectar nuevas posibles fallas.
  • En cambio en el proceso convergente, todos los aspectos del requerimiento son validados y aprobados en iteraciones. Esto es bueno ya que, por un lado se detectan de forma temprana (al principio o transcurso del proyecto y no al final) los errores, arrojando visibilidad sobre los tiempos y permitiendo tomar mejores decisiones respecto del scope del pryecto; y por otro lado todas las definiciones realizadas en cada etapa del proceso son validadas por las partes necesarias.
  • En cambio en el proceso convergente, todos los aspectos del requerimiento son validados y aprobados en iteraciones. Esto es bueno ya que, por un lado se detectan de forma temprana (al principio o transcurso del proyecto y no al final) los errores, arrojando visibilidad sobre los tiempos y permitiendo tomar mejores decisiones respecto del scope del pryecto; y por otro lado todas las definiciones realizadas en cada etapa del proceso son validadas por las partes necesarias.
  • Se parte del scope general y se avanza hacia lo particular, donde varias ideas convergen progresivamente en una solución, en vez de ir refinándose al final de cada implementación.
  • Qué ocurre en cada iteración? Para cada una de las iteraciones/etapas, deben realizarse: 1 2 3 4
  • Habiendo visto las diferencias entre los procesos, este es el “reason why” de incluír tareas de maquetado y prototipado en el proceso de diseño/desarrollo
  • Estas son las etapas del proceso, y a continuación se enumerarán las diferencias entre cada una de ellas
  • Al cabo de esta etapa, tendremos una visión validada de cómo va a funcionar nuestra aplicación, y de que modo debería presentarse la información en ella.
  • Al cabo de esta etapa tendremos un documento con la definición de la estructura de nuestra aplicación y su contenido, y la funcionalidad que va a cubrir. Para el análisis funcional deberá tenerse en cuenta además el contexto de uso de la aplicación (ej: si es una aplicación de productividad, el contexto puede ser “sentando cómodo en mi oficina” o “en la calle, yendo para una reunión, y con una única mano libre”)
  • Al cabo de esta etapa tendremos la confirmación de que el flujo de navegación y la interacción propuestas cumplen a grandes razgos con los requerimientos funcionales de la aplicación.
  • Al cabo de esta etapa tendremos un documento con la definición de la interactividad requerida por nuestra aplicación para presentar la información del modo previamente definido, en función de un análisis en conjunto con la propuesta estética (diseño) y la propuesta funcional.
  • Dentro de un mismo segmento/sistema operativo podemos encontrar muchísimas configuraciones de hardware diferentes
  • Cada variación en la configuración de hardware puede implicar una variación en nuestra aplicación. Qué tipo de variación?
  • Ej: Hay dispositivos que proveen modo “landscape”, otros dispositivos que poseen mayor tamaño de pantalla y por ende me permiten distribuír los elementos de otra forma más “óptima”
  • Al tener más pantalla puedo unificar flow de navegación, o ahorrar un paso donde el usuario ingresa su ubicación en la aplicación porque puedo detectarla vía GPS.
  • Cada plataforma posee una GUI con estructura consistente y definida. Nuestra aplicación no debe ser excepción. Debemos respetar las convenciones del sistema en el que estamos, tanto desde lo estético (look & feel de tabs) como lo funcional (ej: menu contextual de un ítem en una lista, las opciones deben ser similares, por ej, al SMS) y lo interactivo (ese menu se abre con la soft-key izquierda)
  • Mantener la coherencia tanto a lo largo de toda la aplicación, como en la aplicación en diferentes devices
  • Permitir al usuario cumplir su obejtivo en nuestra aplicación es tan importante como permitirle que lo haga en el contexto en que se encuentra Determinar tareas clave de la aplicación y permitir al usuario realizarlas con mínimo esfuerzo Environment-Awareness (acelerómetro, brújula) Location-Awareness (GPS) Otras aplicaciones que el usuario utilice al mismo tiempo

Transcript

  • 1. Diseño de interacción y usabilidad en móviles
    • Santiago Bustelo • Federico Campo Piombi
    • Presentación bajo licencia Creative CommonsAtribución 2.5 Argentina
  • 2. IxDA (Interaction Design Association)
    • Red global dedicada a la práctica profesional del Diseño de Interacción
    • Foro global, 20.000 miembros
    • En Buenos Aires:
      • Encuentros
      • Charlas
      • Congresos
      • Cursos
  • 3. Diseño de Interacción
    • Define el modelo de operación de productos interactivos para lograr mejores experiencias para la mayor cantidad de usuarios.
  • 4. ¿Cuándo está terminado nuestro trabajo?
    • Cuando nos gusta a nosotros
    • Cuando funciona como queríamos
    • Cuando le gusta al cliente
    • Cuando el usuario logra lo que esperábamos
  • 5. Diseño de Interacción: Proceso
  • 6. IxD: Proceso Proceso Lineal Proceso Convergente
  • 7. IxD: Proceso
    • Definición de requerimientos.
    • Diseño y desarrollo a nivel de producción.
    • Entrega.
    Proceso Lineal
  • 8. IxD: Proceso
    • Definición de requerimientos.
    • Diseño y desarrollo a nivel de producción.
    • Entrega.
    • No funciona como se esperaba, o no resuelve la problemática detectada.
    • Se modifica la funcionalidad.
    • No se modifican los deadlines.
    Proceso Lineal
  • 9. IxD: Proceso
    • Objetivos y análisis inicial.
    • Analizar el requerimiento y determinar la mejor solución.
    • Identificar definiciones faltantes al inicio u ongoing del proyecto, y no al final.
    • Asignar responsables de definiciones faltantes.
    Proceso Convergente
  • 10. IxD: Proceso
    • Objetivos y análisis inicial.
    • Diseño y Desarrollo en iteraciones
    • Cada etapa es validada antes de continuar con la siguiente.
    • Detección temprana de errores.
    • Visibilidad sobre tiempos y scope.
    Proceso Convergente
  • 11. IxD: Proceso
    • Objetivos y análisis inicial.
    • Diseño y Desarrollo en iteraciones avanzando progresivamente en:
      • Funcionalidad
      • Estructura y elementos
      • Lenguaje visual
    • Entrega y puesta en producción.
    Proceso Convergente
  • 12. IxD: Proceso
    • Planeamiento de la iteración Definición del problema. Qué queremos aprender de esta iteración y cómo vamos a hacerlo.
    • Implementación Creación del prototipo con la fidelidad correcta
    • Prueba Obtenemos información que valida o descarta la solución.
    • Conclusiones y aprendizaje Qué funcionó o no, y por qué.
    • Jared Spool, Anatomy of an Iteration
    Iteraciones del Proceso Convergente
  • 13. IxD: Objetivos del Proceso
    • Externalizar y comunicar ideas para reflexionar sobre ellas.
    • Poner a prueba las ideas en contexto.
    • Validar requerimientos con stakeholders.
    • Validar la funcionalidad en el contexto de uso de la aplicación (mobile scenario).
    • Descubrir problemas y explorar nuevas direcciones.
    • Hacer esto en una fase del proyecto donde aún sea viable realizar cambios en el alcance.
  • 14. IxD: Entregables del Proceso Sketch Wireframe Prototipo Interactivo Diseño gráfico de la interfaz
  • 15. IxD: Entregables del Proceso Sketch
    • Características:
      • Fidelidad muy baja
      • Permiten opinar sin restricciones
      • Colaborar
      • Probar rápidamente conceptos generales
    • Objetivo:
      • Proponer Estructura espacial
      • Proponer Interactividad
      • Proponer Funcionalidad
  • 16. IxD: Entregables del Proceso Wireframe
    • Características:
      • Fidelidad baja a media
      • Realizar anotaciones
      • Documentar las definiciones
    • Objetivo:
      • Definir estructura espacial
      • Definir áreas de contenido
      • Definir funcionalidad (caso puntual mobile)
      • Definir flow de navegación
      • Permitir pruebas con usuarios
  • 17. IxD: Entregables del Proceso Prototipo Interactivo
    • Características:
      • Fidelidad media a alta
      • Testear experiencia de uso sin haber desarrollado la aplicación
    • Objetivo:
      • Proveer mecanismo para validar flow + interacción
      • Permitir pruebas con usuarios
  • 18. IxD: Entregables del Proceso Diseño gráfico de la interfaz
    • Características:
      • Fidelidad alta
      • Documentar las decisiones
    • Objetivo:
      • Alinear estética de interfaz validada
      • Recursos gráficos para implementación
  • 19. IxD: Conclusión
    • ¿Qué ganamos incorporando IxD a nuestro workflow?
      • Validar funcionalidad, interacción y flujo de la aplicación
      • Identificar key issues en una etapa temprana del proyecto
      • Documentar las definiciones
      • Herramientas de testeo previas al desarrollo
      • Salud
  • 20. Pruebas con usuarios: Validación de la interacción
  • 21. Diseño centrado en el Usuario versus:
    • Diseño autoreferencial
    • Diseño centrado en la tecnología
    • Diseño centrado en el stakeholder
    • Diseño centrado en la competencia
  • 22. ¿Qué es un Usuario?
    • No está viciado por el ejercicio de la profesión ni por el proceso de conceptualización.
    • Tiene o puede representar intención de usar la interfaz para lograr un objetivo.
    • Tiene o puede representar el modelo mental del público al que está destinada la interfaz.
    • No necesita ser una muestra demográfica.
    • “ La prueba con el usuario no tiene que ser perfecta.
Tiene que existir” (Jared Spool)
  • 23. Incorporando al Usuario
    • La diferencia entre probar nuestras hipótesis con cero usuarios, vs. hacerlo con un solo usuario, es infinita.
    • Pruebas rápidas y de gran impacto cualitativo.
    • No se toman requerimientos del usuario. Nos enfocamos en lo que el usuario hace.
    Jakob Nielsen: Why You Only Need to Test with 5 Users
  • 24. Prototipado iterativo Rodolphe Courtier: Mobilist
  • 25. Pruebas con usuarios Lin Lin Designs: Explore Chicago
  • 26. Prototipo funcional
  • 27. Laboratorio de usabilidad Fuentes: Usability Sciences , UserCentric , Design4Mobile
  • 28. Consistencia
  • 29. Mobile IxD
    • Aplicaciones móviles deben ser consistentes con:
      • el Hardware del dispositivo/plataforma
      • el GUI del dispositivo/plataforma
      • el GUI de la misma aplicación
      • el Contexto de Uso
  • 30. Mobile IxD: Consistencia
    • Consistencia con el Hardware:
    Touchscreen Teclado QWERTY (físico, landscape) GPS WiFi Cámara Teclado QWERTY (físico, vertical) GPS WiFi Cámara Touchscreen WiFi Cámara Teclado Estándar GPS WiFi Cámara
  • 31. Mobile IxD: Consistencia
    • Consistencia con el Hardware:
    • En función del hardware de cada dispositivo soportado…
      • ¿Habrá variaciones de interfaz ?
      • ¿Habrá variaciones en el flow ?
      • ¿Habrá variaciones de funcionalidad ?
  • 32. Mobile IxD: Consistencia
    • Consistencia con el Hardware:
    • ¿Porqué podría variar la interfaz ?
      • Porque tengo mayor resolución de pantalla
      • Porque varían los guidelines de UI del dispositivo
  • 33. Mobile IxD: Consistencia
    • Consistencia con el Hardware:
    • ¿Porqué podría variar el flow de navegación ?
      • Porque varía la interfaz y puedo resolver una mecánica en más o menos pasos.
      • Porque varía el hardware, y necesito por ej. que el usuario ingrese su ubicación en vez de obtenerla por GPS.
  • 34. Mobile IxD: Consistencia
    • Consistencia con el Hardware:
    • ¿Porqué podría variar la funcionalidad ?
      • Porque no dispongo de un hardware determinado (GPS, cámara, acelerómetro, multitouch)
  • 35. Mobile IxD: Consistencia
    • Consistencia con el GUI del dispositivo/plataforma:
    Forum Nokia, Design and User Experience Library v2.0
  • 36. Mobile IxD: Consistencia
    • Consistencia con el GUI de la propia Aplicación:
  • 37. Mobile IxD: Consistencia
    • Consistencia con el Contexto de Uso
  • 38. Mobile IxD: Conclusión
      • No perder de vista el objetivo principal de la aplicación
      • No perder de vista al usuario de esa aplicación
      • No inventar la rueda:
          • Utilizar patrones de diseño conocidos y probados
          • Aplicar los guidelines de GUI de la plataforma
          • Verificar los checklists de la plataforma
      • En la medida de lo posible, testear con usuarios
  • 39. ¡Muchas gracias!
    • ixda.com.ar