Presentación realizada dentro del marco del diplomado de Diseño de Interacción y Physical Computing 2013 de la UDD.
Contempla una revisión general de conceptos, una mirada a las metodologías Waterfall y Agile, una revisión de los principales entregables del UCD, una compilación de Principios de interacción y una introducción a las etapas de prototipado y testing
4. Objetivos de este módulo
• Resumen de la primera etapa
• Teórica, pero enfocada en el hacer
• Entregar metodologías aplicables ahora
• Llevar ideas hacia el primer prototipo
• Diseñar centrado en el usuario
• Diferenciar approaches metodológicos
• Identificar principios fundamentales en el hacer
interacción
• Explorar las formas de testear prototipos
25. UCD Waterfall v/s Agile
Waterfall Agile
Más lineal Más iterativo
Más documentación Más prototipos funcionales
Más reflexivo Más impulsivo
Raíces en la administración Raíces en el desarrollo
Feedback en etapas determinadas Feedback constante
Va por el producto final Va por una mejora progresiva
Resistente al cambio Abierto al cambio constante
Se avanza sobre seguro Se avanza sobre la incertidumbre
Se negocia con el cliente Se colabora con el cliente
Funciona como el cliente Funciona como los desarrolladores
Intervalos según entregable Intervalos temporales definidos
Investigación profunda Escasa investigación
Ideal para proyectos con clientes Ideal para proyectos personales
Basado en la visión Basado en la improvisación y mejora progresiva
Mas de conocimiento Mas de experimentación
Métodos
27. Design the box
¿Qué es?
Es una caja que simula que tu idea
viene adentro (aunque nunca venga
dentro de una caja)
¿Para qué sirve?
Para aterrizar ideas, para llegar a
acuerdos en el equipo, para
dimensionar el proyecto, para
definir áreas de investigación
¿Cuándo realizarlo?
Al principio del proyecto
Contenidos:
• Nombre de la idea
• Gráfica (concepto)
• Un tagline
• 3 o 4 “promesas” destacadas en una
lista (portada)
• Una descripción detallada (atrás)
• Requerimientos técnicos
Entregables
28. Content Strategy
Canvas
¿Qué es?
Es un board que se llena según
los recuadros descritos
¿Para qué sirve?
Para sistematizar los
antecedentes y definiciones
preliminares de diseño
¿Cuándo realizarlo?
Al principio del proyecto
Contenido:
• Gancho de la idea
• Forma
• Acción esperada
• Métricas
• Canales
• Detonador de uso
• Persona (usuario)
• Recursos involucrados
• Resultados esperados
Entregables
29. Personas
¿Qué es?
Es una ficha con descriptores de
los usuarios arquetípicos de mi
idea
¿Para qué sirve?
Para entender a los usuarios, sus
intereses, motivaciones,
contextos de uso,
preocupaciones, etc.
¿Cuándo realizarlo?
Al principio del proyecto
¿Cómo se hace?
• Se definen arquetipos de usuarios
• Se hacen entrevistas con los
involucrados
• Se crean fichas por cada usuario
mencionando sus características como
si estuviéramos definiendo a una
persona real
Entregables
30. Storyboarding
¿Qué es?
Es una historia dibujada de
formas de uso de la idea
¿Para qué sirve?
Para focalizarse en lo central de la
idea, para revisar la lógica de la
idea, para comunicar el concepto
de manera fácil
¿Cuándo realizarlo?
Cuando se tienen las primeras
ideas, usuarios y contextos de
uso
¿Cómo se hace?
• Se definen las tareas y usuarios a
dibujar
• Se establece el guión
• Se dibuja la historia
• Se evalúa su resultado
Entregables
31. Benchmarks
¿Qué es?
Es una sistematización de las
mejores ideas de otros proyectos
existentes
¿Para qué sirve?
Para no inventar la rueda, para no
cometer los mismos errores de
otros, para diferenciarme de mi
competencia
¿Cuándo realizarlo?
Al momento de empezar un
proyecto que ya está relativamente
definido en su contexto
¿Cómo se hace?
• Se definen los referentes a analizar
• Se analizan rescatando lo bueno y lo malo
• Se establecen conclusiones haciendo énfasis
en las ideas que me sirven
Entregables
32. Capacidades del
sistema
¿Qué es?
Es un listado detallado de todas
las posibles funcionalidades que
puede tener nuestra idea
¿Para qué sirve?
Para definir y jerarquizar las
funcionalidades de nuestro
proyecto
¿Cuándo realizarlo?
Al momento de tener la idea
clara, los usuarios estudiados y
los referentes analizados
¿Cómo se hace?
• Se crea una tabla con todas las posibles
funcionalidades del sistema
• Se asignan niveles de importancia y
complejidad a cada funcionalidad
• Se definen las funcionalidades que van
finalmente en la solución
Entregables
33. Card Sorting
¿Qué es?
Es una dinámica de organización
de contenidos
¿Para qué sirve?
Para obtener información
respecto de cuál es la manera
más lógica de agrupar contenido
¿Cuándo realizarlo?
Al momento de tener los
contenidos delineados y/o
definidos
¿Cómo se hace?
• Se invita a varios grupos de usuarios a
una sesión de trabajo
• Se le entregan postits (definidos o en
blanco) con los contenidos del proyecto
• Se les pide que organicen los postits en
secciones (ya definidas o por crearse)
• Se realiza un reporte de los resultados
Entregables
34. Site Maps
¿Qué es?
Es un diagrama de ordenamiento
de secciones y sus contenidos
¿Para qué sirve?
Para visualizar las distintas
pantallas de la solución y sus
relaciones
¿Cuándo realizarlo?
Al momento de tener definidos
los contenidos
¿Cómo se hace?
• Se recopilan los contenidos que deben
formar parte del proyecto
• Se establecen cuáles serán las páginas
que formarán parte del proyecto
• Se establecen secciones donde se
encontrará cada página
• Se definen relaciones jerárquicas entre
cada pantalla
• Se crea un diagrama que lo especifique
Entregables
35. Task Flows
¿Qué es?
Es un diagrama de ordenamiento
de procesos y tareas
¿Para qué sirve?
Para visualizar la manera en que
las distintas tareas son realizadas
(paso a paso) y encontrar posibles
errores de lógica
¿Cuándo realizarlo?
Al momento de tener definidas
las capacidades del sistema
¿Cómo se hace?
• Se definen las tareas a visualizar
• Se establecen los pasos necesarios para
realizar una tarea
• Se buscan los puntos de bifurcación y se
establecen rutas alternativas
• Se crea un diagrama que explica las
distintas posibilidades de interacción
http://www.jjg.net/ia/visvocab/spanish.html
Entregables
36. Ideal Task Flows
¿Qué es?
Es un diagrama que muestra la
interacción ideal de un usuario
con el proyecto
¿Para qué sirve?
Para que al momento de diseñar
el proyecto podamos priorizar
evidentemente el flujo ideal
¿Cuándo realizarlo?
Al momento de tener definidas
las capacidades del sistema
¿Cómo se hace?
• Se definen las tareas más relevantes
• Se determina la ruta o los pasos ideales
con los que un usuario debería
relacionarse con el sistema
• Se determinan los puntos clave
• Se visualizan en una serie de diagramas
simples
Entregables
37. Sketching
¿Qué es?
Es un proceso de bocetaje de las
principales ideas del proyecto (no
sólo pantallas)
¿Para qué sirve?
Para sistematizar y visualizar las
ideas y sus posibles soluciones
¿Cuándo realizarlo?
Al momento de tener definidas
las capacidades del sistema
(*mapa de navegación)
¿Cómo se hace?
• Se definen las ideas a bocetear
• Se establecen las variables que
conforman cada idea
• Se realizan múltiples iteraciones hasta
encontrar las mejores soluciones
• Se realizan anotaciones que permitan
argumentar, detallar o invalidar una
idea
Entregables
38. Wireframes
¿Qué es?
Es una serie de imágenes que
muestran el layout, sin gráfica, de
las principales pantallas
¿Para qué sirve?
Para especificar el diseño de layout
de cada página y comprobar su
funcionalidad (usabilidad)
¿Cuándo realizarlo?
Al momento de concluir conforme el
proceso de sketching
¿Cómo se hace?
• Se determinan las pantallas que forman
parte de la médula del proyecto (plantillas a
prototipar)
• Se crean las pantallas utilizando un software
de wireframing (Axure, Omnigraffle)
• Se validan los resultados con usuarios
• Se realizan iteraciones hasta estar
convencido de la solución
Entregables
39. Wireflows
¿Qué es?
Es una serie de wireframes
posicionados en una única gran
pizarra
¿Para qué sirve?
Para ejemplificar las relaciones entre
una pantalla y la otra con tal de
validar la lógica de estas en su
contexto
¿Cuándo realizarlo?
Paralelamente al proceso de
wireframing
¿Cómo se hace?
• Se posicionan los wireframes sobre una
superficie que permita de un vistazo ver el
«big picture»
• Se trazan conectores entre las pantallas que
están relacionadas
• Se realizan comentarios escritos sobre la
pizarra para que faciliten el entendimiento
del documento
Entregables
40. Prototipado
interactivo
¿Qué es?
Es una serie de wireframes o
sketches que están vinculados entre
si (eventualmente tienen
funcionalidades básicas también)
¿Para qué sirve?
Para testear con usuarios
determinados flujos de tareas
¿Cuándo realizarlo?
Cuando se tienen listos los
wireframes o sketches asociados a
un flujo de tarea
¿Cómo se hace?
• Se determina la tarea a testear
• Se realizan los wireframes o sketches que
forman parte de la tarea
• Se les agrega funcionalidad
• Se ejecuta el proceso de testeo
• Se realizan cambios según los resultados
obtenidos
POP app
Entregables
41. Diseño visual
¿Qué es?
Es una serie de imágenes que
representan el diseño final de la
propuesta
¿Para qué sirve?
Para evaluar su diseño, como
insumo final para el desarrollo
¿Cuándo realizarlo?
Cuando se tienen definidos los
wireframes de las plantillas
¿Cómo se hace?
• Se determinan las pantallas a diseñar
• Se le agregan a los wireframes decisiones de
color, tipografía, imagen, textura, etc.
• Se evalúa su funcionamiento (interactive
prototype)
• Se realizan mejoras según los resultados
Entregables
42. …Y luego qué?
Mejoras constantes
Ciclos de iteración
Supervisión colaborativa de desarrollo
Control de calidad
Prototipos funcionales
User testings
Evaluación de KPIs
etc…
Entregables
48. Interaction
Principles
Protege el trabajo del
usuario
Asegúrate de que el usuario
nunca pierda su trabajo como
resultado de un error suyo, los
problemas de internet u otro tipo
de problemas inevitables, como
un apagón.
50. Interaction
Principles
Consistencia
Frente al mismo estímulo, la
misma decisión.
Es tan importante ser
visualmente inconsistente con los
objetos que se comportan de
forma distinta, como ser
consistente con los que se
comportan de igual manera.
Evita la uniformidad. Haz que los
objetos que se comportan
distinto parezcan distintos.
La consistencia más
importante es aquella que
espera el usuario. La única
manera de comprobar las
expectativas del usuario es hacer
pruebas con ellos.
51. Interaction
Principles
Carga cognitiva
El usuario no debe ser obligado a
retener información crítica para el
funcionamiento del sistema.
Deja que el sistema haga todo el
trabajo que le sea posible con tal
de que el usuario se enfoque en
las tareas en las que su
participación es crítica.
52. Interaction
Principles
Functional Minimalism
Todo debe ser tan simple como
sea posible, pero no más simple
que eso.
Evita funcionalidades superfluas.
Separa tareas complejas en
minitareas.
Limita las funcionalidades en pro
de la experiencia.
53. Interaction
Principles
Engagement (Flow)
El engagement aumenta cuando
un usuario siente que la tarea
que ejecuta es lo suficientemente
demandante como para que sea
entretenida, y no es tan difícil
como para que llegue a ser
frustrante.
FLOW- Mihaly Csikszentmihalyi
54. Interaction
Principles
Functional Layering
Según la ley de Pareto (80 -20) el
20% de las funcionalidades son
usadas el 80% de las veces.
Debemos hacer que las
funcionalidades más recurrentes
sean más fáciles de encontrar.
Debemos entregar herramientas
a los usuarios más
experimentados para que
ejecuten las tareas de manera
más rápida (aunque sea un tanto
menos lógica).
55. Interaction
Principles
Control, confianza y
explorabilidad
Si el usuario se siente en control
de lo que sucede en la interacción
eventualmente presentará
confianza en el funcionamiento
de esta por lo que se sentirá en
condiciones de explorarla de
manera más abierta.
56. Interaction
Principles
Prevención, detección y
recuperación de errores
Prevenir errores:
• Deshabilita funciones que no son
útiles
• Usa los patrones de interacción
correctos para permitir el ingreso
de data por parte del usuario
• Entrega instrucciones claras y
precisas
Detectar errores:
• Entrega feedback al usuario en el
caso que se presuma que pueda
estar cometiendo un error
Recuperación de errores
• Si el error ya fue cometido siempre
dale al usuario maneras de
deshacerlo
• Si una acción es crítica y no puede
ser deshecha indícalo antes de su
ejecución
59. Interaction
Principles
Feedback
Comunica el clic de los botones
mediante un feedback visual en
los primeros 50 milisegundos.
Muestra un indicador animado
para cualquier acción que dure
entre 1/2 y 2 segundos.
Si dura más de 2 seg. comunica el
tamaño y el progreso con un
barra de estado.
Indica con pitidos e indicaciones
visuales muy claras cuando el
usuario puede volver al trabajo
con el sistema.
60. Interaction
Principles
Visibility
Los controladores debes ser
fáciles de ubicar y usar.
Debe ser obvio y evidente el
resultado de la operación de un
controlador.
Un sistema con buena visibilidad
permite al usuario transformar
fácilmente objetivos en acciones.
64. ¿Y qué es el
prototipado?
¿Y un prototipo?
Prototipado
65. Prototipo
Modelo experimental construido mediante
múltiples iteraciones rápidas con usuarios.
Contar con prototipos físicos durante el
proceso de diseño permite un alineamiento
mayor y un diseño más eficiente.
Prototipado
70. Formas de clasificación
Baja / Media / Alta fidelidad
Baja fidelidad Media fidelidad Alta fidelidad
Muy precario, con sólo algunas
decisiones medulares tomadas,
sin interacciones
Con decisiones mas elaboradas,
pero aún incompleto. Con
interacciones simuladas
Con la totalidad de las decisiones
tomadas, cercano a ser
transformado en el producto. Con
interacciones reales
Sketches, paper prototypes Interactive Wireframes Interactive visual design,
Interactive prototypes
http://www.medien.ifi.lmu.de/lehre/ws0708/mmi1/e4.pdf
Prototipado
71. Formas de clasificación
Según etapa productiva
Basic Advanced Manufacturing Virtual
Construido con objetos
caseros
Sin preocupación por la
estética
Debe servir para probar
su factibilidad
Mejor construido (con la
ayuda de profesionales)
Se ve y funciona como el
producto
Es la versión master del
producto, desde la cual
se ejecuta la fabricación
en masa
Es una representación
digital del producto con
el detalle suficiente para
ser construído
http://www.edisonnation.com/forums/prototyping/topics/the-different-types-of-prototyping
Prototipado
72. Formas de clasificación
Según etapa de diseño
Sketches /
Storyboards
Paper
prototyping
Horizontal Vertical Wizard of OZ
Historias de uso y
dibujos de las
principales
interacciones
Sketches que
pueden ser
probados por
usuarios
(recorridos
testeables)
Se ve el global de
la idea, aún no
están disponibles
la funcionalidades
en detalle
Se presenta una
funcionalidad
completa para
testear (no está
disponible todo,
solo la
funcionalidad a
testear)
Las partes
complejas del
sistema están
simuladas
(mediante un
humano
entregando
respuestas, no un
sistema)
http://www.medien.ifi.lmu.de/lehre/ws0708/mmi1/e4.pdf
Prototipado
73. Formas de clasificación
Según su uso
Shared
communication
Working
Through a
Design
Selling Your Idea
Internally
Usability Testing Gauging
Technical
Feasibility and
Value
Lo suficiente para
que el equipo
pueda conversar y
evolucionar sobre
sus ideas.
Reemplaza la
conversación
Para trabajar sobre
la misma idea,
para pensar y
depurar
Para vender la idea
a los que no están
trabajando en el
proyecto
Para probar
nuestra idea con
usuarios
Para evaluar su
factibilidad técnica
y los costos de
producción final
Rosenfeld- Prototyping
Prototipado
84. El primer prototipo va a ser malo
Trata de terminar tu primer prototipo en un día
Vas a cambiar el problema
No te encariñes con tu prototipo
Prototipado
Otros
85. ¿Cómo son los buenos
prototipos?
Digo, como pa´saber
Prototipado
98. ¿Y qué es el Testing?
Es probar con usuarios, pero…
¿Para qué sirve?
Testing
99. Testing
• Para sacarnos el balde de la cabeza
• Para definir cambios cuando aún se puede
• Para darnos cuenta de lo que sobra
• Para detectar jerarquías erróneas
• Para obtener retroalimentación
• Para obtener motivación
• Para mejorar
Utilidades
102. Visibilidad del estado
del sistema
El sistema debe informar a los usuarios del
estado del sistema, dando una
retroalimentación apropiada en un tiempo
razonable
Heurísticas
01
103. Utilizar el lenguaje de
los usuarios
El sistema debe utilizar el lenguaje de los
usuarios, con palabras o frases que le sean
conocidas, en lugar de los términos que se
utilizan en el sistema.
Heurísticas
02
104. Control y libertad para el
usuario
El sistema no debe hacer sentir al usuario
que actúa sin su consentimiento.
Heurísticas
03
106. Prevención de errores
Mejor que un sistema con buenos
mensajes de error, es uno donde los
usuarios raramente cometen uno.
Heurísticas
05
107. Minimizar la carga
cognitiva
El usuario no debería tener que recordar
algo para poder continuar, ese algo debería
estar accesible fácilmente.
Heurísticas
06
108. Flexibilidad y eficiencia
de uso
El sistema debería proveer aceleradores
para los usuarios más experimentados.
Heurísticas
07
109. Diseño estético
y minimalista
Cada contenido o elemento innecesario
compite por la atención del usuario y
disminuye el potencial de entendimiento.
Heurísticas
08
110. Ayudar a los usuarios a
reconocer, diagnosticar y
recuperarse de los errores
Los errores deben ser expresados en lenguaje
cotidiano (sin códigos), indicar precisamente el
problema y proponer una solución.
Heurísticas
09
111. Ayuda y documentación
Si bien es mejor que la ayuda no sea
necesaria, en caso de necesitarla debe ser
accesible, contextual y precisa.
Heurísticas
10
112. ¿Cómo se hace bien?
10 Recomendaciones
User -Testing
User Testing
118. Si se puede, testea con
usuarios reales
Si no se puede, con cualquiera que no esté
en el equipo de diseño.
06
User -Testing
119. Testea y re-testea para
comparar
Hazlo con usuarios diferentes.
07
User -Testing
120. No puedes ayudar al tester
Nada de frío-frío, caliente-caliente.
08
User -Testing
121. La culpa NUNCA es
del tester
Evita que sienta que está rindiendo
examen.
09
User -Testing
122. Entrevista al final para
complementar
Puedes hacer un cuestionario para
complementar tus hallazgos.
10
User -Testing
123. ¿Qué estás pensando?
Describe los pasos que te han llevado hasta acá
¿Qué piensas que ocurrirá ahora?
¿Es esto lo que esperabas que pasara?
¿Eso fue confuso?
¿Te importaría repetir eso?
?
User -Testing
128. Más información
Prototyping
Todd Zaki Warfel
Measuring The User
Experience
Thomas Tullis
William Albert
UX Book
Rex Hartson, Pardha Pyla
http://www.uxd.cl/