Darcy

Para terminar con esta trología, les dejo la última parte de la traducción del 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.

“…
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.