Entrada conseguida para la Tarugoconf!!
Este año he tenido suerte y me han pasado en el último momento la posibilidad de comprar una entrada para la Tarugconf para ver sus awesomicas charlas preparadas con cariño durante todo el año.
Con solo una edición, la Tarugoconf es uno de los eventos que más ganas tenía de asistir, dado el nivel de las charlas y ponentes. Osea q estoy súper féliz de ir este año y ver además en persona a amigos de Zaragoza entre sus patrocinadores como Dani de Torres Burriell Estudio o Guillermo (@Superwillyfoc) de Cuentica.
Os dejo un video resumen de la edición anterior para que veais que pasada:
Osea que el 22 de septiembre allí me tendreís en el Campus Google de Madrid, para absorver cual Bob Esponja todo lo que nos cuenten l@s grandes que se suban al escenario y comer toda la empanada, pulpo y tortilla de patata que pueda, ñamñam (Que aunque acabo de volver de Galicia nunca se come lo suficiente je je!!)
Principios Lean UX para guiar el proceso
Una vez que hemos hablado qué cultura y organización debe existir en la empresa y los equipos, vamos a ver cómo deben trabajar.
Trabaja en bloques pequeños para reducir el riesgo
Otro principio fundamental heredado de Lean Manufacturing es la práctica de dividir el trabajo en pequeñas unidades, en su caso con el objetivo de reducir el inventario y obtener la máxima calidad.
Trasladado a Lean UX significa que sólo la cantidad de trabajo necesario se realizará para poder avanzar hacia delante, validando la hipótesis y continuando el desarrollo en base a lo aprendido. Con ello contribuimos a otro de los principios, el de reducir el desperdicio.
Descubrimiento continuo
Para realizar este proceso debemos involucrar al usuario o cliente en el proceso durante la fase de diseño y desarrollo de las ideas.
Muchas veces (en el caso de que se haga) este contacto, en vez de hacerse de forma regular se realiza al final, con el trabajo ya desarrollado. Por ello se deben definir encuentros seguidos mediante métodos cuantitativos o cualitativos que permitan obtener el feedback para la validación.
El objetivo es claro: entender que hacen los usuarios con tus productos y por qué lo están haciendo.
Por ello la investigación debe hacerse de forma regular y con todo el equipo implicado.
Este segundo punto (con todo el equipo implicado) es muy importante ya que normalmente sólo los UX Research hacen esta parte teniendo posteriormente que explicar los resultados al resto del equipo.
Al introducir a todo el equipo en la investigación consigues 3 cosas:
- Que desarrollen una mayor empatía por el usuario y sus problemas
- Entendimiento compartido de lo que ocurre y por que luego se van a tomar ciertas decisiones.
- Reducción de la necesidad de generar documentación que explique los descubrimientos de la investigación
GOOB (Getting out of the building)
Con esta expresión que significa literalmente “salir fuera del edificio”, Steve Blank, profesor de Stanford, quiere conseguir que los equipos salgan fuera de las salas de reuniones con sus interminables divagaciones y suposiciones, y que den a los potenciales usuarios la oportunidad de proveer feedback real tan pronto como sea posible.
Gracias a esta dosis de realidad verás que ideas no funcionan antes de malgastar más recursos en ellas.
Exponer el trabajo
Con este principio, se quiere que las ideas salgan de la cabeza o de las pantallas de las personas y se pongan a la vista de todo el equipo. Esto permite ver el estado del trabajo, creando un flujo de información compartida, de nuevas ideas y sugerencias que surgen en base a lo visto…
Investigación etnográfica
La investigación etnográfica (del griego, «ethnos» que significa: pueblo, tribu y «grapho: escribo) es una técnica que tiene sus orígenes en la antropología y la sociología, siendo el estudio de personas y culturas, observando las prácticas culturales de los grupos sociales pudiendo participar en ellos.
Es uno de los métodos más relevantes que se utilizan en investigación cualitativa.
Nos permite interpretar el día a día del usuario o consumidor desde lo que hace y no sólo por lo que dice que hace, dentro de su realidad social, cultural, demográfica y geográfica. En en algunas investigaciones el rol varía pudiendo el investigador ser observador y en otras participante.
La finalidad es conocer el comportamiento de las personas, mediante la observación directa de las acciones e interacciones que forman parte de esa realidad y preguntando la explicación de su por qué.
Para el sociólogo británico Anthony Giddens, la etnografía es «el estudio directo de personas y grupos durante un cierto periodo, utilizando la observación participante o las entrevistas para conocer su comportamiento social, registrando una imagen realista y fiel del grupo estudiado; el trabajo de campo resulta ser una herramienta imprescindible«.
Estas 2 técnicas, observación participante y entrevistas (con cuestionarios), junto con las notas de campo y los registros permanentes, nos permiten obtener gran cantidad de información sobre los usuarios y la realidad que rodea al proyecto en el que estamos trabajando.
Antes de empezar el proyecto es recomendable mandar una checklist de preguntas con los requerimientos iniciales. Con ello podemos obtener la máxima información de contexto, y obtener así una primera impresión del proyecto y las expectativas del cliente.
Pueden realizarse en persona, pero a veces por motivos de tiempo, o de no estar ubicados en la misma ciudad, es mejor mandarlas y que el cliente las responda cuando pueda.
Notas de campo
Las notas de campo son el recurso más básico para registrar los datos fruto de la observación. Aunque lo idea es apuntar todo, como eso es imposible se suele anotar lo que es relevante oara la investigación del problema.
Lo ideal es tomar las notas lo antes posible tras la observación participante ya que si se hace después suele dismuir la calidad.
Registros permanentes
Con registros permanentes nos referimos a la captura de la información en un soporte que permanezca en el tiempo más que la memoria del observador. Por ello siempre se aconseja grabar las entrevistas complementando la observación con las notas de campo.
Se suelen tomar en varios formatos, algunos más ricos que otros, en concreto fotografías, vídeos y grabaciones de audio.
Entrevista
En relación a la experiencia de usuario, las entrevistas nos permiten intentar conocer:
- Qué quiere el usuario
- Qué necesita
- Su perspectiva
- Los matices que posee el usuario sobre la realidad que investigamos
Y digo «intentar» porque aunque realicemos las preguntas correctas no quiere decir que el usuario sepa las respuestas. A esto debemos añadirle la capa subjetiva de interpretación del investigador.
Ejemplo real de observación participante
La observacion participante es una de las técnicas utilizadas en la etnografía para recoger información de las personas a través de la observación para obtener conocimiento acerca de lo que quieren los usuarios, cómo lo necesitan, como lo solicitan, que quejas o demandas tienen…
El rol del investigador puede variar dependiendo de las necesidades del proyecto. Algunas veces es observador y en otras participante. En este caso, en un trabajo realizado hace unos años, iba a ser participante ya que quería observar cómo podía mejorar el día a día de las personas que trabajaban en Call Center.
Imagen de Call Center en Centraldereservas.com
Sus principales tareas eran:
- atender por teléfono a los clientes que querían reservar un hotel,
- cancelar uno ya reservado y,
- dar soporte de emergencia cuando llamaban con algún problema una vez iniciado ya el viaje (siiii, llamadas súper alegres como podéis imaginar).
Su interacción con el cliente era hablada por teléfono, mientras a la vez delante de un ordenador usaban la web de la empresa u otros programas internos para realizar las tareas necesarias.
Quería observar como realizaban este trabajo por dos motivos:
- Ver si podía mejorar su experiencia diaria y aumentar su satisfacción laboral, mejorando si era posible la página web o el software desarrollado internamente.
- Observar como interactuaban con las personas que llamaban, es decir, qué necesidades tenían los clientes, para ver si podía obtener alguna idea para introducir mejoras en la web cuando el cliente la usaba por si mismo.
Call Center es uno de los departamentos que más importancia deberían tener en las empresas
Para mi, desde siempre, como especialista en experiencia de usuario, las personas que forman Call Center son de vital importancia en las empresas, ya que:
- Están en contacto directo y diario con los clientes por lo que son los que más oyen y conocen sobre lo que necesitan
- Son la voz de la empresa hacia el mundo exterior
- Muchas veces soportan las peores situaciones, es decir, los clientes suelen llamar cuando hay un problema y está enfadados (si, que sea nochevieja y que tu hotel haya pedido la reserva porque la mayorista no la ha procesado bien no es de buen gusto…)
Lo peor, es que muchas empresas suelen externalizar este servicio alejando esta impresionante fuente de información y encima no reconociendo el mérito que su trabajo merece, ya que suele estar bastante mal pagado y realizarse 24 horas al día.
Volviendo al tema que nos ocupa, aunque la empresa ya tenía un canal de sugerencias y mejoras para que los trabajadores expusieran su opinión (e incluso otorgando premios a las mejores) las personas de Call Center (y en general en toda la empresa) no lo empleaban.
Ya existía una canal de sugerencias, pero dado que parecía que no era escuchado se había dejado de usar.
Y es que muchas de estás ideas y mejoras acababan siendo ignoradas, ya fuera porque había otras tareas prioritarias o por no recaer en la persona correcta.
Método How Might We…?
Se basa en la premisa de que cada problema es una oportunidad para el diseño.
Ideada por Procter & Gamble en 1970, se popularizó como técnica de innovación, cuando IDEO la empezó a utilizar, siendo usada hoy por empresas como Google, Facebook…
Consiste en resolver cada desafío haciendo la pregunta «HMW», que proviene de la frase en inglés «How Might We…?» traducida a: ¿Cómo Podríamos Nosotros….?
HMW, un marco perfecto para el pensamiento innovador
Es decir, la técnica consiste en replantear las preguntas con la intención de convertir esos desafíos en oportunidades de diseño. La forma de hacer la pregunta sugiere que una solución es posible y que se puede solucionar de varias maneras.
Cada palabra de esa pregunta está pensada para que psicológicamente las personas no se bloqueen, ni sientan miedo de proponer cosas, sino en estimular la resolución creativa de problemas.
- «How» o Cómo: supone que hay soluciones para esa pregunta, proporcionando la confianza creativa»
- «Might» o Podríamos: indica que podemos poner ideas por ahí que podrían funcionar o no, pero que de todos modos, están bien.
- «We» o Nosotros: como su significado indica, sugiere que vamos a hacerlo juntos y construyendo sobre las ideas de los demás.
Como ves esto es un testimonio del poder del lenguaje para ayudar a estimular el pensamiento creativo y la colaboración libre. Y es que cuando las personas tratan de innovar dentro de una empresa, a menudo hablan de los desafíos que tienen mediante el uso de un lenguaje que suele inhibir la creatividad en lugar de favorecerla.
Y es que cuando una persona en una empresa tiene miedo a proponer una idea, ya sea porque no se siente escuchada o teme que se rían de ella, es cuando la creatividad y la innovación mueren.
Por ello, es muy importante no llegar a ese punto, creando con técnicas como «HMW…?» el ambiente adecuado para ello.
La importancia de hacerse la pregunta adecuada
Pero hay más en la metodología «HMW…?» que usar simplemente esas tres palabras, como vamos a ver de mano de la persona que lo inventó Min Basadur.
Es necesario guiar a la gente a hacer las preguntas adecuadas de «HMW…?» para centrarse en el problema correcto que es necesario resolver.
Min Basadur, director creativo de Procter & Gamble, tenía que elaborar a principios de 1970, un jabón que compitiese con el popular jabón de Colgate-Palmolive, Irish Spring, cuyo diseño tenía un color verde y una atractiva promesa de «refrescante».
Packaging original y actual de Irish Sprint
Basadur pensó que el equipo de P&G hacía la pregunta equivocada («¿Cómo podemos hacer un jabón verde mejor?») y les realizo una serie de preguntas usando HMW, que culminaron con: «¿Cómo podemos crear un jabón más refrescante?», es decir, definiendo el problema correcto.
Resolución de problemas mediante «Framing»
Las personas, cuando nos encontramos con un problema, tendemos a querer resolucionarlo cuanto antes con la primera solución que se nos ocurre para quitárnoslo de en medio y pasar a otro asunto, que seguramente será otro problema.
Tenemos que romper este loop infinito, parándonos a pensar ya no si esa primera solución es la más adecuada, sino si ese problema es correcto, y si es el más prioritario en resolver (De este tema habla mucho el libro «UX Lean» en su capítulo 3, lectura súper recomendada)
Es como cuando intentas ir a un lugar desconocido sin mirar primero el mapa: creemos que podemos llegar bien -y, de hecho, podríamos- pero lo más probable es que no lo hagamos.
Y eso que el coste de no hacerlo es elevadísimo. Imagínalo como construir una casa. Una vez construída, no se puede cambiar su ubicación.
Y es que uno de los pasos más difíciles es definir con precisión esa oportunidad o problema, lo que se traduce como «problem framing«.
Un mejor encuadre (del problema) conduce a mejores soluciones.
Piensa en una pintura, el marco (frame) delimita lo que es la pieza de arte y lo que es parte del mundo exterior. Decidir ese límite, puede ser complicado para el artista, pero es una parte esencial de la pieza de arte.
Y plantear la pregunta adecuada, no es tan sencillo como parece.
Los problemas complejos normalmente son lo que Rittel y Webber llaman «wicked problems« (problemas malvados), no se descubre cuál es realmente el problema hasta que se está a un tercio del camino a través de su resolución.
Muchas veces la definición inicial de un problema no es la correcta. Aunque al principio estamos seguros de que ese es EL PROBLEMA, basta con indagar un poco para ver que no lo es. Técnicas como «Lateral Thinking» (libro de Eduard de Bono que también recomiendo leer o «Design Thinking» ayudan a definir el problema correcto y no focalizarse antes de tiempo.
Definiendo el problema correcto
Una forma de determinar el marco adecuado es jugar con la perspectivas, observando la situación desde diferentes puntos de vista (tiempo, personas, riesgo, recursos…) hasta encontrar el enfoque correcto.
Otro enfoque consiste en seguir esta serie de pasos:
Lo primero es reunir información preliminar sobre el problema, generando varias declaraciones del tipo:
Situación – Complicación – Pregunta clave
Una vez escritas, en equipo, a ser posible integrado por gente con diferentes conocimientos, compararlas y generar una conversación observando si se ha dejado algo fuera. Lo siguiente es elegir cuál es más relevante y por qué, analizando cómo se puede mejorar y si cada palabra de esa frase es justificable.
Es importante recalcar que puede que esa declaración no sea la más correcta, pero si que se debe estar seguro de que, sobre la base de la información a mano en este momento, es lo mejor que puede hacer.
Principios Lean UX para guiar la cultura de la empresa
Seguimos con los principios Lean UX ya que al adoptar este proceso, la cultura de la empresa debe ser la correcta para que se produzca el entorno perfecto para la innovación y la creación conjunta.
De la duda a la seguridad
El desarrollo de un producto digital es a menudo complejo e impredecible ya como hemos comentado el mercado está en constante cambio. Por ello Lean UX se basa en la idea de que todo es una hipótesis hasta que se valide.
Esta validación puede ser muy rápida o hacerse demasiado tarde. Por ello hay que eliminar el riesgo de malgasto de recursos en algo basado en una mala suposición, todo hay que validarlo. Continuamente el equipo se mueve de una posición de incertidumbre a una de conocimiento.
Resultados, no productos
Características y servicios son productos. Los objetivos que ellos quieren satisfacer son los resultados.
En Lean UX los equipos quieren crear un cambio medible y significante en el comportamiento del usuario. Es el equipo el que debe decidir como provocar ese cambio, qué aplicaciones, servicios… debe crear para ello.
Normalmente, hoy en día, sucede lo contrario. El equipo recibe un documento que le explica lo que tiene que realizar: x páginas, un filtro, un buscador… en vez de recibir el objetivo que se cree que es el deseado por el usuario.
Al partir de que todo es una hipótesis hasta que no se valide, es más fácil cambiar una característica por otra si probamos que no cumple el camino hacia el objetivo a conseguir.
Eliminar el desperdicio
Uno de los principios básicos de Lean Manufacturing es eliminar todo aquello que no lleva hacia el objetivo final. En Lean UX el objetivo final es el impacto en el comportamiento que se espera obtener, por lo que cualquier cosa que no contribuya a ello es desperdicio y debe ser eliminado.
Esto se hace porque dos motivos. Por un lado, los recursos suelen ser limitados. Cuanto más pueda ser eliminado, más rápido se moverá el proyecto hacia el resultado final.
Y el segundo motivo es que a nadie le gusta ver que si trabajo no se usa (a no ser que sea porque se ha validado y se ha visto que no es el camino correcto en cuyo caso si que ha tenido un uso).
Los equipos quieren trabajar en los retos correctos.
Queremos sentirnos efectivos. Ver que aportamos algo. Por ello si la empresa no valida cada poco tiempo, y el trabajo de varios meses o año acaba siendo no válido porque no cumple el objetivo, y debe ser realizado de nuevo, la moral del equipo desciende.
Entendimiento compartido
Esto sucede cuando todo el equipo conoce la misma información porque están trabajando de forma conjunta. Cuanto más entienda un equipo por qué están realizando algo, menos necesidad existe de debatir por qué se toma esa decisión y cómo resolver nuevos retos.
Seguir leyendo «Principios Lean UX para guiar la cultura de la empresa»
Recorrido cognitivo
Seguimos hablando de métodos para inspeccionar la usabilidad de un sistema. En este caso toca recorrido cognitivo o «Cognitive Walktrough» en inglés, que trata de evaluar la usabilidad de un diseño mediante la realización de tareas, para identificar errores de diseño o áreas susceptibles de mejora, centrado inicialmente en ver cómo piensa y se comporta un usuario cuando utiliza por primera vez una interfaz.
La principal diferencia entre el recorrido cognitivo con la evaluación heurística, es que el primero es específico a una tarea, mientras que el segundo método adopta visión holística.
Si no se hace con usuarios reales, es un método económico, que permite generar resultados rápidamente, pudiéndose realizar con prototipos de bajo o alto nivel, antes de que empiece el desarrollo.
¿Quién lo realiza?
El recorrido cognitivo lo puede realizar un experto en usabilidad o puede suceder dentro de una sesión de test con usuarios, ya sea remoto o presencial.
Por mi parte soy de la opinión que, aunque muchos fallos de usabilidad pueden ser detectados por un experto, ya sea mediante un análisis heurístico o un recorrido cognitivo, las técnicas DCU (Diseño Centrado en Usuarios) deben incorporar usuarios.
Por ello, recomiendo que los métodos que no incorporan usuarios, complementen sus investigaciones con resultados obtenidos mediante otras técnicas en las que haya intervención de usuarios finales representativos.
El experto en usabilidad, puede realizar cada test en base a la descripción del tipo de «persona» previamente definidas a este paso. Gracias a ello puede ser capaz de responder a preguntas tipo: ¿Será capaz este tipo de usuario (Persona X) de entender este icono? o ¿Dispondrá del conocimiento necesario para acceder a determinada función? aunque siempre será mejor un usuario real.
Walkthrough plural
En esta variante desarrollada inicialmente en los laboratorios IBM, el test lo realizan los 3 actores principales implicados en el proyecto: usuarios, desarrolladores y expertos en usabilidad.
Como otras técnicas colaborativas, al realizarse en conjunto, esta variante se caracteriza por la responsabilidad que toman todos los participantes al asumir el papel de los usuarios reales, lo que conlleva a una mayor implicación con el proyecto y las mejoras a realizar.
Definición de tareas
La tarea o tareas a realizar lógicamente dependerán del sistema a examinar, debiendo estar previamente definidas. Algunos ejemplos: proceso de búsqueda, proceso de pago en una ecommerce, rellenar y enviar un formulario, compra de entradas en un cajero…
Sobre todo si el test lo realizan usuarios externos y sobre todo si este es en remoto, es muy importante la definición y testeo previo de las tareas a realizar para que no haya luego problemas una vez que los usuarios entren a realizar el test.
Optimizar un test con usuarios
Continuación del post anterior «Experiencias de realizar tests con usuarios«
Hoy en día, con los recursos tecnológicos actuales, lo más caro de un test con usuario es el tiempo empleado en decidir que testear y en hacer el recruiting.
Lo primero nadie lo puede hacer por tí, ya que:
Nadie conoce mejor el negocio que tu equipo o tú.
Por lo que piensa bien que testear y haz el mínimo trabajo necesario para comprobar esas asunciones. Partiendo de que nada es válido hasta que se comprueba, gastar el menor tiempo y número de recursos en validar una idea hará que la empresa sea más proclive a seguir testeando.
Por eso como comentan también en el libro UX Lean ( y también por experiencia propia) es mejor externalizar esa parte, ya sea que una empresa busque los usuarios presenciales o en remoto (en la herramienta de testeo que busca también los usuarios u otra de BBDD).
Imagen sacada del libro Sprint, donde se ve a M. Margolis de Goggle Ventures realizar un test con usuarios.
Si hacemos el test presencial, soy de las que opinan que, para evitar que el se pierda tiempo generando documentación extra, lo ideal es que el equipo lo presencia en directo en una habitación continua. Para ello, en un mismo día se convocan a todos los candidatos (unos 5) y se reservan las 5-8 horas de todo el equipo para que vean en directo los resultados de lo que se ha trabajado previamente.
Si es una empresa del tipo «alguien llamado X» decide (que no está en el equipo), invitarlo también a que los vea en directo.
Es asombroso como alinea ideas ver a los usuarios teniendo problemas con algo que antes parecía tan claro.
O como de claro es ver que una idea sobre la que se tenía dudas, consigue sacar sonrisas y encantar a los usuarios. Ese subidón, es una recompensa al trabajo bien hecho.
Lógicamente si el test de usuario lo realiza una empresa externa, lo más normal es que se genere un informe de usabilidad donde se reporten las incidencias y su grado de gravedad. Al estar contratado externalmente estos test suelen ser mucho más costosos que los in-house y los informes muchas veces no los suele leer nadie. Aparte de que es mucho más complejo concienciar e implicar al equipo de esta forma.
Reclutar a los participantes correctos y realizar una correcta sesión de test con usuarios no es fácil. La persona encargada deba trasmitir confianza y confortar.
Es un arte guiar una buena sesión de test con usuarios.
Sonreír, trasmitir una buena postura corporal, realizar preguntas generales al inicio (la famosa «Small talk» inglesa), que generen una situación cómoda, que permitan al usuario sentirse como con un amigo, para ser honestos, abiertos y críticos.
Experiencias de realizar tests con usuarios
Vamos a hablar de la técnica más fiable (pero menos usada) para comprobar si algo funciona o se entiende: el famoso TEST CON USUARIOS (Síiiiiii, en algún lugar muy muy remoto de la galaxia existen!!)
Tanto en el ámbito digital para comprobar si las propuestas de navegación, contenidos o funcionalidad son adecuadas, como en el ámbito físico, para ver si un concepto se entiende, como demuestran en el libro Sprint Design, los test con USUARIOS REALES permiten averiguar si DE VERDAD funciona lo que hemos creado.
Te voy a decir una gran verdad, raro es encontrar una empresa que los haga de manera regular
Tristemente, debo decir que a día de hoy la mayor parte de las empresas (me atrevería decir el 90-95%, por lo menos digitales) no los realiza. Y ya no digo de hacerlos de manera regular como comentan (y apoyo) en en libro UX Lean.
Y no porque sean caros, que no tienen porque serlo ( y más con la tecnología actual)
O yo creo que no lo son dado todo lo que se pueden ahorrar. Sino los hacen es porque nunca los han hecho y los ven como algo imposible, y no tienen a nadie que tire del carro y les convenza y les impulse a hacerlo.
Ejemplo de test con usuarios (Imagen extraída del libro de Steve Krug «Don´t make me think»)
También cuando se trabaja en empresas de tipo consultoría o agencias, los timing no están pensados para realizar test con usuarios, y de hecho, es de las primeras cosas que se quitan de los presupuestos UX (o no se llegan a incluir).
Psst… Sin usuarios no hay UX
Tristemente, debo decir que a veces los que «venden» esos proyectos, tienen cero o ninguna formación o experiencia en UX para poder hacerle entender al cliente lo que de verdad puede necesitar, que a lo mejor es probar la idea con un prototipo y no vender 400 horas de desarrollo en algo que no funciona. Pero si, dile eso a un comercial (luego se quejará de que el cliente se va a otro lado).
Por experiencias vividas, es más fácil conseguir hacerlos si están dentro de la empresa y convences de su valor al CEO, que estar en una empresa externa y tener que pasar por 20 capas de directivos que los vendan por ti.
Un consejo: gánate primero la confianza con tu trabajo previo. Así es más fácil convencer que lo que vas a hacer (el test con usuarios) vale la pena (la inversión de tiempo y recursos).
Si estás dentro de una empresa pequeña (y normalmente menos dinero) es más fácil convencer al CEO que es un grave error gastar muchísimo dinero en desarrollar aplicaciones y servicios web en base a la experiencia previa de un grupo de diseñadores, pudiendo haberlo probado con un prototipo, que cuesta bastante menos dinero con usuarios reales.
Pero si formas parte de una gran empresa es mucho más complicado convencer a toda la cadena jerárquica de los beneficios de los test con usuarios.
Debes estar en una posición que permita «mover los hilos» para ser escuchado.
De hecho a veces, parece que se tiene un pavor a hablar con las personas que van a usar la aplicación. A mi me ha pasado incluso que NO me dejaban hablar con los usuarios al inicio del proyecto, y eso que eran usuarios propios de la empresa al ser una aplicación interna.
Podemos saber mucho de un negocio, y tener muy claras ciertas cosas, pero no es hasta que se prueba con usuarios reales, que de verdad podamos ver si está funcionando o no.
Si te gusta el tema, sigue leyendo mi siguiente post de consejos para optimizar un test con usuarios.