¿Cómo descubres lo que realmente quieren los usuarios? [cerrado]

https://stackoverflow.com/questions/415260

user-experience

03-07-2019
|

Pregunta

He leído en alguna parte (me olvido de la fuente, lo siento, ¿creo que el blog del desarrollador de MS Office?) que al hacer una encuesta a los usuarios preguntándoles qué funciones les gustaría ver en su software / sitio web, a menudo dirán que quieren todo, mientras que las métricas recopiladas muestran que al final, la mayoría de las personas no usan el 99% de estas funciones. El mensaje general de la publicación del blog fue que no debes preguntar a las personas qué usan, debes rastrearlo por ti mismo.

Esto lleva a una situación desafortunada de gallina y huevo cuando se trata de averiguar qué nueva característica agregar a continuación. Sin la característica ya instalada, no puedo medir cuánto se está utilizando en realidad. Con recursos finitos (y muy extendidos), tampoco puedo permitirme agregar todas las funciones y luego eliminar las que no se usan.

¿Cómo puede saber qué será útil para sus usuarios? Si la encuesta es la única opción, ¿tiene que estructurar sus preguntas de ciertas maneras (por ejemplo: no muestre una lista)? de posibles características, ya que eso los llevaría a)?

Solución

Contrariamente a la creencia popular, no les pregunta. Bueno, no los escuches cuando le dicen a ti lo que quieren. Los miras mientras usan lo que tienen ahora. Si no tienen nada, los escuchas lo suficiente para darles un prototipo, luego los ves usarlos. La forma en que una persona realmente usa el software le dice mucho más de lo que realmente dice que quiere. Observe lo que hacen para descubrir lo que realmente necesitan.

Otros consejos

Déles opciones y pídales que las organicen en orden de importancia. Como dijiste, los usuarios van a querer todo, pero esto te permitirá decir lo que más quieren.

Les dices. Entonces ambos lo saben.

(No, sus usuarios no le dirán lo que quieren. Eso es trabajo. Si los usuarios quisieran más trabajo por hacer, no estarían buscando el software para hacer su trabajo por ellos)

Una anécdota de una vida anterior:

Estábamos planeando una nueva versión y queríamos agregar algunas características nuevas a la aplicación. Reunimos a los usuarios e hicimos una lluvia de ideas sobre las cosas que querían ver en el sistema, colocando cada "característica". En un amarillo pegajoso en un tablero blanco. Luego agrupamos solicitudes similares y eliminamos duplicados o cerca de dups.

Luego colocamos cada adhesivo sobre una mesa con una taza delante. Cada usuario obtuvo 10 centavos para " votar " En las características que querían. Podrían poner tantos centavos en cada taza como quisieran, hasta todos sus centavos en una taza si así lo deseaban. Luego contamos el número de centavos en cada taza y elegimos implementar los 5 principales captadores de votos, en orden de votos.

Fue sorprendente ver a personas que se apasionaban por una característica mientras intercambiaban ideas y categorizaban, y no votaban por esa característica (o votaban a la ligera por ella).

Por supuesto, una técnica como esta solo funcionará si tiene acceso inmediato a su base de usuarios (esto fue para un sistema empresarial que desarrollamos internamente).

Les preguntas.

(No, no sabes lo que tus usuarios quieren mejor que ellos. Sí, obtendrás muchas respuestas estúpidas. Evita las encuestas de opción múltiple y en su lugar opta por revisar las respuestas de forma libre. La información que recopiles será ser invaluable.)

Por supuesto & # 8212; siempre puede permitir que sus usuarios voten sobre las funciones que más les gustan ...

Los usuarios saben lo que no quieren mejor de lo que saben lo que quieren.

Hemos traído un equipo para hacer una implementación de Oracle eBusiness Suite. Adoptaron un enfoque interesante que les había funcionado muy bien en el pasado. Pero fue fenomenal en nuestro entorno.

Teníamos problemas culturales, lo que significaba que ninguno de los usuarios se iba a quedar para decir lo que quería. Tenía historia con los usuarios del pasado. Tratar de obtener requisitos de ellos era como tratar de sacar sangre de una piedra. Pero una vez que te pusiste en marcha, la queja comenzaría.

De todos modos, el equipo de implementación instaló Oracle eBusiness Suite directamente. Brinde a los usuarios la capacitación básica. Luego, aproximadamente cada 4 semanas durante los siguientes 6 meses, personalizaron la instalación base para acomodar las quejas.

