Tal como comenté en ese post, me contactaron los responsables del estudio, por lo que aproveché la oportunidad de exponerles mis preocupaciones y hacer las preguntas que me surgieron luego de leer el estudio.

¿Qué pregunté?

• ¿Qué tipo de usuarios incorporaron en el estudio? ¿Hubo una segmentación sobre qué nivel de conocimiento tenían sobre internet?
• ¿Se les dieron tareas a los usuarios para navegar por los diferentes sitios? ¿o se les dejó navegar libremente? ¿qué tareas fueron encomendadas?
• ¿Por qué recomiendan agregar movimiento a la publicidad si es muy conocido en el medio el fenómeno sicológico que produce la ceguera a este tipo de formato?
• ¿Cuál es la definición de “creativo” de la que hablan en el estudio? ¿Fue medida la creatividad?
• ¿Por qué son 69 usuarios? ¿Cómo establecen que eso es representativo?

¿Qué me respondieron? (textualmente)

• El efecto de banner blindess debe ser tratado cuidadosamente. Hay mucho mas allá del heatmap y se ha utilizado de forma muy erronea.
• Muy importante es el error de creer en la asignación de tareas para un estudio que requiere navegación libre para analizar la publicidad y no la usabilidad. Una tarea como cuál podría ser la adecuada??
• También sabes y conoces las métricas y la cantidad de milisegundos necesarios para una impresión en la memoria temporal.
• No es un modelo publicitario invasivo el video, sino que se habla de la publicidad en video cuando el participante busca ver un video (buscar una serie en mundofox.com).  Es casi como decir que si yo escribo “heineken” en youtube y me sale un comercial de heineken, eso sería publicidad invasiva!!
• No hay miles de estudios hecho sobre publicidad en páginas (no diarios) digitales.  Hay miles de estudios de usabilidad y UX en páginas web.
• Respecto a ¿por qué 69? ¿Por que no 69??  En realidad es un número que resultó después de hacer más grabaciones y algunas fueron desechadas por gaze data sampling, otras por sesgos y así terminaron siendo 69.

La verdad es que creo que trataron de responderme las preguntas, pero lamentablemente sigo con dudas por lo que volví a escribirles. Esta vez no sólo por las dudas metodológicas, si no por la preocupación que siento como profesional.

Mis reflexiones

Con respecto a Nielsen (ceguera de los banners), concuerdo en que lo que estipula se ha vuelto muy poco flexible, sin embargo, desde la experiencia y el sentido común, varias de sus conclusiones pueden ser aplicadas en beneficio de los usuarios.

Creo que la utilización del eyetracking para estudios relacionados a la experiencia de usuario puede desembocar en conclusiones como las del estudio realizado por OMD, y aunque éste no es un estudio de usuarios (o sus objetivos no están orientados en  ellos), lo que determina y concluye son acciones que afecta la experiencia de usuario directamente. Entiendo que no es un estudio de UX como tal, pero implícitamente se ve muy relacionado.

Piensen en un profesional que se dedica al desarrollo de aplicaciones. sitios, etc. que anda navegando por Internet buscando información con respecto a cómo hacer que la publicidad en web sea más efectiva y entra al sitio de la IAB y se encuentra con este estudio. ¿Qué piensa ese profesional? “este estudio debe tener razón, es un estudio después de todo no? y está publicado en el sitio de la IAB”. Eso tiene una consecuencia, el profesional se sienta en su computador a hacer su trabajo e incorpora las recomendaciones de este estudio. ¿Cuál es el resultado? Publicidad molesta para los usuarios, poco efectiva para el avisador, mala experiencia y todo lo que eso conlleva.

El tema de la publicidad, su visualización, medición y venta es una preocupación de varios colegas profesionales de la experiencia de usuario, y creo que es necesario abordarla de varios puntos de vista y no sólo desde la visión sesgada de la publicidad en sí misma.

Sigo pensando que las conclusiones del estudio son muy raras y no estoy para nada de acuerdo con el planteamiento que no son necesarias las tareas. Me siento en la obligación de aclarar este punto porque puede haber afectado directamente los resultados:

Cuando un usuario navega en un sitio lleva implícito en la cabeza la idea de una tarea u objetivo que quiere lograr. Se dirige a ver su cartola al banco, va a leer una noticia, revisa su correo electrónico, a jugar en facebook, etc. Siempre hay un objetivo.

Si le dices a un usuario que navegue libremente es muy esperable que se dedique a mirar lo que sea en el sitio, dado que no está buscando nada en particular, ahí está el sesgo. Si estás midiendo la efectividad de la publicidad debes recrear el contexto de navegación lo más real posible y establecer desde ahí si la publicidad inserta en un sitio es efectiva o no, a partir de la navegación o el modelo mental que un usuario establece a la hora de indagar por un sitio.

Otro tema es la  cantidad de milisegundos necesarios que se necesitan para que haya una impresión en la memoria temporal, eso no basta para decir que la publicidad es efectiva. Por lo demás, las métricas de fijación por sí sola no  sirven para diseñar mejores experiencias de uso y la publicidad es parte de la experiencia de uso, les guste o no a quienes las diseñen y las producen.

