Reconozco que he asistido con bastante pereza al evento: a la mitad de los ponentes no los conocía y sus temas me parecían muy introductorios; a la otra mitad, porque los conocía y sus temas me parecían muy habituales.

El primer día la calidad general de las presentaciones fue de ‘aprobado raspado’.  Los asistentes se cebaron en los jóvenes -y no tan jóvenes- que subieron al escenario:  por su academicismo, por su tema, por su forma de leer las presentaciones…

El segundo día los ponentes se pusieron las pilas para que no les crucificaran en Twitter y el nivel subió un poco hasta el ‘notable bajo’.

Durante los dos días, el feedback directo desde las butacas fue bastante escueto, casi limitándose a los aplausos, excepto en el debate final, donde los jardines se abrieron al público.

Como antes comentaba, el público es muy diverso:

• investigadores, programadores, diseñadores, gestores…
• de Madrid, de Barcelona, de otras provincias…
• profesores de masters, estudiantes de masters, gente que aprende haciendo y leyendo…
• gente de 40 años que lleva en internet desde hace 20 años, gente de 20 años nativos digitales…

Ante tal variedad, y con las condiciones ambientales adecuadas (calor, hacinamiento, aburrimiento, el caldo de Twitter, el espíritu del 15M), ante la más mínima chispa, salta el fuego. Y al final, saltó.

¿Los test de usuarios no son necesarios?

Este fue el primero y más polémico de los temas.  Twitter se inflamó y llegó a ser trending topic en España.

A favor de la tesis estaban los veteranos de Cadius. En contra, el resto del mundo:  los que pagan su hipoteca con ellos, o los que repiten como un mantra aprendido que no sólo son necesarios, sino que son imprescindibles.

Es lo que pasa cuando derribas un pilar de una religión, que la gente se mosquea. En la actualidad, los proyectos de diseño se cuentan por miles. Me atrevo a aventurar que ni el 5% de esos proyectos (siendo generosa) se testan en laboratorio clásico, y si lo hacen es por alguna de estas razones:

• porque la empresa quiere estar muy segura antes de lanzar un producto al mercado
• porque tienen problemas de conversión y no son capaces de detectar dónde está el problema
• porque los usuarios son muy especiales, y ponerse en su piel es muy complicado para un diseñador
• porque es política de la empresa, porque tiene dinero para hacerlo y/o porque quiere hacerlo

Por ejemplo, si hacemos un sitio web normalito para una pyme, o montamos un blog para un amiguete, ¿a que no lo testeamos en un laboratorio? Es lo que Jesús Gorriti o  Javier Cañada querían decir con lo de que tenemos herramientas y paradigmas aprendidos que nos permiten no tener que testar siempre en laboratorio.

Pero… ¿y si tenemos que diseñar algo más complejo, como el interfaz de una lavadora para ancianos o un bisturí para neurocirujanos? Aún siendo un diseñador experto y especializado en ese área,  la investigación es necesaria. Sí o sí. Ya veremos si es en laboratorio, en casa de los usuarios, en el centro comercial estudiando los diferentes tipos de lavadoras que hay, o en la biblioteca leyendo libros del sector… Si no investigas, no avanzas. Te quedas aplicando siempre los paradigmas aprendidos. Eso es aburrido, y no puede haber peor enemigo para un diseñador de Experiencia de Usuario que un proyecto sea aburrido. Y para nuestros clientes, eso es mortal.

Que significa trabajar en UX

Según uno de mis profesores, los que nos dedicamos a la experiencia de usuario somos  gente de letras que no podemos trabajar en nuestro campo y que tenemos que buscarnos la vida en otros sectores, pero que realmente no tenemos ni idea de diseño industrial.

Ante esta afirmación (no exenta de mucha razón), me gusta argumentar que, en el fondo, todos los que participamos en un proyecto estamos colaborando en su éxito final. Da igual si eres programador de front o de back, si eres el que eliges los materiales del producto, el que negocias el precio de los proveedores o el que recibe a las usuarios y les acompaña hasta el laboratorio. Como diría el limpiador de Cabo Cañaveral a J.F. Kennedy, “estoy ayudando a mi pais a pisar la luna”.

Cualquier persona, en cualquier puesto, afecta al diseño de la Experiencia de Usuario. Todos los que trabajamos en el producto o servicio (tanto en su creación como en su ejecución), estamos ayudando a poner un pie en la luna. De nada sirve que en las especificaciones del servicio diga que los camareros deban ser simpáticos, si luego no lo son.

Como comentó Justyna Adamczyk, de Tuenti, las labores de un puesto de UX no están nada claras, porque en el fondo, todos afectamos al resultado final, que es lo importante. Unos pintan prototipos, otros investigan con usuarios, otros programan, otros seleccionan los materiales… Entre todos, se llega o no a la luna.

El problema de que todo sea UX, es que al final el término se pervierte y nada es UX.  Quizá sería mejor así. Nos evitaríamos perder el tiempo en discusiones terminológicas y nos centrariamos en lo importante: en la sonrisa del usuario cuando utiliza nuestro producto o servicio.

Masters, carreras y formación

Aquí se abrió otro bonito jardín para ver si era mejor la formación reglada, la no reglada, la auto-formación, la gratuita, la de pago, el grado, el posgrado, el master…

No quiero entrar mucho porque me parece un debate baldío. Cada cual que elija la que más le guste. Yo prefiero mezclar un poco de cada una y, sobre todo, hacer, un aprendizaje mucho más completo que cualquier cosa que te pueda contar un libro o un profesor.

Madrid, Barcelona y teletrabajo

Otro debate digno de Messi y Cristiano. El volumen de trabajo en las dos ciudades es comparable en términos cuantitativos, no cualitativos. Nadie tenía datos actualizados y, aunque los tuviera, ¿para qué entrar en esa discusión?

En cuanto al teletrabajo, cada cual cuenta la feria según le va.

Por qué nos dedicamos a esto

Por dinero. Si no nos pagaran, trabajaríamos en otra cosa. Dejemos de ser unos buenos-rollistas del amor al usuario y pongamos en valor nuestro trabajo. Pagamos dinero para cursar masters, pagamos dinero para comprar libros, pagamos dinero y tiempo por ir de conferencias, pagamos tiempo para cuidar de nuestra marca personal a través de blogs y participación en conferencias. Somos profesionales, no una ONG, aportamos valor a las empresas.

A modo de conclusión

En definitiva, es bueno que haya debates en la comunidad donde cada uno exprese su punto de vista y se implique emocionalmente porque nos importa y nos afecta. Twitter nos permite expresar en caliente nuestras sensaciones inmediatas, pero echo de menos un mayor nivel de implicación, e invito a todos los asistentes, una vez apagado el calentón, compartir con la comunidad una reflexión elaborada, no un twit, sobre cualquiera de los temas que se trataron -o no- en UX Spain.

Cuando empecé a trabajar, los diseñadores éramos simplemente diseñadores: se nos pedía que hiciéramos un logo bonito, unos colores adecuados, una composición elegante… Con un poco de maña, también tenías la posibilidad de currarte tu propio sitio web desde cero, con ayuda de Geocities y un html con marquesinas, marcos y parpadeos.

Pero las cosas cambiaron

En el año 2000 se publicó en español un libro que hizo cambiar algunas cosas en la industria española. No todos los libros tienen esa capacidad, y eso hay que reconocerlo. A partir de 2002 ya podías escuchar a clientes que te decían: es que yo he leído un libro de Jakob Nielsen que dice que… Lo bueno de esa frase es que abrías los ojos y pensabas: “¡Genial, alguien que se preocupa por la usabilidad!” y lo malo es que pensabas “¿Cómo le digo que ese libro se escribió en 1998 y que las cosas ya han cambiado?“.

El reinado de la usabilidad fue largo, y tuvo un gran compañero de viaje en Internet Explorer. Al ‘no haber otros navegadores’ para los que diseñar, los diseñadores nos centramos en la versión 6, y dedicábamos a él todo nuestro tiempo. Tanto los usuarios como los diseñadores nos convertimos en especialistas en sacarle el máximo rendimiento. Pero, como dije en el primer párrafo, todo cambia. Cambiamos los usuarios, cambiamos los diseñadores, cambiaban nuestras exigencias… pero Internet Explorer no cambiaba. Todo lo que podíamos hacer era confiar en que las cosas monas se hicieran en Flash. Raro era el proyecto web que no tenía su magnífico intro en Flash. Y lo que en un principio era muy bonito, se volvió cansino, no porque la herramienta fuera mala en sí misma, sino porque se hizo un mal uso de ella; y las simpatías hacia Flash se tornaron en odio.

Pero las cosas volvieron a cambiar

Durante el reinado de la usabilidad, otras disciplinas convivieron de forma más o menos pacífica con ella: la accesibilidad, el SEO, las métricas, la arquitectura de información… Llegó un punto en que nos dimos cuenta de que todo estaba relacionado. Estábamos asistiendo al nacimiento de la Experiencia de Usuario como entidad.

Otras muchas cosas cambiaron. Los móviles empezaban a conectarse a internet (el wap era una broma, eso no contaba), Apple y Google se establecían como referentes, las tecnologías de lado cliente y de servidor ofrecían millones de capacidades, los usuarios se convirtieron en personas muy exigentes… y, lo más importante, las empresas comprendieron que la Experiencia de Usuario no era un gasto superfluo en diseño, sino como inversión con una rentabilidad cierta y un elemento diferenciador de la competencia.

El diseño de la Experiencia de Usuario contemplaba conocer múltiples disciplinas y poder aplicarlas en múltiples ámbitos. Divertido, pero agotador al mismo tiempo. No se puede ser un excelente analista de métricas, un excelente moderador de focus-groups, un excelente auditor de accesibilidad y un excelente diseñador de interfaz al mismo tiempo. Del mismo modo, no se puede ser un diseñador especializado en interfaces móviles y al mismo tiempo en aplicaciones de intranet. Ni siquiera, siendo un diseñador especializado en interfaces móviles, puedes abarcar todos los modelos de dispositivos, sistemas operativos y tamaños de pantalla. Simplemente, no da tiempo en la vida. Los diseñadores nos fuimos especializando en áreas, cada vez más específicas.