Recomendaría no mostrarles opciones; Como señala, si está disponible, entonces la gente lo querrá solo por tenerlo. A menudo, los usuarios no son conscientes de los costos adicionales de desarrollar una característica en particular, y solo la quieren porque mencionaste la posibilidad de tenerla.

La otra opción es mostrar una lista de todas las características que posiblemente podría agregar, y luego adjuntar un precio a cada una, y luego preguntar a los usuarios, ¿valdría $ X tener la característica Y, o cuánto más? ¿Estaría dispuesto a pagar por la característica Y?

Coma su propia comida para perros

Intenta utilizar la aplicación que escribes tú mismo tanto como sea posible. Entonces sabrás cómo puedes mejorar tu aplicación.

De acuerdo con el 37 Señales: Obtención real del libro, no hace nada, no hace nada. incluso si registra lo que desean, simplemente borra los correos después de una lectura sin ninguna acción.

Cuando se trata de implementar / arreglar cosas, recordará las cosas más importantes que sus usuarios desean desde lo más alto de su cabeza. Obviamente, esto requiere un poco de base de usuarios.

Debe vincular las características con el costo. Todos quieren funciones, pero no vale la pena pagar por todas las funciones. Pregunte qué funciones son las más importantes, ¿por qué estarían dispuestos a pagar sus usuarios? Desarrolle funciones basadas en las prioridades proporcionadas por los usuarios y deténgase cuando ya no estén dispuestos a pagar. Consiga el producto en sus manos lo más rápido posible para que pueda obtener comentarios reales sobre lo que no funciona y lo que debe agregarse. Cuando los usuarios tienen acceso a software real, obtienes mucha mejor información. Esto funciona mejor cuando se está desarrollando específicamente para un cliente en particular. Si no tiene acceso a clientes reales, considere la posibilidad de sembrar su producto con personas (¿puede decirlo, beta pública?) Gratis para obtener mejores comentarios.

Los usuarios no saben qué características quieren. Usted no sabe qué características podrían ofrecerse. " Características " no significa nada, excepto porque les ayuda a cumplir tareas y alcanzar metas. Y ahí es donde debes comenzar, porque tendrán una comprensión muy imperfecta de cómo se relacionan.

Hay una cosa que saben, tal vez, mucho mejor que tú. Y así es como hacer su trabajo.

Tan pronto como los conceptos y la terminología de la computadora / software comiencen a filtrarse en la discusión entre usuarios y diseñadores, estará fuera de control.

Muchas veces los usuarios enfocarán sus requisitos en términos de lo que está mal o podría mejorarse con el software que usan actualmente. Con el tiempo, incluso pierden la distinción entre sus trabajos y el software que usan para hacer sus trabajos.

Es un problema muy difícil y muy importante para resolverlo.

La única forma de saber lo que realmente hacen los usuarios " " la necesidad es "ser" el usuario. Su programación de nivel de cinturón negro de kung fu.

" Sé como el agua que se abre paso a través de las grietas. No sea asertivo, pero ajústese al objeto, y encontrará un camino redondo oa través de él. Si nada dentro de ti permanece rígido, las cosas externas se revelarán. Vacía tu mente, déjate llevar. Sin forma, como el agua. Si pones agua en una taza, se convierte en la taza. Usted pone agua en una botella y se convierte en la botella. Lo pones en una tetera se convierte en la tetera. Ahora el agua puede fluir o puede golpear. Be water my friend. & Quot;

Cuando seas el agua / cliente, ahora lo harás.

Creo que Bruce Lee sería un buen programador.

Estoy muy serio. Así es como trabajo. No puedo hacer cosas que no entiendo, así que tengo que entender antes de hacer cosas. Cuando entiendo, y mis clientes saben que entiendo, entonces puedo hacer un buen trabajo. Sin entender habrá malentendidos. Usted es la única persona que sabe cuándo tiene el nivel de comprensión correcto, y también es la persona responsable de obtener ese conocimiento.

El oráculo en Delphi

Pros: la precisión es excelente Contras: si puede interpretar los mensajes, que muchas personas no pueden hacer (a menudo ver lo que quieren ver). También requiere súplica, lo que puede volverse desordenado (a diferencia de la opinión popular, su hecatomb no necesita ser 100 del mismo tipo de ganado).
Psíquicos

Pros: precisos hasta cierto punto.

Contras: raro. Son propensos a la inestabilidad mental, son muy vulnerables a los seres de energía y pueden atraer la atención no deseada de ellos. Además, se necesita experiencia para sortear el misterio que es la mente humana para obtener la información deseada. Y a veces todavía necesita sondear sujetos mientras realmente están haciendo lo que necesitan ayuda, ya que los usuarios mienten.
Planta un lunar

