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.

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