Y se empezó a hablar de Experiencia de Usuario como una entelequia, algo a lo que se debía llegar, que se tenía que tener en cuenta, que se debía ofrecer al cliente, pero era difícil de concretar. Al final se le terminaban ofreciendo al cliente servicios muy concretos -un test de usuarios, unos prototipos, un rediseño – pero no un servicio integral de Experiencia de usuario como tal.

Y las cosas cambiaron de nuevo

Recuerdo el laboratorio de Next-D hace casi 5 años. Ofrecían una nueva visión del Diseño dentro de la cadena de producción. Hablaban, sin nombrarlo directamente, del Service Design, del Design Thinking, de la co-creación, y de todas esas cosas que ahora están tan de moda. Un diseñador que no es diseñador, sino un facilitador de la creación. Los diseñadores hiper-especializados, que habíamos vuelto a estar casi al final de la cadena, nos situamos en la cabeza del producto. Ya no sólo debemos saber hacer un logo bonito, tenemos que tener las habilidades del MBA para liderar y la mentalidad del I+D+i para anticipar el futuro. Recuerdo mi posición conservadora y escéptica hace 5 años, pero ahora mi percepción ha cambiado y estoy de acuerdo con ellos en más cosas que antes.

Las cosas volverán cambiarán

El diseño se reinventará, una vez más. Beberá de lo anterior, pero lo planteará de un modo distinto. La profesión evolucionará desde la etapa anterior, en la que lideramos productos, a una posición en la que nos convirtamos en los Steve Jobs de nuestros productos: deberemos asegurarnos de que sean perfectos, que gusten a todos, que sean novedosos y que sean rentables. Deberemos ser exigentes con todo -empezando por nosotros mismos-, tener la capacidad de la última decisión y manejar el presupuesto. Deberemos estar rodeados de un equipo excelente y tener una formación multidisciplinar. Y por supuesto, tendremos que conseguir un logo bonito, unos colores adecuados y una composición elegante.

Como cuando diseñábamos hace 15 años, pero diferente.

Los profesionales invitados a dar su punto de vista sobre la profesión fueron:

• Carmen Bustos
• José de Sola Gutiérrez
• Carlos González de Herrero
• Aldara Sánchez

A continuación extraigo algunas frases y conceptos que dijeron.

Carmen Bustos

Habló sobre el “design research”, o investigación a través del diseño, aunque en realidad se trata de “marketing research”. Aunque la frase suene a manida, “no pretendas que las cosas cambien si siempre haces las mismas cosas”, sino que hay que replantearse las cosas: hay que probar y arriesgar para conseguir resultados distintos.
Una cuestión a resolver es qué cosas puede hacer un diseñador en el mundo empresarial, porque es raro que se mezclen el mundo del diseño y de la empresa. De eso se trata el “design research”, de incorporar las habilidades de los diseñadores en el mundo de la investigación y de la empresa.
Destacó 4 conceptos:

1. personas vs clientes – debemos diferenciar entre la función estética y la estratégica del producto.
2. hechos vs datos – cuidado con las opiniones, debemos tener datos sobre los que apoyarnos.
3. necesidad vs posibilidad – se puede hacer determinada cosa en un diseño, ¿pero es realmente necesaria?
4. verdades incómodas vs verdades absolutas – los investigadores en diseño vemos “insights”, no somos dioses, nos podemos equivocar. Recordemos que innovación puede implicar fracaso y reintentarlo de nuevo.

José de Sola

Habló sobre el comportamiento del consumidor y de cómo las metodologías de investigación permiten conocer, anticipar y analizar la conducta del consumidor para facilitar la toma de decisiones.
Explicó algunos niveles de investigación:

• económico – conocer el comportamiento objetivo de consumo
• individual - llegar al núcleo de los intereses gustos y preferencias (consumer behavior)
• sociológico – conocer las tendencias, modas y motores del comportamiento

Con ello se pretende:

• escuchar al consumidor
• conocer su psicología más profunda
• anticipar lo que hará

Nuestro trabajo se basa en la búsqueda del insigth: las necesidades, los gustos, los intereses, los sueños, las satisfacciones e insatisfacciones, los productos, los precios, la comunicación, la distribución, los entornos y las oportunidades.
A continuación habló sobre las metodologías que usa en su trabajo:

• Registro y observación de conducta, donde no hay intervención
  • hogares, conducta de compra…
  • tendencias culturales, sociales, modas…
  • rastreos y motores de búsqueda en internet
  • simulaciones de compra online
  • bases de datos
• Análisis cualitativo del consumidor (analisis del porqué, de las motivaciones, de emociones, de sueños, temores, percepciones, influencia de los entornos, rechazos e intereses)
  • grupos de discusión
  • insight
  • discurso grupal
  • sociodramáticas
  • psicodramáticas
  • proyectivas
  • entrevistas en profundidad
  • juegos proyectivos
  • psicodrama
  • contar cuentos
  • análisis de discurso verbal
  • juegos
  • dibujos
• análisis cuantitativo de la conducta (observación, encuestas o experimentación, estadística de agrupación).
  • entrevistas personales (CAPI)
  • entrevistas telefónicas (CATI)
  • entrevistas online (CAWI)

  Como apunte, decir que las online son más sinceras y las personales más profundas

El objetivo final de todas las investigaciones es intentar conocer al consumidor, porque:

• el consumidor nunca dará información sobre lo que no quiera
• no se puede predecir completamente lo que hará hasta que no lo tenga delante
• su comportamiento es impresvisible en muchos sentidos
• si le gusta, lo encumbra; si no, lo hunde

Para finalizar, algunas reflexiones que hizo:

• Cuando un producto capta una necesidad de verdad, se vende solo
• Vamos hacia una globalización en la comunicación
• La publicidad gusta, pero no la satuación
• El consumido busca información sencilla, sincera y directa
• El consumidor desconfia de la publicidad
• Vamos a un mundo viral fomentados por las redes sociales
• Si algo gusta, gustará en todo el mundo
• la investigación del consumidor solo ayuda, no resuelve

Carlos González

Habló sobre la co-creación y los nuevos escenarios en el diseño. Explicó:

• las diferencias entre user centered design; critical design; design and emotion; y participatory design research
• qué se obtiene cuando desplazas al usuario: es diferente visitarle que que traerle a tu laboratorio
• la necesidad de los equipos multidisciplinares: los modelos de colaboración y las dinámicas de producción
• la iteracción continuada y la flexibilidad: co-desing
• se puede aplicar al diseño de productos no digitales, como muebles

Aldara Sánchez

Enfocó su objetivo hacia los riesgos que tiene el investigador de Experiencia e Usuario, entre ellos los errores que tienen los observadores.
Por un lado, cuidado con las grandes verdades en el pretest, el test y el análisis (post-test). El investigador es un usuario, y como tal también es subjetivo (y además está contaminado), que responde ante unos objetivos de negocio y unos objetivos propios.

• A veces, en los laboratorios, sólo se busca confirmar una hipótesis y se enfoca la investigación en eso, manipulando de algún modo la credibilidad de todo el proceso.
• El ‘think aloud’ cambia al usuario, a veces es mejor no hacerle hablar.
• A veces se busca la frase para la foto (o el video)
• Se desvirtúa la motivación real y entorno natural

En cuanto el eyetracking, lo define como un complemento al análisis, pero a veces se interpreta a la carta. Dejó bien claro que en sí mismo no hace milagros y es muy manipulable: da mucha información sobre lo que se ve y lo que no, pero en el fondo da datos muy globales sobre cómo interactúa el usuario con la web.

Algunos consejos finales que ofreció fueron:

• evitemos caer en la tentación
• el usuario no es un experto
• es necesario un trabajo continuo entre cliente-empresa-moderador
• piensa en lo que estás evaluando y no te precipites
• aunque tengas las mente en blanco, seguirás siendo subjetivo
• sólo observa y así conseguirás contar sólo lo que ha ocurrido
• ten cierto control sobre el cliente
• relaja al cliente, relaja al usuario y relájate

Lo que todo profesional de la experiencia del usuario tiene que saber acerca de las estadísticas y las pruebas de usabilidad

¿Te gustan los ordenadores, pero odias las matemáticas? ¿Te gusta trabajar en la creación de tecnología punta, pero crees que no tienes la aptitud cuantitativa para ser un programador o ingeniero informático? Entonces, ¡conviértete en un profesional de la experiencia de usuario! Si puedes contar hasta 5 (el número de usuarios en un test de usabilidad), entonces ¡ya sabes todas las matemáticas que necesitas! ¡Todo lo demás es arte! Apuesto a que eres bueno en el arte, ¿no?

¡Ja! ¡Iluso! Resulta que es necesario saber algo de matemáticas para trabajar en Experiencia de usuario. Estar en UX significa que tarde o temprano vas a tener que lidiar con los datos sobre el rendimiento o la satisfacción del usuario, habitualmente de un test de usabilidad. Incluso si te limitas a dejar el diseño y la investigación de usuarios en otras personas, vas a tener que revisar los resultados de la investigación del usuario para mejorar tu trabajo de diseño, por lo que vamos a necesitar conocer algunos de esos conceptos para poder hacer la evaluación de esos datos.

En concreto, necesitas saber un par de cosas sobre estadística inferencial, la rama de la estadística que nos ayuda a determinar lo que razonablemente se puede concluir acerca de la población de usuarios en función de lo que estás viendo en la muestra de usuarios. La estadística inferencial tiene dos objetivos básicos, los dos sobre los datos del usuario:

• Valor de la inferencia. Dado un porcentaje observado o el rendimiento promedio en la muestra de los usuarios, inferir lo que probablemente estaría sucediendo en toda la población de usuarios. Puedes intuir que el promedio o el porcentaje del rendimiento de los usuarios que vemos en una pequeña muestra fácilmente podría no corresponderse con el promedio o porcentaje los usuarios en toda la población. Por ejemplo, podría ocurrir que se obtuviera al azar algunos usuarios que se desempeñaron mejor o peor que los usuarios promedio. El valor de la inferencia explica cuál es la probabilidad de que esto ocurra.
• Relación de la inferencia. Habida cuenta de una aparente conexión entre dos variables en la muestra de los usuarios, inferir si existe algún tipo de relación sistemática o causal entre los dos. Es posible que aparezca un cierto patrón en la muestra. Por ejemplo, puede observarse que los usuarios que comienzan en una determinada página tienen más probabilidades de realizar una compra que quienes comienzan en otra página. Podría ser una coincidencia o pura casualidad. O podría haber algún tipo de relación subyacente. La relación con la inferencia nos dice la probabilidad de que existan una relación sistemática entre dichas variantes.

