Desde hace bastante tiempo me interesan las metodologías y procesos de desarrollo de proyectos, particularmente las relacionadas con el web, donde la rapidez y flexibilidad es un requisito. Es un hecho que resulta vital contar con un proceso definido y adaptable, que permita resolver los problemas del desarrollo de proyectos de un modo eficaz. Factores como la optimización de procesos, reproductibilidad de las actividades, modularización e incluso manejo de riesgos justifican de sobra la adopción o creación de un proceso de desarrollo. Sin embargo, las metodologías existentes se enfocan al desarrollo de proyectos de software, en los que la funcionalidad es el eje del desarrollo y el factor humano es un dato más dentro de esta perspectiva, pero normalmente bastante disminuído:

• UML con Rational Unified Process
• Feature Driven Development
• Xtreme Programming

Un factor común en la mayoría de los enfoques de la gestión de proyectos es el considerar cuatro etapas o fases principales, en una simplificación extrema esto es aproximadamente como lo siguiente:

Análisis

Como factor común la primera etapa consiste necesariamente en asimilar el problema, conocerlo y dimensionarlo para poder tener una visión completa de él. Normalmente esto significa establecer descripciones simples del problema, para luego ir progresivamente profundizando en sus detalles mediante la definición de requerimientos, identificación de la audiencia, etc.

Diseño o Planificación

Luego de la primera etapa, teniendo una definición completa del problema, se comienza a planificar la solución, tanto desde la perspectiva del manejo de proyecto, considerando la definición de roles, actividades, plazos, costos, etc., así como desde el diseño lógico, la planificación concreta de la solución.

Desarrollo

Con la planificación y diseño conceptual resueltos, se procede a desarrollar las piezas necesarias que compondrán la solución.

Distribución, Transición o Implantación

Finalmente, luego del desarrollo de las piezas que constituyen la solución, se procede a realizar las pruebas finales y se distribuiye el producto al entorno del cliente.

¿Y qué Ocurre con el Factor Humano?

Ninguno de los procesos y metodologías que he conocido considera de modo central el enfoque de diseño centrado en el usuario. RUP incluye algunos roles y actividades relacionadas, pero en rigor sólo se trata de componentes menores del proceso de desarrollo, todo el problema se enfoca básicamente desde la perspectiva de desarrollo, de ingeniería de software.

Por otro lado, el Diseño Centrado en el Usuario o User Centered Design (UCD) es más bien una disciplina, o un conjunto de ellas, que define una filosofía, antes que un proceso concreto de desarrollo. Naturalmente, las herramientas permiten establecer un proceso que se complemente con los procesos de ingeniería de software y permita crear productos más completos, funcionales y fáciles de usar. Ése es el desafío de quienes trabajamos en esta área: hacer notar que el desarrollo de software es importante en la medida que el propósito esté claro, y que no es un objetivo en sí mismo. Hablo de software porque inevitablemente nuestro medio, el web, es en mayor o menor medida un problema de software, pero antes que todo, es un problema de comunicación.

Personalmente procuro sistematizar mis propios mecanismos de trabajo y establecer una metodología lo más clara posible, con un proceso predefinido y adaptable, que contribuya a facilitar el desarrollo de los proyectos actuales y futuros. Esto es un proceso dinámico que permanentemente va evolucionando en la medida que se refinan los procedimientos y se agregan nuevas herramientas.

En concreto, las principales disciplinas relacionadas al diseño centrado en el usuario, al menos en lo que concierne al web, son la Arquitectura de Información, la Usabilidad, elDiseño de Interacción, Diseño de Interfaces y el Diseño Gráfico. En particular, soy de aquéllos que consideran la Accesibilidad como una subdisciplina de la Usabilidad, fundamentalmente porque se trata de usabilidad aplicada a tipos de usuarios con requerimientos concretos comunes.

La relación entre todas estas disciplinas es estrecha y los límites en muchos casos son difusos, pero finalmente contribuyen a generar lo que conocemos como Experiencia de Usuario. Los siguientes gráficos ilustran cómo cada una de estas disciplinas participa dentro del proceso de desarrollo y cómo se relacionan en términos de dependencias y temporalmente:

Este diagrama muestra las curvas de participación de las diferentes disciplinas durante el desarrollo de un proyecto, o de una iteración de un proyecto mayor. Las displinas se extienden en las etapas que identificamos representando el tiempo o el momento en que participan. Así, una de las primeras en intervenir es la arquitectura de información, capturando requerimientos, identificando grupos de usuarios, contenidos, etc. Del mismo modo, su protagonismo declina finalizando la etapa de diseño. El diseño de interacción tiene un rol relevante que en algunos caso puede reemplazar a la AI cuando el foco está más en la funcionalidad que en el contenido. Un muy buen punto sobre esto lo plantea Garrett en el clásico diagrama de Experiencia de Usuario, expandido en su libro The Elements of User Experience: User-Centered Design for the Web. Luego continúa el diseño de interfaces, concretando las definiciones del diseño de interacción. A éste le sigue el diseño gráfico, que debe entregar la experiencia estética junto con potenciar el contenido mediante códigos visuales. Casi transversalmente, la usabilidad participa durante todo el proyecto, cautelando que el resultado sea usable.

Por mucho que intentemos establecer un ambiente familiar y apropiado para los tests de usuarios, es fundamental tener claro que es imposible reproducir en condiciones de laboratorio la forma en que un usuario se comporta cuando utiliza libremente y sin presiones una aplicación. Desde la perspectiva de usabilidad, es importante observar directamente a los usuarios, pero es necesario compensar y tener claro que, por mucho esfuerzo que pongamos:

• Los usuarios no están en su ambiente natural, ni realizando las tareas de un modo real, sino siguiendo las instrucciones de los evaluadores
• En laboratorio el usuario no es interrumpido por sus compañeros de trabajo, ni recibe mensajes instantáneos, ni revisa el email con la misma frecuencia, por lo tanto no tiene que dejar y retomar la tarea como haría en el mundo real
• El usuario se sentirá evaluado, sin importar cuánto insistas en que no es una evaluación de su desempeño, sino del software
• El nivel de tolerancia a los problemas es mayor, y la tarea será abandonada mucho después de lo que lo haría en su entorno natural
• Muchos usuarios se culparán a ellos mismos por lo errores, antes que al software
• La motivación para finalizar una tarea es diferente en el laboratorio, en el que sedesafía tácitamente al usuario a finalizarla

No estoy tratando de descartar el test de usuarios sino simplemente apuntando ciertos factores que deben ser considerados. Aproveché de comentar sobre esto porque coincidentemente me topé hoy, mientras revisaba mis feeds en Bloglines, con dos artículos relacionados de algún modo: When Do Users Really Give Up? , de Heidi Adkisson y Usability Stockholm Syndrome de Jensen Harris.

Después de todo, cualquiera que haya realizado un test de usabilidad sabe lo importante que es, pese a todo, observar a los usuarios de primera mano.

Aunque con unos días de retraso, no puedo dejar de comentar un par de cosas que me parecieron relevantes del fin de semana recién pasado. En Chile las transmisiones de mando de un presidente saliente al recién electo se realizan tradicionalmente los 11 de marzo. Sí, extraña coincidencia con el 11M español. Pero este 11 de marzo fue especial: asumió laprimera mujer electa Presidenta de la República. Esto por sí mismo ya es digno de comentario, aunque en realidad lo que quiero destacar es un detalle: la ceremonia de traspaso fue transmitida por cadena nacional con closed caption y lenguaje de señas.

Hace un tiempo atrás había comentado la iniciativa de algunos canales locales de implementar closed caption en sus transmisiones, inicialmente en los noticiarios centrales y ahora en varios de sus programas. Pero una cadena nacional de televisión ya es otra cosa.

Esto me pareció una señal muy positiva de políticas de accesibilidad y ciertamente una promisoria forma de comenzar un gobierno. Los dejo con algunas fotos de la transmisión, incluyendo el closed caption y la traducción a lenguaje de señas.