Pros: Nuevos gadgets. ¡Nuevos venenos! Planes dentro de planes dentro de planes. El bebé es un espectáculo raro. Puede aprender todo tipo de cosas fascinantes además de la información que necesita para ayudar al usuario.

Contras: Caro. Existe la posibilidad de que el agente se vuelva contra usted o no aprenda algo que no podría aprender más simplemente. Si se descubre, es probable que la organización gire o liquide el activo, lo que representa una gran inversión de recursos. La organización puede corresponder.
Adivina

Pros: Lleve a un grupo de personas con promedio a grandes imaginaciones y habilidades de resolución de problemas, déles un poco de alcohol e inspirarlos con algunas citas de Ghostbusters, Big Trouble en Little China o The Big Lewbowski. Quién sabe dónde irá, pero será divertido y podrían producir algo interesante / útil.

Contras: las posibilidades de satisfacer las necesidades del usuario son mayores de lo que cree, pero no tan buenas.
Pregunte al usuario

Pros: los usuarios se sienten habilitados como parte del proceso.

contras: hasta que tengan que decidir sobre cualquier cosa, en qué momento estás por tu cuenta. A menos que el usuario sea un usuario muy experimentado, en cuyo caso probablemente tengan una buena idea de lo que quieren. Sin embargo, solo hay 4 usuarios experimentados en el planeta, y nadie conoce a nadie que pueda hacer un trabajo por ellos. Pueden ser bestias míticas.
Imagina que te importa y pregúntale al usuario (aunque en realidad no lo haces), luego observa cómo se involucra en cualquier flujo de trabajo / proceso / etc. clave y presta atención a lo que hacen.

Pros: engañas a los usuarios para que piensen que sus opiniones son importantes, lo que les da poder pero no entrega ningún otro equipaje. Dado que los usuarios mienten , sin importarles intencionalmente o maliciosamente, realmente puede verlos en acción y comprenda mejor cuál es el problema, lo que le brinda una mejor base para construir una solución. Además, evitas la ruta psíquica y, por lo tanto, evitas una ruta larga y sinuosa que comienza con la promesa, pero termina contigo y la psíquica siendo devorada por una cosa monstruosa e inefable que no es de este mundo. Observar el proceso es como totalmente Zen, lo cual es bueno para su Mistica del desarrollador.

Contras: no hay viaje por carretera al oráculo (que sería EPIC). Los espías son mucho más sexy; Los pollitos cavan espías. Cazafantasmas | Gran problema en la pequeña China | El Gran Lewboski probablemente no esté involucrado. Se siente más como un trabajo que el resto de las opciones.

Preguntar a los usuarios sobre las características les pedirá que hablen con usted sobre las características.

Si quiere saber qué quieren realmente los usuarios , está hablando de comprender sus objetivos y motivaciones. He encontrado que la forma más fácil de comenzar a hacer esto es entrevistar a los usuarios, no sobre las características, sino sobre cómo los usuarios usan su producto y productos similares, por qué lo están utilizando y cómo encaja en su vida.

Una vez que comprenda qué intentan hacer los usuarios con su producto y por qué lo quieren hacer, está en condiciones de emitir un juicio informado sobre si las características que las personas solicitan son lo que realmente necesitan.

Idealmente, creo que su problema es entender a los usuarios en lugar de escuchar sus solicitudes.

Esta es una pregunta antigua con muchas buenas respuestas ya, pero pensé que solo agregaría un poco de experiencia personal por el bien de las personas que terminan aquí en el futuro a través de una búsqueda como la que hice.

Si su proyecto no necesita ganar una audiencia lo más rápido posible para tener éxito (como una aplicación web) si se trata más de un proyecto o producto interno que se vende para un cliente fijo o tipo de cliente, entonces cree que lo mejor es ir por el camino de las 37 señales: dé a sus usuarios el mínimo absoluto que necesitan para cumplir las tareas más básicas del ciclo de trabajo más básico al principio, luego escuche lo que dicen falta objetivamente para que puedan hacer su trabajo correctamente. No es lo que quieren o le gustaría tener, sino lo que realmente necesitan . Y la única manera de saber con certeza lo que realmente necesita es cuando no lo tiene.

Trabajé como diseñador en el equipo de desarrollo de una base de intranet " corazón de la empresa " Aplicación que siguió esa estrategia, y los resultados fueron maravillosos. Primera semana: todos estaban enojados. Cuando terminó, más del 90% de aprobación, y la aplicación aún era simple y hermosa. Y la mayoría de las personas que no estaban del todo satisfechas parecían entender por qué no podía ser lo que querían, y la solicitud principal de casi todos fue que, hiciera lo que hiciéramos, mantuviera la aplicación simple.

