Personas vs. Jobs-to-Be-Done

Personas vs. Jobs-to-Be-Done

Jobs-to-be-done centra en los problemas y necesidades de los usuarios mientras que Personas, bien ejecutado, incluye la misma información y además aporta detalles conductuales y actitudinales.

Introducción

Personas ha sido una herramienta útil en el proceso de diseño centrado en el usuario; Sin embargo en los últimos años Jobs-to-be-done, una nueva técnica para centrarse en las necesidades de los clientes, ha ido ganando prominencia constantemente.

Definición: Jobs-to-be-done (JTBD) es un framework basado en la idea de que cuando los usuarios "contratan" (es decir, usan) un producto, lo hacen para un "trabajo" específico (es decir, para lograr un resultado particular). El conjunto de "trabajos" para el producto equivale a una lista completa de las necesidades del usuario.

Con la popularidad del paradigma JTBD, hay algunos mensajes para abandonar Personas, lo que sugiere que JTBD ha surgido como una técnica más útil. Este punto de vista se basa en un malentendido fundamental del propósito de Personas como una representación principalmente demográfica de los usuarios, perdiendo las consideraciones clave de comportamiento que son esenciales para Personas y que proporcionan una orientación muy necesaria para el diseño de la interacción y la estrategia del producto.

Jobs-to-Be-Done: Una herramienta útil para enfocarse en los resultados en lugar de las funciones

El framework de JTBD es una representación de las necesidades de los usuarios que surgen de la investigación cualitativa de los mismos, como los estudios de campo, las entrevistas y las pruebas de usabilidad con descuento. Implica identificar para qué objetivos "contratan" los clientes su producto (también averiguar si hay productos de competidores que estos usuarios quieran adquirir). Armado con este conocimiento un equipo de producto puede pensar en la naturaleza de los problemas y necesidades principales de los usuarios desde una nueva perspectiva, e idear características de producto que resuelvan esa necesidad lo mejor posible.

Si bien el framework JTBD es nuevo, es similar en muchos aspectos a métodos ya establecidos, como el análisis de tareas y los casos de uso, que se centran en el contexto, las metas y los pasos involucrados en la interacción con un producto. El núcleo diferenciador entre JTBD y estas técnicas tradicionales de análisis de sistemas es que JTBD es mucho menos prescriptivo sobre qué es exactamente la tarea de los usuarios y cómo lo lograrán. El análisis de tareas y los casos de uso buscan comprender la mejor manera en que el producto maneja las actividades típicas que los usuarios necesitan hacer (y con frecuencia terminan sesgados por las soluciones existentes); El enfoque de JTBD se centra en los resultados deseados y pregunta si esas actividades típicas son la forma de alcanzar los resultados que realmente buscan los usuarios.

Por ejemplo, si un análisis de tareas tradicional revela que los conductores de repartos necesitan imprimir direcciones que muestren cómo navegar entre cada parada de su ruta diaria, es probable que el equipo de diseño se concentre en hacer lo más fácil posible para los conductores el Formato e Imprimir las direcciones; sin embargo, un enfoque centrado en JTBD se enfocara en el "trabajo" del conductor (es decir, obtener una guía de navegación mientras conduce) y buscara soluciones a ese problema (como un sistema GPS que proporcione la guía por voz).

El marco de la JTBD sugiere que la innovación y el buen diseño provienen de la evaluación de las necesidades reales de los clientes y de la creación de una solución libre de los productos existentes que satisfagan esas necesidades. Sin embargo, la innovación radical puede ser una estrategia costosa y arriesgada de mejora del producto.

A menudo, escuchamos a los defensores de JTBD refiriéndose a la famosa cita de Theodore Levitt: "La gente no quiere comprar un taladro de 6 mm., quiere un agujero de 6 mm.". En lugar de centrarse en una lista de características de un producto, el framework JTBD obliga a los diseñadores a pensar en los resultados: ¿serán los usuarios capaces de completar el trabajo para el que contrataron el producto? ¿Esta solución proporciona un resultado mejor que los existentes?