La publicidad es una parte importantísima de la web, por lo tanto creo que no es posible analizarla y separarla del contexto de navegación desde el punto de vista de la usabilidad o la experiencia de usuario, la publicidad debe ser parte de la experiencia de usuario.

Por eso, algo que me preocupa es que dan mucha importancia, y de hecho recomiendan, que el formato de la publicidad sea una en la que se genere movimiento. Las personas huyen de ese tipo de publicidad, la bloquean.

Es por eso que les pregunté qué tipo de usuarios participaron, porque si son usuarios “nuevos” seguramente van a ver la publicidad, pero si son usuarios más avanzados, la verdad es que lo dudo.

Creo firmemente que es una irresponsabilidad asegurar que los usuarios ven publicidad en movimiento, esto hace parecer que su estudio es sesgado en el sentido que se centra en la publicidad como un fin en sí mismo, pero deja de lado el resto de la experiecia de usuario.

No sé por qué obtuvieron esos resultados, a eso iban destinadas mis preguntas, a esclarecer por qué según el estudio las personas ven publicidad en movimiento (por ejemplo) algo que he comprobado empírica y académicamente que es falso. Creo que los resultados se dieron de esa forma porque algunas de las variables o están mal interpretadas o los usuarios tienen características especiales, pero no tengo cómo saberlo dado que esa pregunta no me la contestaron.

Con este post quiero transmitir mi preocupación sobre lo más importante de mi trabajo: que el usuario que navega en la web tenga el mayor nivel de satisfacción posible. Y lo que me preocupa de este estudio es que nos dice que tenemos que hacer todo lo contrario a los estándares de usabilidad que se conocen con respecto a la publicidad. Este tipo de estudio es leido por gente que trabaja en el medio y que obviamente puede tomar sus conclusiones y aplicarlas.

Existe mucha literatura sobre estudios de eyetracking en la web. Los invito a que busquen, lean e investiguen. Los invito también a que observen, miren a sus compañeros de trabajo, a sus hijos, a sus amigos, a sus padres, observen la forma en cómo navegan, hagan el ejercicio de preguntarles si recuerdan la publicidad que supuestamente han visto.

Mi objetivo es que aprendamos a hacer publicidad que entregue valor, esto es beneficioso no sólo para nuestros usuarios, si no para los que pagan por ella. Buscar maneras de publicitar que el usuario valore, no que evite.

Pensé que era una mala interpretación de la noticia, sin embargo, después de hacer varios comentarios vía twitter me contactaron de la empresa Omnicom Media Group (OMD), responsables del estudio, para hacerme llegar el documento y un comunicado donde aparecen las principales conclusiones.

Qué dice el estudio

Dice entre otras cosas lo siguiente:

• Que se revela la efectividad de la publicidad online y su incremento al incorporarle movimiento y ubicarla en la pantalla inicial.
• Que el video es el formato más creativo y el que más llama la atención (…) siendo un elemento de gran ayuda cuando el video oscurece y bloquea el resto de la pantalla, atenuando otros elementos distractores e impidiendo el scrolling.
• Basado en la percepción y no en la observación dice que los participantes del estudio consideran que el banner ocupa el segundo lugar en creatividad y en llamar la atención para leer.
• Que los robapáginas, por su ubicación en la página principal, también forma parte de la exploración visual de los usuarios.
• Es recomendable ubicar la publicidad en el inicio de la pantalla, en la primera visualización del sitio, puesto que la probabilidad que el aviso sea visto es mayor, independientemente del largo de scroll o de la estructura de contenidos del sitio.
• Que es necesario considerar que por naturaleza el usuario sigue el movimiento, por lo tanto es importante generar movimiento en los distintos avisos, con el objetivo que llamen más la atención al ojo que el resto de los elementos del sitio.
• Si se busca que el aviso funcione como enlace, se deben preferir los videos.
• Si se quiere que el aviso funcione como un cartel publicitario se deben preferir los banners y robapáginas.

Mis preocupaciones

He leído y participado de varios estudios de eyetracking y este estudio contradice todo lo que se ha escrito con respecto cómo los usuarios ven (o no ven) la publicidad.

Famoso es el artículo de Jakob Nielsen en el que habla de la cegura de los banners, donde afirma luego de sus numerosos estudios que:

En tanto, en el estudio realizado por la empresa AyerViernes, se establece que los usuarios son capaces de discriminar entre contenido relevante y publicidad. Lo que nos habla sobre el fenómeno sicológico que ocurre en cuanto a cómo vemos la publicidad en Internet.

Eduardo Manchón hace un excelente resumen sobre esto:

“Lo que dicen estos artículos es básicamente que la ceguera a los banners es un fenómeno causado por mecanismos psicológicos, independiente del contenido de los banners o de la segmentación del usuario objetivo, porque es producida unicamente por el formato del banner. Aunque la ceguera a los banners es citada frecuentemente, no es por todos conocido su funcionamiento real y que este fenómeno explica también una parte importante del comportamiento de los usuarios en Internet.

