user-experience - ejemplos - que es ux

¿Cómo averiguas qué es lo que realmente quieren los usuarios? (27)

Miralos.
Identificar los cuellos de botella en su trabajo
Crea algo que resuelva ese cuello de botella de una manera elegante
Déjalos usarlo
Repite hasta que todos estén felices

He leído en algún lado (me olvidé de la fuente, lo siento, ¿creo que el blog del desarrollador de MS Office?), Que cuando haces una encuesta de usuarios preguntándoles qué funciones les gustaría ver en tu software / sitio web, lo harán más a menudo dicen que quieren todo, mientras que las métricas recopiladas muestran que, al final, la mayoría de las personas no usa el 99% de estas características. El mensaje general de la entrada del blog fue que no debes preguntarle a las personas qué usan, debes seguirlo tú mismo.

Esto lleva a una desafortunada situación de huevo y gallina cuando intentamos averiguar qué nueva característica añadir a continuación. Sin la función ya implementada, no puedo medir cuánto se está usando en realidad. Con recursos limitados (y muy extensos), tampoco puedo permitirme agregar todas las funciones y luego eliminar las que no se usaron.

¿Cómo averiguas qué será útil para tus usuarios? Si una encuesta es la única opción, ¿tiene que estructurar sus preguntas de ciertas maneras (p. Ej .: no muestre una lista de posibles características, ya que eso las estaría guiando)?

El oráculo de Delfos
Pros: la precisión es excelente Contras: si puede interpretar los mensajes, lo cual muchas personas no logran (a menudo viendo lo que quieren ver). También requiere súplica, lo que puede ser complicado (contrariamente a la opinión popular, su hecatomb no necesita ser 100 del mismo tipo de ganado).
Psíquicos
Pros: exacto a un punto.
Contras: raro. Propenso a la inestabilidad mental, altamente vulnerable a seres sobrenaturales, y puede atraer atención no deseada de ellos. Además, se necesita experiencia para ordenar el misterio que es la mente humana para obtener la información deseada. Y a veces todavía necesita probar temas mientras hacen lo que necesitan, ya que los usuarios mienten.
Plantar un topo
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. Es probable que el agente se vuelva en su contra o que no aprenda algo que no pueda aprender de manera más simple. Si se descubre, es probable que la organización cambie o liquide el activo, lo que representa una gran inversión de recursos. La organización puede corresponder.
Adivinar
Pros: Considera a un grupo de personas con una imaginación de promedio a excelente y habilidades para resolver problemas, dales un poco de alcohol e inspíralos con algunas citas de Ghostbusters, Big Trouble in 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 más altas de lo que crees, pero no tan buenas.
Preguntar al usuario
Pros: los usuarios se sienten empoderados como parte del proceso.
Contras: hasta que tengan que decidir sobre cualquier cosa, en ese punto usted está solo. A menos que el usuario sea un usuario con mucha experiencia, en cuyo caso probablemente tenga una buena idea de lo que quiere. Sin embargo, solo hay como 4 usuarios experimentados en el planeta, y nadie conoce a nadie que pueda hacerles un trabajo. Pueden ser bestias míticas.
Pretenda que le importa y pregúntele al usuario (aunque realmente no lo haga) y luego obsérvelos haciendo el flujo de trabajo / proceso / etc. clave y preste atención a lo que hacen.
Pros: engañas a los usuarios para que crean que su opinión importa, lo que les da poder pero no entrega ningún otro equipaje. Dado que los usuarios mienten -no les importa de forma intencionada ni malintencionada-, en realidad los pueden ver en acción y obtener una mejor idea de cuál es el problema, lo que les brinda una mejor base para construir una solución. Además, evitas la ruta psíquica y, por lo tanto, evitas un camino largo y tortuoso que comienza con promesas pero termina cuando tú y el vidente se comen por algo monstruoso e indescriptible que no es de este mundo. Observar el proceso es como totalmente Zen, lo cual es bueno para su Developer Mystique.
Contras: No hay un viaje por carretera al Oracle (que sería EPIC). Los espías son mucho más sexys; los pollitos cavan espías. Cazafantasmas | Gran problema en la pequeña China | Los grandes Lewboski probablemente no estén involucrados. Se siente más como trabajo que el resto de las opciones.