¿Por qué evitar la Estadística inferencial?

"No me fío de los números"

Si estás calculando un valor de la inferencia o la relación de la inferencia, la estadística inferencial es fundamental para establecer la confianza que debes tener en tus datos. Puedes pensar que no vale la pena molestarse con la estadística cuando el rendimiento general de la prueba es sólo una de las muchas cosas que tienen un peso en el diseño. Pero sin establecer un nivel de confianza para ese rendimiento, ¿cómo puedes saber cuánto pesan en las discusiones sobre tu diseño? ¿Cómo sabes si estás realmente aprendiendo algo de un test de usabilidad o simplemente te estás engañando a ti mismo? Sin establecer un nivel de confianza, ¿cómo puedes convencer a tu cliente sobre la importancia del problema que estás tratando de resolver? ¿Qué haces si un jefazo, por ejemplo Wayne de Finanzas, dice: "Bah, sólo es una prueba con cinco usuarios. Eso no es estadísticamente significativo." ¿Te encoges de hombros?

¡Oh, el “Sr. Significación Estadística”! Temido por algunos. Tratado con desprecio por los demás. Es como si casi todo el mundo deseara que se fuera. Creo que la mayoría de profesionales de UX contamos con que haya algún “Sr. Significación Estadística” que pregunte si los tamaños de muestra en nuestra investigación del usuario son lo suficientemente grandes. Esto nos da a los UXers la incómoda sensación de que si lo permitimos, el “Sr. Significación Estadística” empezará a decir lo falsos que son los datos de los test de usabilidad con muestras pequeñas. Al igual que Galileo mostrando que la Tierra gira alrededor del sol, puede probar que la credibilidad en las pruebas de usabilidad es nula. Y no podemos permitir que haga eso. Sin embargo, como el solitario incomprendido en una película de clase B, el “Sr. Significación Estadística” en realidad tiene algo valioso que ofrecer a la comunidad de UXers si nos tomáramos el tiempo suficiente para aplacar su ignorancia matemática.

En su lugar, oigo que no merece la pena el esfuerzo de aplicar un análisis estadístico a un test de usabilidad típico con muestras pequeñas, o, es más, que las estadísticas no se aplican a muestras pequeñas, como si ser simple nos excluyera de las leyes de probabilidad. Me han dicho cosas como: "El tamaño de la muestra es demasiado pequeña para el análisis estadístico", que es algo así como decir: "Nuestro barco es demasiado pequeño como para preocuparse de la sobrecarga."

Algunos creen que es mejor disparar por si acaso al mensajero antes de que digamos cosas inconvenientes. Frases como, "sé que no va a ser importante, con sólo cinco personas, así que ¿por qué molestarse?" Y se van intentando ocultar el problema. Vale. “Sé que mi paracaídas no se despliega correctamente, entonces ¿por qué comprobarlo?” Disculpe, pero es tengo que hacer paracaidismo.

"Estoy siendo cualitativo"

Es legítimo sostener que las estadísticas no son pertinentes en las pruebas de usabilidad con muestras pequeñas, ya que tu interés está en los datos cualitativos y su análisis, en lugar de datos cuantitativos y su análisis. El análisis cualitativo es un acercamiento eficaz y científico perfecto para responder a los tipos de preguntas que desea responder a un test de usabilidad, especialmente cuando se usa como parte del diseño interactivo (es decir, formativo en lugar de prueba sumativa). En ese caso, estás menos interesado en el valor de la inferencia que en las inferencias de las relaciones. No te importa nada cuántos usuarios tienen problemas con tu producto. Como UXer, asumes que habrá problemas con tu producto, y muy a menudo, así será, a pesar de tus mejores esfuerzos como UXer.

Lo que quieres saber es cuáles son esos problemas y, sobre todo por qué ocurren. Sin la habilidad de inferir una relación entre el problema (por ejemplo, el usuario se pierde) y la causa (la etiqueta del vínculo es confusa), no sabrás cómo mejorar el producto. Para inferir relaciones de forma cuantitativa, tienes que anticipar el problema y la causa, y medir o controlar cada uno, haciendo algo más cercano a las pruebas A/B que las pruebas clásicas de usabilidad con muestras pequeñas. A causa de esto, lo cualitativo es mejor que lo cuantitativo cuando estás haciendo pruebas de usabilidad de tipo investigación exploratoria "vamos a poner un usuario frente a esta cosa y a ver qué pasa" y este tipo de pruebas de usabilidad.

Así que definitivamente debes recopilar y evaluar datos cualitativos. Sin embargo, debe hacerse esto porque es la mejor metodología, no como táctica para ignorar las cuestiones estadísticas. A propósito:

• Sólo por llamarlo "cualitativas" no la convierte en cualitativo. Algunos UXers parecen pensar que cualitativa significa simplemente tener un carácter vago en sus informes, que mientras no representas nada con números arábigos, puedes omitir las partes estadísticas. Las frases que usan son "algunos usuarios" y "la mayoría de los usuarios", o muestran los datos en gráficas, en lugar de dar un número preciso o un porcentaje. Cada vez que tratas con cantidades relativas o niveles de algo, tratas con cantidades, y las estadísticas son necesarias. Cada vez que asciende el gráfico, está utilizando las estadísticas, pero no necesariamente las estadísticas inferenciales. Los verdaderos datos cualitativos son historias, secuencias de acontecimientos relacionados y las percepciones, cosas que no se pueden reducir a cantidades sin perder información clave que necesita para hacer relaciones inferenciales cualitativas. La cuantificación de los datos implica necesariamente abstraerlos. No es posible cambiar los datos cuantitativos en datos útiles cualitativos -no tendrás la información narrativa rica que necesitas para el análisis cualitativo.
• Ser cualitativo no es generalmente más barato o más fácil de lo cuantitativo. Mientras que la investigación cualitativa se realiza normalmente en tamaños de muestra pequeños, el tiempo y el esfuerzo dedicado a cada usuario es mucho más alto que la investigación cuantitativa. En la investigación cuantitativa, la recopilación de datos para un usuario puede limitarse a la comprobación de un cuadro para registrar si un usuario completa una tarea o no. En el análisis, ese dato se procesa en un unos pocos ciclos de CPU para obtener los resultados. En la investigación cualitativa, para obtener la información rica que se necesita, necesitas registrar mucho más sobre el desempeño del usuario, dónde se detienen, lo que casi se hace clic, lo que dijo pensando en voz alta, y cómo responde a tus preguntas abiertas. En el análisis, tienes que juntar todo en una narración coherente, que tiene una gran cantidad de ciclos de cerebro. La investigación cualitativa no suele tener tamaños de muestra pequeños con el fin de ser más barato que la investigación cuantitativa, sino porque es muy duro pagar una gran muestra del estudio cualitativo. Mientras que en algunas situaciones la investigación cualitativa es más rentable que cuantitativa, y viceversa, en promedio es lo mismo. Ser cualitativo por defecto no te va a ahorrar tiempo o dinero.
• A veces anticipa los problemas y causas. Si bien la investigación formativa y el diseño iterativo siempre puede descubrir resultados fortuitos, es mejor centrarse en cuestiones concretas de diseño. Aunque esto no excluye usar investigación cualitativa para resolver esta cuestión, al menos implica que puedes conducir un estudio cualitativo: has planteado una hipótesis sobre cómo un diseño concreto afectará al rendimiento del usuario. Se pueden variar los detalles del diseño y medir resultados específicos. Cuando tienes esa especificidad, un enfoque cuantitativo normalmente te dará una respuesta más clara que un enfoque cualitativo.
• A veces es necesario hacer inferencias de valor. La investigación cualitativa puede hablar de la relación entre dos cosas, pero no es adecuado para medir la frecuencia o cantidad de las cosas. Sin embargo, a veces esto es lo que necesitamos saber. A veces no es suficiente para saber si un producto tiene un problema. También tenemos que saber cómo de grave es el problema, por ejemplo, a cuántos de sus usuarios les afecta. Con los recursos de usabilidad limitados, ¿vale la pena el gasto para reparar el problema? ¿Es mejor priorizar otros problemas? ¿O tienes resultados contradictorios de dos fuentes diferentes y necesitas saber cuál de las dos fuentes es mejor? Los valores de inferencias son casi siempre mejores si se hacen con estadística inferencial. Este artículo se centra en hacer valores de inferencias de los resultados con muestras pequeñas en pruebas de usabilidad.
• Los métodos cuantitativos y cualitativos no son mutuamente excluyentes. Puede usar los dos, a veces con la misma muestra de los usuarios para aprovechar las fortalezas de ambos. Por ejemplo, se puede incluir preguntas abiertas en un estudio cuantitativo. Y puedes realizar análisis estadístico inferencial sobre las principales variables cuantitativas en un test de usabilidad con muestras pequeñas, aunque sea una investigación cualitativa.

La importancia de “Ser significativo”

Supongamos que te he convencido que es importante aplicar la estadística inferencial a los problemas de la experiencia del usuario. Entonces, ¿qué es la significación estadística y por qué es necesario prestarle atención? La respuesta es que es sólo una convención social y se puede ignorar.

Vale. Voy a dar alguna explicación sobre cómo llegué a esa respuesta.

Técnicamente, "significación estadística" significa que los resultados que estamos viendo en la muestra de los usuarios no pueden ser atribuidos a la aleatoriedad del muestreo. Por ejemplo, digamos que realizar un test de usabilidad con una muestra ínfima de tres usuarios, y dos de cada tres tienen un problema para completar la tarea. Una tasa de 67% de fracaso suena bastante mal, pero ¿podría ser atribuido a un error de muestreo al azar? En otras palabras, a pesar de tus esfuerzos para conseguir usuarios representativos para hacer la prueba, podrías haber traído a un par de bichos raros que no son capaces de manejar una interfaz de usuario que sería perfectamente clara para casi todas las formas de vida en el planeta. Con una muestra de sólo tres, es bastante probable. Incluso hay gente que lo piensa incluso con cinco usuarios. Podemos esperar que Wayne de Finanzas piense que es muy posible, dado que él no aceptaría resultados siquiera de 5 usuarios.

Sin embargo, Wayne probablemente no distingue el “alfa” de un agujero en el suelo. Esto no es algo que se juzgue forma subjetiva. Se puede calcular la probabilidad de dos fracasos de cada tres en una tarea si hacemos una suposición razonable y tenemos más información.