Cuando un estímulo aparece de forma repetida y frecuente nos insensibilizamos a él (…) El reflejo de orientación es un mecanismo de defensa que nos hace girar la vista en dirección a cualquier ruido, cosa que se mueva o sea de vivos colores. Este reflejo de orientación es un mecanismo producido por la evolución humana para defenderse de agresiones externas (…) La desensibilización ocurre de forma más acelerada si la información es irrelevante.

La identificación de los banners se produce por la creación en los usuarios de un esquema perceptivo que a través de determinadas claves visuales de los banners (forma, características, imágenes, fondo llamativo, posición en la página, etc.) permite descartarlos como información a analizar. Esta ceguera visual sirve a los usuarios para discriminar entre contenido de posible utilidad (contenidos reales del sitio) y contenido de nula utilidad (generalmente publicidad). La ceguera es posible debido a este formato llamativo de la publicidad (que proporciona esas claves visuales identificativas).

Al principio no es posible quitarles el ojo de encima, pero finalmente los usuarios se vuelven “ciegos” a ellos.  Así se aprende a no prestar atención a la parte superior de la pagina.

Por estas afirmaciones es que me preocupa el estudio encargado por .Fox. Creo que ha habido una mala interpretación de los resultados y algunas pequeñas fallas metodológicas:

• Por ejemplo ¿quiénes son los usuarios que participaron en el estudio? No es lo mismo que sean usuarios avanzados o nuevos usuarios de Internet, los resultados serían absolutamente diferentes, dado que se sabe a través de estos estudios que los nuevos usuarios tienden a mirar la publicidad, mientras que los más experimentados la bloquean automáticamente.
• ¿Cuáles fueron las tareas que se le dieron a los usuarios para hacer este estudio? Las tareas son extraordinariamente importantes. Al sitio de un diario una persona va a leer noticias, a un banco a ver su cuenta corriente, a una universidad va a ver las carreras, cada objetivo es diferente, cada necesidad distinta, cada contexto influye en qué tanto me siento abierto a ver o no publicidad. Si navego el sitio de Lan estaré más dispuesto a recibir publicidad dado que probablemente encuentre ahí lo que ando buscando. Pero no es lo mismo para todos los casos.
• No es lo mismo pasar la vista involuntariamnete por la publicidad que mirarla realmente. Posar la vista por un segundo no es indicador que las personas hayan puesto atención en la publicidad.
• No conozco a ningún usuario que le guste la publicidad invasiva. Creo que la publicidad es necesaria, pero se debe hacer con respeto al usuario. ¿De qué sirve incorporar una página completa con publicidad en un sitio si el usuario lo único que quiere es cerrarla?
• Lo que más llama mi atención es que se da como recomendación que la publicidad debe tener movimiento porque así se diferenciará del resto de los contenidos. Eso es absolutamente falso. Las personas, como vimos antes, aprendemos rápidamente que un elemento con movimiento es publicidad y la sacarmos de nuestro foco de atención. Podemos pasar la mirada por sobre ella, sí, es cierto, pero eso no significa que le hayamos puesto atención.
• El estudio dice que el 66,7% de los usuarios vieron los banners por un espacio de tiempo de o,73 segundos y que el 60,6% vieron el robapáginas por o,87 segundos. Mi opinión es que acá se ha malinterpretado y malentendido el “ver” con el “pasar la vista”, pasar la vista por menos de un segundo no significa que los usuarios hayan visto realmente estos elementos.
• La interpretación general de OMD/.Fox parece tendiente a validar un modelo publicitario invasivo, heredado de la TV y aplicado en Web. Esto es un problema metodológico dado que no se evalúa realmente la efectividad de la publicidad, sino sólo su visualización. La principal diferencia entre Web y TV, en cuanto a la publicidad (y para muchas otras cosas) es la participación y la interacción.
• Así al parecer se vislumbra un caso de interacción-blindness, dado que no se asume la participación como un factor a analizar, tal como los usuarios sufrimos ad-blindness (ceguera publicitaría).

Creo que este estudio es útil en cuánto a la comparación entre los tipos de publicidad, en eso hay un tremendo aporte, pero asimismo, creo que es una gran irresponsabilidad afirmar que se revela la efectividad de la publicidad online y su incremento al  incorporarle movimiento.

La pregunta lógica entonces es cómo hacer publicidad efectiva. Creo que no generando ruido, contextualizándola con los objetivos de cada sitio. Entregando valor más que molestia. No perjudicando la satisfacción ni experiencia del usuario, sino entregándole ayuda.

Contacté a la persona encargada del estudio y le escribí las dudas que expongo acá. Cuando reciba respuestas prometo publicarlas.

Obviamente no encontramos todos los que existen, pero descubrimos una lista interesante en el IA Institute e información en varios blogs y sitios que hablan del tema. Además de la ayuda de @claudiolobo que nos está ayudando con más programas.
Y como sabemos que no somos los únicos que andamos en busca de esta valiosa información, queremos compartir esta lista con los interesados.

El llamado eso sí es que si saben de otros programas los posteen en este post como comentarios para agregarlos y hacer crecer esta lista.

Se agradecen los aportes.

Vean acá el enlace a Google Docs.

Según sé, habrá streaming, así que podrán ver el evento desde otros lugares.
Acá les dejo la presentación, le doy las gracias a Esteban Saavedra (@esaaveni) que me ayudo con los diagramas:

La idea de este seminario es explorar lo que hacemos los arquitectos de la información más allá de la web.

• Cuándo: Viernes 22 y sábado 23 de octubre.
• Dónde: Viña del Mar (Escuela de arquitectura y diseño de la UCV) y Santiago (Auditorio Edificio Telefónica) respectivamente.
• A qué hora: de 9 a 14 horas ambos días.
• Conoce el programa.
• Conoce a los expositores.

De manera paralela realizaremos clases de 30 minutos de:

• Card sorting.
• Testeo de usuarios.
• Wireframe.
• Test Heurístico.
• Benchmark.

La inscripción es gratuita y pero debes inscribirte.

Independiente de la metodología que se aplique para el diseño y el desarrollo, ésta es una pregunta que debe estar presente en las discusiones sobre lo que se requiere diseñar.

Esto no parece un trabajo que presente mayores dificultades desde el punto de vista del diseño centrado en el usuario dado que es un cuestionamiento que viene incorporado en los principios de esta metodología. Sin embargo, se presenta un problema cuando los principios básicos  de la arquitectura de la información, usabilidad y accesibilidad se ven amenazados por la utilización de otras metodologías, cuando no es considerado el trabajo de investigación de usuarios ni de documentación del proceso de diseño.

Ante esto y como conclusión quiero recordar algunos conceptos y hacer una recapitulación, tanto de lo los últimos tres post como de mi experiencia personal trabajando en este tema.

Acá va:

• Las metodologías de desarrollo ágil son compatibles con las de diseño centrado en el usuario si los equipos las conocen a cabalidad.
• Para aplicar metodologías de desarrollo ágil no es necesario seguir al pie de la letra lo que dicen los libros, dado que no todos los proyectos ni los contextos son iguales.
• Las maquetas y las definiciones de las necesidades no pueden salir de la imaginación del equipo de diseño ni del equipo de desarrollo, es importantísimo hacer investigación de usuarios, particularmente cuando se trata de desarrollos transaccionales complejos.
• Juntar diseño centrado en el usuario y desarrollo ágil puede ser catastrófico si no se está consciente que las definiciones del negocio deben ser concebidas antes y no durante el proceso de desarrollo.
• De nada sirve hacer investigación de usuarios si en el proceso esto se diluye.
• El diseño no se puede discutir en los sprint, debe ser un tema que esté cerrado y testeado con usuarios antes de que se comience con el proceso de desarrollo.
• No hay que perder de la vista que el diseño es centrado en el usuario, no en el desarrollador.
• Si bien en el desarrollo ágil se trata de disminuir la excesiva documentación, es necesario documentar el diseño, aunque sea fuera de este proceso, con el objetivo de no comenzar el diseño de cero en un sprint.
• Las maquetas deben ser testeadas con usuarios antes del desarrollo, o más bien, antes del primer sprint.

La experiencia de usuario debe ser vista como una política institucional. Poco se logra si no toda la institución está orientada a aumentar los niveles de satisfacción de los usuarios.

Relacionados:

• Llevando el Diseño Centrado en el Usuario al desarrollo ágil I
• Llevando el diseño centrado en el usuario al desarrollo ágil II.
• Llevando el diseño centrado en el usuario al desarrollo ágil III.

“…
El desarrollo ágil es bueno para la refinación, no para su definición

Si tiene un producto que ya existe y que quiere desarrollar a un nivel superior, el desarrollo ágil funciona porque ya tiene una base sobre la que aplicar mejoras.

Esto significa que si usted ya sabe lo que necesita y los requerimientos ya han sido definidos y debidamente obtenidos (desde una correcta investigación del usuario, desde el análisis comparativo, desde la persperctiva de los objetivos de negocio, y el análisis de contenido) puede perfectamente lograrse desde el punto de vista técnico.

Pero gastar dinero en el desarrollo de software sin un plan de lo que se quiere construir es como pedirle a un equipo de construcción que construya una torre sin ninguna planificación.

Diseño Centrado en el Usuario

El diseño centrado en el usuario requiere iteración, diseñar, probar y testear con usuarios, perfeccionar, probar con usuarios otra vez, mejorar … repitiendo hasta que esté bien. Aquí es donde el desarrollo ágil y el diseño centrado en el usuario pueden trabajar juntos con brillantez.

El desarrollo ágil realmente trata de averiduar (o suponer más bien dicho) qué se necesita para cambiar las cosas,  y eso es algo bueno cuando proviene de un proceso de refinamiento.

Descubriendo requisitos para formar una estrategia

Diseño Centrado en el Usuario (DCU) no se trata de responder a los requerimientos, sino que también incluye la definición de requisitos. Debemos presumir poco acerca cuál debería ser la solución a un problema específico y poco acerca de lo que el problema en realidad es, poque las presunciones nos cierran a nuevas posibilidades.

Es preferible, para hacer alguna investigación de diseño, crear un punto de vista y luego formar una hipótesis sobre lo que podríamos construir.