Si bien el enfoque JTBD no prescribe un formato específico o entregable, la mayoría de las veces JTBD se define en un formato de oración, anotando lo que los usuarios tienen que hacer y cualquier información contextual clave, como por qué o dónde lo hacen. Finalmente, una descripción de JTBD típica captura los criterios de éxito funcional (el objetivo, los requisitos para que este trabajo sea exitoso), así como los criterios de éxito emocional (que pueden ser desglosados ??en los criterios emocionales individuales de los usuarios y cualquier otra consideración social, tales como cómo se imaginan que serán percibidas por otros).


Imaginanet

Los JTBD son normalmente resumidos en una sola oración que describe lo que el usuario necesita lograr y cualquier contexto importante que pueda afectar a este trabajo (en este ejemplo, viajes de trabajo para una  conferencia, en lugar de viajes de vacaciones). Los JTBD también suelen incluir alguna información sobre el objetivo, los criterios de éxito funcional, así como los criterios subjetivos de éxito emocional que cubren lo que cuenta como una buena experiencia. Los criterios emocionales se dividen a menudo en dos niveles: criterios personales y consideraciones sociales.

Personas va más allá de la demografía

Muchos de los argumentos que sugieren que Personas se ha vuelto irrelevante con la introducción de JTBD se basan en la suposición errónea de que Personas es principalmente descripciones demográficas de los clientes. La demografía es problemática para las decisiones sobre productos o diseños ya que no proporciona datos conductuales o actitudinales, y es más adecuada para tomar decisiones de marketing y publicidad.

De hecho, Personas está destinado a ofrecer abundantes representaciones de los usuarios, e ir más allá de meros detalles demográficos o personales. La mayoría Personas bien diseñados incluyen una multitud de información como:

  • Detalles demográficos como edad, estado civil o ingresos
  • Detalles personales como una breve biografía, fotografía y nombre
  • Detalles de actitud y / o cognitivas tales como información acerca del modelo mental, los puntos de dolor y los sentimientos acerca de las tareas que se deben realizar
  • Metas y motivaciones para el uso del producto
  • Detalles sobre el comportamiento de cómo la persona tiende a actuar al usar el producto

Los datos demográficos y personales existen por dos razones principales:

  1.  Para construir la empatía del equipo del producto hacia el usuario
  2.  Como dispositivos mnemónicos para ayudar a hacerlos memorables para el equipo

Desafortunadamente, muchas Personas (en realidad los segmentos de marketing se disfrazan de Personas) no van más allá del nivel demográfico o personal, por lo que Personas a menudo se perciben como menos valiosas para tomar decisiones de diseño que JTBD.

Personas bien ejecutado se basa en gran medida en características de comportamiento, datos de actitud e ideas sobre modelos mentales, y requiere investigación cualitativa con usuarios reales para descubrir el porqué de los comportamientos de los usuarios. Estos Personas normalmente incluyen información relacionada con objetivos específicos que los usuarios deben alcanzar cuando usan el producto; Estos objetivos son directamente comparables a la información que se encuentra en la definición de JTBD.

Jobs-to-Be-Done no promueve la empatía

Una de las principales razones por las que Personas se centra originalmente en representaciones realistas del usuario es la de alejarse de la mentalidad del cuadro de comprobación de las listas de características y requisitos, y centrarse en como debería ser la experiencia para los usuarios. Aunque JTBD incluye algunas consideraciones clave sobre el contexto emocional y social de una meta de usuario, las generaliza entre toda la base de usuarios y, por lo tanto, pierde ese sentido clave de contexto sobre los usuarios y pierde la oportunidad de crear empatía entre el equipo de diseño.

Personas ayuda con la priorización entre diferentes usuarios

Imagina el siguiente escenario: estás en un equipo de diseño que crea una nueva versión de una aplicación de escritorio popular de productividad. En los últimos años, los competidores han entrado en el mercado con productos innovadores, y hay un deseo en tu empresa para rediseñar la aplicación y así competir con los nuevos productos en el mercado. Si bien es útil entrevistar a tus clientes actuales y los potenciales nuevos para averiguar qué JTBD son importantes para ellos, también vale la pena señalar las diferencias que serán clave entre estos grupos: si diseñas desde cero, tratando de resolver los JTBD de una manera que se adapte a los usuarios nuevos, es probable que se alteren seriamente los flujos de trabajo de tus clientes existentes (y, por tanto, con impacto negativo en su productividad ya que tienen que volver a aprender el producto). Si rediseñas completamente una característica heredada (o, como suele sugerir el framework JTBD, creas una solución totalmente diferente e innovadora al problema), podrías dañar tu base de usuarios existente.