La suposición

La suposición más razonable es que tu muestra es una muestra aleatoria de la población de usuarios de tu producto. Hacer esta suposición permite las leyes de la probabilidad hacer que el cálculo sea posible. Ahora, por supuesto, no has tomado una muestra estrictamente al azar de los usuarios, donde todos los usuarios de la población tienen la misma oportunidad de estar en su muestra. Es probable que los sacaras de una ubicación geográfica específica, y hay límites en su capacidad de persuadir a los usuarios a participar en la prueba de usabilidad. También tienes un límite de tiempo concreto: tu producto será utilizado por los usuarios en los próximos años, pero ¿has tenido en cuenta a esa muestra del futuro? ¡Ajá! ¡Ninguna muestra al azar!

Sin embargo, intentaste tomar una muestra representativa de los usuarios, usuarios que tienen características similares a los usuarios en tu población: conocimiento, habilidades, e incluso las variables demográficas. A efectos de cálculo estadístico, una muestra representativa es tan buena como una muestra aleatoria. Si estás pensando en cómo tu profesor de psicología te taladró la cabeza con la importancia del azar, seguro que estás pensando en la asignación aleatoria de las condiciones experimentales, no en un muestreo aleatorio para su inclusión en el experimento. La asignación al azar es muy diferente e infinitamente más factible que el muestreo aleatorio. Algunos hasta podrían argumentar que una muestra representativa es mejor que una muestra aleatoria, que los resultados que se obtienen son más coherentes con el desempeño de la población que sólo recogiendo los usuarios al azar. Sin embargo, si piensas en ello, tus métodos de selección de usuarios representativos probablemente dependen de criterios bastante crudos. Por ejemplo, puedes elegir los usuarios con un rango determinado de años de experiencia en informática y web, pero eso es una medida bastante indirecta de sus modelos mentales y de su comprensión real de los ordenadores e internet. Por todos los medios, intenta conseguir grupos representativos de usuarios, aunque probablemente el resultado será prácticamente igual de bueno que una verdadera muestra aleatoria. Que es lo suficientemente bueno para nuestros propósitos.

Entre paréntesis, también tienes que asumir el desempeño independiente entre tus usuarios, donde la posibilidad de que un usuario falle no afecta a la posibilidad de otro que falle. Sin embargo, eso no suele ser un problema en las pruebas de usabilidad, siempre y cuando:

• Probamos usuarios por separado y no como un equipo o focus group para que no se influyan entre sí.
• Tenemos un número por usuario y por cada variable. Por ejemplo, no deberíamos hacer que cada usuario intente la tarea dos veces para obtener un tamaño de muestra de seis en lugar de tres. Podemos, sin embargo, combinar el rendimiento en ambas tareas para cada usuario (por ejemplo, grabar 0, 1 o 2 fallos por usuario) con el fin de utilizar todos los datos, pero manteniendo un tamaño de muestra de tres).

La información adicional

Bueno, vamos a comprar el supuesto de una muestra aleatoria, así que vamos a calcular la probabilidad de que dos de cada tres fallen. A lo que inmediatamente debes preguntarte, la probabilidad ¿de qué? Para el cálculo de una probabilidad, se necesita algún tipo de punto de anclaje, una especie de número para conseguir tracción. Por ejemplo, al lanzar una moneda, para calcular la probabilidad de tener tres caras seguidas, tenemos que tener la posibilidad de tener una cara en un tiro.

En el caso de nuestro test de usabilidad, podemos calcular la probabilidad de que dos de cada tres fallos sean culpa del defecto de nuestra muestra. Lo cual, si lo supiéramos, nos evitaría hacer el estúpido análisis cuantitativo desde el principio. Pero espera: ¿es útil usar un estado hipotético de la población-aunque sea por buscar un argumento sobre la posibilidad de fracasar? ¿Y cuál es el argumento en este caso? En lo que estamos realmente interesados en si esta tasa de fracaso “dos de cada tres” significa que habrá una tasa de fracaso inaceptable cuando el producto esté en el mercado. En otras palabras, queremos hacer un valor de la inferencia.

Los estados de tu población hipotética

Para calcular la probabilidad de esa tasa de fracaso “dos de cada tres” necesitamos un número real para el estado de la población hipotética. ¿Es necesario probar el 50% de los usuarios en la población? ¿El 25%? ¿El 10%? ¿El 0%? Podemos trabajar con los stakeholders para decidir lo que constituye una tasa de fallo aceptable para su uso como un estado de la población hipotética. Una forma de verlo es comparar el costo de arreglar el diseño con el costo de no arreglar el diseño. Puede que incluso Wayne te dé algunas cifras para calcularlo. Por ejemplo, supongamos que rediseñar lo que la falla tiene en promedio un total de 10 horas de trabajo, a 100€ la hora, lo que el coste de una solución es de 1000€.

El coste de no arreglar el diseño puede ser más difícil de cuantificar en dinero. En el software de negocios, un fallo de diseño puede hacer que la tarea lleve más tiempo (que cuesta más tiempo del usuario), reducir el ánimo de los trabajadores, aumento de llamadas de dudas técnicas (que requieren más personal), aumento de la probabilidad de un error indeterminado, y así sucesivamente. Para una aplicación web de consumo, un defecto de diseño puedan molestar a los usuarios, disminuyendo el valor de la marca, lo que se traduce en pérdidas de ventas o una reducción del número de usuarios que no puedes vender a los publicitarios.

Digamos que es una aplicación de negocios, y por cada fallo, los usuarios van a perder 15 segundos (un fracaso en la categoría de “leve molestia”). Si los usuarios cobran 30€ por hora, ese fallo tiene un coste de 0,125€ cada vez que ocurre. Así que si hay más de 8.000 fallos en el tiempo de vida del diseño, entonces vale la pena revisar el diseño (8.000 * 0,125€ = 1000€, el costo de reparación). Digamos que tienes 100 usuarios usando tu diseño una vez por día, en promedio con 250 días de trabajo por año, y la vida útil del diseño es de 2 años. Eso da 50.000 encuentros durante la vida de la aplicación de (100 * 1 * 250 * 2). Así, la tasa de fracaso del punto de equilibrio es de 16% por visita (8.000 / 50.000). Si la tasa de fallo de la población es más del 16%, el rediseño te ahorrará dinero a largo plazo. Si la tasa de fallo de la población es menos de 16%, entonces ahorramos dinero al no arreglar el diseño (teniendo en cuenta sólo los costes de tiempo del trabajador).

El coste total de no reparar un defecto depende del número de usuarios y el número de veces que los usuarios se encuentran el diseño durante la vida útil del producto. Haz el mismo tipo de cálculos en una aplicación de comercio electrónico con millones de usuarios y cientos de millones de dólares en ventas, y verás que vale la pena arreglar un fallo de diseño que haría que una fracción de los usuarios se encuentran el error se vayan a un competidor.

En la práctica, no vas a ser capaz de determinar la tasa de población con tanta precisión. Lo que puedes hacer es calcular un rango de tasas de población jugando con los números que tenemos y hacer algunos cálculos prudentes junto con tus stakeholders:

• Estado Hipotético A: ¿Qué tasa de fracaso consideran absolutamente aceptable? Llamémosle nivel “a quién le importa”.
• Estado Hipotético B: ¿Qué tasa de fracaso consideran que requieren una solución?

Obviamente el Estado Hipotético B es mayor que Estado Hipotético A. El verdadero equilibrio de la tasa de fracaso se ubica entre el Estado A y B, llamémosle “zona x”.

La respuesta es …

Así que estamos tratando de calcular la probabilidad de obtener la tasa de fracaso “dos fallos de cada tres intentos” en los Estado Hipotéticos A y B. Digamos que Wayne dice que ambos tienen que ser del 0%, no el 1% o 0,1%, sino del 0%. El fracaso no es una opción. El jefe se preocupa profundamente por todos los fracasos de los usuarios e insiste en que no exista ningún fallo nunca. Cualquier fallo que se solucione vale la pena. ¿Cuál es la probabilidad de que dos de cada tres usuarios de tu muestra fallen teniendo en cuenta que las posibilidades de fallar en la población total es del 0%?

Respuesta: 0. Acabas de ver dos usuarios que han fallado, así que sabemos que no puede ser 0%. Quiero decir, tal vez ha llegado hasta las dos únicas formas de vida entre millones de usuarios que son capaces de fallar, pero esto significa que la tasa de fallo no puede ser del 0%. Eso fue fácil. Esto es algo que los que se preocupan de los tamaños de muestra pequeños parecen olvidar: con independencia del tamaño de la muestra, si alguna vez observas a los usuarios fallando, ciertamente hay algunos usuarios que fallan con su producto. Es sólo una cuestión de cuántos.

Vamos a hacer lo que realmente hay que hacer para calcular. Una tasa de 0%de fracaso es demasiado ambiciosa. En un sitio web para el público en general, se puede tolerar un pequeño fracaso. Probablemente nos sentiremos muy contentos con un 1% o 2% de tasa de fracaso. Probablemente podemos vivir con un 1% a 2% de nuestros usuarios que realicen un mayor esfuerzo, pidan a ayuda, lean documentación, o, en el peor de los casos, se vayan a otro lado. Tal vez incluso del 5% al 10% sería aceptable siempre y cuando estemos hablando de pequeñas molestias y problemas de reembolso. Por el contrario, si estamos consiguiendo una tasa de fracaso del 50%, incluso si son sólo molestias pequeñas, entonces nuestro sitio web está empezando a parecerse a una zona de desastre de usabilidad. Por ejemplo:

• Estado Hipotético A: 10% fracaso. Definitivamente no se soluciona el diseño.
• Estado Hipotético B: 50% fracaso. Definitivamente arreglar el diseño

Eso coloca al punto de equilibrio entre arreglar y no arreglar en el rango 20-40%. Eso podría ser razonable para algunas aplicaciones de intranet con pequeñas poblaciones de usuarios.

Con respecto a la significación estadística, usaremos el Estado hipotético A. Vamos a revisar Estado hipotético B después.

¿Cuál es la probabilidad de que dos de cada tres usuarios fallen, cuando la tasa de fracaso es del 10% de la población?

Respuesta: 0,028.

