-
En este video vamos a introducir una técnica llamada Evaluación Heurística.
-
Como hemos hablado al principio del curso, hay un montón de maneras diferentes de evaluar el software.
-
Uno que podría estar más familiarizados con los métodos empíricos es,
-
donde, por cierto nivel de formalidad, hay personas reales probando el software.
-
También es posible disponer de métodos formales, donde se está construyendo un modelo
-
de cómo se comporta la gente en una situación particular,
-
y que le permite predecir la cantidad de interfaces de usuario diferentes funcionará.
-
O, si no se puede construir un modelo cerrado de forma oficial,
-
también puede probar la interfaz con la simulación y tienen pruebas automatizadas -
-
que puede detectar errores de usabilidad y diseños eficaces.
-
Esto funciona especialmente bien para los de bajo nivel de cosas, es más difícil de hacer para un mayor nivel de cosas.
-
Y lo que vamos a hablar hoy se basa la crítica de los enfoques,
-
donde la gente te está dando retroalimentación directa, con base en su experiencia o un conjunto de heurísticas.
-
Como cualquiera de ustedes que han tomado alguna vez un arte o conocimientos clase de diseño,
-
la crítica de los compañeros puede ser una forma muy efectiva de retroalimentación,
-
y puede hacer que usted hace sus diseños aún mejor.
-
Usted puede conseguir realmente la crítica por pares en cualquier etapa de su proceso de diseño,
-
pero me gustaría destacar un par que creo que puede ser muy valiosa.
-
En primer lugar, es muy valioso para conseguir crítica por pares antes de las pruebas de usuario,
-
porque eso ayuda a no perder a sus usuarios en cosas que sólo va a ser recogido de forma automática.
-
¿Quieres ser capaz de enfocar los recursos valiosos de pruebas de usuario
-
en cosas que otra gente no sería capaz de captar.
-
La retroalimentación cualitativa rica que la crítica entre pares ofrece
-
También puede ser muy valioso antes de rediseño de su aplicación,
-
porque lo que se puede hacer es que puede mostrar qué partes de tu aplicación es probable que desee guardar,
-
y cuáles son otras partes que son más problemáticas y merecen rediseño.
-
En tercer lugar, a veces, usted sabe que hay problemas,
-
y lo que necesita datos para poder convencer a otros actores para hacer los cambios.
-
Y la crítica de los compañeros puede ser una gran manera, sobre todo si es estructurado,
-
para poder obtener la información que necesita, para hacer los cambios que usted sabe que es necesario que ocurra.
-
Y por último, este tipo de crítica peer estructurado puede ser muy valioso antes de liberar software,
-
porque le ayuda a hacer un lijado final de todo el diseño, y suavizar los bordes ásperos.
-
Al igual que con la mayoría de los tipos de evaluación, por lo general es útil comenzar con un objetivo claro,
-
incluso si lo que en última instancia, aprender es completamente inesperado.
-
Y así, lo que vamos a hablar hoy es una técnica especial llamada Evaluación Heurística
-
Evaluación Heurística fue creada por Jakob Nielsen y sus colegas, hace unos veinte años ahora.
-
Y el objetivo de la evaluación heurística es para ser capaz de encontrar problemas de usabilidad en el diseño.
-
Me enteré de Evaluación Heurística
-
cuando TA'd Intro James Landay a curso HCI, y lo he estado usando y enseñando desde entonces.
-
Es una técnica muy valiosa, ya que permite obtener información muy rápido
-
y es un gran bang-para-el-dinero estrategia.
-
Y las diapositivas que tengo aquí están basados en diapositivas de James para este curso,
-
y los materiales están disponibles en la página web Jacob Nielsen.
-
La idea básica de la evaluación heurística es que usted va a proporcionar un conjunto de personas -
-
a menudo otras partes interesadas en el equipo de diseño o de expertos externos de diseño -
-
con un conjunto de heurísticas o principios,
-
y que van a usarlos para buscar problemas en su diseño.
-
Cada uno de ellos por primera vez vamos a hacer esto de manera independiente
-
y por lo que voy a caminar a través de una variedad de tareas usando su diseño para buscar estos errores.
-
Y verás que diferentes evaluadores van a encontrar problemas diferentes.
-
Y luego van a comunicar y hablar juntos sólo al final, después.
-
Al final del proceso, que van a volver a estar juntos y hablar de lo que encontraron.
-
Y este "independiente en primer lugar, reunir después"
-
es la forma de conseguir una "sabiduría de las masas" beneficio en tener múltiples evaluadores.
-
Y una de las razones por las que estamos hablando de esta primera hora de la clase
-
es que es una técnica que se puede utilizar, ya sea en una interfaz de usuario que trabaja o en bocetos de interfaces de usuario.
-
Y evaluación de manera heurística funciona muy bien en conjunto con prototipos en papel
-
y otras técnicas rápidas y de baja fidelidad que puedan estar usando para obtener sus ideas de diseño fuera muy rápida.
-
Aquí hay diez Neilsen de heurística, y son un conjunto bastante bueno.
-
Dicho esto, no hay nada mágico en estas heurísticas.
-
Ellos hacen un buen trabajo de cubrir muchos de los problemas que se ven en muchas interfaces de usuario;
-
pero se puede añadir en cualquier que desee
-
y deshacerse de cualquiera que no son apropiados para su sistema.
-
Vamos a revisar el contenido de estos diez heurísticos en los próximos dos conferencias,
-
y en esta conferencia me gustaría presentar el proceso que se va a utilizar con estas heurísticas.
-
Así que esto es lo que vamos a tener los evaluadores hacer:
-
Dales un par de tareas a utilizar el diseño para
-
y hacer que cada tarea, paso a paso por varias veces con cuidado.
-
Cuando haces esto, van a mantener la lista de principios de usabilidad
-
como un recordatorio de lo que prestar atención.
-
Ahora que los principios se utilizarán?
-
Creo que diez heurísticas de Nielsen son un comienzo fantástico,
-
y usted puede aumentar aquellos con cualquier otra cosa que sea relevante para su dominio.
-
Por lo tanto, si usted tiene objetivos particulares de diseño que le gustaría que su diseño para lograr, incluyen los de la lista.
-
O, si usted tiene metas específicas que usted ha creado
-
de análisis de la competencia de diseños que están ahí fuera ya,
-
eso es genial.
-
O si hay cosas que has visto tu, u otros diseños sobresalen los casos,
-
esos son objetivos importantes también y puede ser incluido en su lista de heurísticas.
-
Y entonces, evidentemente, lo importante es que usted va a tomar lo que has aprendido de estos evaluadores
-
y utilizar esas violaciónes de la heurística como una forma de solucionar los problemas y rediseño.
-
Vamos a hablar un poco más acerca de por qué es posible que desee tener múltiples evaluadores en lugar de sólo uno.
-
El gráfico de esta diapositiva es una adaptación de la obra de Jacob Nielsen sobre evaluación heurística
-
y lo que vemos es cada cuadrado negro es un error que un determinado evaluador encontró.
-
Un individuo evaluador representa una fila de esta matriz
-
y hay una veintena de evaluadores en este conjunto.
-
Las columnas representan los problemas.
-
Y lo que puedo ver es que hay algunos problemas que fueron encontrados por los evaluadores relativamente pocos
-
y otras cosas que casi todo el mundo encuentra.
-
Así que vamos a llamar a las cosas en la derecha los problemas y las cosas fáciles a los problemas difíciles de izquierda.
-
Y así, en conjunto, lo que podemos decir es que ningún evaluador encontró todos los problemas,
-
y algunos evaluadores, más que otros, y por eso hay gente mejor y peor que se puede hacer esto.
-
¿Por qué no tienen un montón de evaluadores?
-
Bueno, como agregar más evaluadores, que hacen encontrar más problemas;
-
pero es como que va disminuyendo con el tiempo - se pierde ese beneficio con el tiempo.
-
Y así, desde una perspectiva de costo-beneficio es simplemente deja de tener sentido después de un cierto punto.
-
¿Y dónde está el pico de la curva?
-
Es, por supuesto, va a depender de la interfaz de usuario que está trabajando,
-
cuánto está pagando a la gente, cuánto tiempo está implicado - todo tipo de factores.
-
Jakob Nielsen regla de oro para este tipo de interfaces de usuario y la evaluación heurística
-
es que tres o cinco personas tiende a funcionar bastante bien, y esa ha sido mi experiencia también.
-
Y creo que, definitivamente, una de las razones por las que la gente utiliza la evaluación heurística
-
es porque puede ser una forma muy rentable de encontrar problemas.
-
En un estudio que Jacob Nielsen corrió,
-
se estima que el costo de los problemas encontrados con la evaluación heurística fueron $ 500.000
-
y el coste de su realización fue de poco más de 10.000 dólares,
-
y por lo que estima que un 48-fold relación costo-beneficio para esta interfaz de usuario en particular.
-
Obviamente, estos números son parte posterior del sobre, y su kilometraje puede variar.
-
Usted puede pensar en la forma de estimar el beneficio que se obtiene de algo como esto
-
si usted tiene una herramienta de software propio usando algo como aumentos de la productividad -
-
que, si usted está haciendo un sistema de informes de gastos
-
o de otro tipo en la casa-sistema que hará que el tiempo de la gente de manera más eficiente utilizado -
-
eso es una victoria usabilidad grande.
-
Y si tienes el software que usted está haciendo en el mercado abierto,
-
se puede pensar en el beneficio de las ventas u otras medidas por el estilo.
-
Una cosa que podemos obtener de ese gráfico es que los evaluadores tienen más probabilidades de encontrar problemas graves
-
y eso es una buena noticia;
-
y por lo tanto con un número relativamente pequeño de personas,
-
usted es bastante probable que tropezar con las cosas más importantes.
-
Sin embargo, como hemos visto con una sola persona, en este caso particular,
-
incluso mejor el evaluador encontró sólo alrededor de un tercio de los problemas del sistema.
-
Y por eso conjurando un número de evaluadores, digamos cinco,
-
te va a sacar el máximo provecho de los beneficios que se le va a ser capaz de lograr.
-
Si comparamos la evaluación heurística y pruebas de usuario, una de las cosas que vemos
-
es que la evaluación heurística puede ser a menudo mucho más rápido - Se tarda sólo una hora o dos para un evaluador -
-
y la mecánica de obtener una prueba de usuario en servicio puede tomar más tiempo,
-
not even accounting for the fact that you may have to build software.
-
Asimismo, los resultados de la evaluación heurística vienen pre-interpretado
-
ya que los evaluadores están directamente le proporciona problemas y cosas que arreglar,
-
y por lo que le ahorra el tiempo de tener que deducir de las pruebas de usabilidad lo que podría ser el problema o la solución.
-
Ahora, por el contrario, los expertos de caminar a través de su sistema
-
puede generar falsos positivos que en realidad no suceden en un entorno real.
-
Y este hecho se produce, por lo que es la prueba de usuario, más o menos, por definición, va a ser más preciso.
-
Al final del día, creo que es valioso a los métodos alternativos:
-
Todas las técnicas diferentes que se aprenden en esta clase para obtener retroalimentación cada uno puede ser valioso,
-
y que [por] el ciclismo a través de ellos a menudo se pueden obtener los beneficios de cada uno.
-
Y eso puede ser debido a que la evaluación de usuario y pruebas de usuario, usted encontrará diferentes problemas,
-
y mediante la ejecución de HE o algo así al principio del proceso de diseño,
-
podrás evitar el desperdicio de usuarios reales que usted puede traer en el futuro.
-
Así que ahora que hemos visto los beneficios, ¿cuáles son los pasos?
-
Lo primero que debe hacer es obtener todos los evaluadores a la velocidad,
-
sobre cuál es la historia detrás de su software - cualquier conocimiento del dominio necesario que puedan necesitar -
-
y decirles sobre el escenario que usted va a tener que dar un paso adelante.
-
Entonces, obviamente, tiene la fase de evaluación, donde la gente está trabajando a través de la interfaz.
-
Después, cada persona va a asignar una calificación de la gravedad,
-
y lo hace de forma individual en primer lugar,
-
y entonces usted va a agregarse aquellos en el nivel de gravedad del grupo
-
y elaborar un informe global de eso.
-
Y, por último, una vez que tienes este informe global, se puede compartir con el equipo de diseño,
-
y el equipo de diseño puede discutir qué hacer con eso.
-
Realizar este tipo de examen de expertos puede ser realmente agotador,
-
y así para cada uno de los escenarios que usted pone en su diseño,
-
puede ser valioso tener el evaluador pasar por esa situación dos veces.
-
La primera vez, que sólo va a tener una idea de ella, y la segunda vez, que pueden centrarse en elementos más específicos.
-
Si tienes algún sistema walk-up-and-uso, como una máquina expendedora de billetes en alguna parte,
-
entonces usted puede desear para no dar a la gente la información sobre mí en absoluto,
-
porque si hay gente que se acaba de bajar del autobús o el tren,
-
y se acercan a su máquina sin ninguna información previa,
-
esa es la experiencia que usted desea que sus evaluadores a tener.
-
Por otro lado, si vamos a tener un sistema genómico o de otro experto interfaz de usuario,
-
usted querrá asegurarse de que cualquier entrenamiento que le daría a los usuarios reales,
-
le vamos a dar a los evaluadores también.
-
En otras palabras, cualquiera que sea el fondo es, debe ser realista.
-
Cuando los evaluadores están caminando a través de su interfaz,
-
que va a ser importante para generar una lista de problemas muy específicos
-
y explicar los problemas con respecto a una de las heurísticas de diseño.
-
Usted no quiere que la gente sólo para estar, como, "No me gusta".
-
Y para maxilinearly que predica estos resultados para el equipo de diseño;
-
usted querrá una lista de cada uno de ellos por separado, para que puedan ser tratados eficazmente.
-
Listas separadas también puede ayudarle a evitar enumerar el mismo problema repetido una y otra vez.
-
Si hay un elemento que se repite en cada pantalla solo, no quiero enumerar en cada pantalla individual;
-
desea que lista una vez de modo que se pueda fijar de una vez.
-
Y estos problemas pueden ser muy detalladas, como "el nombre de algo es confuso",
-
o puede ser algo que tiene que ver más con el flujo de la interfaz de usuario,
-
o la arquitectura de la experiencia del usuario y que no está específicamente vinculada a un elemento de la interfaz.
-
Los evaluadores también puede encontrar que le falta algo que debería estar allí,
-
y esto puede ser a veces ambigua con los primeros prototipos, como prototipos de papel.
-
Y lo que usted desea que aclare si la interfaz de usuario es algo que usted cree que es completa,
-
o si hay elementos que faltan intencionales antes de tiempo.
-
Y, por supuesto, a veces hay rasgos que van a ser, obviamente, hay
-
que están implícitos en la interfaz de usuario.
-
Y así, de un suave y relajarse en ellas.
-
Después de que sus evaluadores han pasado a través de la interfaz,
-
cada uno puede asignar de forma independiente el nivel de gravedad de todos los problemas que he encontrado.
-
Y eso va para que pueda asignar recursos para solucionar esos problemas.
-
También puede ayudar a ofrecerle comentarios sobre lo bien que está haciendo
-
en términos de la facilidad de uso del sistema en general,
-
y darle una especie de punto de referencia de sus esfuerzos en este sentido.
-
Las unidades de medidas que los evaluadores van a salir con que va a combinar varias cosas:
-
Se va a combinar la frecuencia, el impacto,
-
y la omnipresencia del problema que estamos viendo en la pantalla.
-
Por lo tanto, algo que sólo está en un lugar puede ser mucho menos importante
-
que algo que aparece en la interfaz de usuario completa.
-
Del mismo modo, va a haber algunas cosas como el texto mal alineados,
-
que puede ser poco elegante, pero no es un asesino oferta en términos de su software.
-
Y aquí es el sistema de clasificación de gravedad que Nielsen creó, es obvio que puede usar cualquier cosa que desee:
-
Se extiende de cero a cuatro,
-
donde cero "al final del día su evaluador decide que en realidad no es un problema de usabilidad"
-
todo el camino hasta que sea algo realmente catastrófico que tiene que ser arreglados de inmediato.
-
Y he aquí un ejemplo de un problema particular
-
que nuestra TA Robby encontró cuando estaba tomando CS147 como estudiante.
-
Caminó a través de la interfaz móvil de alguien que tenía un "peso" elemento de entrada a la misma;
-
y se dio cuenta de que una vez que has introducido tu peso, no hay manera de corregir a posteriori.
-
Por lo tanto, eso es un poco torpe, te gustaría arreglarlo - tal vez no un desastre.
-
Y así, lo que se ve aquí es que ha enumerado el tema, que ha dado una clasificación de gravedad,
-
él tiene la heurística que viola, y luego describe exactamente cuál es el problema.
-
Y, por último, después de todos los evaluadores han pasado por la interfaz,
-
enumeraron sus problemas, y las ha combinado en términos de la gravedad e importancia,
-
usted querrá interrogarlo con el equipo de diseño.
-
Esta es una buena oportunidad para poder hablar de temas generales en la interfaz de usuario y la información cualitativa,
-
y le da la oportunidad de ir a través de cada uno de estos elementos
-
y sugerir mejoras de cómo se puede abordar estos problemas.
-
En esta sesión, interrogar, puede ser valioso para el equipo de desarrollo
-
para estimar la cantidad de esfuerzo que se necesitaría para reparar uno de estos problemas.
-
Así, por ejemplo, si tienes algo que es uno en su escala de gravedad y un trato no demasiado grande -
-
que podría tener algo que ver con la letra y de su suciedad fácil de fijar -
-
que le dice "adelante y arreglarlo."
-
Por el contrario, puede tener algo que es una catástrofe
-
que toma mucho más esfuerzo, pero su importancia se llevará a arreglarlo.
-
Y hay otras cosas en la importancia relativa de los costos involucrados
-
simplemente no tienen sentido para hacer frente a estos momentos.
-
Y esta sesión interrogar puede ser una gran manera de generar ideas de diseño futuras,
-
sobre todo cuando se tienen todas las partes interesadas en la habitación,
-
y las ideas sobre cuáles son los problemas con la interfaz de usuario están frescos en sus mentes.
-
En los próximos dos videos que vamos a ir a través de diez Neilsons 'heurística y hablar más sobre lo que significan.