Basado en los principios:

Los usuarios saben lo que quieren, pero no saben lo que realmente necesitan .
NUNCA lo harás bien la primera vez.

Parece un problema de gallina y huevo. Muy parecido a computar el PageRank. El rango de página de una página depende del PageRank de otras páginas que enlazan con esa página. Una forma de calcular PageRank es por iteración.

¡La iteración es la clave!

A. Votación

Reúna una lista completa de características que todos los usuarios desean (haga que enumeren cada característica 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 comercial, enumere las características que cree que son necesarias. Esto es necesario porque:

los usuarios a veces no tienen una idea general
usted tiene esta GRAN idea que los usuarios no pensarán en un millón de años.

C. Implementar

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

D. Prueba

Pruébalo en usuarios. Escucha sus quejas Observen: características que usan a menudo, cosas que les impiden, etc. etc.

E. Iterar

Buena pregunta.

Si está compilando un juego de FPS, realmente necesita saber por sí mismo qué se debe incluir, ya que el 99% de sus usuarios nunca se pondrá en contacto con usted para decir "Me gustaría que su juego solo tuviera 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 están tratando de lograr cuando usan su producto, y trate de enfocar su conjunto de características en torno a esos objetivos.

Si está escribiendo una aplicación personalizada para 100 usuarios en un negocio, puede tener un chat con la docena de usuarios más ávidos del software. Ellos son los que conocen todos los formularios de atrás hacia adelante, han descubierto todas las teclas de acceso directo no documentadas y también han descubierto cómo eludir muchas de las reglas de validación de datos.

Casos de uso.

¿Qué van a hacer con esa característica?

Funciona así.

La gente toma acciones. Creamos software para ayudarlos a tomar acciones
Para tomar una acción, una persona debe tomar una decisión. Desarrollamos software para ayudarlos a tomar decisiones.
Para tomar una decisión de tomar una acción, una persona necesita información. Desarrollamos software para recopilar y presentar información.

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

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

Editar

Tenga en cuenta que no todos son buenos para describir los 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 comercial (o personal). Es posible que no sepan realmente qué decisiones se supone que deben tomar, y son imprecisos con la información que necesitan.

Otros usuarios saben qué valor crean, y por qué, y pueden analizar 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.

Debe atar las características al costo. Todos quieren características, pero no vale la pena pagar por cada función. Pregunte qué características son las más importantes, por qué los usuarios estarían dispuestos a pagar. Desarrolle funciones basadas en las prioridades proporcionadas por los usuarios y deténgase cuando no estén dispuestos a pagar por más. Obtenga 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 un software real, obtienes información mucho mejor. Esto funciona mejor cuando se está desarrollando específicamente para un cliente en particular. Si no tiene acceso a clientes reales, considere distribuir su producto con personas (¿puede decir, beta pública?) Gratis para obtener una mejor respuesta.

Deles opciones y pídales que las arreglen en orden de importancia. Como dijiste, los usuarios van a querer todo, pero esto te permitirá saber qué es lo que más quieren.

Es un hecho comprobado que los usuarios no saben lo que quieren. Lo que necesita preguntar es qué está mal con lo que hay ahora: ¿qué problemas están teniendo con su software? ¿Por qué no usan x característica y control y? ¿Por qué la interacción x funcionó para ellos mientras que la interacción los hizo tratar de calibrar sus ojos?

Por supuesto, para poder hacer esas preguntas, necesita hacer un estudio de campo y ver qué características se usan, qué patrones muestran y analizan los usuarios. Ese análisis le dará la base para preguntas mucho más específicas que los usuarios pueden responder de manera decisiva y precisa.

Imagina que eres ellos

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

"Sé como el agua que se abre camino a través de las grietas. No seas asertivo, sino ajústate al objeto, y encontrarás una forma de atravesarlo o atravesarlo. Si nada dentro de ti permanece rígido, las cosas externas se revelarán. Vacía tu mente, sé sin forma, sin forma, como agua. Si pones agua en una taza, se convierte en la taza. Pones 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 romper. Sé agua, mi amigo ".

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

Creo que Bruce Lee sería un buen programador.

Soy muy serio. Esta es la forma en que trabajo No puedo hacer cosas que no entiendo, así que tengo que entender antes de hacer las cosas. Cuando entiendo, y mis costomers 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 correcto de comprensión, usted también es la persona responsable de obtener ese conocimiento.

Los usuarios no saben qué características quieren. No sabe qué características se les pueden ofrecer. Las "características" no significan nada, salvo que las ayudan a cumplir tareas y alcanzar objetivos. Y ahí es donde debes comenzar, porque tendrán un entendimiento muy imperfecto de cómo se relacionan.

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

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

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

Es un problema muy difícil y críticamente importante para ti resolver esto.

Personalmente me gusta el enfoque de manos libres de los clientes. Le brindan requisitos de alto nivel y usted proporciona la implementación. Su equipo de software / compañía / división se supone que son los expertos. Seguro que cometerá algunos errores, si es horrible, el cliente recurrirá y lo arreglará, pero en general tener la implementación a su medida y la de los desarrolladores es un dilema divertido de resolver.

Investigación, investigación, investigación. Aprende de otros diseños, luego crea tu propio diseño kickass. No es fácil, pero una vez más no les pagan a los desarrolladores mucho dinero por nada.

Si habla en serio, los graba en video en su trabajo, y luego analiza lo que están tratando de lograr y cómo su producto puede ayudarlos. Esto es parte de una disciplina completa llamada ingeniería de usabilidad. Una buena introducción a la técnica es el libro de Jakob Nielsen Usability Engineering . Antes de convertirse en un mercachifle desvergonzado, Jakob era un muy buen científico y aprendió mucho sobre maneras baratas de averiguar qué necesitan los usuarios. Especialmente bueno si tienes un presupuesto ajustado. Lo que más me impresionó fue usar prototipos de papel ; esta es una gran manera de simular el software que aún no ha creado y ayuda a responder su pregunta sobre qué construir a continuación. Hasta que vi esta técnica en acción, no podía creer lo efectiva que podría ser.

PD: un ejemplo de lo que sucede si solo le pregunta a la gente: el 90% de las solicitudes de características para Microsoft Office 2007 eran 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 leo acerca de esto ... lo siento por no tener una referencia.

Supongo, basándome en su redacción, que está creando un producto para vender y no creando algo para un cliente específico.

En ese contexto, diría que debe comenzar convirtiéndose en un usuario y creando las características que necesita de la manera que lo desea. A medida que desarrolle el producto, necesitará los comentarios de otros usuarios, pero al menos esto lo inicia y rompe el ciclo del huevo y la gallina.

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

Tú diles. Entonces ustedes dos saben.

(No, sus usuarios no le dirán lo que quieren. Eso es trabajo. Si los usuarios quisieran más trabajo, no buscarían 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 intercambiamos ideas sobre qué cosas querían ver en el sistema, colocando cada "característica" en un papel adhesivo amarillo sobre un tablero blanco. Luego agrupamos solicitudes similares y eliminamos duplicados o near dups.

Luego colocamos cada pegajoso sobre una mesa con una taza en frente de él. Cada usuario obtuvo 10 centavos para "votar" sobre las características que deseaba. 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 mejores captadores de votos, en orden de votos.

Fue sorprendente ver a personas apasionadas por una función mientras se genera una lluvia de ideas y se categoriza dando la vuelta y no votando por esa característica (o votando ligeramente por ella).

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

Usted les pregunta.

(No, usted no sabe lo que sus usuarios quieren mejor que ellos. Sí, obtendrá muchas respuestas estúpidas. Evite las encuestas de opción múltiple y en su lugar opte por revisar las respuestas de forma libre. La información que recopile será invaluable. )

Por supuesto, siempre puedes permitir que tus usuarios voten sobre las características que más les gustan ...

Yo recomendaría no mostrarles las opciones; como usted señala, si está disponible, la gente lo querrá por el solo hecho de tenerlo. A menudo, los usuarios no son conscientes de los costos adicionales de desarrollar una función en particular, y solo la quieren porque usted mencionó 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 extra sería? dispuesto a pagar por la característica Y?

Coma su propia comida para perros

Intente usar la aplicación que usted mismo escribe tanto como sea posible. Entonces sabrá cómo puede mejorar su aplicación.

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

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

Tuvimos problemas culturales, lo que significaba que ninguno de los usuarios iba a decir nada para decir lo que querían. Tenía un historial con los usuarios del pasado. Tratar de obtener los requisitos de ellos fue como tratar de obtener sangre de una piedra. Pero una vez que salgas a la luz comenzaría la perra.

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

Se llama investigación de mercado.

No, esto no fue una exageración para el hombre, de eso se trata realmente. Claro, hay un montón de técnicas que las personas UCD usan en el campo para obtener los requisitos del usuario, pero son exactamente las mismas herramientas utilizadas por los investigadores de mercado. La clasificación de tarjetas, las listas de prioridades, etc., son todos términos de investigación de mercado.

De acuerdo con 37 Signals - Getting Real book, no haces nada, ni siquiera grabas lo que quieren, simplemente borras correos después de una lectura sin ninguna acción.

Cuando se trata de implementar / arreglar cosas, recordarás las cosas más importantes que tus usuarios quieren de la cabeza. Obviamente, esto requiere una base de usuario poco.

Generalmente, 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 tiempo en la universidad, nos enseñaron algo llamado "desarrollo impulsado por usuarios". Aquí realmente debe dirigirse al cliente, observar cómo trabaja la gente, qué herramientas utilizan y tratar de descubrir qué podría facilitarles la vida. A continuación, cree una maqueta, acuda al cliente nuevamente, preséntela a los usuarios, obtenga sus comentarios y luego proceda 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 la retroalimentación de corrección tan pronto como sea posible.

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

PD Preguntarles directamente "¿Qué es lo que quieres?" podría ser una pregunta peligrosa ... Babylon 5 - ¿Qué quieres?

Preguntar a los usuarios sobre las funciones les pedirá que hablen sobre las funciones.

Si desea averiguar qué es lo que realmente desean los usuarios, entonces está hablando de comprender sus objetivos y motivaciones. He encontrado que la forma más fácil de empezar a hacer esto son las entrevistas a los usuarios, no sobre las características sino sobre cómo los usuarios usan su producto y productos similares, por qué lo usan y cómo encaja con su vida.

Una vez que comprenda lo que sus usuarios están tratando de hacer con su producto y por qué lo desean, está en condiciones de emitir un juicio informado sobre si las características solicitadas por las personas son las que realmente necesitan.

Idealmente, creo que su problema consiste en comprender a los usuarios en lugar de simplemente escuchar sus solicitudes.

Esta es una vieja pregunta con muchas buenas respuestas, 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 obtener 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 para ser vendido para un cliente fijo, o tipo de cliente, entonces creo lo mejor posible. la apuesta es seguir el camino de las 37 señales: dé a sus usuarios el mínimo absoluto que necesitan para realizar las tareas más básicas del ciclo de trabajo más básico al principio, luego escuchen lo que dicen que es objetivamente perdido para que puedan hacer su trabajo. funcionar correctamente. No es lo que quieren o quisieran tener, sino lo que realmente necesitan . Y la única forma en que sabes con certeza lo que realmente necesitas es cuando no la tienes.

Trabajé como diseñador en el equipo de desarrollo de una aplicación de "corazón de la compañía" basada en la intranet que siguió esa estrategia, y los resultados fueron maravillosos. Primera semana: todos estaban enojados. Cuando terminó, 90% + de aprobación, y la aplicación todavía 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 como querían, y el pedido principal de casi todos fue que, hiciéramos lo que hiciéramos, mantuviéramos la aplicación simple.

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

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

No pides funciones Usted pide problemas Puntos de dolor. Descubra lo que odian sobre su solución actual. Descubra lo que come en su tiempo.

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

Cuando resuelves problemas reales, entonces creas productos reales para los cuales la gente te dará dinero con mucho gusto.

Pero lo que también es importante es respetarlos durante su fase de investigación. Las encuestas siguen siendo excelentes para investigar, pero si les haces una docena de preguntas, te odiarán. Debe respetar su tiempo y usar una herramienta de encuesta que los involucre y deje una gran impresión.