Human Centered Design

Human-centered design es un enfoque creativo a resolver problemas.

Es un proceso que comienza con los usuarios para quienes estás diseñando la interface y termina con la respuesta al problema diseñado para sus necesidades.

Transcript

1. HUMAN-CENTERED DESIGN por Bellatrix Martinez
2. Human-centered design es un enfoque creativo a resolver problemas. Es un proceso que comienza con los usuarios para quienes estás diseñando la interface y termina con la respuesta al problema diseñado para sus necesidades. ¿QUÉ ES?
3. comienzos de la interacciÓn con computadoras En Julio de 1945 Vannevar Bush escribió un artículo para una publicación llamada “The Atlantic”. El artículo se llamó “As We May Think”. Donde hablaba de cómo la interacción con las computadoras aumentaría el nivel intelectual de los seres humanos.
4. Memex. Escritorio interactivo.
5. Computadoras del tamaño de un cuarto estaban siendo construidas…
6. En 1950 Grace Hopper creó el primer compilador.
7. Ivan Sutherland (father of graphics) vino con la idea del Input and Output. Esto se refería a que el Input del usuario generara el Output del sistema.
9. En 1968 Doug Engelbart creó el Mouse. Estuvo sumamente inspirado por el artículo que escribió Bush en 1945.
10. Alan Kay estaba en la audiencia de la universidad de Utah cuando hicieron el demo del primer mouse. El había ya pasado años soñando con la computadora personal. “The best way to predict the future is to invent it.”
11. …y construyó el prototipo de su computadora personal…Dynobook.
12. Pasó más de una década para que Xerox lanzara la primera interface gráfica. En los años 80s. Se llamó Star Computing System.
13. INNOVACIÓN Pasaron más de 3 décadas en crear el primer producto usable para el público. Esto es lo que llamó Bill Buxton “La Nariz Larga de la Innovación.”
15. ¿Cómo CREAR INNOVACIÓN? Para crear un producto necesitamos: 1 2 3 Entrevistas Prototipos - Storyboards - Mockups - low - Mockups - high - Interacción Feedback
16. ENTREVISTAS
17. entrevistas Las personas que entrevistemos deben representar el target para el cual se está diseñando la aplicación. La idea con estas entrevistas es identificar una necesidad que podamos solventar con nuestro sistema.
18. Debemos tratar que las preguntas que hagamos no sean preguntas inductivas. Si uno le pregunta a un usuario si le gustaría tener cierta funcionalidad, su respuesta siempre va a ser si, así y no la necesite. Debemos evitar las preguntas donde las respuestas sean si y no.
19. La idea es recolectar información, indagar, estar curioso. “If I had asked what people wanted, they would have said a faster horse” Henry Ford. Si, pero si nos enfocamos en la necesidad del usuario la solución es nuestra…un carro.
20. Algunas buenas preguntas: • Describe un escenario ideal. • Describe un escenario frustrante. • Cuéntame acerca de un momento que haya pasado… • La semana pasada cuantas veces… • Si quisieras que tu experiencia fuese distinta, ¿cómo la harías?
21. PROTOTIPOS
22. ¿quÉ es un prototipo? Un prototipo es ejecutar tu idea de producto rápidamente y con las herramientas que tengas disponibles. Crear un prototipo se trata de retroalimentación e iteración continua.
23. “The best way to have a good idea is to have tons of ideas.” Linus Pauling Nuestros prototipos son preguntas que buscan respuestas. Es más valioso trabajar en varios prototipos que nos den información valuable que trabajar por demasiado tiempo en uno sólo.
24. Hartmut Esslinger fue la persona que ejecuto la mayoría de los prototipos para Steve Jobs.
27. Apple lleva más de 30 años estudiando y haciendo prototipos de lo que hoy conocemos como iPhone, iPad y iWatch.
28. Facebook (launched in 2004)
29. Twitter (launched in 2006)
30. eBay (launched in 1995)
31. Airbnb (launched in 2008)
32. ENTREGAS TEMPRANAS Y RÁPIDAS En la web vemos este fenómeno se lanzar producto rápido y seguido. Esta modalidad dependerá de qué tan costoso es iterar sobre el producto lanzado. Por ej. Una página web es fácil de cambiar. Un carro no.
33. ¿CÓMO CREAMOS UN PROTOTIPO?
34. storyboards Los storyboards no tienen nada que ver con diseño. Son más para expresar una idea. ¿Qué hace el app? ¿Cuales son sus casos de uso? Un storyboard te lleva desde la necesidad hasta que el usuario exitosamente consigue lo que busca.
36. En esta fase se crean las personas. ¿Para quién estamos diseñando esta aplicación? Dale un nombre, una vida, una personalidad. Esto nos hará más fácil identificarnos con los usuarios que estarán trabajando con nuestra aplicación.
37. mockups - LOW FIDELITY En esta fase básicamente dibujamos la idea que tenemos de interface de usuario. La idea seria dibujarlo en papel y lápiz (preferiblemente un marcador, ya que esto nos evita entrar en detalle de la interface). De esta manera entendemos el flujo de usuario.
38. mockups - LOW FIDELITY
39. mockups - HIGH FIDELITY En esta fase se diseña la interface con detalle. Se definen colores, imágenes, tono, tipografía, etc. Nos basamos en lo que hemos descubierto en el proceso de los mockups de low fidelity.
40. mockups - HIGH FIDELITY
41. INTERACCIÓN En el pasado se simulaba la interacción de los usuarios utilizando los mockups, haciendo videos y editando lo que pasaba entre vista y vista. Hoy por hoy tenemos apps como Invision que simulan la interacción de los usuarios super bien.
42. INTERACCIÓN
43. RETROALIMENTACIÓN Hay muchos métodos de retroalimentación, Observación de Participantes, Evaluaciones Heurísticas, entre otros.
44. Evaluación Heurística Basado en crítica. Originalmente creadas por Jakob Nielsen. Se pueden cambiar, no es necesario usar exactamente las mismas siempre.
45. Puede ser conducido en cualquier paso de creación de la interface. Desde el inicio desde que hay mockups, hasta luego de haber lanzado la aplicación. La idea es darle ciertos parámetros de estas evaluaciones a un grupo de personas para que evalúen el diseño y flujo en base a estos valores.
46. Luego de esta evaluación se recolecta la retroalimentación y se decide cuales son los aspectos más importantes a ejecutar. Se le da un puntaje del 1 - 4 de acuerdo a la gravedad que represente el fallo. Nuestra meta es hacer la interface en la que estemos trabajando más usable y natural de usar.
47. 10 HEURÍSTICAS DE DISEÑ0 ENTENDIMIENTO Ayudamos al usuario a entender la aplicación. 1. Consistencia 2. Uso de metáfora y lenguaje familiar 3. Diseño limpio, funcional y minimalista.
48. 1. CONSISTENCIA Nuestro cerebro ejecuta acciones en base a experiencias pasadas, por ende es super importante que nuestros diseños sean consistentes.
49. Los elementos dentro del layout deben ser consistentes, en color, tamaño, posición y forma. 1.1 CONSISTENCIA EN EL LAYOUT
51. 1.2 CONSISTENCIA EN LOS NOMBRES Los nombres que usemos dentro de nuestra aplicación deben ser los mismos para nuestra navegación, secciones y títulos.
53. 1.3 CONSISTENCIA EN OPCIONES Las opciones que se le dan al usuario deben aparecer cuando el usuario las espera como parte del flujo.
54. 1.3 CONSISTENCIA EN OPCIONES
55. 1.4 CONSISTENCIA EN OPCIONES CLARAS Debemos ofrecer opciones claras al usuario. Hacer pensarlo y leer lo menos posible.
56. 1.4 CONSISTENCIA EN OPCIONES CLARAS
57. 2. USO DE METÁFORAS Y LENGUAJE FAMILIAR Se nos hace más fácil reconocer imágenes y términos que vemos, usamos y reconocemos de la vida real.
58. 2.1 metÁfora Uso de mismos elementos o conceptos de la vida real en el software
59. 2.1 metÁfora
60. 3. DISEÑO LIMPIO, FUNCIONAL Y MINIMALISTA “Form follows function”. La forma sigue la función.
61. 3.1 encima del FOLD La idea es que la información más importante para tu usuario la encuentre encima del primer fold de la página
62. 3.1 encima del FOLD
63. 3.2 seÑal vs. ruido Los elementos que tienen tu interface ¿Comunican algo al usuario? o ¿Hacen ruido a la experiencia?
64. 3.2 seÑal vs. ruido
65. 3.3 funcionalidad Debemos considerar el tipo de funcionalidad que construimos como parte de la aplicación. Menos es SIEMPRE más. ¿Es el tipo de funcionalidad que buscan nuestros usuarios?
66. 3.3 funcionalidad
67. ACCIÓN Ayudamos al usuario a actuar con nuestra interface. 4. Libertad 5. Flexibilidad 6. Reconocer por encima que recordar 10 HEURÍSTICAS DE DISEÑ0
68. 4.LIBERTAD Libertad para explorar los diferentes flujos de la aplicación sin forzar al usuario a ir por uno en específico. Esta definición depende de con qué frecuencia el usuario ejecuta la acción. También influye qué tanta experiencia tiene nuestro usuario.
69. 4.1 explorar El sistema permite al usuario explorar diferentes opciones antes de tomar la decisión final.
70. 4.1 explorar
71. 4.2 regresar (undo) El sistema permite al usuario regresar, cambiar de opinión o editar.
72. 4.2 regresar (undo)
73. 5. FLEXIBILIDAD Interfaces exitosas ofrecen flujos flexibles para que los expertos sean más eficientes.
74. 5.1 shortcuts Si tenemos shortcuts definidos, nuestros usuarios podrán ejecutar los comandos con más eficiencia.
75. 5.1 shortcuts
77. 5.2 opciones por defecto y abiertas Ofrecer la posibilidad al usuario de escoger entre las opciones más seleccionadas y también ofrecerles agregar la data que buscan.
78. 5.2 opciones por defecto y abiertas
79. 5.3 información ambiental Este principio viene de la idea de que podemos tomar mejores decisiones si tenemos un poco de información de contexto.
81. 5.4 proactivo Nuestros sistemas deben ser proactivos y ofrecer ayuda a nuestros usuarios antes de que lo necesiten.
82. 5.4 proactivo
83. 5.5 recomendaciones Al nuestro sistema saber las opciones que nos gustan nos pueden recomendar opciones similares que nos podrían gustar también.
84. 5.5 recomendaciones
85. 5.6 relevante La información que mostramos o proponemos a nuestros usuarios debe ser de su interés y relevante a lo que buscan.
86. 5.6 relevante
87. 6. RECONOCER POR ENCIMA QUE RECORDAR ESTO ES CLAVE! Se basa en que se entienda la acción a ejecutar en vez de que el usuario se tenga que recordar opciones o acciones.
88. 6.1 evita cÓDigos Las opciones que tienen nuestros usuarios deben ser claras. Evitemos leyendas o explicaciones para ejecutar una acción.
89. 6.1 evita cÓDigos
90. 6.2 pasos extra Evitemos que nuestros usuarios tengan que dar pasos extras para llegar al mismo flujo. Analiza los pasos para ejecutar una acción y refactoriza lo que no sea necesario.
91. 6.2 pasos extra
92. 6.3 preview (vista miniatura) Enséñale al usuario de una manera visual lo que está seleccionando.
93. 6.3 preview (vista miniatura)
94. RETROALIMENTACIÓN Le explicamos al usuario su status dentro del app. 7. Mostrar estado 8. Prevenir errores 9. Apoyar la recuperación de los errores 10. Proporcionar ayuda 10 HEURÍSTICAS DE DISEÑ0
95. 7. MOSTRAR ESTADO Esto es parte de la retroalimentación. Cuando diseñemos una interface mostremos la respuesta o dónde esta el usuario en qué parte del flow.
96. 7.1 TIEMPO DE RESPUESTA Si le respuesta toma más de 1 segundo en producirse siempre es bueno mostrar el status de espera o búsqueda. Un preloader o algo que muestre que el sistema responderá pronto. Esto evita que el usuario piense que algo pasó y se vaya.
97. 7.1 TIEMPO DE RESPUESTA
98. 7.2 ESPACIO Así como mostramos un progreso en el tiempo, también lo podemos mostrar en espacio. Ciertas aplicaciones tienen un espacio limitado. Es buena idea mostrarle al usuario cuanto les queda disponible.
99. 7.2 ESPACIO
100. 7.3 CAMBIO Cuando ejecutamos un cambio en un archivo, es bueno que el sistema nos avise que hay cambios que se perderán si la acción no es ejecutada o salvada. En la mayoría de los casos el botón por defecto que se debe seleccionar esta resaltado. Y es el ejecutado al darle enter.
101. 7.3 CAMBIO
102. 7.4 siguientes pasos Mostrar al usuario después de haber ejecutado la acción que queríamos ¿qué debe hacer? ¿cual es el siguiente flujo después de haber culminado el flujo inicial?
103. 7.4 siguientes pasos
104. 7.5 terminaciÓN Una vez que el flujo ha sido culminado, debemos dejar saber al usuario que ha culminado.
105. 7.5 terminaciÓN
106. 8. PREVENIR ERRORES El punto anterior de mostrar estados nos ayudará a prevenir errores de los usuarios.
107. 8.1 prevenir pérdida de data Notificar al usuario antes de que sobre escriba o pierda la data que ha trabajado.
108. 8.1 prevenir pérdida de data
109. 8.3 prevenir LOS FLUJOS CONFUSOS Eliminar las opciones extras que no ofrecen valor al usuario y lo que pueden ayudar es a confundir y tener un mal resultado.
110. 8.3 prevenir LOS FLUJOS CONFUSOS
111. 8.4 prevenir mala data (bad input) Ofrecerle al usuario las opciones ya escritas para prevenir errores de syntax, typos, etc.
112. 8.4 prevenir mala data (bad input)
113. 9. APOYAR LA RECUPERACIÓN DE ERRORES Tratamos de evitar que el usuario cometa errores. Pero cuando los errores pasen debemos hacerlos claros al usuario para que sepa como salir de ellos.
114. 9.1 hacer claros los problemas Si llegamos a un error dentro del app. Necesitamos dejar saber al usuario qué generó ese error y cómo debe salir de el.
115. 9.1 hacer claros los problemas
116. 9.2 ofrecer soluciones Debemos ofrecer siempre soluciones de como salir del error que se me presenta.
117. 9.2 ofrecer soluciones
118. 9.3 proponer una alternativa Cuando el sistema no encuentra o no permite ciertas acciones debemos proponer una alternativa a nuestros usuarios.
119. 9.3 proponer una alternativa
120. 10. PROPORCIONAR AYUDA Brindar ayuda a nuestros usuarios debe siempre ser una de nuestras metas primordiales y no ideas secundarias.
121. 10.4 mostrar los pasos Debemos mostrar al usuario los pasos a seguir y donde nos encontramos dentro del flujo en general.
122. 10.4 mostrar los pasos
123. 10.8 ayudar a la gente a divertirse Algunas veces debemos perder la formalidad y hacer nuestras interfaces más divertidas.
124. 10.8 ayudar a la gente a divertirse
125. 10.8 ayudar a la gente a divertirse
126. CONCLUSION “Be the change you want to see in the world” … and innovate! there is so much more to do!
128. credits - coursera
129. Q & A Preguntas, dudas, acotaciones. Hola!!! :) Si quieres saludar luego: @bellatrixmartnz bellatrix@softwarecriollo.com