Segunda y última parte de este artículo que aborda uno de los principales desafíos que enfrentamos los profesionales de User Experience referido a cómo lograr que nuestros clientes acepten trabajar bajo un proceso de Diseño Centrado en el Usuario en lugar de uno en cascada. En base al mismo caso planteado en la primera parte del artículo se describe dónde radica la mayor eficiencia del DCU y porqué.    

El diseño centrado en el usuario propone un abordaje iterativo para el desarrollo de interfaces. Cada iteración está compuesta de tres instancias: análisis, elaboración y prueba. A su vez cada proyecto puede componerse de N cantidad de iteraciones dependiendo su complejidad. En el centro de este proceso se encuentran representantes del negocio y los usuarios, a partir de los cuales se determinan los objetivos de cada iteración. 

A diferencia del proceso de desarrollo en cascada donde existe una única instancia de relevamiento (al inicio del proyecto) que alimentará todo el proceso, con los riesgos que esto implica como hemos visto en la primera parte de este artículo, el DCU contiene tantas instancias de relevamiento como iteraciones. Al inicio de cada una de ellas, durante la fase de análisis, se definen los elementos de la interfaz que se abordarán y se relevan en detalle.

En las sucesivas etapas de relevamiento de cada iteración, es posible revisar lo relevado en la iteración anterior a la luz de los resultados obtenidos en la etapa de prueba. De esta forma, se genera un proceso virtuoso de retroalimentación donde cada supuesto es desarrollado, puesto a prueba y refinado. 

El diseño centrado en el usuario en acción

Volviendo al proyecto imaginario de la aplicación móvil que nos han solicitado desarrollar en cinco semanas (ver los supuestos del proyecto en la primera parte de este artículo) definiremos cada iteración con una duración de dos semanas, usando una para la fase de diseño y otras dos iteraciones para la fase de programación. El proyecto tomaría la siguiente forma:

A diferencia de la metodología en cascada, el DCU contempla medir la performance de la herramienta en cada iteración, lo que permite ir corrigiendo los desvíos y por lo tanto disminuir el riesgo final del proyecto.  

Las instancias de prueba estarían planificadas al finalizar la semana dos (fin de la iteración de diseño) y luego al finalizar la semana tres (fin de la primera iteración de programación).  Sin embargo, dado que entre la primera instancia de prueba y la segunda habría sólo una semana y que en la primera prueba ya se estarían probando algunos elementos funcionales desarrollados durante la primera semana de programación, podríamos planificar la segunda prueba al final de la segunda iteración, es decir en la semana cinco.

De acuerdo a este plan se requerirían U$S 6000 (U$S 4000 correspondientes a las dos semanas de diseño más U$S2000 de la primera semana de programación)  y sólo dos semanas para tener una primera medición de la performance de la interfaz, lo que representa la mitad de lo requerido por la metodología en cascada en términos de presupuesto y un 60% menos en términos de tiempo.  

Tres semanas después existiría la posibilidad de volver a realizar pruebas con usuarios antes de lanzar el producto al mercado. Esta instancia coincidiría con el momento donde se realizaría la prueba en el caso de la metodología en cascada que comentamos en la primera parte de este artículo. 

Sin embargo, la cantidad de errores o el nivel de desvío que podría manifestarse en el caso del DCU sería cómo máximo de tres semanas, mientras que en el caso de la metodología en cascada sería de cinco, dado que no se realizó ninguna prueba intermedia. 

Podría argumentarse que en este plan de proyecto no están contemplados los tiempos y costos necesarios para realizar las pruebas y posteriores ajustes. Pero del mismo modo, tampoco se contempló en el caso de la metodología en cascada los tiempos y costos necesarios para realizar el relevamiento y documentación correspondiente que se genera normalmente al inicio del proyecto en ese tipo de metodologías. 

El riesgo en un proceso de diseño centrado en el usuario

Veamos qué sucede con el riesgo. Las dos variables que elegimos para medir el riesgo son, al igual que en el caso de la metodología en cascada: 

• Especificación de requerimientos: las definiciones de requerimientos para el DCU se realizan durante la primera etapa de la iteración y son específicas para los elementos de la interfaz que se desarrollarán durante esa iteración particular. Cada iteración tiene su etapa de relevamiento y al ser las iteraciones sucesivas, la información que alimenta cada iteración es cada vez más precisa y exacta, ya que ha pasado por un proceso de validación en la etapa de prueba anterior. 
• Tiempo de desarrollo: el tiempo transcurrido hasta la primera instancia de medición de performance y, por lo tanto, de identificación de posibles problemas y su corrección, se podría hacer en la segunda semana del proyecto, teniendo por delante tres semanas completas para realizar los ajustes necesarios antes del lanzamiento de la aplicación. 

Teniendo en cuenta estas dos variables, podríamos graficar el comportamiento del riesgo durante el proyecto de la siguiente forma:

En el gráfico se puede ver claramente de qué manera el riesgo disminuye en las instancias de pruebas con usuarios, donde los supuestos considerados en la etapa de análisis y elaboración son puestos a prueba y, si es necesario, corregidos. 

Esto impide que la curva de riesgo ascienda en línea recta desde el inicio del proyecto hasta su finalización. En cambio, lo hace de manera espasmódica dentro de cada iteración, reduciéndose drásticamente en las instancias de prueba. 

En síntesis

• Costo: el proceso de diseño centrado en el usuario es en promedio un 35% más eficiente que el proceso de desarrollo en cascada debido a una mejor definición de los requerimientos y control de los desvíos.
• Tiempos: el DCU permite desarrollar un proyecto sin desvíos en el tiempo o acotándolos mucho más. En el caso de la metodología en cascada el desvío de tiempo puede alcanzar el 35% promedio. 
• Riesgo: la existencia de pruebas en cada iteración es un efectivo reductor del riesgo, que de esta manera nunca puede superar la inversión necesaria para realizar cada iteración (normalmente dos semanas). En nuestro ejemplo, el riesgo fue reducido a la mitad del reproducido en la metodología de cascada.  
• Medición de performance: el DCU requiere la mitad del presupuesto que la metodología en cascada para realizar una primera medición de performance de la interfaz, lo cual es crítico para evitar que el riesgo del proyecto crezca en una progresión lineal. 

Seguramente este modelo de análisis comparativo no sea completo, pero el objetivo de este artículo es justamente tratar de realizar un análisis simple que contemplando las variables principales de un proyecto (alcance, tiempo, presupuesto y riesgo) brinde argumentos de base que muestren las ventajas de trabajar bajo un proceso de diseño centrado en el usuario.