IxDA Montevideo. User Research.

Notas del editor

• #4: Necesitamos entender al usuario y su experiencia actual; porque siempre tiene una experiencia, sea buena o mala. Todos estamos de acuerdo en esto, sin embargo cuando nos acercamos a un proyecto el pensamiento es…
• #5: Hay muchísimas historias sobre como la innovación falla. Por ejemplo, My Ford Touch. ----
• #6: En el CES de 2010 se presentó esta novedosa idea. Reemplazar el tablero del auto por uno touch que controle el sistema de entretenimiento, clima y navegación, todo centralizado. Cuando se presentó se vio como el tablero del futuro, intuitivo y fácil de usar. Fue instalado en autos, camiones y camionetas. En 2011 Ford cayo del 5to puesto al puesto 23 en la encuesta de calidad de J.D. Power & Associates automotive quality survey. En 2013 cayo del 28rd al 34th. Lo reviews fueron rotundos, el sistema hizo la experiencia de manejar peor, incluso peligroso. Los revendedores llegaron a contratar consultores que estaban siempre ocupados para ayudar a los usuarios con el sistema. El problema fue básico, el sistema no tenía ningún feedback táctil para los controles, necesitaba que quitáramos la atención de la ruta para configurar cosas básicas (https://www.youtube.com/watch?v=H64QTs8qDfI) Muchos de los diseñadores por supuesto eran conductores. El proceso sin embargo no tuvo en cuenta a los usuarios, se encerraron en una sesión de semanas de brainstorming. Pasaron rápidamente a fases de prototipado y testeo por tareas con algunos usuarios. Pero al no testear en contexto el error no sale a la vista tan fácilmente.
• #8: No exactamente. Un brief típico de marketing o publicidad es perfecto par definir un mensaje de comunicación. Pero en nuestro caso no estamos haciendo un anuncio estamos haciendo los zapatos. Podemos usar esta información para comenzar nuestro research pero esta bastante lejos de poder darnos suficiente información para trabajar.
• #9: Estudiar a la competencia es una buena idea, pero sin un conocimiento profundo de los usuarios seguimos sin saber porque usan a la competencia, y las necesidades que buscan cubrir.
• #10: Grooveshark, cambiaron toda su diseño para ser más similar a Spotify. En el camino perdieron features clave como la playlist al vuelo, una de las razones por la que varios usábamos Grooveshark. Podían perfectamente hacer un rediseño sin perder esto.
• #11: Lo que los usuarios dicen que quieren muchas veces no es la mejor solución para sus necesidades, sino simplemente una mejora de la solución que ya conocen. Como la frase de Ford: Si le hubiera preguntado a la gente qué querían, me habrían dicho “caballos más rápidos” También hay que tener presentes algunos comportamientos típicamente humanos: Tendemos a actuar tal cual el grupo espera que hagamos. Tendemos a pensar que estamos en lo correcto y conocemos la verdad. Tendemos a actuar distinto a como pensamos así que la respuestas que demos dependen mucho del contexto. ( http://www.uxbooth.com/articles/design-research/bridging-the-gap-between-actual-and-reported-behavior/ )
• #12: Podemos obtener información para diseñar de cualquiera de estas fuentes. Pero en si mismas no nos permiten respondernos la pregunta...
• #13: Lo clave que necesitamos entender es. ¿Qué es lo que los usuarios quieren hacer?
• #16: Necesitamos saber cierta información básica que apliquen, como sexo, edad, estrato social. Sus conocimientos y experiencia en el área que estamos estudiando. Su conocimiento tecnológico, sus necesidades y metas. Que tareas realiza, que flujo tienen, ¿necesita a alguien más en el proceso? Que software y hardware tienen, ¿usan papeles u otros medios? El entorno; físico y social. ¿Dónde realizan la tarea, hay interrupciones, ruido? ¿Necesitan trabajar en equipo? ¿De que forma? Tenemos que lograr responder: Quién, Cómo, Dónde, Cuándo, Qué, Por qué (que implica una emoción) y Para qué (qué implica una intención).
• #17: Como hablamos los usuarios no siempre dicen lo mismo que hacen. También pueden existir problemas en el diseño que simplemente no pasan por su cabeza directamente, es parte de nuestro trabajo de research descubrirlas. Un buen ejemplo es el caso de OXO, una empresa que se dedica a hacer artículos de cocina.
• #18: Crearon un pequeño research con usuarios en un cuarto con jarras de medida y una pileta. Hicieron pasar 1 a 1 a distintas personas y les hicieron una primera pregunta: ¿Que tienen de malo tu jarra de medida? Surgieron varios problemas como, -“el material vidrio que puede ser pesado y romperse”, -“si uso líquidos calientes a veces es incomoda agarrarla”, -“el agarre a veces es resbaloso sobre todo si están con las manos sucias o engrasadas”. Tomaron nota de cada uno de los puntos que los usuarios comentaron. Siguieron preguntando hasta que le dijeran: -“Sí, es todo.” A continuación les pidieron que les mostraran como la usan habitualmente en la casa. La gente se acerco a la pileta, hecho un poco de agua, se agacho a mirar cuanto liquido había, luego agregaron un poco más, volvieron a agacharse, y así sucesivamente. Este mismo patrón se repitió a lo largo de todos los usuarios. Para los investigadores fue claro que ahí existía un necesidad no resuelta.
• #19: Este caso es llamativo sobre todo porque era un producto que parecía cumplir las necesidades de los usuarios y en el cual el mercado no estaba pidiendo mejoras.
• #21: Especialmente cuando el usuario siquiera entiende claramente la fuente del problema. Como comentamos antes, tenemos que pasar a través de las soluciones que en general el usuario encuentra (y muchas veces se transforman en nuestros requerimientos) y comprender cual es el problema de fondo que intenta solucionar.
• #23: Tenemos un rango de técnicas para usar que van desde la observación a las entrevistas. Por supuestos la técnica elegida dependerá de lo que queramos saber. También estas técnicas pueden combinarse entre sí.
• #24: Ir a un lugar, observar y tomar notas. Es bueno porque podemos observar con tiempo a los usuarios en un contexto real. Sabremos más de cómo la gente actúa de lo que piensa (o dice). Como desventaja podremos crear una serie de presunciones al no entender la intención del comportamiento.
• #25: En la otra punta del espectro esta la entrevista. Esta nos da tiempo con la persona para preguntar y obtener información, incluso reformular o pedir una clarificación si es necesario. La desventaja es que obtendremos lo que la gente piensa o dice en lugar de cómo actúa. Podremos tener una falta de contexto.
• #26: Debemos observar el usuario en su contexto real. A medida que escuchamos, observamos la interacción del usuario con el sistema, el ambiente, otras personas y otros materiales que use mientras completa las tareas. ¿Tiene que llenar un formulario de muchas páginas pero el teléfono suena cada cinco minutos? ¿Tiene muchos campos que jamás llena? Estas situaciones comunes es posible que nunca surjan en una simple conversación. Podemos coordinar una visita en un día típico o que guarden algo de trabajo para el día de la reunión. Si los participantes tienen tareas que no pueden interrumpirse puede ser una mejor solución hacer una entrevista antes, luego observar y al final hacer otra serie de preguntas para clarificar nuestras observaciones. Es importante dejar claro que no es una entrevista, no puede hacerse fuera de contexto, y no puede hacerse con muchos usuarios al mismo tiempo. También debe hacerse sin público presente. Si estas reglas no se aceptan es mejor cancelar la cita y pensar en un método alternativo.
• #28: Estudiar previamente la información que necesitamos, hablar con el cliente para definir que es lo que queremos saber al final del estudio. Elegir algún método de estudio y definir el grupo de usuarios a estudiar. Crear una guía para ayudarnos a trabajar. Una lista de los pasos que seguimos, las preguntas o tareas y espacio para tomar notas. El tiempo y lugar se define con los usuarios. Si lo hacemos por la web podemos usar PowWow ( http://usepowwow.com/ ) Es buena idea al confirmar recordarle las reglas del estudio que estemos haciendo (si es un contextual inquery por ejemplo, recordarles que es personal y que guarden parte de su trabajo).
• #30: Intenta encontrar usuarios reales siempre que sea posible. Testeadores profesionales o usuarios enviados por reclutadoras no siempre son la mejor opción en estos casos.
• #31: Al investigar en contexto, necesitamos observar, tomar notas, hacer preguntas y mantener la comunicación y el tono en un ambiente que no controlamos. Puede ser útil que vayamos de a dos: uno toma notas y otro encargado de dirigir. Para tomar registro es bueno usar los métodos menos intrusivos posibles. Cámaras y micrófonos pueden hacer sentir incomodo al participante y cambie su comportamiento natural (si es que tenemos espacio para ellas). Tomar las fotos si es necesario al final de la sesión. Para tomar notas es una muy buena opción usar un Livescribe.
• #32: Sirve para sacar notas y reproducirlas luego en el momento a través de software. La controlamos con las teclas de la propia hoja. Nos permite escuchar el audio de una nota en particular (mantiene la sincronización audio-texto).
• #33: Muchas veces la persona puede hablar muy poco, o hablar sin parar. Debemos mantener el control del estudio pero siempre abierto el canal de comunicación, hacerlos sentir cómodos y sacarlos del modo examen que pueden sentirse, en general usamos un lenguaje simple. Siempre tenemos que tener cintura para ser flexibles en las preguntas, si es necesario permitir cierta definición de los usuarios con sus propias tareas. En el caso de una investigación en contexto los usuarios tienen que enfocarse en el trabajo, así que puede ser que necesitamos sacarlos del modo entrevista. Para esto es buena táctica usar un modelo de maestro-aprendiz. Ellos son quienes dominan el tema y van a enseñarnos a nosotros sobre eso. Eso nos permite clarificar nuestras ideas y corroborar lo que entendimos, obtener el conocimiento implícito en las tareas. Si en alguna tarea comienza a explicar y hablar de ella, pedirles que nos lo muestren. ¿Cómo harías eso? Otras veces el usuario puede usar la situación para transmitirnos su lista de ideas y problemas, en ese caso podemos tomar nota o llevarla, pero le decimos que la veremos al final y seguimos con nuestro plan.
• #34: Presentarnos de una forma que haga sentir a los participantes a gusto (ropas, actitud también cuentan). Ser lo más informal posible para el contexto. Evitar leading questions y gestos de aprobación o desaprobación. Leading questions son preguntas que asumen hechos, implican una respuesta o simplemente preguntan por una confirmación. En lugar de eso hacer preguntas especificas y con repuesta abierta. Si la pregunta tiene opciones hacerlas que tengan el mismo valor: Hacer al usuario elegir entre la que le parezca más real, no que busque por la correcta.
• #35: Aprender el máximo posible del tema. Entrevistar primero a los interesados para tener una idea general del tema. Observar distintas personas haciendo la misma tarea para mejorar nuestra comprensión. Revisar nuestras notas después. Si usa un lenguaje demasiado complejo, recordar el método de experto-aprendiz y hacer preguntas simples para recordarles que estamos hablando sobre algo que no sabemos.
• #37: Es buena idea después de cada sesión guardar un tiempo para aclarar las notas y pasarlas un poco en limpio. En general calcular 2-3 veces el tiempo de la sesión. Podemos para facilitar el trabajo creando un Spreadsheet. Si es necesario también podemos usar después un diagrama de afinidad para analizar más claramente la información.
• #40: Puede pasar que nuestro cliente nos pida datos cuantitativos. Más aún si ni tuvieron la posibilidad de conocer el proceso de que seguimos. Podemos usar métodos cualitativos o más tradicionales como encuestas o focus groups para contrastar nuestro estudio. La idea es usar nuestros descubrimientos en el estudio de campo para generar estos otros estudios.
• #41: Tenemos que ser creativos al momento de hacer user research.
• #42: Podemos invertir un tiempo limitado con un conjunto limitado de usuarios para mostrar los resultados de los estudios (digamos pedir un par de semanas). Ir a lugares donde estén nuestros usuarios y observar y hablar con ellos. Para obtener información de los usuarios podemos acudir a los grupos de LinkedIn (si son especializados en algún área). De aquí podremos obtener nombres para contactar, intereses, lenguaje usado… Hacer researchs remotos, hacerlos entre gente de la empresa o conocidos que sean parte del target. Que nos muestren que hacen o pedirles un set de tareas más genéricas. Por ejemplo la empresa de computadoras Gateway. A fines de 1990 era un vendedor para usuarios de alto conocimiento que querían poder configurar todos los componentes de su maquina. Cuando decidieron ampliar su mercado a consumidores sin conocimiento crearon un wizard que los ayudara a configurar su compra. En el testeo, en lugar de plantear tareas lo que se hizo fue preguntarle al usuario si estuvo buscando una computadora. “-Sí, para la oficina”. Luego les pidieron que les mostraran como harían para comprar buscar y comprar una máquina. Luego de intentar un poco en el sitio de Gateway se dieron por vencidos y se fueron al sitio de Dell. Este patrón se repitió con varios usuarios, al preguntarle a uno que es lo que estaba buscando específicamente dijo. “Cuando estoy buscando una PC estoy buscando la cosa entera. La caja, con el monitor y la impresora”. Esto llevo a rediseñar el sistema de ventas a uno mucho más simple, similar al que ahora esta usando el Apple Store.
• #43: Recuerden que el objetivo es responder ¿qué es lo que los usuarios quieren hacer? Recabar la mayor cantidad de información real de los usuarios, las necesidades no cumplidas (unmet needs) y los problemas que enfrentan.
• #44: 1. Más detalles del tema. 2, 3, 4. Artículos. 5. Si les interesa en particular conocer métodos sobre como guiar una entrevista ver el libro de Portigal. 6. Muchos ejemplos vienen del libro Customers Included de Mark Hurst.