Aproximadamente un usuario de cada 36. Esa es una posibilidad bastante baja. ¿Qué significa? Realmente es muy poco probable que la tasa de fracaso sea del 10% de la población. No sabemos cuánto es, pero es evidente que sería improbable que fuera menos del 10%. Es mucho más probable que sea superior al 10%. Esto significa que es muy probable si se deja el sitio web tal como está, la tasa de fallo estará por encima del "a quién le importa". La tasa real estará en la “zona x” o superior, tal vez muy por encima del punto “Realmente Merece la Pena Rediseñarlo” del 50%. Con dos de cada tres o 67% de los usuarios en su muestra fallan, ¿qué debe hacer? Preocúpate. Muestra a los usuarios un poco de amor. Arregla el diseño. Probablemente lo peor que puedes hacer es buscar un punto de equilibrio.

El valor de p

Para los estadísticos, el número 0,028 que he calculado se simboliza por p, por lo que llaman el "valor de p." El valor de p representa la probabilidad de observar un determinado resultado (2 fallos de 3) dada una situación hipotética de la población (10% de tasa de fracaso). Lo que acabo de hacer es básicamente de lo que se trata casi toda la estadística inferencial. He calculado un valor de p para un resultado de la muestra dado un estado hipotético bien escogidos de la población (una "hipótesis nula" en la jerga de estadística). Luego miré el valor de p y decidí que era demasiado pequeño como para ser plausible: es poco probable que la tasa de fracaso sea del 10% (o menos). Lo más probable es que se trate de más del 10%. Es probable que tengamos algo de lo que vale la pena preocuparse. Ten en cuenta que mientras que un valor de p es un número infinitamente continuo entre 0 y 1, tenemos que tomar una decisión binaria sobre si merece la pena rediseñar el producto o no.

En casi todos los casos, probablemente estarás de acuerdo en que 0,028 es tan baja que tienes que creer que el índice de fracaso real es más del 10%. Pero ¿y si el valor de p fue de 0,10? ¿0,20? ¿0,50? En alguna parte hay que trazar la línea y establecer un criterio. Puedes pensar en el valor de p como la duda sobre el estado de la población hipotética con respecto a los resultados observados. Un valor de p pequeño significa mucha duda sobre el estado de la población hipotética, y más confianza en que el estado real de la población está más en la dirección de tu resultado de la muestra (en este caso, la tasa de fracaso real es mayor del 10%). Un valor de p alto significa que el resultado de la muestra te dará pocas razones para dudar de la población del estado hipotético. Quizás tienes alguna otra razón para dudar de la población del estado hipotético, pero no es debido a los resultados cuantitativos de sus pruebas de usabilidad.

Otra forma de pensar sobre el criterio de valor de p es tu deseo de estar equivocado. Decidimos volver a diseñar el producto a pesar de que sea poco probable que la tasa de fracaso sea igual o inferior a nuestro nivel "a quién le importa". Poco probable, pero no imposible. De hecho con un valor de p de 0,028, en 28 de cada 1000 pruebas de usabilidad, un nuevo diseño definitivamente no vale la pena. Los estadísticos llaman a estas acciones “Error de tipo I” al hecho de no creer en el Estado hipotético de la población A, cuando en realidad es cierto. La probabilidad de un error de tipo I es igual a tu criterio sobre el valor de p, el punto en el tú dices, "yo no me creo ese estado hipotético. Vamos a actuar como que no es cierto".

Por cierto, la probabilidad de un error de tipo I es simbolizada por la letra griega “alfa”. Ya sabes algo que Wayne el de finanzas no distinguiría de un agujero en el suelo.

Determinando la significación estadística

Vale, hemos conseguido un valor de p de 0,028, por lo que tenemos una duda muy alta de que la tasa de fallo de la población sea de 10% o menos; al contrario, tenemos mucha confianza en que la tasa de fallo sea más del 10%. Pero, ¿es estadísticamente significativa? Ahí es donde las convenciones sociales entran en juego

Como UXer, tú y tus stakeholders pueden usar en principio cualquier criterio de valor de p que deseéis en función de la tolerancia al riesgo en tu situación particular. Los científicos, sin embargo, necesitan estandarizar sus procedimientos estadísticos, lo que incluye la selección de un valor para dividir entre dudoso y plausible. En lo que puede ser considerado como un notable ejemplo de cooperación internacional, decidieron como una comunidad que el criterio de la duda es de 0,05. Es una convención social, pero no arbitraria, teniendo en cuenta los límites prácticos de la investigación teórica y lo que los científicos están tratando de lograr. Para los científicos, las decisiones que tomen sobre la base de este criterio influyen en si tienen nuevos conocimientos científicos o no. Para la estadística inferencial, los científicos seleccionaron un Estado hipotético A de la población que representa esencialmente el status quo conocido. Si los científicos observan algo con un valor de p inferior a 0,05 según ese status quo conocido, entonces la conclusión es que el status quo es incorrecto, y que han descubierto algo nuevo.

0,05 es un criterio muy estricto. Básicamente dice que "realmente no puedes desestimar esta información por un error de muestreo y debes tomarla en serio." Significa que, con una certeza del 95%, debe haber algo más que un error de muestreo. Francamente, hay pocas cosas fuera de las matemáticas que te aseguren una certeza del 95%. Quiero decir, la gente dice "Estoy 95% seguro de tal y tal" todo el tiempo, pero si te pones a contar realmente con qué frecuencia era realmente cierto lo que decían, te saldrá algo así como el 70%. Y estoy 95% seguro de eso.

El valor de p de 0,05 es el criterio científico convencional para la significación estadística. Si un valor de p es igual o menor a 0,05, entonces el resultado de la muestra es "estadísticamente significativo." Significa que se concluye que un estado hipotético particular de la población es falso. Por otra parte, si el valor de p está por encima de 0,05, "no es estadísticamente significativo". Significa que no se puede concluir que un hipotético estado particular de la población es falso.

Así que, si tuviéramos que seguir esta convención científica, tendríamos que reconocer (dada una tasa de fallo hipotética de 10%) consiguiendo 2 fallos de cada 3 usuarios tiene un valor de p menor de 0,05.

¡Maldición! Estamos haciendo “estadísticamente significativa” una muestra de sólo 3 usuarios!

Mayores efectos se logran convalores de p más pequeños

Ahora, antes de ir a decirles a todos tus amigos que todo lo que necesitas es una muestra de tres elementos para tener “significación estadística”, pensemos en lo que estábamos calculando. El valor de p es concretamente la probabilidad de obtener 2 fallos de cada 3 usuarios con una tasa hipotética de error de 10%. Si sólo un usuario fallara, estaríamos calculando la probabilidad de obtener 1 fallo de cada 3 usuarios con una tasa de falla hipotética de 10%, que es un número diferente.

De hecho, el valor de p en este caso es 0,271. Con un valor p de 0,271 hay más de un 25% de probabilidades de obtener 1 fallo de cada 3 usuarios con una tasa de fallo hipotética de 10%; improbable, pero razonablemente posible. (Es decir, encontrarse 2 de cada 3 fallos es estadísticamente significativo, pero 1 de cada 3 no lo es.)

Tienes un gran riesgo de cometer un error de tipo I si inviertes en el cambio de un diseño cuando sólo uno de cada tres usuarios fallan. Hay una gran probabilidad de que sea una pérdida de dinero.

Por lo demás, puedes que tengas normas más estrictas de credibilidad que la comunidad científica. Después de todo, el 0,05 está lejos de ser imposible. Bueno, para ti, tal vez te interese saber que la probabilidad de obtener tres fallos en tres usuarios con una tasa de 10% de la población es de 0,001 ó 1 de cada 1000. Posible, pero en realidad muy poco probable. Si quieres estar super-extra-mega seguro de que no estás cometiendo un error tipo I en tu rediseño, tal vez sólo deberías rediseñar si tres de cada tres usuarios fallan en el test de usabilidad. Un valor de p de 0,001 se llama, y con razón, una elevada significación estadística. Sí, Wayne, con una simple muestra de 3 personas.

Aquí tienes todos los valores de p para un tamaño de muestra de tres y un estado de la población hipotética de 10% o menos:

He incluido los porcentajes de la muestra para mostrar que cuanto más se desvía de la muestra por encima del valor de la población hipotética (10% en este caso), menor es el valor de p.

Cuida tus Ps

Estas son las lecciones que debes aprender:

1. Wayne es un idiota
2. No se puede mirar simplemente el tamaño de una muestra y decidir si un resultado es estadísticamente significativo o no. El cálculo del valor de p depende de la diferencia entre el resultado observado y el estado seleccionado de la población hipotética. Cuanto más grande sea la diferencia, más probable es que sea estadísticamente significativo. Por eso dije que Wayne probablemente estaba lanzando una cortina de humo cuando dijo que los resultados con un tamaño de muestra de cinco no eran estadísticamente significativos. Él no podría saber si eran significativos o no, sin saber el estado hipotético seleccionado de la población y el resultado observado. Un resultado puede ser significativo con una muestra de tres. Del mismo modo, un resultado a veces puede no ser significativo con una muestra de 300.000.
3. La significación estadística no es lo realmente importante. La significación estadística incluye la convención social del punto de 0.05, que puede o no ser adecuado para tu situación. Hablando de mí mismo como científico, el punto de corte de 0,05 no es malo. Ha servido a la comunidad científica, y si no tienes otra cosa para continuar, es un punto bueno para usar en tu propio trabajo. Sin embargo, como diseñador de interfaz de usuario, tu objetivo es producir el mejor diseño posible, que es un meta diferente de un científico que intenta establecer nuevos conocimientos. Eso puede implica un punto de corte diferente a 0,05.

A esto es lo que me refería cuando dije que deberías ignorar la significación estadística. Lo más importante que la significación estadística ofrece a las pruebas de usabilidad no es una etiqueta “significativo-o-no” para discriminar los resultados, sino más bien el proceso de cálculo de la probabilidad de un resultado dado, un estado de la población hipotética. En lugar de decidir si tiene o no significación, debes considerar los valores de p. Ellos representan un concepto puramente matemático que se pueden aplicar a cualquier situación. Cada vez que informes del resultado de una muestra, ya sea grande o pequeño, también debes incluir explícitamente el valor de p. Entonces, tú, los diseñadores del proyecto, los stakeholders, o quien esté viendo el resultado, puede decidir por sí mismo lo que debe hacer. Por ejemplo en ABtests.com , estoy francamente cansado de tener que calcular el valor de p para mí mismo. Realmente debería estar a la derecha a la etiqueta "¡Mayor conversión!".

