Todos sabemos que crear una nueva funci\u00f3n o producto que genere un profundo compromiso por parte del cliente es dif\u00edcil de conseguir. Jared Spool<\/a> (l\u00edder en UX e investigaci\u00f3n de usuarios) explica por qu\u00e9 en el siguiente tweet:<\/p>\n Las pruebas de usabilidad son un proceso conocido y bien documentado. Pero, \u00bfhay formas de probar la demanda de un nuevo producto o funci\u00f3n antes de construirlo? <\/p>\n S\u00ed.<\/strong> Siempre que lo hagas correctamente. He aqu\u00ed c\u00f3mo hacerlo: <\/p>\n Empecemos destacando un error com\u00fan en las pruebas:<\/p>\n Por desgracia, preguntar a un encuestado si utilizar\u00eda un producto no produce una respuesta fiable. El tweet anterior de Jared explica parcialmente el motivo. Pero la raz\u00f3n subyacente por la que esta pregunta es un predictor poco fiable de la demanda es que al encuestado no le cuesta nada decir \u00abs\u00ed\u00bb. <\/p>\n En la vida cotidiana, sin pruebas, decir \u00abs\u00ed\u00bb es una decisi\u00f3n de compromiso. Para decir \u00abs\u00ed\u00bb primero tenemos que determinar: \u00ab\u00bfVale realmente la pena para m\u00ed?\u00bb. Como \u00e9sta es la misma pregunta que se har\u00e1n tus usuarios cuando tu producto (o funci\u00f3n) salga al mercado, tienes que forzar esa decisi\u00f3n tambi\u00e9n durante las pruebas. Hay tres formas de hacer que decir \u00abs\u00ed\u00bb a una pregunta cualitativa cueste algo durante una prueba. <\/p>\n Para que quede claro, esto NO garantiza necesariamente la creaci\u00f3n de un producto (o funci\u00f3n) que los clientes quieran utilizar. Despu\u00e9s de todo, estoy seguro de que te has descargado aplicaciones que no utilizas, o has cancelado una reserva de hotel pagada por adelantado. Sin embargo, estas pruebas son una forma estupenda de evitar una mala implementaci\u00f3n del producto o funci\u00f3n. En pocas palabras, si una persona que responde a una prueba no est\u00e1 dispuesta a darte su tiempo, su reputaci\u00f3n o su dinero, es que realmente no quiere utilizar tu producto. <\/p>\n Otra buena validaci\u00f3n de la demanda futura es si el encuestado ha utilizado un producto\/funci\u00f3n comparable en el pasado. Jared sugiere hacer esta pregunta: <\/p>\n El objetivo de hacer esta pregunta es comprender mejor por qu\u00e9 un usuario \u00abalquil\u00f3\u00bb un producto de la competencia. La parte \u00abh\u00e1blame de \u00e9l\u00bb trata de profundizar en lo que les har\u00eda cambiar a tu producto. \u00bfQu\u00e9 les gusta u odian del otro producto? Lo que Jared quiere decir es que es poco probable que convenzas a alguien que actualmente no realiza una actividad para que la elija. Sin embargo, puedes animarles a cambiar de otro producto si el tuyo satisface una necesidad actualmente insatisfecha. Y, por supuesto, querr\u00e1s utilizar las Pruebas Minimalistas para estas pruebas con el fin de validar a qu\u00e9 caracter\u00edsticas va a decir \u00ab\u00a1s\u00ed!\u00bb un cliente. Las pruebas de Validaci\u00f3n de la Demanda son el primer paso. Para impulsar el compromiso de los clientes, un producto o funci\u00f3n debe aportar valor y<\/u> ser f\u00e1cil de usar<\/u>. Una vez que hayas validado la demanda, tienes que realizar tambi\u00e9n pruebas de usabilidad.<\/strong> Al observar las pruebas de usabilidad, nos hemos dado cuenta de algunos errores comunes. <\/p>\n Descargar gratis<\/a><\/p>\n <\/p>\n A continuaci\u00f3n te presentamos dos estructuras de prueba diferentes, con el mismo objetivo. Intenta determinar las dos diferencias antes de que te las contemos. <\/p>\n \u00bfAdivinaste las principales diferencias entre las pruebas? \u00a1Sigue leyendo para averiguarlo! Enunciado de la \u00abtarea<\/strong>\u00bb \u00bfPor qu\u00e9 es importante? El enunciado de una tarea es importante porque los nuevos usuarios acuden a tu producto para resolver un problema que tienen. La soluci\u00f3n que ofreces y c\u00f3mo etiquetas el camino hacia esa soluci\u00f3n es lo que est\u00e1s probando con una prueba de usabilidad. Sin embargo, si durante tu prueba eres demasiado prescriptivo con tu tarea, haciendo esencialmente una \u00abpregunta cargada\u00bb, los resultados se ver\u00e1n empa\u00f1ados. La prueba 1 indica al usuario d\u00f3nde debe hacer clic. As\u00ed, no estar\u00eda claro si una persona es capaz de completar la tarea porque la UX es intuitiva, o porque simplemente busc\u00f3 los botones con la etiqueta \u00abbloc de notas\u00bb y \u00aba\u00f1adir nota\u00bb, ya que hemos utilizado esas palabras. Por el contrario, la Prueba 2 es m\u00e1s propicia a c\u00f3mo pensar\u00eda normalmente un usuario, es decir, con un problema a resolver en mente. En este caso, el problema a resolver es \u00aba\u00f1adir mis pensamientos sobre un proyecto\u00bb. Por lo tanto, la navegaci\u00f3n satisfactoria por el flujo y la finalizaci\u00f3n de la tarea por parte del encuestado de la prueba puede darnos la seguridad de que la funci\u00f3n UX es intuitiva.<\/p>\n Esencialmente, el enunciado de la tarea para una prueba de usabilidad debe basarse en el caso de uso. Evita ser demasiado prescriptivo al formular una tarea, o acabar\u00e1s recibiendo respuestas ret\u00f3ricas. <\/strong><\/p>\n <\/p>\n En esta app \u00abde juguete\u00bb que hemos construido, la funci\u00f3n \u00aba\u00f1adir nota\u00bb est\u00e1 en la p\u00e1gina \u00abbloc de notas\u00bb. Pero como la mayor\u00eda de los usuarios que utilizan la aplicaci\u00f3n pasan tiempo en el \u00abproyecto actual\u00bb, realmente tenemos que probar si navegar desde la p\u00e1gina del \u00abproyecto actual\u00bb a la p\u00e1gina del \u00abbloc de notas\u00bb para a\u00f1adir notas es intuitivo para nuestros clientes. <\/p>\n Esto es especialmente importante porque la tarea del usuario es \u00abcompartir sus pensamientos sobre un proyecto\u00bb, como hemos se\u00f1alado antes. Empezando en la p\u00e1gina principal, podemos averiguar si el usuario piensa intuitivamente en navegar hasta el \u00abbloc de notas\u00bb cuando quiere completar el caso de uso de \u00abcompartir pensamientos\u00bb. Si el punto de entrada de una prueba de usabilidad inicia al usuario en la p\u00e1gina con la actividad (como hicimos en la Prueba 1), entonces no est\u00e1s probando la capacidad del usuario para navegar hasta la funci\u00f3n correctamente. Simplemente est\u00e1s probando si el usuario puede realizar una actividad en esa p\u00e1gina concreta. B\u00e1sicamente, una buena prueba de usabilidad no s\u00f3lo mide la capacidad de un usuario para completar una tarea, sino que tambi\u00e9n prueba la capacidad de un usuario para completar los flujos de navegaci\u00f3n habituales hacia esa tarea.<\/strong> He aqu\u00ed c\u00f3mo estructurar\u00edamos una prueba de usabilidad para esta funci\u00f3n: <\/p>\n <\/p>\n Eso es todo por ahora, amigos. Nos complace anunciar que Justinmind y Validately unir\u00e1n sus fuerzas a finales de este mes.<\/strong> As\u00ed que<\/em>estad atentos para m\u00e1s detalles sobre la integraci\u00f3n<\/em> y para m\u00e1s actualizaciones de UX.<\/em> <\/em><\/strong>Mientras tanto, \u00bfpor qu\u00e9 no<\/em> <\/em>inscr\u00edbete en una demostraci\u00f3n de Validately<\/em><\/a> y<\/em> si a\u00fan no lo has hecho <\/em>descarga Justinmind<\/em> <\/em>\u00a1para empezar a mejorar tu flujo de trabajo!<\/em><\/p>\n![\"pruebas](\"https:\/\/www.justinmind.com\/wp-content\/uploads\/2016\/01\/usability-testing-past-behavior.jpg\")
<\/a><\/p>\nPreguntar \u00ab\u00bfLo har\u00edas?\u00bb NO es suficiente<\/strong><\/h4>\n
![\"pruebas](\"https:\/\/www.justinmind.com\/wp-content\/uploads\/2016\/01\/usability-testing-would-you-use-it.jpg\")
<\/a><\/p>\nTienes que hacer que el \u00abS\u00ed\u00bb cueste algo<\/strong><\/h4>\n
\n
![\"usabilidad-direcci\u00f3n-de-correo-contacto\"](\"https:\/\/www.justinmind.com\/wp-content\/uploads\/2016\/01\/usability-email-address.jpg\")
<\/a><\/p>\n\n
![\"usabilidad-primer-usuario-nuevo-producto\"](\"https:\/\/www.justinmind.com\/wp-content\/uploads\/2016\/01\/usability-first-user.jpg\")
<\/a><\/p>\n\n
![\"usabilidad-pre-pago-producto\"](\"https:\/\/www.justinmind.com\/wp-content\/uploads\/2016\/01\/usability-pre-pay-product.jpg\")
<\/a><\/p>\n\u00bfQu\u00e9 pueden decirnos las pruebas de validaci\u00f3n de la demanda?<\/strong><\/h4>\n
El comportamiento anterior es un buen indicador<\/strong><\/h4>\n
![\"usabilidad-cu\u00e9ntamelo\"](\"https:\/\/www.justinmind.com\/wp-content\/uploads\/2016\/01\/usability-tell-me-about-it.jpg\")
<\/a><\/p>\n
\n\u00a1Desc\u00e1rgate Justinmind hoy mismo para ponerte a prueba!<\/span><\/h2>\n
\n<\/div>\nErrores comunes en las pruebas de usabilidad<\/strong><\/h4>\n
![\"usability-testing-mistakes\"](\"https:\/\/www.justinmind.com\/wp-content\/uploads\/2016\/01\/usability-testing-mistakes.jpg\")
<\/a><\/p>\nLas diferencias clave:<\/strong><\/h4>\n
\nLa primera gran diferencia entre las dos pruebas es el enunciado de la tarea. Es una diferencia sutil, pero el impacto es significativo. <\/p>\n\n
La p\u00e1gina de entrada<\/strong><\/h4>\n
![\"usabilidad-todo-app\"](\"https:\/\/www.justinmind.com\/wp-content\/uploads\/2016\/01\/usability-todo-app.jpg\")
<\/a><\/p>\n\n
![\"Descargar](\"https:\/\/www.justinmind.com\/wp-content\/uploads\/2017\/01\/Download_free.png\")
<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"