El uso de técnicas UX en áreas de tecnología: el testeo con usuarios

Escribe Juan Luis Martínez, Director de Capire.info.

Trabajando en temas de experiencia o similares y cada vez que definimos y diseñamos servicios, en especial digitales, en algún punto nos encontramos con las áreas de tecnología internas o proveedoras.

Muchas veces ese encuentro no es del todo fácil. La primera impresión que surge en ellos es que el trabajo de crear servicios digitales es algo que no necesita más que tecnología “y algo de imagen”. Que ya está todo resuelto y que nos estamos metiendo en temas que ya los cubren ellos: las áreas de tecnología o similares.

Esta primera visión queda rápidamente diluida una vez que las áreas más técnicas entienden que lo que hacemos es todo aquello que más problemas les trae: representar el negocio, poner de acuerdo diversas áreas, comprender a los clientes y entender la forma de relacionarse con ellos. Finalmente estás áreas técnicas entienden que el problema es convertir el negocio, y las necesidades de cliente, en interfaces digitales donde la tecnología es el motor pero no el lugar donde viajamos.

De ese nada fácil primer contacto, finalmente nacen nuestros mejores aliados: si, las mismas áreas de tecnología e informática. A partir de lo que hacemos como especialistas en experiencia o UX, su trabajo se les hace más fácil y pueden por fin concentrarse en sus tareas específicas, léase programar o similares. Todo está más claro en requerimientos, vienen ya revisados y negociados. Las palabras, las interacciones, los posibles errores ya están analizados y diseñados. Así, uno de los factores de éxito de estos procesos de diseño de UX, es que estás áreas llamadas “duras” hayan participado, en equipo, desde un comienzo aportando en su área de conocimiento.

Todo lo que aquí se menciona está ejemplificado en áreas de tecnología, sin embargo, las situaciones se repiten de igual manera con otras áreas que asumen la responsabilidad de crear o administrar un servicio o producto digital sin considerar que se requieren competencias específicas.

Cómo una buena técnica puede llevar a errores

Estas experiencias llevan a algunas empresas a incorporar algunas de las técnicas que han visto, y que han conocido a partir de trabajos de UX, para avanzar en modificar internamente todos aquellos fallos que comienzan a verse como evidentes.

La primera y más básica es testear con usuarios. Así es como muchas organizaciones implementan un sistema en el cual definen requerimientos de sistemas o servicios digitales, los implementan y antes de darlos por buenos los testean con usuarios/clientes para ver “que opinan”.

Sin embargo, esto no siempre lleva a buenos resultados y termina frustrando el uso de la técnica. Se encuentran reportes similares en distintos sistemas o procesos testeados y se hace muy difícil entender porqué los clientes/usuarios reaccionan como lo están haciendo.

Además, como la inversión ha sido alta en la implementación o desarrollo de lo que se testeó, se comienzan a elaborar teorías no del todo autocríticas sobre que está sucediendo. El tener que rehacer se hace caro y se comienzan a buscar culpables.

Peor aún es cuando lo testeado es supuestamente “validado” con clientes/usuarios y sin embargo finalmente no hay éxito real cuando se libera.

 

¿Qué provoca este lío?

Las razones para que testear con usuarios no sea un real aporte son de metodología y están consistentemente estudiadas.

  • Testear esperando que sean los clientes/usuarios quienes digan si algo esta bien es pedirles la opinión. Y ese es un error básico. Lo que se debe evaluar es la capacidad que tienen para realizar lo que se espera de ellos, en condiciones normales, despejando variables excepcionales. Desconocer la técnica lleva a barbaridades como los “focus de testeo con usuarios”.
  • Centrarse en el testeo dejando de lado el proceso de creación, es perder de vista los objetivos y centrarse sólo en requerimientos. El contexto, las diversas áreas involucradas, los efectos en otros procesos, hacen necesario un método para tener buenos resultados. Los equipos deben ser multidisciplinarios y todas las visiones deben llegar a acuerdos.
  • Desconocer los perfiles necesarios para realizar buenos testeos lleva a improvisar testeadores o a encargarlos sin poder discriminar la calidad del trabajo. La técnica requiere entrenamiento para no caer en falsos positivos y tener respuestas sólidas a los clásicos cuestionamientos a la técnica que hace quienes se sienten “heridos” por los malos resultados.

El testeo en si es una excelente técnica, pero es una parte del proceso de creación de un servicio/producto o de digitalización de una operación. Entenderlo como la tarea que soluciona todo le entrega una función que no tiene y desvirtúa su valor.

 

¿Qué hacer para que funcione mejor?

La respuesta global es simple: aprender, practicar y aplicar una metodología de diseño de UX que incluya factores de negocio, de contexto, técnicos e incluso políticos. Incluyendo un elemento clave: el usuario. Por ningún motivo el usuario debe ser el “opinante” final, es parte del proceso y de la metodología.

 

Algunas claves que es necesario considerar:

  • Definir bien el contexto: qué, por qué y para quién. Identificar expectativas, apoyos y resultados esperados.
  • Crear equipos integrados: toda operación o servicios tiene múltiples visiones y efectos. Es necesario identificarlas.
  • Diseñar con método: se debe evitar la tentación de copiar, seguir “ideas geniales” o dejarse llevar por modas. Esto permite conocer e integrar la visión de quienes finalmente usarán y darán éxito a lo que hacemos: los usuarios o clientes.
  • Crear prototipos de bajo costo y testear en ellos: sólo después de tenerlos, y de borrar los errores evidentes, se debe convertir en algo visible o tangible el producto o servicio. Al testear se debe cuidar la selección de las personas que testearán, el contexto de prueba y el método para recolectar, procesar y aprovechar los resultados. Interpretar los resultados es tan importante como recabarlos.
  • Con eso es posible seguir el proceso entregando información segura y acompañar los imprevistos del desarrollo o implementación con antecedentes que permitan rápidas y buenas respuestas.

 

Cierre: testear es parte camino, no la solución salvadora

Testear es una muy buena técnica dentro del diseño de productos y servicios, sobre todo digitales. Sin embargo, no es una solución en si. Es parte de un proceso que requiere ser entrenado para aprovechar su potencial.

Tan importante como testear es saber comprender el problema, verlo desde diferentes puntos, integrar al usuarios final y sobre todo entender que lo que estamos solucionado es siempre un problema de negocio y no un problema estético ni técnico.

*********************

Artículo publicado en Capire.info bajo licencia Creative Commons. Toda reproducción total o parcial debe incluir la fuente: www.capire.info

Compartir:Tweet about this on TwitterShare on LinkedInShare on Facebook

One comment

  • Muy acertado, Juan Luis. Pasa frecuentemente que se espera demasiado del testeo con usuarios, tal como pienso que se espera mucho de las entrevistas etnográficas e incluso, en lenguaje startup, de la idea de “get out of the building”. Finalmente, aunque el testeo con usuarios resulte exitoso o bien se identifican brechas y errores que se corrigen, eso no significa que una vez el producto / la funcionalidad en producción, los usuarios llegarán solos y lo adoptarán. ¿Quizás falta más foco en el proceso y en las metas a mediano y largo plazo?

Agregar un comentario

Su dirección de correo no se hará público. Los campos requeridos están marcados *