design - significado - ¿Cómo puedo pensar como un usuario?
user interface design pdf (19)
Estamos metidos hasta el cuello en un proyecto en este momento, los horarios son ajustados (pero razonables). Nuestra estrategia general es hacer una beta fuerte, lanzarla para pruebas y obtener retroalimentación de nuestros evaluadores.
Muy a menudo, estamos siendo golpeados por pequeñas cosas que giran en espiral en discusiones largas que cuestan mucho tiempo. Todos se reducen a una cosa: si bien sabemos qué características necesitamos, tenemos problemas con los pequeños detalles, cosas como ''¿a dónde debe llegar este mensaje?'' Y ''¿Necesitan estos comentarios inmediatamente, o romperán su flujo, entonces debemos esperar?
Estas son todas las cosas que nuestros probadores DEBERÍAN atrapar, pero
a) Cada error de "baja prioridad" como este agota el tiempo de los problemas críticos
b) Queremos tener un producto lo más fuerte posible
y
c) Incluso el mejor grupo de prueba extrañará cosas de vez en cuando.
Usamos nuestro producto, y sabemos cómo nuestros usuarios usan la versión anterior ... pero todos estamos perdidos en cuanto a cómo pensar como un usuario cuando tratamos de usar la nueva versión (que tiene una gran cantidad de gráficos y cambios subyacentes).
editar - un poco más de fondo:
Estamos escribiendo una aplicación web utilizada por una base de usuarios ampliamente distribuida. Nuestra aplicación es una gran parte de sus trabajos, pero no la más grande (y, por supuesto, solo les importamos cuando no funciona). Hacer que los usuarios reales utilicen nuestro producto es difícil, ya que estamos geográficamente distantes de la ubicación más cercana que sirve como usuario final (Estamos en Ohio, y creo que la ubicación más cercana que atendemos está a más de 3 horas de distancia).
Lo más cerca que podemos llegar es nuestro equipo de Servicio al Cliente (que realmente ha sido de gran ayuda), pero tampoco piensan realmente como los usuarios. También sirven como probadores (realmente los motiva a encontrar errores cuando saben que cualquiera que NO encuentren puede significar un gran aumento en el número de llamadas). Hemos tenido tres (de alrededor de 12 en total) representantes de servicio al cliente aquí la mayor parte de la semana haciendo algunas pruebas preliminares ... también se han involucrado en las discusiones.
Compre una cámara de video económica y fácil de usar, y grabe sus comprobadores con la aplicación. Aún mejor, haga que algunas personas no estén familiarizadas con la aplicación. para usarlo y grabarlos en video. Es relativamente barato, y te sorprendería lo que destacará.
El problema suele ser que incluso los usuarios no saben lo que quieren hasta que realmente están trabajando con el software. A veces, un pequeño descuido puede ser un gran problema de usabilidad, a veces una función bien pensada que fue solicitada por muchos usuarios ve muy poco uso.
Mis sugerencias para disminuir el riesgo de no implementar las funciones de usabilidad correctas:
Eche un vistazo a los usuarios que realmente hacen su trabajo diario. Incluso si usan otro software o ningún software en absoluto. Podrá determinar los artefactos que a menudo necesitan para realizar su trabajo. Verá qué datos necesitan con frecuencia. Concéntrese en los artefactos, datos y flujos de trabajo más utilizados. Deberían ser los más útiles. Los flujos de trabajo exóticos pueden consumir más tiempo para los usuarios que los flujos de trabajo utilizados con frecuencia.
Use prototipos de trabajo de la GUI para que los usuarios puedan trabajar a través de un flujo de trabajo realista. Mírelos y observe lo que los obstaculiza y lo que funciona bien. Ajuste sus prototipos en consecuencia.
Si surge un problema en una parte del software que se usa con frecuencia, es hora de analizarlo ahora y en detalle. Si el problema se refiere a una pieza que rara vez se usa, conviértalo en un tema de baja prioridad y discútalo si tiene tiempo. Si los problemas o sugerencias son de baja prioridad, deben permanecer con baja prioridad. Si no puede determinar si la solución A o la solución B son las mejores, no corra en círculos con los mismos argumentos una y otra vez. Simplemente implemente una de las soluciones y vea si les gusta a los beta testers. Lo peor que puede hacer es perder el tiempo con los pequeños problemas, mientras que los grandes problemas deben solucionarse.
Un software nunca será perfecto, porque los puntos de vista de los usuarios difieren. Algunos usuarios pensarán que un problema menor rompe toda la aplicación. Otros vivirán incluso con graves problemas de usabilidad. La gente tiende a prestar su oído a aquellos que argumentan más fuerte. Conozca a sus usuarios para separar los problemas "fuertes" de los importantes. Se necesita experiencia para hacer esto, y algunas veces se tomarán decisiones incorrectas, pero no hay una manera perfecta, solo una de mejora constante.
Si puede, reserve una cierta cantidad de recursos de desarrollo de usabilidad para la fase de despliegue de su software. Los problemas de usabilidad surgirán cuando las personas comiencen a trabajar con él en un entorno de producción real. A veces no es importante presentar el software perfecto, sino resolver problemas rápidamente a medida que surgen.
Hablando en general, no puedes. No hay forma de que puedas apagar la parte del "programador" de tu cerebro y pensar como un usuario.
Y tiene razón acerca de (c), los grupos de prueba no necesariamente detectan todos los errores. Pero lo mejor que puede hacer es conseguir un grupo de prueba formado por usuarios finales reales y honestos, y valorar sus comentarios. Saca otras conclusiones de sus comentarios generales.
Si desea saber cómo verán los usuarios su sistema, lo más cercano que puede obtener es la prueba de usabilidad con usuarios reales. Todo lo demás es solo heurística y experiencia, y también está sujeto a error. No existe un producto libre de errores, pero debería poder obtener un producto "fuerte" con pruebas de usabilidad.
Intenta usar tu aplicación cuando tengas mucha prisa (p. Ej., Tienes a alguien que espera una cena). Verá todas estas pequeñas cosas porque tiene que esperar, tiene que volver al mouse del teclado, etc.
Y también, haz que tu esposa lo use. O tu madre
Otra prueba útil: ayudar a alguien a usarla, por teléfono. Si no puede encontrar el botón con tus indicaciones, probablemente sea un error.
La forma "correcta" de hacerlo es prototipar (o simular) las nuevas características de la interfaz y ver a los usuarios intentar usarlas. Nada es tan esclarecedor como ver a un usuario real tratar de usar una nueva característica.
Desafortunadamente, dado el tiempo y los recursos de la mayoría de los proyectos, esto no es posible. Si esa es la posición en la que se encuentra, le recomiendo que discuta en el equipo que tenga la mejor comprensión de usabilidad, y luego los haga responsables de las decisiones de usabilidad, pero esa persona necesitará consultar regularmente a los usuarios reales para asegurarse de que sus ideas son consistentes con lo que quieren los usuarios.
La respuesta frívola (aunque algo precisa) a cómo pensar como si un usuario le pusiera una aguja de tejer en el oído y lo empujara con fuerza.
La respuesta más larga es que nosotros como programadores no somos normales y lo digo en una buena forma. Me rasco la cabeza al número de personas que todavía ejecutan ejecutables que reciben de desconocidos en correos electrónicos y luego se preguntan cómo se infectó su computadora.
Cualquier grupo de personas con el tiempo desarrollará su propia jerga, convenciones, prácticas y expectativas. Como programador, usted esperará cosas diferentes de un sistema operativo que Joe User. Esto es natural, de esperar, pero difícil de evitar.
También es por eso que existen BA (analistas de negocios). Por lo general, provienen de un negocio o antecedentes de prueba y no piensan como programadores. Ellos son su enlace a los usuarios.
Realmente, sin embargo, debería hablar con sus usuarios. No hay nada que debata lo que hacen los usuarios. Solo arrastre algunos para ver qué hacen.
Leer No me hagas pensar
Lo importante es obtener suficiente información para que usted mismo pueda convertirse en un "usuario" . Una vez que lo haces, puedes responder la mayoría de las preguntas tú mismo.
La forma en que siempre hago esto es hablar con ellos sobre lo que deben hacer, qué hacen normalmente y cómo usan sus herramientas actuales para hacerlo. Luego ( muy importante ) siéntate con ellos mientras lo hacen. Asegúrate de seguir con ellos lo suficiente como para que puedas volver a ellos con preguntas sobre cómo manejan casos extremos en los que piensas más adelante (a menudo la respuesta será la espantosa "vamos alrededor del sistema manualmente para eso").
Casi siempre notaré algo que están haciendo que es un PITA real que no mencionaron porque están acostumbrados a tener que hacer eso y no saben nada mejor. Siempre notaré que su flujo de trabajo típico% 90 no es el flujo de trabajo más fácil que ofrecen las herramientas.
Realmente no se puede confiar en los simples requisitos anticuados reunidos por sí mismos, porque eso es pedirles que piensen como un desarrollador . Por lo general, no saben qué es posible hacer con su software, qué es fácil y qué es difícil. Además, generalmente no tienen idea de los principios de diseño de la GUI. Si les pide entrada de diseño, simplemente le dirán que ponga cualquier control nuevo en su página favorita, hasta que se vea como un panel de control 747.
Me gusta la política de "comer tu propia comida para perros" (" http://en.wikipedia.org/wiki/Eat_one " s_own_dog_food). Te lleva un paso más cerca, porque te conviertes en un usuario, aunque puedes pensar como tal.
No hay una técnica de "pensar como un usuario", poner sus manos sobre alguien que no sabe nada del proyecto y tirar lo que ha hecho con ellos.
Es la única forma de ver cómo la funcionalidad look + feel + se presenta al usuario final.
Una vez que sorprendió a esa persona que no sabía nada del producto, escuche todas sus quejas idiotas (o eso crees que son), arréglelas, arregle cada cosa estúpida que señalen (ya sea arreglando la UI o mejorando la documentación tu tenias)..
y después de que haya satisfecho a la persona que eligió para mirar su aplicación desde cero conocimiento en la primera ronda del tema, elija otra ... y otra ... hasta que dejen de sorprenderse cuando lo vean, y no se quedan atrapados en .. "ok ... ¿qué hace esto?" tipo de fases
Usted (como miembro del proyecto, ya sea el gerente de proyecto, desarrollador, etc.) nunca pensará que un usuario es mi respuesta a esa pregunta.
Para pensar como un usuario, sea uno. Pero, ¿son estos realmente errores que los probadores están informando? ¿O son "solicitudes de mejora"? Si el software se comporta como se diseñó según los requisitos y simplemente no le gusta la forma en que funciona, eso no es un error. Eso es una falla de requisitos y diseño. Haga que funcione, hágalo sólido como una roca, haga que sea fácil cambiarlo y podrá hacerlo de acuerdo con sus deseos.
Pida a alguien que no tenga absolutamente ningún conocimiento, experiencia o experiencia en programación que use el programa y trate de descubrir cada función del programa.
Las personas que NUNCA usarían dicho programa tienen más probabilidades de encontrar errores.
Véalo como un nuevo usuario de Safari (o FF) que trata de poner la URL dentro del campo de búsqueda ... Como programador, usted adivina que nadie sería tan estúpido (o, bueno, no conocido), pero la gente en realidad a veces encuentra ellos mismos en estas situaciones. Como programador, extrañamos estas cosas.
Puede tomar el enfoque TDD / BDD y lograr que los usuarios participen antes de la versión beta, para que trabajen con usted en los requisitos de refinación a medida que escribe las pruebas de su unidad. Estamos comenzando a incorporar algunas de esas tendencias en nuestro proyecto actual, y estamos viendo menos errores en las áreas donde hemos involucrado a los usuarios anteriormente.
Sugeriría hacer alguna forma de prueba de usabilidad; He participado en eso en el pasado, y los encontré bastante útiles.
Si estuvieras escribiendo un sistema de tickets, por ejemplo, abre las tareas y haz preguntas como "cómo actualizarías este ticket" o "qué esperas que ocurra si se hace clic en este botón".
No necesariamente necesita una aplicación completa, en algunos lugares se pueden usar capturas de pantalla.
Trato a todos los usuarios como idiotas maliciosos.
Malicioso porque supongo que todos los usuarios van a tratar de romper mi código, hacer cosas que no están permitidas, evitar escribir datos válidos y hacer todo lo que esté a su alcance para hacer de mi vida un infierno.
Idiotas porque de nuevo no puedo suponer que entiendan cosas simples como formatos de teléfono, huirán gritando si se presentan a muchas opciones, y no darán un salto de fe en instrucciones complicadas. El objetivo es mantener su mano en todo el camino.
Al mismo tiempo, es importante asegurarse de que el usuario no se dé cuenta de que piensa que es un idiota.
Un grupo de prueba de usabilidad ayudará a ... pruebas que no se centran en descubrir errores, sino en la curva de aprendizaje del nuevo diseño, hecho por un grupo de usuarios, no de programadores.
Un viejo dicho: puedes hacer algo "a prueba de tontos" pero no puedes hacerlo "A prueba de tontos".
Además: cuando haces algo "a prueba de idiotas", el mundo inventa un mejor idiota.
Aparte de eso, estoy de acuerdo con lo que todos los demás dijeron.
Veo algunas buenas sugerencias aquí, especialmente observar a las personas que intentan usar su aplicación. Una cosa que sugeriría es mirar el orden en que las cosas se presentan al usuario en formularios impresos (si usan estos para hacer la entrada de datos) y hacer que la página final de entrada de datos imite ese orden lo más cerca posible. Tantos errores de entrada de datos (y pérdida de velocidad de entrada de datos) provienen de que tienen que saltar por la página y perder su lugar. Hice un poco de trabajo para una campaña política este año y, en todos los casos, ingresar datos se hizo mucho más difícil porque la pantalla de la computadora hacía las cosas en un orden diferente al de las entradas en papel. Esto es particularmente importante si el formulario no se puede cambiar (como un formulario de registro de votante, una campaña tiene que usar lo que proporciona el estado) para que coincida con la pantalla de la computadora. También sea consistente de pantalla a pantalla si es posible. Si es el primer nombre del apellido en un formulario, su nombre y apellido en el siguiente confundirá a las personas y guanteee los errores de ingreso de datos.
Si está realmente interesado en comprender a los usuarios, le sugiero encarecidamente tomar un curso de ingeniería de factores humanos. Es una experiencia iluminadora.
Ver a alguien usando la aplicación es un gran beneficio para mí. Posiblemente alguien que no esté completamente familiarizado con eso.
Ver cómo intentan navegar, cómo intentan ingresar información o ventanas de tamaño. Cosas que damos por sentado después de crear / ejecutar la aplicación hora tras hora, día tras día.
Los usuarios siempre tratarán de hacer las cosas que nunca esperabas y verlas en acción podría sacar a la luz cómo puedes cambiar algo que podría haber parecido menor, pero realmente tiene un gran impacto en ellos.