En cuanto a esto, nos cruzamos con reino de los product managers, productores, administradores de programas, analistas de negocio y similares, encontrando poco espacio y harta resistencia alrededor. Frente a la reticencia para definir las aburridas y viejas necesidades del negocio (diferentes a las necesidades del cliente), estas personas limitan nuestro trabajo DCU a las pruebas de usabilidad en diseños que cumplan los requisitos que ellos establecen.

Ellos prefieren que nos dediquemos sólo a ayudar con el desarrollo, si pudiéramos hacerlo más rápido con una metodología de desarrollo ágil… sería fantástico.

¿Es siempre conveniente hacer una amplia investigación antes de comenzar el diseño? Eso es una buena pregunta y una que Jared Madurez puede ayudar a responder. A veces podemos obtener información que no se encuentra fácilmente frente a nuestros ojos, por eso es importante que conozcamos las necesidades de los usuarios, tenemos que darnos el lujo de hacerlo. La investigación es un componente esencial para poner nuestros pies en el lugar correcto.

Después de investigar lo que los usuarios y la empresa requieren, podemos aplicar la estrategia de Experiencia de Usuario de Jasse James Garrett (puedes verlo con más detalle en su libro The Elements os User Experience)  sobre esto se debiera basar todo lo que vamos a hacer durante el proyecto. Al aplicarlo no debería haber ningún error extraordinariamente grande.

Lamentablemente, las metodologías de desarrollo ágil no da cuenta de esto más allá de la fase de planificación (la iteración cero), que bien puede definir una estrategia, pero ¿puede de esta forma definirse una estrategia correcta?.

Sin duda, a través de una cuidadosa consideración de tres cosas:

1. Con una empática investigación cualitativa que descubra y revele el contexto del usuario, sus necesidades, metas y objetivos.

Cooper sugiere que el cliente no sabe lo que quiere y defiende el papel de diseñador de interacción como planificador de necesidades. Esto evitaría la mala construcción de los requisitos, pero el tiempo para hacer esto debe entrar en el ciclo de desarrollo en alguna parte. Se trata de hablar con los usuarios (preferentemente en persona) en su medio ambiente para crear modelos y personajes y casos de la experiencia de usuario.

2. Es recomendable hacer un análisis detallado qué sitios parecidos existen en Internet, puede ser en términos de productos, características y tecnología (no necesariamente hacer frente a una situación similar a la nuestra, sino que tome ciertas características con las que nuestro proyecto se vea identificado).

3. Una articulación clara del problema del negocio, los objetivos, las medidas de éxito y limitaciones. Lo que discute la gente de negocios debe ser informado y considerado en la etapa de la estrategia.

Desarrollo del concepto

Si logramos construir algo útil e intuitivamente razonable sin investigación o estrategia, ¿tuvimos éxito? La mayoría de los reproductores de MP3 se ajustan a esto, pero ninguno salió como el iPod de Apple.

Dejando a un lado usabilidad de una interfaz, el iPod tiene un concepto de servicio detrás, que incluye la digitalización, la reposición y la gestión de tu colección entera de música con iTunes. Esto fue parte del concepto del iPod desde el principio y en combinación a un buen plan de marketing y diseño, y aún continúa eclipsando a la competencia después de siete años.

Si no se aplica explícitamente este aspecto fuera de nuestra metodología ágil, es posible que ese valioso tiempo para pensar se pierda.

Lo mejor de ambos mundos

En la metodología de diseño centrado en el usuario puede ser que la documentación sea  demasiado pesada y compleja, pero las metodologías de desarrollo ágil necesitan ayuda con los requisitos de la definición y desarrollo del concepto.

¿Cómo pueden los principios de ambas metodologías trabajar juntas?

Primero entendamos lo que funciona bien con la metodología de desarrollo ágil y no tan bien con el diseño centrado en el usuario.

En este sentido, el trabajo del diseño centrado en el usuario puede producir documentación que no se lee, describiendo interfaces específicas de forma aislada que quizás no serán viables ni ser codificadas en el tiempo asignado.

Así, si se requiere hacer un diseño detallado es mejor hacerlo en conjunto con el equipo de desarrollo, de manera  que las interfaces resultantes puedan ser ajustadas a medida que se trabaja.

Una visión compartida de los fundamentos de la interacción

En el desarrollo de un buen software, un modelo de interacción conceptual que ha sido pensado de antemano destaca por la forma en el usuario navega por el sistema, como realiza tareas y utiliza las herramientas en términos genéricos.

Después de que mapa ha sido esbozado, reforzando la investigación y la conceptualización antes de la actividad de desarrollo, es posible garantizar la coherencia y la cohesión de cada componente cuando posteriormente se codifica por separado.

En muchos casos, el conceptualización necesitará iteraciones para dar cabida a las diferentes experiencias y tendremos, a lo menos, alguna indicación (o modificación) a grandes rasgos.

Entonces, en medio de iteraciones del desarrollo ágil, arreglando los detalles al lado del equipo de desarrolladores, se requiere un nivel de experticia y experiencia de parte del diseñador, porque lo que diseñamos se construirá antes de que tengamos tiempo de arrepentirnos.

El riesgo que se presenta en la interfaz son las nuevas y significativas mejoras de lo que ya se ha hecho. Esto es preferible abordarlo como una actividad única en un sprint antes de desarrollarlo (no trate de producir código).

Esto evita la presión de entregar algo antes de que esté en óptmo estado, hacer un ejercicio de reflexión y testear con usuarios le asegura que no estamos perdiendo el tiempo y esfuerzo.

A veces la mayor parte del producto se hace de esta manera y eso está bien siempre y cuando los desarrolladores y diseñadores trabajen juntos y exista una relación de comunicación diaria.

Las primeras iteraciones de desarrollo son muy importantes para los desarrolladores para sentar las bases de arquitectura basada en la visión. Los diseñadores deberían utilizar este tiempo para adelantar el trabajo en las interfaces más complicadas y de alta prioridad.

Lo más importante para el éxito: el área de negocios tiene que aceptar que algunas cosas no se verán bien ni estarán perfectas en un principio. Mientras que el compromiso del equipo, antes de la liberación del producto, es no dejarse arrastrar en la tentación de lanzar algo que no está desarrollado de manera óptima o como se acordó en un principio.

Conclusión

En resumen, las actitudes dogmáticas acerca de cada uno de estos enfoques deben ser evitados si necesita combinar ambas metodologías.

Recuerde, el desarrollo ágil no exige una forma de definir conceptos y no es una dirección de diseño global, pero es una gran oportunidad para ejecutar una investigación de diseño sólido y bien establecido. El diseño centrado en el usuario debe ser lo suficientemente flexible como para responder a la realidad cuando el equipo de desarrollo encuentra problemas.

Los documentos sólo se necesitan para hacer llegar el mensaje, porque la colaboración interdisciplinaria y la comunicación cara a cara son vitales.

Trabajando en un sprint por delante del equipo de desarrollo es muy útil para dar al  equipo de diseño tiempo suficiente para probar (adelantarse a los hechos).

Si estas reglas  son consideradas, los dos enfoques pueden trabajar muy bien juntos.

Relacionados:

• Llevando el diseño centrado en el usuario al desarrollo ágil I.
• Llevando el diseño centrado en el usuario al desarrollo ágil II.

“…
El campo minado

En sí mismas, las metodologías de desarrollo ágil hacen un buen trabajo en cuanto a su flexibilidad frente a los cambios. Pero es necesario preguntarse si ésta fue diseñada para tratar un gran síntoma de las organizaciones: la empresa no sabe lo que quiere. Aunque el equipo de desarrollo ágil podría hacer frente de mejor forma a esto, en otras ocasiones no se resuelve el problema y en la mayoría de los casos crea otros nuevos.

Mina 1: El papel del diseño es poco claro

Las empresas contratan a los desarrolladores para crear programas, sitios, aplicaciones o sistemas, algunos de los desarrolladores pueden tener habilidades de diseño, pero eso no es un escenario muy común. Muchos desarrolladores también han tenido malas experiencias con los diseñadores, por varias razones (no son apropiados, no conocen el negocio, etc).

Ha tomado tiempo lograr enfrentar el diseño (como profesión) y el diseño de sistemas complejos, pero todavía hay un déficit de conocimientos en este campo. Más complejo se torma el escenario cuando uno de los principios del desarrollo ágil dice que “la gente de negocios y los desarrolladores deben trabajar juntos diariamente a lo largo del proyecto”. Entonces ¿dónde encaja acá el diseñador?.

Mina 2: El proceso de recopilación de requisitos no se define

El desarrollo ágil acoge las actividades de diseño desde la perspectiva de un desarrollador, tiende a recibir las especificaciones desde el punto de vista del requirente (empresa o cliente que se supone que todo lo saben) y da por sentado que éstos son apropiados.

Según Ken Schwaber, SCRUM tiene la intención de ser una metodología de gestión integral y deja espacio para otras actividades (para que la programación se produzca en el marco de los ciclos iterativos).

Pero cuando las organizaciones adoptan SCRUM, con frecuencia desechan las buenas partes del desarrollo en cascada como la investigación y la formación de un plan de alto nivel para el diseño general, arrojando por la borda la documentación.

Como el Manifiesto del Desarrollo Ágil dice que el software es más importante que la documentación completa, muchos apelan a esto y no quieren hacer ningún tipo de documentación, algo que puede ser muy valioso para presentar un esbozo de la visión institucional, aunque sea en un sentido rudimentario.

Mina 3: La presión para cortar las esquinas

Las implementaciones de desarrollo ágil ubican las actividades de diseño dentro de las mismas iteraciones que el desarrollado, para garantizar o asegurar que el diseño se realice y se desarolle al momento de hacer el código. Esto también impone una enorme presión sobre el equipo de experiencia de usuario, el de “alimentar la máquina de desarrollo” en el tiempo suficiente para que se pueda poner en práctica su visión.

Esto puede llevar (y de hecho así ocurre) a diseñar impulsivamente. ¿Qué hay de malo en eso? Nada si el trabajo está basado en los principios del diseño centrado en el usuario. Desde esta perspectica se sugiere que se debe probar las ideas con los usuarios finales antes de comprometerse a desarrollar el código.

Sin duda, nos permite ahorrar mucho tiempo y recursos, y levanta una importante duda ¿cómo sabemos si la maqueta funciona de la misma forma como si ya estuviera programada, en un contexto diferente, sin haber probado antes con el usuario? ¿Cómo podemos innovar copiando lo que ya existe?