Los profesionales UX tienen que buscar el equilibrio en las consideraciones de diseño entre muchos tipos diferentes de usuarios, que a menudo tienen intereses en competencia. Mientras que todos los compradores de un taladro tienen el mismo JTBD de hacer agujeros en cosas, un contratista profesional priorizará la durabilidad de la herramienta, mientras que alguien que cuelga algunos cuadros en su hogar priorizará el precio. Estas dos consideraciones están en conflicto entre sí, por lo que si intentamos abordar el trabajo sin diferenciar (y priorizar) entre estos usuarios, es probable que obtengamos una solución insatisfactoria, por muy innovadora que sea.

Si bien el mismo JTBD puede tener requisitos diferentes para diferentes grupos de usuarios, lo contrario también es cierto: un grupo de usuarios (o Persona) puede "contratar" el producto para diferentes trabajos en diferentes contextos. Por ejemplo, utilizar el mismo sitio web de reserva de vuelos para viajes de trabajo y viajes de vacaciones. Estos tipos de viajes diferentes son en última instancia distintos JTBD con consideraciones muy diferentes, pero independientemente de la situación para la que se esté utilizando el sitio, comparten el mismo modelo mental de cómo funciona el sistema, las características de actitud y los rasgos de comportamiento. Es probable que tengan comportamientos y actitudes que son similares a algunos  usuarios, y muy diferentes de otros grupos de usuarios. Es por eso que creamos múltiples Personas: reflexionar sobre los factores clave de diferenciación entre nuestros usuarios, para poder equilibrar las necesidades y priorizar entre Personas.

Personas y Jobs-to-Be-Done son compatibles

A pesar de muchas voces contrarias que sugieren que JTBD puede reemplazar completamente a Personas, los dos son bastante compatibles. Dependiendo de las necesidades de tu organización y de si tu equipo ya usa Personas o JTBD, pueden ser utilizados de manera complementaria, o la información básica de JTBD puede integrarse en Personas.

En las organizaciones que ya han adoptado JTBD, no hay necesidad de duplicar este trabajo en Personas: cada Persona puede hacer referencia a los ya puestos de JTBD existentes que se aplican a ese Persona en particular, junto con cualquier información única y diferenciar la información sobre los criterios de éxito funcional o emocional de ese Persona para ese JTBD.

Si tu organización usa Personas, pero no incluye las metas y detalles de comportamiento que son claves para tener un Personas efectivo, comienza por aumentar los artefactos de Persona con información parecida a JTBD: en lugar de simplemente enumerar los objetivos de Persona, considera formatear esta información como los JTBD, y preguntar: ¿qué está intentando lograr el usuario? ¿cuáles son las claves de éxito (tanto funcionales como emocionales) para esos trabajos?

Si hay mucha resistencia en tu organización a la creación de Personas (como problemas para obtener el apoyo del liderazgo, o colegas escépticos), pero hay recursos y las ganas por obtener los datos centrados en el usuario para influir en el diseño del producto, JTBD puede ser un alternativa útil.  JTBD siempre se puede utilizar en combinación con Personas.

Conclusión

La usabilidad de cualquier diseño dado sólo puede evaluarse en relación con dos variables: quiénes son los usuarios y qué es lo que necesitan hacer. Por eso es crítico para la validez de un estudio de usabilidad reclutar a usuarios de prueba representativos y darles tareas representativas a realizar. Por esa razón, necesitamos especificar el público objetivo y sus objetivos durante el proceso de diseño, para que no diseñemos para los usuarios equivocados o creemos las características incorrectas. Usuarios y tareas: necesitamos ambos para que un proceso UX tenga éxito.

Personas es más que simples segmentos demográficos o de marketing, e incluye información enriquecida sobre las metas, necesidades, puntos de dolor y expectativas de los usuarios, al tiempo que incorpora esta información en un formato narrativo que promueve la empatía entre el equipo de diseño. Aunque JTBD puede proporcionar una forma útil de articular las necesidades específicas de los usuarios, esta información ya está representada en Personas si está bien ejecutado.

Comentarios

Sin comentarios
Ha habido un error en el envío
Comentario enviado. Será revisado por la moderación antes de ser publicado.

Deja tu comentario

Tu nombre:
Tu email:
Tu comentario: