User-Center Design. El ciclo de vida

Es evidente que no podemos entender ucd como una actividad inicial de definición de las interfaces, una actividad previa a la liberación del producto, sino como un conjunto de actividades a ser ejecutadas durante todo el ciclo de vida de desarrollo del producto.

Pese a todo, debemos partir de la premisa que UCD no es una metodología de desarrollo de software en sí misma, por lo que la clave es cómo la integramos con una metodología de desarrollo de software.

En cualquier caso, existen diferentes normativas que especifican las claves principales de un sistema UCD como se recoge en la ISO 13047:

• User focus. Desde un inicio los objetivos, necesidades y tareas de los usuarios finales y promotores deben guiar activamente el desarrollo del proyecto
• Active user involvement. Usuarios representativos deben participar activamente en el proceso de desarrollo
• Evolutionary system development. El desarrollo debe ser iterativo e incremental
• Simple design representations. Los diseños debe ser representativos y de fácil de comprensión para los usuarios y promotores del proyecto
• Prototyping. Desde las fases iniciales del proyecto los prototipos deben ser usados para visualizar y evaluar ideas en colaboración con los usuarios finales
• Evaluate user context. Criterios de diseño y usabilidad deben gobernar el desarrollo
• Explicit and concious design activities. El proceso de desarrollo debe dar espacio a tareas dedicadas de diseño de las interfaces y de la experiencia del usuario
• Professional attitude. Los equipos de desarrollo deben ser constituidos por miembros multi-disciplinares
• Usability champion. Este equipo debe incluir al menos un experto en usabilidad (senior designer)
• Holistic design. Todos los aspectos involucrados con el futuro uso de la aplicación deberían ser desarrollados en paralelo.
• Process customization. El proceso UCD debe ser adaptador específicamente por cada organización
• A user-center attitude should always be established. Todo miembro del equipo debe estar comprometido con la usabilidad y la participación del usuario.

En base a esta relación de claves podemos encontrar cientos de procesos que la representan, quizá el más conocido sea el de Nielsen (1993, aunque otros como Gulliksen o Mayhew deben ser tenidos en consideración.

Ilustración del modelo propuesto por Gullikssen, 2003.

Y  Ilustración del modelo propuesto por  Mayhew ya por el 1999.

En cualquier caso, llegado a este punto debemos realizar una primera diferenciación vital, entre lo que sería un proyecto llave en mano, y lo que sería un producto. Y más aún si cabe, si el producto es un servicio público en Internet, y los usuarios no son "conocidos"

A día de hoy existen multitud de herramientas accesibles que dan soporte a esa democratización del diseño. Ejecución de Test A/B o multivariantes, lanzamiento de encuestas de usuario, extracción de conocimiento en base a técnicas de analítica web, mapas de calor, etc (Avinash 2010)

Otra cosa es que sea viable el despliegue de ese concepto en proyectos llave en mano, no por que no sea útil, si no por que medir la magnitud de algo tan incierto, para poder establecer un contrato de colaboración es complejo (por no decir irreal o imposible)

No es que en el desarrollo de los productos se disponga de un presupuesto ilimitado, no es así, más bien suele ser al contrario, presupuestos mínimos en desarrollo y maximizar el test y la validación de los modelos de negocio. Pero es que simplemente por el hecho de no tener usuarios, el proceso de creación varia notablemente.

Retomando nuevamente la necesidad de integrar UCD con una metodología de desarrollo, lo más relevante, dentro de lo beneficioso que es avanzar la participación del usuario y la validación de las interfaces mediante, por ejemplo, prototipos. es minimizar el riesgo de que la necesidad de mejoras una vez dispongamos de la versión operativa, no estén dentro del alcance previsto, ni tengan una afectación "mortal" sobre el proyecto. El coste del cambio aumenta exponencialmente cuanto más avanzado está el proyecto. 

Encontrar un equilibrio entre minimizar la potencial frustración del cliente o promotores, y que el proveedor software no entre en overran y tenga pérdidas, es imprescindible. 

Y, aunque idílicamente, el proceso de UCD debería estar integrado en las fases iniciales de captación de requisitos, análisis y diseño. La realidad es que esa situación no refleja la realidad del desarrollo de software.

Veamos que vías de integración tenemos de UCD y las metodología de desarrollo ágil.

Saludos,