También debería incluir el estado hipotético de la población, a menos que sea implícita. Esto no es necesario en el caso de una prueba A/B, porque se entiende que el estado de la población hipotética es que A y B tienen el mismo tipo de conversión.

Para ayudarte en el uso de la inferencia estadística en tus propias pruebas de usabilidad, a continuación pongo los valores de p para un tamaño de muestra de tres diferentes estados hipotéticos.

También he preparado tablas para los valores numéricos reales ( http://www.zuschlogin.com/content/blogimages/67/BinomialTable.htm ). Estos valores son los valores de p para obtener un número X de "fracasos" o más, donde un "fracaso" puede ser lo que tú definas, siempre y cuando es algo que tú quieras reducir. Por ejemplo, puede ser cuando un usuario se pierde totalmente en la tarea que le proponemos; o cuando comete un error del que se recupera en una parte específica de la interfaz de usuario; o quizás sólo cuando tarda demasiado tiempo en terminar la tarea. Todo lo que importa es que seamos constantes con todos los usuarios de la muestra. Los gráficos y tablas funcionan para cualquier caso en el que puede dividir los eventos del usuario en dos categorías mutuamente excluyentes y exhaustivas. Para usarlos, debemos:

• Definir qué es un fracaso.
• Seleccionar un Estado hipotético A
• Contar cuántos usuarios fallan.
• Buscar el cálculo para el tamaño de tu muestra y tu Estado hipotético A elegido, y leer el valor de p.
• Si el valor de p es lo suficientemente bajo para ti, considera que la tasa actual es mayor que el hipotético Estado A.

Si tienes "éxitos" (algo de lo que deseas que haya más en tu diseño), entonces conviértelos en fracasos. Convierte también el hipotético Estado A (que es una tasa de éxito) en una tasa de fracaso. Réstala del 100%. Lo siento, no puedo hacer todas las matemáticas por ti.

¿Qué pasa con el Estado hipotético B?

Bueno, ¿cuál es la probabilidad de que los estadísticos determinen un error de "tipo I" cuando no existe tampoco un "error de tipo II"?

Para recapitular, estamos calculando la probabilidad de ver el resultado que vimos en el ejemplo de Estado Hipotético A ("¿A quién le importa?"). Este valor de p es la probabilidad de un error de tipo I (cuando el rediseño del producto realmente no vale la pena). Digamos que rediseñas tu producto sólo si dos o más usuarios fallan. Luego en la tabla (o gráfico), vemos que hay una probabilidad de 0,028 de hacer un rediseño cuando definitivamente no debemos. Suena bien. Sigues la tradición científica de mantener la tasa de error tipo I de 0,05 o menos. Pero hay otras consideraciones aparte de mantener bajos el coste del diseño. También podemos preguntarnos, ¿cuál es el coste de no rediseñar una página? ¿Y de no rediseñar cuando definitivamente valdría la pena hacerlo? Esto es un error de tipo II, que es que cuando deberías haber valorado que el estado hipotético fuera erróneo, pero no lo hiciste.

Aquí es donde el Estado hipotético B entra en juego. Representa la tasa hipotética de la población donde definitivamente valdría la pena rediseñar. Digamos que seleccionaste el 50% o más para tu Estado hipotético B. Podemos utilizar las tablas para calcular la probabilidad de que debamos rediseñar del producto cuando definitivamente deberíamos hacerlo. Esa probabilidad se llama "potencia estadística". Réstalo de uno, y tienes tu tasa de error Tipo II, la probabilidad de no rediseñar cuando deberías.

Veamos: 2 de cada 3 fracasos, con una tasa hipotética de 50%, te da 0,500.

Vaya, vaya.

Rediseñando sólo si ocurren dos o más fracasos, estás manteniendo la tasa de error de tipo I en 0,028, pero la tasa de error de tipo II es 1-0,500 = 0,500. Vas a perder la mitad de los defectos de diseño, que son los que más valdría la pena rediseñar. La mitad o más de los problemas que afectan al 50% de los usuarios o más van a llegar a los que usen el producto final. ¡Habrá errores frecuentes en la interacción! ¡Tardarán en completar las tareas! ¡Perderemos ingresos! ¡Habrá motines de usuarios! ¡El colapso de la civilización!

Hambrientos de poder

En las pruebas de usabilidad, un error de tipo II es tan malo como un error de tipo I. Hay que minimizar la probabilidad total de error equilibrando los tipos I y II de probabilidades de error. Así es como fijamos nuestros estados hipotéticos, siendo el Estado A un “definitivamente no merece la pena el rediseño” y el Estado B un “definitivamente merece la pena el rediseño”, y el punto de equilibrio cualquiera en la zona en el medio. Las desviaciones de dicha zona en uno u otro sentido son igualmente malas.

Esto contrasta fuertemente con la investigación científica, donde los errores de Tipo I son peores que los errores de Tipo II. Un error de Tipo I significa que estás descubriendo algo que no es verdad, lo que socavaría la credibilidad de la ciencia y daría pie a un montón de gente a hacer cosas innecesarias (y posiblemente peligrosas) sobre la base de información errónea. Aumenta la probabilidad de que dos hechos contradictorios sean "probados" estadísticamente, lo que causaría una confusión infinita. Un error de tipo II en la ciencia significa que un descubrimiento tendrá que esperar para otro día. Permite a la ciencia ser conservadora, a adoptar una actitud escéptica ante las nuevas ideas hasta que sean empíricamente apoyadas con gran confianza.

Con esto en mente, volvamos a nuestra mesa para una muestra de tres. ¿Qué tipo de resultado sería el mejor balance de los errores de tipo I y II? Echemos un vistazo a un fallo de cada tres. Teniendo en cuenta un Estado hipotético de Población A, de 10%, la tasa de error Tipo I es 0,271. Teniendo en cuenta un Estado hipotético de Población B del 50%, el poder estadístico es 0,875, con una tasa de error tipo II de 0,125. Esos no son grandes probabilidades, pero son un mejor equilibrio que 0,028 y 0,500.

Teniendo en cuenta tus opciones en este ejemplo particular, me parece que deberías solucionar todos los problemas que detectes en cada usuario. Este parece ser el mejor equilibrio de poder estadístico y la tasa de error de tipo I en un tamaño de muestra de tres con el estado hipotético seleccionado. La estadística inferencial para las pruebas de usabilidad se reduce a esta selección de un resultado crítico tan mínimo (1 en este caso) para decidir si rediseñas el producto o no. Al informar sobre tus decisiones, debes informar del resultado crítico y su tasa de error de Tipo I y el poder para que su público entienda la probabilidad de que pudiéramos estar equivocados en nuestras decisiones. ¿Y la significación estadística? A la porra la significación estadística. Si calculas la tasa de error de Tipo I y el poder, entonces no tienes necesidad de declarar la validez o no de la significación estadística. Incluso el tamaño de la muestra es irrelevante.

Justicia estadística

Fíjate que hay un compromiso entre la tasa de error tipo I y el poder estadístico. Rediseñar cuando dos de cada tres usuarios fallan significa una baja tasa de error de tipo I (0,028), pero con poco poder (0,500). Rediseñar cuando uno de cada tres usuarios fallan no significa un buen poder estadístico (0,875), pero tendrías que comprometer las tasas de error tipo I para conseguirlo (0,271). Eso parece justo. No puedes tenerlo todo.

¿Y si no quieres renunciar? Tal vez no puedes elegir entre aceptar un error de tipo I de 0,271 o el poder estadístico de 0,500. Digamos que simplemente no te gustan esas opciones. Significa demasiados errores, rediseñar cosas que no necesitan ser rediseñadas con demasiada frecuencia; o demasiadas cosas que necesitan ser rediseñadas no son rediseñadas. Tal vez los errores de tipo I o II son demasiado costosos para aceptar ese tipo de tasas. Hay algo que puedes hacer al respecto: aumenta el tamaño de la muestra. Echa un vistazo a una muestra de cinco, por ejemplo (ver también la tabla de datos http://www.zuschlogin.com/content/blogimages/67/BinomialTable.htm )

Específicamente, mira la consecución de dos de cada cinco: la tasa de tipo I para el 10% es 0,081. No está mal. No muy lejos de la norma de la significancia estadística para los científicos. El poder estadístico para el 50% es 0,813. Tampoco está mal. Francamente la mayoría de los científicos sería muy feliz con ese tipo de poder. Como dicta tu intuición, las muestras de mayor tamaño reducen la tasa de error. Una muestra mayor significa una confianza mayor en los resultados, y una menor probabilidad de que pienses de forma errónea en un sentido u otro. Sin embargo, no es como que haya un cierto umbral de muestra mágico que asegure que los resultados son fiables. Es todo una cuestión de grado. Una muestra más grande es como un microscopio más grande, que permite detectar de forma más fiable las diferencias más pequeñas en las cosas. Una muestra más grande significa pruebas de usabilidad más caras, por lo que sólo tienen sentido si lo que necesitas es ahorrar en los costes de los errores de tipo I y II. Hay justicia estadística en el mundo. ¿Quieres generar menos errores? Entonces es mejor que estés dispuesto a gastar más. Recoges lo que siembras.

(Para más información sobre cómo seleccionar un tamaño de muestra para una prueba de usabilidad, véase Lewis, JR, (2006) “Sample sizes for usability tests: Mostly math, not magic.” Interactions, 13 (6), p29-33. Fíjate sin embargo que Lewis sólo se refiere a lograr el poder estadístico suficiente, y realmente no analiza las tasas de error de tipo I. Por otra parte, en muchos proyectos, como cuando diseñas para una gran población de usuarios, eso es apropiado porque entonces merece la pena arreglar un detalle de diseño incluso si una fracción muy pequeña de tus usuarios tiene un problema; los errores de tipo I ya no significan un problema real y lo único que necesitas especificar es el estado hipotético B)

Si alguna vez te has estado preguntado por qué los test de usabilidad trabajan muestras de 3 a 5 usuarios, ahora puedes verlo desde un punto de vista estadístico, lo que no está tan mal. De hecho tienes muchas probabilidades de detectar serios detalles de diseño que afectarían a la mayoría de tus usuarios mientras no pierdes el tiempo en detalles que afectan a unos pocos usuarios. Lejos de ser una amenaza a las prácticas de usabilidad, la estadística inferencial las valida. Desde una perspectiva estrictamente racional y matemática de minimización de costes debido a (1) hacer rediseños innecesarios, (2) dejar que los defectos de diseño lleguen a la fase de producción y (3) realizar test de usabilidad, las muestras pequeñas son a menudo la solución óptima.

La limitación principal de una muestra pequeña es que genera una gran incertidumbre acerca de cómo de grande es un problema dado una vez que has decidido que tienes uno. Por ejemplo, podemos saber que es muy probable que afecte al menos al 10% de los usuarios, pero es bastante plausible que el valor real sea entre 10% y 80%. Para la mayoría de las situaciones usabilidad, tal imprecisión es aceptable. Si en cualquier caso vas a arreglar todos los problemas detectados, ¿a quién le importa cuáles son los peores?

Si todavía desconfías de las muestras pequeñas, olvida las matemáticas y míralo de esta manera: si un problema se presenta en una gran parte de tu población de usuarios, es muy probable que lo veas en una muestra pequeña; si el problema se presenta en una porción muy pequeña de tus usuarios, es muy poco probable que lo vea en una muestra pequeña. La muestra pequeña en pruebas de usabilidad, en otras palabras, son una red de malla grande, ideal para la captura de grandes problemas -que son los que al cliente le preocupan en primer lugar.

También hay justicia estadística en los propios errores, en el sentido de que si cometes un error, probablemente no será un error grave. En este ejemplo con poder estadístico de 0,813, tienes una posibilidad de 0,187 de que un defecto de diseño que afecte al 50% o más de tus usuarios. ¿Podría afectar a muchos más que el 50%? Claro que es posible, pero no probable. Mira la tabla para ver la probabilidad de decidir no corregir un defecto que afecte al 80% de los usuarios: 0,007. Lo más probable es que si cometes un error de tipo II, será para un problema cerca de la marca del 50%. Lo mismo sucede con los errores de tipo I. Si al final terminas arreglando un defecto que no merece la pena arreglar, es más probable que ayude al 9% de los usuarios que al 1%, lo que puede no ser rentable, pero no es una total pérdida de recursos de diseño, sobre todo si yo personalmente estoy dentro de ese 9%. El castigo es proporcional al crimen.

Resumen de criterios

Problema: usar estadística inferencial para tomar deciones racionales de rediseño basadas en tests de usabilidad con muestras pequeñas.

Posible solución:

• Con tus stakeholders, elige los estados hipotéticos A y B.
  • estado hipotético A de la población: un acuerdo sobre la tasa de fracaso de la población para la cual no merece la pena el rediseño.
  • estado hipotético B de la población: un acuerdo sobre la tasa de fracaso de la población para la cual definitivamente merece la pena el rediseño.
• Usando las tablas de este post, busca los valores p de los estados A y B para el tamaño de tu muestra.
• Selecciona un resultado crítico que equilibre estos valores de p, dándote una baja probabilidad para el estado A y una alta probabilidad para el estado B.
  • El valor de p para el estado hipotético A es tu probabilidad de error de Tipo I – el caso de que rediseñar algo definitivamente no merece la pena.
  • El valor de p para el estado hipotético B es tu poder estadístico – el caso de que rediseñar algo definitivamente merece la pena.
• Si no hay un resultado posible con combinaciones aceptables de p, entonces aumenta el tamaño de la muestra.
• Si observas a los usuarios fallando en o por encima de tu resultado crítico elegido, deberías rediseñar el producto.
• Utiliza el análisis cuantitativo para decidir cómo rediseñar el producto.

Eso es todo. Haz tus elecciones y apuesta por ellas.

El rincón del geek de las estadísticas

Todas las probabilidades en este puesto y en las tablas son cálculos binomiales de una cola. Uso cálculos de una cola porque en un test de usabilidad (a diferencia de la investigación científica de carácter teórico), en general no hay interés en los casos en que la tasa de fallo de la población es menor que el valor de la hipótesis nula, todo lo que importa es si tienes que rediseñar el producto o no. Además, con tamaños de muestra como estos, necesitas todo el poder estadístico que puedas obtener.

Los test de estadística binomiales no hacen suposiciones sobre la normalidad de la distribución de la muestra u otras cosas que hacen los test de parámetros, lo que los hace ideales para los tamaños de muestra pequeños de los test de usabilidad con pequeñas muestras. Su principal desventaja es que está limitada a eventos binarios (por ejemplo, éxito o fracaso). Si estás tratando con promedios o más de 2 categorías de rendimiento, otros test estadísticos son más apropiados, pero más complicados de usar correctamente.

• Si vas a hacer etnografía en tu empresa, date cuenta de que no es un proyecto corto, si lo quieres hacer bien. Hay que conocer la cultura de la empresa en la que te encuentras . Esto implica mucho tiempo, y en consecuencia mucho dinero antes de que se obtengan resultados. (1)
• Presentaron la herramienta de testeo web remoto Webnographer que se caracteriza por su adaptación a metodologías ágiles (2) ya que se permite usar directamente los datos recogidos en el proceso de diseño.(3)
• Otro tema que tocaron fue si había que diseñar para personas que se arriesgan y cambian su modo de hacer las cosas; o por el contrario había que diseñar para personas que no quieren cambiar de hábitos. Puedes seguir el hilo de este tema en Johny Holland(4)

Mis comentarios

En el fondo no contaron nada que no tuviéramos en mente, pero siempre es interesante encontrarse a gente que tiene los mismos problemas que tú y ver cómo lo hacen para convencer a sus clientes.

1. Esto se dijo también en la charla de la UPA. Pásate por acá para ver más sobre lo que se dijo
2. Próximamente habrá un post sobre metodologías ágiles y UX.
3. Según los padres de la criatura, yo no he probado esta herramienta y lo que mostraron en la presentación no difería mucho de otras herramientas de testeo remoto del mercado.
4. Sobre innovación también recomiendo leer las teorías de Everet Rogers

1. Apple ha investigado para qué usamos los netbook, un mercado en el que aún no había entrado:
   
2. Ha encontrado qué problemas encontramos al hacerlo, para poder darle soluciones concretas:
   

Esto, que parece una tontería, es lo que les hace diferentes de otras empresas: investigación de usuarios, Diseño Centrado en el Usuario con mayúsculas.
Es su modelo de negocio. No parece que les vaya mal.

Según la próxima versión de la ISO 9241-210, la Experiencia de Usuario es all aspects of the user’s experience when interacting with the product, service, environment or facility. Entonces tenemos que la Experiencia de Usuario es una característica subjetiva del producto, en la que se incluye, entre otras, la usabilidad, pero también el diseño emocional, la ergonomía, la simplicidad, su belleza, el cool-factor, lo útil que resulte para el usuario, el esfuerzo de aprender funciones avanzadas… cosas que ni los cuestionarios SUS (System Usability Scale) o SUMI pueden alcanzar a medir.

¿Entonces cómo lo hacemos? ¿Cómo medimos la experiencia de usuario? ¿Con Entrevistas o Focus Groups quizás? ¿No estamos volviendo a lo mismo, a utilizar métricas y metodologías de usabilidad? ¿Por qué no crear una métrica y una metodología propia?

Veamos qué está moviéndose en una disciplina prima-hermana de la Experiencia de Usuario: la Experiencia de Cliente. Habitualmente se ha trabajado con el C-Sat o el Net Promoter Score (NPS), valorando sobre todo la fidelidad del cliente y la superación de sus expectativas como valores clave a analizar. Pero he aquí que aparace un nuevo método, el Customer Effort Score (CES) o Índice de Esfuerzo de Cliente, que intenta determinar el esfuerzo requerido por el cliente en cualquier interacción del cliente con la empresa (¿a qué me suena eso?) mediante una única pregunta: ¿recomendaría este producto a un amigo? (Vaya, esto también me suena). Hasta la Customer Experience está utilizando las mismas o similares unidades de medida que la usabilidad y simplificando al máximo.

Entonces, ¿qué pasa con la UX? ¿Descartamos los otros factores? ¿Cómo la medimos? ¿Para cuando una ISO para la UX?

Sigo dándole vueltas. A lo mejor no sería mala idea empezar a plantearse crear una métrica nueva.

10 errores de percepción sobre el diseño de experiencia de usuario

Whitney Hess es una diseñadora de experiencia de usuario independiente, escritora y consultora de Nueva York. Escribe en el blog “Pleasuse and Pain“.

Cuando le digo a la gente que soy una diseñadora de experiencia de usuario, normalmente recibo una mirada en blanco. Rápidamente intento explicar que hago que las cosas sean sencillas y agradables de usar. Es una descripción breve que repito a menudo, pero a la vez es una simplificación demasiado grande que no me hace ningún favor.

El término “experiencia de usuario” o “UX” da mucho juego, pero muchos negocios confunden lo que es realmente y cómo de importante es para su éxito.

He preguntado a algunos de los más conocidos y respetados consultores de experiencia de usuario cuáles son los peores errores de percepción sobre lo que hacemos y el resultado es una lista de 10 mitos. Léela, apréndela, vívela.

La experiencia de usuario no es…

1. … Diseño de interfaz de usuario.

   No es difícil confundir “experiencia de usuario” con “interfaz de usuario” – después de todo es una gran parte de cómo los usuario interaccionan mientras experimentan(*) productos digitales y servicios. Pero la interfaz de usuario es sólo una pieza del puzle.

   “La interfaz es un componente de la experiencia de usuario, pero hay mucho más”, según Peter Merholz, fundador y presidente de Adaptive Path. Christian Crumlish, responsable de la Biblioteca de Patrones de Diseño de Yahoo!, explica que “no es sobre la cosmética, sobre poner un pixel aquí o allá, o dónde colocar un botón. Es un conjunto y es cuestión de todos, no sólo de la gente de arte”.

   Dan Saffer, fundador y director de Kicker Studio, reconoce que es común que la gente confunda UX con el diseño sólo por temas de decoración o estilo “He tenido clientes que me han dicho que no me preocupara por la estrategia porque ¿para qué quiere un diseñador preocuparse de eso? UX es más que profundo que sólo la piel.

2. … un paso en el proceso

   Porque la UX es el proceso. Para crear una gran experiencia para tus usuario, no diseñes sólo algo que nos gustaría usarlo, tenemos que escuchar a los usuarios durante todo el proceso. No tiene por qué ser un proceso rígido, pero necesita existir.

   “El diseño de UX no es una lista de características que deben ser cumplidas” según Liz Danzico, una consultora independiente de experiencia de usuario y presidenta del Máster de Diseño de Interacción de la Escuela de Artes Visuales. “No haces tu proyecto y luego pones en marcha la UX. Necesita estar integrada en todo lo que se hace.”

   Dan Brown, co-fundador y director de EightShapes apunta que “muchos clientes esperan que el diseño de experiencia sea una actividad pequeña, que resuelva sus problemas con una especificación funcional sencilla o un estudio simple. Debe ser un esfuerzo continuo, un proceso de aprender continuamente de los usuarios, reaccionando a sus comportamientos, y mejorando el producto o servicio.”

3. … relativa a la tecnología

   La UX ni siquiera está relacionada con la tecnología, según Mario Bourque, gerente de arquitectura de información y gestión de contenidos de Trapeze Group. “Está relacionado con cómo vivimos, con todo lo que hacemos. Nos rodea”

   Igual que un pintor usa la pintura para comunicar conceptos y emociones, lo diseñadores de UX utilizan la tecnología para ayudar a la gente a conseguir sus propósitos. Pero el objetivo principal es ayudar a la gente, no crear tecnología grandiosa.

   “El diseño de UX no está limitada a los confines de un ordenador. Ni siquiera se necesita una pantalla”, argumenta Bill DeRouchey, director de diseño de interacción de Ziba Design. “La UX es cualquier interacción con cualquier producto, cualquier artefacto, cualquier sistema”.

   Realmente, el diseñador de UX puede ayudar a mejora la experiencia de un usuario con cualquier cosa: un grifo, un picaporte, un carrito de la compra… Normalmente no nos referimos a la gente como usuarios, pero lo son”.

4. … sólo relativo a la usabilidad

   “La gente suele pensar que el diseño de UX es una forma de convertir productos malos en buenos dedicando recursos al diseño del producto.”, dice Chris Fahey, fundador y director de Behaviour. Hacer que las cosas sean sencillas e intuitivas está lejos de ser nuestro único objetivo. Para conseguir que la gente cambie su comportamiento, necesitamos crear cosas que quieran usar también.

   David Malouf, profesor de diseño de interacción en el Colegio Savannah de Arte y Diseño, explica que “mientras que la usabilidad es importante, ésta se centra en la eficacia y eficiencia, lo cual eclipsa otros factores importantes de la UX, como la facilidad de aprendizaje, o las respuestas viscerales o emocionales a los productos o servicios que usamos.” No todo tiene que ser simple hasta decir basta, si puede ser fácilmente aprendido, y es crítico que sea atractivo, ya que si no, la gente nunca se atreverá a utilizarlo una única vez.

   “La usabilidad no es una sinécdoque para la UX”, afirma Will Evans, arquitecto jefe de experiencia de usuario en Semantic Foundry. Apunta que el panal de abejas de Peter Morville de UX, además de la usabilidad, incluye la utilidad, la deseabilidad, la accesibilidad, la credibilidad, la encontrabilidad y la validez como las facetas esenciales de la experiencia de usuario.

5. … sólo relativo al usuario

   A Russ Unger, estratega de diseño de experiencias, le gusta decir que el mayor equívoco en el diseño de la UX es la “U”. “Hay una serie de objetivos de negocio que necesitamos cumplir y para los cuales nosotros diseñamos también. No podemos hacer siempre lo que es mejor para el usuario. Tenemos que intentar asegurarnos que estamos presentando una experiencia global que puede conciliar en lo posible tanto objetivos de las empresas como necesidades de los usuarios.”

   COmo diseñadores de experiencia de usuario, necesitamos encontrar un punto de equilibrio entre las necesidades de los usuarios y los objetivos de negocio, y asegurar además que el diseño cumple los estándares de la compañía.

6. … caro

   Todo proyecto requiere un acercamiento al cliente basado en los recursos disponibles en la empresa, las capacidades, los presupuestos, las fechas de cumplimiento, y una gran cantidad de límites existentes en el mundo real. Pero eso no significa siempre que necesite ser muy caro o llevar una eternidad.

   Steve Baty, director y estratega de US en Meld Consulting, rebate la falacia de que el diseño de UX añade demasiado tiempo al proyecto. “Algunas veces un proceso formal y completo, basado diseño centrado en el usuario, puede no ser los mejor en el primer momento. Es muy importante- y siempre posible sin importar dónde trabajas ni en qué momento del proyecto llegas- hacer pequeñas mejoras tanto en el proyecto como en el producto introduciendo algunas técnicas de diseño de UX.

   “La gente se aferra a cosas como las personas, investigación de usuario, dibujar comics, etc.”, dice Saffer. “En realidad los mejores diseñadores tienen un puñado de opciones, y sólo eligen los métodos adecuados para cada proyecto en concreto”.

7. … fácil

   Sólo por el hecho de que nosotros sepamos cómo conducir algunas actividades chulas y útiles; y las empresas conozcan su negocio muy bien; no significa que el proceso sea un camino de rosas. Y reducir gastos para algunos pasos es un camino para el desastre.

   Saffer mantiene que un error de percepción es que, “habitualmente entre diseñadores y clientes, creen que hay un método secreto que resolverá sus problemas de diseño.”

   Una trampa en las que muchas compañías caen es pensar que ellos son sus propios usuarios finales. Erin Malone, director de Tangible UX, encuentra que tanto los gestores de producto como los programadores creen que la experiencia de usuario se creará a medida que crean el producto. “Los diseñadores de UX están atrapados en el medio intentando hablar el lenguaje de negocios y el de desarrollo para justificar por qué necesitamos hacer nuestro trabajo y por qué es importante para el éxito.

   Si hacemos suposiciones sobre la gente que creemos que va usar nuestro producto o servicios -quiénes son, cómo se comportan, qué les motiva- probablemente nos equivoquemos siempre. Pero si nos tomamos un tiempo en conocerles, y contratamos a las persona adecuada para facilitar el proceso, podemos asegurarnos de que lo haremos bien.

8. … tarea de una persona o un departamento

   Los diseñadores de UX son enlace, no son expertos en la materia, médicos o cualquier tipo de seres mágicos. No tenemos un conjunto de buenas prácticas que pueden ser implementadas de forma robótica, ni tenemos todas las respuestas. Nuestra mejor arma es que sabemos escuchar. Aunque podemos ayudar a evangelizar sobre los mejores procesos dentro de una organización, es responsabilidad de todos los miembros de la organización que esos procesos sean un éxito.

   “La UX no es sólo responsabilidad de un departamento o persona” según Livia Labate, directora de arquitectura de información y experiencia de usuario de Comcast Interactive Media. “Esa visión compartimentada de la UX es una prueba de que no es parte de la cultura de la organización y la recomendación es desarrollar una visión y objetivos colectivos”.

   Malone subraya el hecho de que hay diferentes consultorías debajo del paraguas de UX. “Nosotros, como una industria, no hemos hecho un bien trabajo separando especialidades y roles con un lenguaje suficientemente único para que los clientes y empresas contraten lo que necesitan en diferentes partes del ciclo de vida del proyecto”.

9. … una disciplina única

   Lo cierto es que estamos al principio de esto. Louis Rosenfeld, editor de Rosenfeld Media, autor de libros sobre diseño de UX, y co-autor del libro “Arquitectura de la Información para la WWW” (2002, considerado como la semilla de la UX); argumenta que la UX puede incluso no ser siquiera una disciplina. “Aún no hay una comunidad. Como mucho, es una conciencia común, un hilo que agrupa personas de diferentes disciplinas que se preocupan del un buen diseño, y que se dan cuenta de que está aumentando la complejidad de los diseños actuales y se necesita sintetizar diferentes tipos de expertos.”

   Existe una proliferación de puestos nebulosos: arquitecto de información, arquitecto de experiencia de usuario, diseñador de interacción, ingeniero de usabilidad, analista de diseño, y muchos más. Y no significan lo mismo para cada persona o compañía.

   Distintas personas se especializan en diferentes partes del proceso. Algunos consultores de UX se centran en una técnica específica, como Indi Young en modelos mentales; o en aplicaciones concretas, como Luke Wroblewski en formularios web; o en una actividad determinada, como Steve Krug y los tests de usuarios. Del mismo modo que no irías a un cardiólogo a curarte un pie roto, no esperes que cualquier profesional del mundo de la UX te ayude en todo lo que necesitas.

10. … una elección

    Para aquellos que piensan que no necesitan un diseñador de experiencia de usuario, tened esto en mente: “Nadie quiere cree que lo que estás ofreciendo de baja calidad o deficiente”, según Kaleem Khan, consultora independiente de UX, “porque nadie fija un mal diseño como objetivo. Siempre hay un riesgo. Los malos diseños y la mala experiencia suceden.”

    Jared Spool, fundador y CEO de User Interface Engineering (UIE), la mayor empresa de investigación de usabilidad del mundo, ha hecho mucha investigación en las cualidades de los equipos de trabajo con éxito y satisfactorios. Por decirlo de forma sencilla, el error más común que ha encontrado es que la compañía piensa que “el diseño de una buena experiencia es un añadido, no un requisito inicial.”

    Josh Porter, que anteriormente trabajó en UIE y ahora es director de Bokardo Design, reafirma lo que dice Spool cuando dice “el mayor error de concepto es que las compañías tiene la posibilidad de invertir en su experiencia de usuario. Para sobrevivir, no la tienen”.

    Hay muchos consultores increibles que pueden ayudarte en tu ciudad. Busca en el Instituto de Arquitectura de Información (IAI), la Asociación de Diseño de Interacción (IxDA), o la Asociación de Profesionales de Usabilidad (UPA), o simplemente encuentra a alguien a través de LinkedIn.

Mirando adelante

El 2009 va a ser un año de recesión, pero puede ser también una llamada al pragmatismo. Es hora de adoptar prácticas más efectivas, progresivas, inteligentes y fluidas. Hemos llegado un nivel de madurez tecnológica en donde ser funcional no es suficiente.

Es cómo captamos gente y el respeto y valor que les damos lo que separará el grano de la paja. ¿En qué lado vas a estar tú?

Whitney Hess es una consultora de experiencia de usuario independiente que trabaja con Happy Cog, Boxee y otras compañías que ponen a las personas primero. Escribe sobre cómo hacer las cosas sencillas y agradables de usar en su blog Pleasure and Pain.

Presentación Desconferencia 2008