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

1. Prototipado y testeo
Un camino desde la idea al
producto

2. Hola, soy Juan Paulo
Diseñador UX, Consultor en Usabilidad y Profesor

3. ¿Y ustedes?
¿A qué se dedican?
¿Por qué están aquí?

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

5. Repasando…
¿Qué es lo que más les ha gustado de lo
que han aprendido hasta ahora?

6. Veamos algunos
conceptos medulares
Para que nuestras conversaciones sean
más precisas
Conceptos

7. User Experience
¿Qué es?
Conceptos

8. UX
The spectrum of UX- Information Architects Institute
Conceptos

9. User experience
Disciplines of UX- Dan Saffer
Conceptos

10. User experience
Elementos de la experiencia de usuario – J.J. Garrett
Conceptos

11. User experience
The User Experience Honeycomb- Peter Morville
Conceptos

12. User experience
Stephen P. Anderson “Creating Pleasurable Interfaces”
Conceptos

13. User experience
Leena Arhippainen & Marika Tähti
Conceptos

14. Interacción / Interfaz
¿Qué diferencias hay?
Conceptos

15. Usabilidad / Accesibilidad / Ai
¿Qué son?
Conceptos

17. ¿Cómo diseñar interacción?
¿Y no morir en el intento?
Métodos

18. 2 vertientes
metodológicas
Waterfall / Agile
Métodos

19. UCD Waterfall
Métodos

20. UCD Waterfall
Métodos

21. UCD Waterfall
Métodos

22. UCD Waterfall
Métodos

23. Agile
Métodos

24. Agile
Métodos

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

26. OK, pero
¿por dónde empiezo?
Algunos entregables del UCD
Entregables

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

43. Una posibilidad… Kanban
¿Pero cómo llevo control del proceso?

44. ¿Es sólo aplicar bien la
metodología?
Pista: NO
Entregables
Para hacer buenos prototipos

45. Algunos principios de
interacción
Tognazzini / Norman + invitados
Métodos

46. Interaction
Principles
Anticipación
Las aplicaciones deberían
intentar anticiparse a las
necesidades y deseos del usuario.

47. Interaction
Principles
Objetos humanos
Los objetos humanos de la
interfaz se comportan de manera
estándar por lo que se facilita su
uso.

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.

49. Interaction
Principles
Alinear experiencias y
expectativas
Consiste en realizar modelos
conceptuales que se comporten
de la manera en que espera el
usuario (modelo mental).

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

57. Interaction
Principles
Affordance
Las características morfológicas
de un objeto deben servir de
ayuda para identificar su
funcionamiento

58. Interaction
Principles
Jerarquías de control
Cuando un elemento controla a
otro deben encontrarse
agrupados de manera jerárquica

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.

61. Interaction
Principles
Mapping
Los controladores deben ubicarse
de manera que se relacionen
correctamente con sus ámbitos
de acción

62. Interaction
Principles
Constraints
El usuario debe ser capaz de
realizar sólo las acciones que
corresponden en el momento
determinado evitando así
constantes episodios de error.

63. Prototipado
¿Qué debo saber?
Hablemos específicamente ahora
Prototipado

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

66. Prototipado

67. Prototipado

68. Tipos de prototipado
Dependiendo de sus características
Prototipado

69. 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

74. Matriz de prototipos

75. 8 Principios
Para un buen prototipado
Prototipado
Rosenfeld- Prototyping

76. Entiende a tu
audiencia y tu
objetivos
Son la base de un buen resultado
Prototipado
01

77. Planifica un poco,
prototipa el resto
Manos a la obra
Prototipado
02

78. Establece las
expectativas
¿Qué esperar de este prototipo?
Prototipado
03

79. Dibuja
Es el más rápido de los prototipos y es casi
gratis
Prototipado
04

80. Es un prototipo, no la
Mona Lisa
Si es lo suficientemente claro, es lo
suficientemente bueno
Prototipado
05

81. Si no lo puedes hacer,
falséalo
Da lo mismo lo que está detrás del
escenario
Prototipado
06

82. Prototipa solamente
lo que necesites
El resto no es necesario (por ahora)
Prototipado
07

83. Reduce el riesgo.
Prototipa luego y
seguido
Mientras más tiempo pasa, más caro es un
error
Prototipado
08

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

86. Rápidos
Debes ser capaz de crear varios y
modificarlos rápido
Prototipado
01

87. Baratos
Desecharlo y empezar de nuevo debe darte
lo mismo
Prototipado
02

88. Minimalistas
Deben contener sólo lo imprescindible
Prototipado
03

89. Testeables
Deben permitir que la gente los use, no
que escuchen como funcionarían
Prototipado
04

90. Medibles
Debes poder identificar lo que está bien y
lo que está mal (ojalá mediante números)
Prototipado
05

91. Algunos ejemplos
De prototipado
Prototipado

92. Video prototyping
Prototipado

93. Video prototyping
Prototipado

94. Lego prototyping
Prototipado

95. 3D Printing
Prototipado

96. Paper prototyping
Prototipado

97. Testing
¿Y cómo se prueban los prototipos?
Testing

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

100. Algunos tipos de
testing
Test heurístico – User Testing
Testing

101. ¿Heurísticas?
Checklist de J. Nielsen de aspectos a
evaluar
Testing
Test Heurístico

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

105. Consistencia y estándares
Ante un mismo estímulo, una misma
respuesta.
Heurísticas
04

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

113. Pensamiento hablado
Pídele al usuario que diga lo que piensa.
01
User -Testing

114. Todo es testeable
Mientras se tenga un prototipo y usuarios.
02
User -Testing

115. Comportamiento > Opinión
Créele a lo que ves por sobre lo que
escuchas.
03
User -Testing

116. Se prueban tareas definidas
Nunca un paseo libre.
04
User -Testing

117. Registra los indicadores
clave
Que luego te permitan comparar
performance.
05
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

124. Ejemplos
Usuarios probando cosas
Testing

125. Ejemplos
Testing

126. Ejemplos
Testing

127. Ejemplos
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/

129. Gracias!
Preguntas?
Juan Paulo Madriaza
mad@uxd.cl