Diferencias Entre Heuristicas Y Pensamiento En Voz Alta

1,402 views

Published on

Published in: Technology, Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,402
On SlideShare
0
From Embeds
0
Number of Embeds
20
Actions
Shares
0
Downloads
20
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Diferencias Entre Heuristicas Y Pensamiento En Voz Alta

  1. 1. Comparación Entre las Evaluaciones de Pensamiento en Voz Alta y Heurísticas Apoyo SSD4
  2. 2. Introducción <ul><li>HE es una técnica de análisis que se puede usar rápidamente en las primeras etapas de diseño (por ejemplo con usar sólo esquemas de ideas en papel sin haber escrito los procedimientos exactos que se necesitan usar). </li></ul><ul><li>Las evaluaciones de pensamiento en voz alta requieren un diseño más detallado y que sea llevado a cabo en prototipos que se puedan crear en VB </li></ul>
  3. 3. Introducción <ul><li>¿Porqué enseñar ambas técnicas? </li></ul><ul><ul><li>Con HE se pueden descubrir algunos aspectos que no se pueden descubrir usando las evaluaciones pensamiento en voz alta y viceversa. </li></ul></ul><ul><ul><li>Como estas técnicas no cubren exactamente las mismas cosas, el uso de las dos muestran resultados más completos. </li></ul></ul>
  4. 4. Introducción <ul><li>En muchas ocasiones las heurísticas que hemos visto son capaces de predecir con éxito los problemas de usabilidad que aparecen en las evaluaciones de usabilidad de pensamiento en voz alta. </li></ul>
  5. 5. Casos de no coincidencia <ul><li>Aunque muchos incidentes de evaluación de usabilidad de pensamiento en voz alta no confirman las predicciones que se hacen durante la evaluación heurística. </li></ul><ul><li>Esto se puede dar en los siguientes casos: </li></ul>
  6. 6. Casos de no coincidencia <ul><li>La evaluación de pensamiento en voz alta contradice la predicción de HE. </li></ul><ul><ul><li>Esto ocurre cuando la evaluación heurística predice que un aspecto de usabilidad es una característica positiva y debe conservarse en la siguiente versión del sistema, pero los participantes de las evaluaciones pensamiento en voz alta tienen problemas con ese aspecto. </li></ul></ul>
  7. 7. Casos de no coincidencia <ul><li>No resulta ninguna evidencia de la evaluación de pensamiento en voz alta que confirme la predicción de un problema que presentó la evaluación heurística. </li></ul><ul><ul><li>Esto ocurre cuando la evaluación heurística predice un problema de usabilidad, pero la evaluación de pensamiento en voz alta no muestra ninguna evidencia de que el usuario tenga problemas con este aspecto. </li></ul></ul><ul><ul><li>(Nótese que lo que nos preocupa aquí son los problemas, no las características positivas identificadas en la evaluación heurística.) </li></ul></ul>
  8. 8. Casos de no coincidencia <ul><li>En general, si la evaluación heurística predice que un aspecto de usabilidad es una característica positiva, pero los usuarios experimentan problemas con ese aspecto en la evaluación de pensamiento en voz alta —considera la información de pensamiento en voz alta. </li></ul>
  9. 9. Recomendación <ul><li>Por lo general, confía en las observaciones de la información de la evaluación de pensamiento en voz alta sobre los resultados de cualquier técnica analítica. </li></ul>
  10. 10. Casos de no coincidencia <ul><li>Se pueden aplicar dos reglas de dedo a los problemas de usabilidad que se han identificado en las evaluaciones heurísticas pero que no se han confirmado en las evaluaciones de pensamiento en voz alta. </li></ul>
  11. 11. 1a regla <ul><li>Si un problema que se predijo en HE no aparece como problema en las evaluaciones de pensamiento en voz alta, repasa las observaciones de la información de pensamiento en voz alta, específicamente para ver si la situación a la cual se refiere el UAR HE se presentó durante la evaluación </li></ul>
  12. 12. Problema HE no aparece en EPVA <ul><li>Si la situación a la cual se refiere el UAR HE no sucedió, es posible que 1) el UAR HE indique una falsa alarma o 2) que otros usuarios en otras circunstancias tendrán el problema que predijo el HE. </li></ul><ul><li>Esto puede suceder porque sólo has evaluado a varios usuarios realizar ciertas tareas, y es posible que al siguiente usuario que evalues se le presente este problema, no es posible que evalues a todos los usuarios que van a utilizar este sistema. </li></ul>
  13. 13. Problema HE no aparece en EPVA <ul><li>En este caso, si en las evaluaciones hay mas de un usuario que enfrentó la situación y ninguno de estos usuarios tuvo problemas con ese aspecto—confía en la infomación y asígnale a ese problema prioridad baja en la lista de cosas pendientes por modificar. </li></ul>
  14. 14. Problema HE no aparece en EPVA <ul><li>Si la situación a la cual se refiere el UAR HE no sucedió durante la evaluación pensamiento en voz alta o si solo uno de los usuarios enfrenta esta situación, entonces no tienes información confiable que contradiga el problema que predijo el HE. </li></ul><ul><li>Tienes que juzgar el problema de acuerdo a su gravedad, su relación con otros UAR, y la dificultad que tendrás para modificarlo. </li></ul>
  15. 15. 2a regla <ul><li>Si los usuarios reales van a usar el sistema que estás diseñando de forma regular, (como por ejemplo un procesador de datos o una hoja de cálculo), debes corregir los problemas que indica la heurística de flexibilidad y eficiencia de uso —aunque no aparecan en las evaluaciones de pensamiento en voz alta. </li></ul>
  16. 16. 2a regla <ul><li>Esta heurística indica problemas de usabilidad para usuarios expertos, no para usuarios novatos, y las evaluaciones de pensamiento en voz alta no manejan información de usuarios expertos. </li></ul>
  17. 17. Problemas de HE que no pueden demostrarse en práctica <ul><li>Existen varios tipos de problemas que las evaluaciones heurísticas no pueden demostrar en principio y varios que no se demuestran en la práctica </li></ul>
  18. 18. Problemas de HE que no pueden demostrarse en práctica <ul><li>Cuando la HE se hace usando un prototipo en papel (por ejemplo usando solo los diagramas del diseño), no se pueden identificar problemas con la dinámica del sistema. </li></ul><ul><li>Por ejemplo, no se pueden demostrar los problemas de velocidad del sistema —esto es, cuando los usuarios se desesperen porque el sistema se vuelva muy lento.. </li></ul>
  19. 19. Problemas de HE que no pueden demostrarse en práctica <ul><li>La evaluación heurística tampoco puede detectar las situaciones donde las respuestas del sistema son tan lentas que el usuario no sabe que es lo que le sucede al sistema </li></ul>
  20. 20. Problemas de HE que no pueden demostrarse en práctica <ul><li>Estos problemas sólo se pueden ver cuando el usuario usa un prototipo en las evaluaciones de usabildad. </li></ul><ul><li>Solamente cuando un usuario usa el sistema real puede detectar los problemas en el código que hacen que se caiga el sistema. </li></ul>
  21. 21. Problemas de HE que no pueden demostrarse en práctica <ul><li>Las evaluaciones heurísticas suponen que el sistema va a funcionar tal y como fue diseñado </li></ul><ul><li>Finalmente, es seguro que los usuarios van a hacer cosas que tú como analista, no puedes anticipar por ninguna de las técnica analíticas existentes. </li></ul>
  22. 22. Conclusión <ul><li>En donde se presentan situaciones mas complicadas, los usuarios pueden llegar a interpretar los menús de forma inesperadas y pueden recorrer caminos dentro del sistema que tu nunca has explorado. </li></ul>
  23. 23. Conclusión <ul><li>Para tratar de corregir sus errores, utilizan el sistema de manera imprevista, y tratarán de hacer cosas que tu nunca pensaste que fueran posibles con el sistema. </li></ul><ul><li>Observa con cuidado al usuario pues te puede sorprender y dar nuevas ideas para mejorar el sistema </li></ul>

×