HUMAN-CENTERED DESIGN
por Bellatrix Martinez
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?
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.
Memex. Escritorio interactivo.
Computadoras del tamaño de un cuarto estaban siendo construidas…
En 1950 Grace Hopper creó el primer
compilador.
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.
En 1968 Doug Engelbart creó el Mouse.
Estuvo sumamente inspirado por el artículo
que escribió Bush en 1945.
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.”
…y construyó el prototipo de su computadora
personal…Dynobook.
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.
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.”
¿Cómo CREAR INNOVACIÓN?
Para crear un producto necesitamos:
1 2 3
Entrevistas Prototipos
- Storyboards
- Mockups - low
- Mockups - high
- Interacción
Feedback
ENTREVISTAS
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.
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.
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.
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?
PROTOTIPOS
¿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.
“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.
Hartmut Esslinger fue la persona que ejecuto la mayoría de los prototipos para Steve Jobs.
Apple lleva más de
30 años estudiando
y haciendo
prototipos de lo que
hoy conocemos
como iPhone, iPad y
iWatch.
Facebook (launched in 2004)
Twitter (launched in 2006)
eBay (launched in 1995)
Airbnb (launched in 2008)
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.
¿CÓMO CREAMOS
UN PROTOTIPO?
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.
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.
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.
mockups - LOW FIDELITY
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.
mockups - HIGH FIDELITY
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.
INTERACCIÓN
RETROALIMENTACIÓN
Hay muchos métodos de retroalimentación,
Observación de Participantes, Evaluaciones
Heurísticas, entre otros.
Evaluación Heurística
Basado en crítica.
Originalmente creadas por Jakob Nielsen.
Se pueden cambiar, no es necesario usar
exactamente las mismas siempre.
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.
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.
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.
1. CONSISTENCIA
Nuestro cerebro ejecuta acciones en base a experiencias
pasadas, por ende es super importante que nuestros
diseños sean consistentes.
Los elementos dentro del layout deben ser
consistentes, en color, tamaño, posición y forma.
1.1 CONSISTENCIA EN EL LAYOUT
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.
1.3 CONSISTENCIA EN OPCIONES
Las opciones que se le dan al usuario deben
aparecer cuando el usuario las espera como
parte del flujo.
1.3 CONSISTENCIA EN OPCIONES
1.4 CONSISTENCIA EN OPCIONES CLARAS
Debemos ofrecer opciones claras al usuario.
Hacer pensarlo y leer lo menos posible.
1.4 CONSISTENCIA EN OPCIONES CLARAS
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.
2.1 metÁfora
Uso de mismos elementos o conceptos de la
vida real en el software
2.1 metÁfora
3. DISEÑO LIMPIO,
FUNCIONAL Y MINIMALISTA
“Form follows function”.
La forma sigue la función.
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
3.1 encima del FOLD
3.2 seÑal vs. ruido
Los elementos que tienen tu interface
¿Comunican algo al usuario? o ¿Hacen ruido
a la experiencia?
3.2 seÑal vs. ruido
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?
3.3 funcionalidad
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
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.
4.1 explorar
El sistema permite al usuario explorar diferentes
opciones antes de tomar la decisión final.
4.1 explorar
4.2 regresar (undo)
El sistema permite al usuario regresar,
cambiar de opinión o editar.
4.2 regresar (undo)
5. FLEXIBILIDAD
Interfaces exitosas ofrecen flujos flexibles para que los
expertos sean más eficientes.
5.1 shortcuts
Si tenemos shortcuts definidos, nuestros
usuarios podrán ejecutar los comandos
con más eficiencia.
5.1 shortcuts
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.
5.2 opciones por defecto y abiertas
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.
5.4 proactivo
Nuestros sistemas deben ser proactivos y
ofrecer ayuda a nuestros usuarios antes de que
lo necesiten.
5.4 proactivo
5.5 recomendaciones
Al nuestro sistema saber las opciones que nos
gustan nos pueden recomendar opciones
similares que nos podrían gustar también.
5.5 recomendaciones
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.
5.6 relevante
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.
6.1 evita cÓDigos
Las opciones que tienen nuestros usuarios
deben ser claras. Evitemos leyendas o
explicaciones para ejecutar una acción.
6.1 evita cÓDigos
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.
6.2 pasos extra
6.3 preview (vista miniatura)
Enséñale al usuario de una manera visual lo que
está seleccionando.
6.3 preview (vista miniatura)
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
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.
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.
7.1 TIEMPO DE RESPUESTA
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.
7.2 ESPACIO
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.
7.3 CAMBIO
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?
7.4 siguientes pasos
7.5 terminaciÓN
Una vez que el flujo ha sido culminado,
debemos dejar saber al usuario que ha
culminado.
7.5 terminaciÓN
8. PREVENIR ERRORES
El punto anterior de mostrar estados nos ayudará a prevenir
errores de los usuarios.
8.1 prevenir pérdida de data
Notificar al usuario antes de que sobre escriba o
pierda la data que ha trabajado.
8.1 prevenir pérdida de data
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.
8.3 prevenir LOS FLUJOS CONFUSOS
8.4 prevenir mala data (bad input)
Ofrecerle al usuario las opciones ya escritas para
prevenir errores de syntax, typos, etc.
8.4 prevenir mala data (bad input)
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.
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.
9.1 hacer claros los problemas
9.2 ofrecer soluciones
Debemos ofrecer siempre soluciones de como
salir del error que se me presenta.
9.2 ofrecer soluciones
9.3 proponer una alternativa
Cuando el sistema no encuentra o no permite
ciertas acciones debemos proponer una
alternativa a nuestros usuarios.
9.3 proponer una alternativa
10. PROPORCIONAR AYUDA
Brindar ayuda a nuestros usuarios debe siempre ser una de
nuestras metas primordiales y no ideas secundarias.
10.4 mostrar los pasos
Debemos mostrar al usuario los pasos a seguir y
donde nos encontramos dentro del flujo en
general.
10.4 mostrar los pasos
10.8 ayudar a la gente a divertirse
Algunas veces debemos perder la formalidad y
hacer nuestras interfaces más divertidas.
10.8 ayudar a la gente a divertirse
10.8 ayudar a la gente a divertirse
CONCLUSION
“Be the change you want to see in the world”
…
and innovate! there is so much more to do!
credits - coursera
Q & A
Preguntas, dudas, acotaciones.
Hola!!! :)
Si quieres saludar luego:
@bellatrixmartnz
bellatrix@softwarecriollo.com