Una vez más, si está trabajando en un producto o sitio web que necesita atraer a las personas primero, es posible que no sea factible o que demore mucho las cosas. Pero si tiene algún control o margen de maniobra sobre la base de usuarios, definitivamente recomendaría este enfoque.

No solicita funciones. Pides problemas. Puntos de dolor. Descubra lo que odian de su solución actual. Averigüe qué se come en su tiempo.

Cuando sabes lo que no les gusta, creas la solución a esos problemas.

Cuando resuelves problemas reales, estás creando productos reales que la gente con gusto te dará dinero.

Pero lo que también es importante es respetarlos durante su fase de investigación. Las encuestas aún son excelentes para investigar, pero si les haces una docena de preguntas, te odiarán. Debe respetar su tiempo y utilizar una herramienta de encuesta que los involucra y deja una gran impresión.

Es un hecho comprobado que los usuarios no saben lo que quieren. Lo que debe preguntar es qué hay de malo en lo que hay ahora, ¿qué problemas tienen con su software? ¿Por qué no están usando la función xy el control y? ¿Por qué la interacción x funcionó para ellos mientras que la interacción los hizo tratar de medir sus ojos?

Por supuesto, para poder hacer esas preguntas, debe hacer un estudio de campo y ver qué características se utilizan, qué patrones exhiben sus usuarios y analizar esos datos. Ese análisis le dará la base para preguntas mucho más específicas que los usuarios podrán responder de manera decisiva y precisa.

Si hablas en serio, graba en video su trabajo, y luego analizas lo que están tratando de lograr y cómo tu producto puede ayudarlos. Esto es parte de toda una disciplina llamada ingeniería de usabilidad. Una buena introducción a la técnica es el libro de Jakob Nielsen Ingeniería de usabilidad . Antes de que se convirtiera en un villano descarado, Jakob era un muy buen científico y aprendió mucho sobre formas baratas de descubrir qué necesitan los usuarios. Especialmente bueno si tienes un presupuesto limitado. Lo que más me impresionó fue usar prototipos de papel ; esta es una excelente manera de simular software que aún no ha creado y le ayuda a responder su pregunta sobre qué crear a continuación. Hasta que no vi esta técnica en acción, no podía creer lo efectiva que podría ser.

P.S. Un ejemplo de lo que sucede si solo pregunta a las personas: el 90% de las solicitudes de funciones para Microsoft Office 2007 fueron para funciones que ya estaban en Microsoft Office 2003. En ese caso, lo que los usuarios necesitaban eran mejores formas de encontrar lo que ya estaba allí. Desearía poder encontrar dónde leí sobre esto ... perdón por no tener una referencia.

Supongo que, según tu texto, estás creando un producto para vender y no construyendo algo para ordenar a un cliente específico.

En ese contexto, diría que debe comenzar convirtiéndose en un usuario usted mismo y creando las funciones que necesita de la manera que lo desee. A medida que evolucione el producto, necesitará la retroalimentación de otros usuarios, pero al menos esto le permite comenzar y romper el ciclo del huevo de gallina.

En cuanto a la medición del uso real de las funciones, puede configurar un foro de discusión para obtener comentarios sobre las funciones que agregó ... no necesita nada demasiado complicado si tiene poco tiempo.

Personalmente, me gusta el enfoque de manos libres de los clientes. Le dan requisitos de alto nivel y usted proporciona la implementación. Su equipo de software / empresa / división se supone que son los expertos. Seguro que cometerás algunos errores, si es horrible que el cliente lo diga y lo arregles, pero en general, tener la implementación depende de ti y de tus desarrolladores es un dilema divertido que resolver.

Investigación, investigación, investigación. Aprende de otros diseños, luego haz tu propio diseño kickass. No es fácil, pero tampoco les pagan nada a los desarrolladores por nada.

Esa es una buena pregunta.

Si estás creando un juego de FPS, realmente necesitas saber por ti mismo qué debe incluirse, porque el 99% de tus usuarios nunca se pondrán en contacto contigo para decir "Deseo que tu juego haya tenido solo X". Un equipo experimentado de pruebas beta puede ayudar aquí.

Si está escribiendo una aplicación de contabilidad, necesita comprender la industria y lo que los usuarios intentan lograr cuando usan su producto, y tratar de enfocar su conjunto de características en torno a esos objetivos.