Antes de que Google reinventara las búsquedas en Internet, otros motores de búsqueda suponían que le correspondía al usuario aprender a buscar de manera adecuada.

La mayoría de los resultados de búsqueda eran pobres, entonces Google llegó y se dio cuenta de lo que ahora es evidente: La gente sólo quiere encontrar lo que necesita, no quiere aprender a usar un motor de búsqueda.

No estoy sugiriendo que los otros motores de búsqueda no podría haber hecho lo que Google hizo antes, sólo estoy señalando con el dedo la pérdida de oportunidad por no considerar las necesidades de los usuarios.

Curiosamente, Google no es conocido por sus diseñadores. Es principalmente una casa de desarrollo, pero muchos de los desarrolladores claramente tienen cierta sensibilidad con la experiencia de usuario, particularmente cuando se trara del diseño centrado en el usuario.

No hay nada de malo en usar la matodología de desarrollo ágil para producir resultados rápidamente, si tiene la intención de hacer pruebas de usabilidad con anterioridad. Sin embargo, no hay que dejarse engañar pensando que esto podría ahorrar mucho tiempo, dado que ante el desconocimiento y el apuro los resultados pueden ser más costosos.

Mina 4: La tentación de llamarlo “suficientemente bueno”

Invariablemente, cuando se ha terminado el código a finales de cada ciclo, se corre el riesgo de liberarlo aunque no sea lo suficientemente bueno. A veces, eso involucra hacer lo que sea para terminar el ciclo y comenzar con otro, pero en definitiva puede que no sea lo mejor para el usuario.

¿Hay que gastar tiempo en la próxima iteración u ocupar tiempo en arreglar sobre la que se está trabajando? Demasiado a menudo, el re-proceso va en favor de comenzar el nuevo desarollo y resulta un producto con ciertas características que probablemente no van a satisfacer a los usuarios.

Mina 5: Insuficiente tiempo para explorar el riesgo

La iteración “cero” (es decir, una planificación y diseño de la iteración anterior a la iteración del primer desarrollo) se puede utilizar para hacer esto y otras actividades de planificación.

Sin embargo, dependiendo de cuánto tiempo se demora esta iteración, el nivel de rigor aplicado a la exploración puede ser insuficiente.

Un argumento utilizado por algunos profesionales de metodología de desarrollo ágil es que hacer un ejemplo práctico (ir entregando productos programados) es la mejor manera de validar si es adecuado a las necesidades del cliente.

El “suck it and see” omite la conceptualización, las actividades donde se dedica tiempo a esbozar soluciones diferentes a un nivel alto y validarlos con los usuarios antes de excavar en el diseño detallado o hacer el código. Con el “Suck it and see” habría solamente que construir, lanzar y ver si se tuvo suerte y cumplió con satisfacer a los usuarios. De esta forma, se pierde tiempo de producción en desarmar o reconstruir.

El argumento contrario es que si se tomó el tiempo para construir, habría que considerar el tiempo para investigar y diseñar antes de hacer una línea de código.

Tiene que haber cierto nivel de diseño independientemente de la metodología se utiliza, y esto suma días a la línea de tiempo.

Mina 6: Marca daños

Digamos que el diseño y la investigación toman la misma cantidad de tiempo que el desarrollo. En el peor de los casos, se pierde por completo la marca o la visión por no hacer una investigación y diseño de la solución, en ese caso se debe comenzar todo de nuevo. Entonces a final de cuentas se gasta el mismo tiempo (teóricamente), pero en caso de comenzar otra vez, sin definiciones de diseño, no hay ninguna garantía de que resulte.

La razón de éxito de muchas empresas es producir productos de forma consistente y servicios adecuados. Por el contrario, la creación de un producto o servicio defectuoso afecta negativamente la marca y la percepción de los usuarios. Se requiere mucho más tiempo para reparar los daños a la marca que hacerlos.

Continuará…

Post relacionados:

• Llevando el Diseño Centrado en el Usuario al desarrollo ágil I

Hace unos meses apareció en mis feeds un artículo escrito por Anthony Colfelt llamado Bringing User Centered Design to the Agile Environment que expone aspectos negativos y positivos acerca de integrar el diseño centrado en el usuario al desarrollo ágil, particularmente en Scrum.

Escribí y traduje este post en 3 partes, el cuarto post lo dejaré para mis reflexiones personales. Acá vamos:

“En cuando tuve la oportunidad de obtener un trabajo post burbuja .com lo tomé. Gocé del lujo de hacer las cosas exactamente como pensaba que era correcto y por un tiempo fue de verdad fantástico.

Formé un equipo con un investigador de usuarios, un arquitecto de la información, diseñadores visuales y de interacción, e incluso establecimos un laboratorio de usabilidad donde tuvimos testeos con usuarios regularmente.

Desafortunadamente, el entusiasmo que tenía por mi nuevo trabajo disminuyó después de seis meses cuando un ejecutivo fue nombrado como Jefe de Desarrollo de Productos, quien nos aseguró que conocía Scrum mejor que nadie.