Human centered design

  • 1.
  • 2.
    Human-centered design esun 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 lainteracciÓ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.
  • 5.
    Computadoras del tamañode un cuarto estaban siendo construidas…
  • 6.
    En 1950 GraceHopper creó el primer compilador.
  • 7.
    Ivan Sutherland (fatherof 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 DougEngelbart creó el Mouse. Estuvo sumamente inspirado por el artículo que escribió Bush en 1945.
  • 10.
    Alan Kay estabaen 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ó elprototipo de su computadora personal…Dynobook.
  • 12.
    Pasó más deuna 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 de3 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? Paracrear un producto necesitamos: 1 2 3 Entrevistas Prototipos - Storyboards - Mockups - low - Mockups - high - Interacción Feedback
  • 16.
  • 17.
    entrevistas Las personas queentrevistemos 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 quelas 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 esrecolectar 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.
  • 22.
    ¿quÉ es unprototipo? 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 wayto 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 fuela persona que ejecuto la mayoría de los prototipos para Steve Jobs.
  • 27.
    Apple lleva másde 30 años estudiando y haciendo prototipos de lo que hoy conocemos como iPhone, iPad y iWatch.
  • 28.
  • 29.
  • 30.
  • 31.
  • 32.
    ENTREGAS TEMPRANAS YRÁ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.
  • 34.
    storyboards Los storyboards notienen 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 fasese 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 - LOWFIDELITY 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 - LOWFIDELITY
  • 39.
    mockups - HIGHFIDELITY 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.
  • 41.
    INTERACCIÓN En el pasadose 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.
  • 43.
    RETROALIMENTACIÓN Hay muchos métodosde retroalimentación, Observación de Participantes, Evaluaciones Heurísticas, entre otros.
  • 44.
    Evaluación Heurística Basado encrítica. Originalmente creadas por Jakob Nielsen. Se pueden cambiar, no es necesario usar exactamente las mismas siempre.
  • 45.
    Puede ser conducidoen 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 estaevaluació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 DEDISEÑ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 cerebroejecuta acciones en base a experiencias pasadas, por ende es super importante que nuestros diseños sean consistentes.
  • 49.
    Los elementos dentrodel layout deben ser consistentes, en color, tamaño, posición y forma. 1.1 CONSISTENCIA EN EL LAYOUT
  • 51.
    1.2 CONSISTENCIA ENLOS 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 ENOPCIONES Las opciones que se le dan al usuario deben aparecer cuando el usuario las espera como parte del flujo.
  • 54.
  • 55.
    1.4 CONSISTENCIA ENOPCIONES CLARAS Debemos ofrecer opciones claras al usuario. Hacer pensarlo y leer lo menos posible.
  • 56.
    1.4 CONSISTENCIA ENOPCIONES CLARAS
  • 57.
    2. USO DEMETÁ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 demismos elementos o conceptos de la vida real en el software
  • 59.
  • 60.
    3. DISEÑO LIMPIO, FUNCIONALY MINIMALISTA “Form follows function”. La forma sigue la función.
  • 61.
    3.1 encima delFOLD La idea es que la información más importante para tu usuario la encuentre encima del primer fold de la página
  • 62.
  • 63.
    3.2 seÑal vs.ruido Los elementos que tienen tu interface ¿Comunican algo al usuario? o ¿Hacen ruido a la experiencia?
  • 64.
  • 65.
    3.3 funcionalidad Debemos considerarel 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.
  • 67.
    ACCIÓN Ayudamos al usuarioa 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 explorarlos 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 sistemapermite al usuario explorar diferentes opciones antes de tomar la decisión final.
  • 70.
  • 71.
    4.2 regresar (undo) Elsistema permite al usuario regresar, cambiar de opinión o editar.
  • 72.
  • 73.
    5. FLEXIBILIDAD Interfaces exitosasofrecen flujos flexibles para que los expertos sean más eficientes.
  • 74.
    5.1 shortcuts Si tenemosshortcuts definidos, nuestros usuarios podrán ejecutar los comandos con más eficiencia.
  • 75.
  • 77.
    5.2 opciones pordefecto 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 pordefecto y abiertas
  • 79.
    5.3 información ambiental Esteprincipio viene de la idea de que podemos tomar mejores decisiones si tenemos un poco de información de contexto.
  • 81.
    5.4 proactivo Nuestros sistemasdeben ser proactivos y ofrecer ayuda a nuestros usuarios antes de que lo necesiten.
  • 82.
  • 83.
    5.5 recomendaciones Al nuestrosistema saber las opciones que nos gustan nos pueden recomendar opciones similares que nos podrían gustar también.
  • 84.
  • 85.
    5.6 relevante La informaciónque mostramos o proponemos a nuestros usuarios debe ser de su interés y relevante a lo que buscan.
  • 86.
  • 87.
    6. RECONOCER POR ENCIMAQUE 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 Lasopciones que tienen nuestros usuarios deben ser claras. Evitemos leyendas o explicaciones para ejecutar una acción.
  • 89.
  • 90.
    6.2 pasos extra Evitemosque 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.
  • 92.
    6.3 preview (vistaminiatura) Enséñale al usuario de una manera visual lo que está seleccionando.
  • 93.
  • 94.
    RETROALIMENTACIÓN Le explicamos alusuario 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 Estoes 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 DERESPUESTA 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 DERESPUESTA
  • 98.
    7.2 ESPACIO Así comomostramos 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.
  • 100.
    7.3 CAMBIO Cuando ejecutamosun 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.
  • 102.
    7.4 siguientes pasos Mostraral 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.
  • 104.
    7.5 terminaciÓN Una vezque el flujo ha sido culminado, debemos dejar saber al usuario que ha culminado.
  • 105.
  • 106.
    8. PREVENIR ERRORES Elpunto anterior de mostrar estados nos ayudará a prevenir errores de los usuarios.
  • 107.
    8.1 prevenir pérdidade data Notificar al usuario antes de que sobre escriba o pierda la data que ha trabajado.
  • 108.
  • 109.
    8.3 prevenir LOSFLUJOS 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 LOSFLUJOS CONFUSOS
  • 111.
    8.4 prevenir maladata (bad input) Ofrecerle al usuario las opciones ya escritas para prevenir errores de syntax, typos, etc.
  • 112.
    8.4 prevenir maladata (bad input)
  • 113.
    9. APOYAR LA RECUPERACIÓN DEERRORES 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 claroslos 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 claroslos problemas
  • 116.
    9.2 ofrecer soluciones Debemosofrecer siempre soluciones de como salir del error que se me presenta.
  • 117.
  • 118.
    9.3 proponer unaalternativa Cuando el sistema no encuentra o no permite ciertas acciones debemos proponer una alternativa a nuestros usuarios.
  • 119.
    9.3 proponer unaalternativa
  • 120.
    10. PROPORCIONAR AYUDA Brindarayuda a nuestros usuarios debe siempre ser una de nuestras metas primordiales y no ideas secundarias.
  • 121.
    10.4 mostrar lospasos Debemos mostrar al usuario los pasos a seguir y donde nos encontramos dentro del flujo en general.
  • 122.
  • 123.
    10.8 ayudar ala gente a divertirse Algunas veces debemos perder la formalidad y hacer nuestras interfaces más divertidas.
  • 124.
    10.8 ayudar ala gente a divertirse
  • 125.
    10.8 ayudar ala gente a divertirse
  • 126.
    CONCLUSION “Be the changeyou want to see in the world” … and innovate! there is so much more to do!
  • 128.
  • 129.
    Q & A Preguntas,dudas, acotaciones. Hola!!! :) Si quieres saludar luego: @bellatrixmartnz bellatrix@softwarecriollo.com