Si está escribiendo una aplicación personalizada para 100 usuarios en una empresa, podría conversar con la docena o más usuarios más ávidos del software. Ellos son los que conocen todos los formularios, han descubierto todas las teclas de acceso directo no documentadas y también han descubierto cómo evitar muchas de sus reglas de validación de datos.

Imagina que eres ellos

Casos de uso.

¿Qué van a hacer con esa función?

Funciona así.

Las personas toman medidas. Construimos software para ayudarles a tomar acciones
Para tomar una acción, una persona debe tomar una decisión. Construimos software para ayudarles a tomar decisiones.
Para tomar una decisión de tomar una acción, una persona necesita información. Construimos software para recopilar y presentar información.

Cada característica debe ser una Acción, una Decisión o Información. Y es mejor que la conexión sea directa. La información que no conduce a una decisión o una acción no es siquiera agradable para tener " - es basura.

Los usuarios dicen muchas cosas. ¿Qué hacen ? ¿Qué decisiones toman? ¿Qué información necesitan?

Edit

Tenga en cuenta que no todos son buenos para describir casos de uso. Algunas personas no tienen visión y simplemente le dirán lo que hacen hoy sin entender cómo están creando valor empresarial (o personal). Puede que realmente no sepan qué decisiones se supone que deben tomar, y son vagos en la información que necesitan.

Otros usuarios saben qué valor crean y por qué, y pueden discutir bien los casos de uso. Pueden imaginar formas alternativas de crear valor; pueden articular opciones para sus acciones. Las decisiones no tienen muchas implementaciones alternativas (las personas toman decisiones, no el software) y la información requerida tampoco cambia mucho.

Míralos.
Identificar cuellos de botella en su trabajo
Crea algo que resuelva eso cuello de botella de una manera elegante
Deja que lo usen
Repite hasta que todos estén contentos

Basado en los principios:

Los usuarios saben lo que quieren, pero ellos no sé lo que realmente necesitan .
ERES NUNCA voy a hacerlo bien el primera vez.

Parece un problema de huevo y gallina. Al igual que la informática PageRank. El rango de la página de una página depende del PageRank de otras páginas vinculadas a esa página. Una forma de calcular el PageRank es por iteración.

¡La iteración es la clave!

A. Votar

Reúna una lista completa de las características que todos los usuarios desean (haga que enumeren cada una de las características que desean).
Luego pídales que revisen la lista y les permitan votar sobre las características. Digamos, dales 100 puntos para distribuir en las características. Pueden dar más de 1 punto a una función.

B. Análisis

Analice el modelo de negocio, enumere las características que cree que se necesitan. Esto es necesario porque:

los usuarios a veces no obtienen lo grande foto
tienes esto realmente genial idea de que los usuarios no pensarán en una años bajillion.

C. Implementar

Analice la lista de A y B, fusione, elimine algunos, mejore algunos. Implementar.

D. Prueba

Pruébelo en los usuarios. Escucha sus quejas. Mirar - características que utilizan a menudo - cosas que se atascan en - etc etc etc

E. Iterar

Por lo general, los usuarios no siempre saben lo que quieren y si quieren algo. En nuestra empresa, los vendedores acuden a clientes existentes y potenciales, les muestran nuestro producto y les explican por qué lo desean desesperadamente.

En mi época en la universidad nos enseñaron algo llamado "desarrollo impulsado por el usuario". Aquí realmente tiene que acudir al cliente, observar cómo trabajan las personas, qué herramientas utilizan y tratar de averiguar qué podría facilitarles la vida. A continuación, crea una maqueta, vuelve al cliente, se lo presenta a los usuarios, recibe sus comentarios y luego procede a mejorar su maqueta. Cuando todos están más o menos de acuerdo con el curso de acción, usted realiza la implementación, mostrando regularmente al cliente lo que está tratando de obtener comentarios de corrección lo antes posible.

Importante no es hablar con los gerentes que desean el producto, sino con los usuarios que lo usarán. De lo contrario, toda la obra no te traerá nada.

P.S. Preguntándolos directamente " ¿Qué quieres? & Quot; podría ser una pregunta peligrosa ... Babylon 5 - ¿Qué quieres?

Se llama Market Research.

No, esto no fue una excavación para el tipo, de eso se trata realmente. Claro, hay un montón de técnicas que las personas con UCD usan en el campo para obtener los requisitos del usuario, pero son exactamente las mismas herramientas que usan los investigadores de mercado. Clasificación de tarjetas, listas de prioridad, etc., son términos de investigación de mercado.

Licenciado bajo: CC-BY-SA con atribución

No afiliado a StackOverflow