Como Director Creativo le cedí autoridad para desarrollar el producto como él estimara conveniente.

He trabajado con Scrum antes, entrenando con Ken Schwaber (autor y co-fundador de la Agil Alliance) y sabía un par de cosas desde la experiencia, sobre cómo lograr integrar con cierto éxito un equipo de diseño a uno Scrum.

Esto siginificó que el equipo de diseño debía trabajar en los sprint (trabajo iterativos de 1 mes) por delante del equipo de desarrollo. Pero el nuevo ejecutivo, insistía en que se debía seguir las instrucciones al pie de la letra, es decir, todas las actividades debían ser incluidas en el mismo sprint, considerando también el diseño.

Vinieron requeririmientos desde la imaginación del jefe de desarrollo de productos, y como consecuencia de la presión del tiempo el diseño fue apresurado y mal concebido, en tanto el desarrollo fue también hecho a la rápida, mal hecho o peor aún, sin terminar.

El final de las reuniones informativas del Sprint consistía en una reprimenda para todo el equipo por parte de los ejecutivos (ya que nadie había entregado lo que habían comprometido por tratar de hacer demasiado, o no habían hecho lo suficiente). Cada Sprint consistía en tratar de arreglar lo malo del Sprint anterior “o tirarlo debajo de la alfombra“, además el desarrollo era inestable sobre un código basura. La moral disminuyó, el producto era malo, el personal empezó a rotar… fue horrible.

Este es un mal ejemplo extremo de Scrum. No estoy en contra de las metododologías de desarrollo ágil aunque me da rabia a veces y siento temor cuando escucho a alguien cantando sus alabanzas, sin tener mucha experiencia.

En los últimos ocho años, he visto metodologías ágiles mal aplicadas con más frecuencia que las bien aplicadas (pero sí, se puede hacer bien también). La idea de este artículo es presentar cómo las prácticas de diseño centrado en el usuario (DCU) pueden mitigar los riesgos inherentes del desarrollo ágil y cómo éstos pueden ser integrados dentro de los enfoques de desarrollo ágil.

¿De dónde proviene el desarrollo ágil?

Fue creado por un grupo de desarrolladores, Agile es un enfoque de desarrollo iterativo que toma pequeños pasos hacia la definición de un producto o servicio. Al final de cada etapa, se construye algo que se puede mostrar al cliente (o al dueño de este producto o servicio), de esta manera, es posible incluir al cliente en oportunidades donde las metodologías en cascada suelen fallar.

El desarrollo ágil va en la línea de trabajar y construir algo a medida que se avanza en las tareas, en lugar de hacerlo  al estilo del desarrollo en cascada (donde se profundiza en la especificación) y donde a veces se descubre mucho después que no es posible construir partes de la especificación por determinadas razones (por ejemplo: un error de cálculo o nuevas necesidades).

El desarrollo ágil se puede considerar como una estrategia de gestión de riesgo. Pero en este contexto, a menudo los desarrolladores toman contacto directo con un cliente que no sabe qué es o qué hace un diseñador de experiencia de usuario, arquitecto de información o diseñador de interfaz.

Sabemos que profesionales de estas disciplinas suelen interpretar lo que los clientes quieren y traducirlo a algún tipo de especificación para los desarrolladores. Sin esta función, el desarrollador es libre para elaborar y construir lo que cree que el cliente quiere.

Debido a que el desarrollo ágil necesita mucho compromiso con el cliente, al final de cada iteración (que puede ser cada semana) se reduce el riesgo de ir demasiado lejos hacia la creación de algo que el cliente no quiere. Como tal, es un mecanismo de defensa para las necesidades cambiantes de un cliente durante el desarrollo.

¿Por qué la gente celebra esto?

Es atractivo ante la posibilidad de un retorno más rápido de la inversión, porque se podrían ver resultados u obtener una versión del software antes. En el corto plazo, esto suele lograrse. En el largo plazo puede lograrse también, aunque sólo cuando el equipo no ha sido víctima de la tentación (se abordará con más detalles después).

El desarrollo ágil también es bueno en la generación de impulso, dado que con las iteraciones se puede tener control sobre la velocidad dado que se está continuamente revisando avances y logros. Es necesario alentar a los desarrolladores a hacer sólo lo necesario para cumplir los requisitos.

Debido a que se hace hincapié en contacto cara a cara por un equipo multidisciplinario, las metodologías de desarrollo ágil, tienden a alentar que profesionales de diversas áreas contribuyan desde sus diferentes perspectivas. Esto es generalmente una influencia positiva en la innovación y la velocidad de resolución de problemas. El equipo está facultado para tomar decisiones en cuanto a cómo jerarquizar sobre los requisitos que deben cumplirse.”

Continuará…

Es posible participar escribiendo breves explicaciones o haciendo algo más lúdico, utilizando imágenes, inforgrafías o videos.

Todos pueden participar, pero sólo los miembros del Information Architecture Institute votan. En los anuncios del grupo pueden ver más información sobre premios y otros datos importantes

Como muestra les dejo el video IAs are like Robin Hood y Explain IA? We’d have to go way back ambos de Matthew Hodgson (puedes revisar su Flickr).