Basaso en el modelo “OpenUP/MMU-ISO” de Andrés Rodriguez

En parte, esto ocurre porque diseñadores y desarrolladores tienen diferentes procesos y metodologías de trabajo y les falta un lenguaje compartido. Pero dado que necesitan trabajar en conjunto para lograr objetivos comunes, es importante encontrar una forma para que esta integración sea posible.

Pero dado que necesitan trabajar en conjunto para lograr objetivos comunes, es importante encontrar una forma para que esta integración sea posible.

Como parte de su tesis doctoral, Andrés Rodríguez propuso un modelo donde compara y equipara los roles de IT con los roles de UX en el marco de metodologías de desarrollo RUP, para generar una visión compartida entre ambas disciplinas.

A continuación, un resumen del modelo, basado en la Metodología RUP de IBM (Rational Unified Process):

Brevemente, la metodología RUP a pesar de ser un proceso dogmático, no es lineal sino que establece iteraciones, vueltas y pivoteo. Combina elementos de metodologías estructuradas y metodologías ágiles, y asegura que hay pasos pero no todos son secuenciales.  

Lo primero que Andrés Rodríguez resaltó como una problemática fue ver qué roles existen dentro de esta metodología y a qué nivel son comparables con los de UX. Así, desarrolló las siguientes comparaciones:

Stakeholders: están, en cierta forma, fuera del proceso. Es el cliente, el dueño del proyecto y puede ser:

  • Patrocinador o sponsor: es la persona que le da apoyo político o económico al proyecto. Suele ser una sola persona que en caso de caerse u oponerse al proceso el proyecto se interrumpe. Por eso es importante definir claramente quién es el patrocinador del sponsor.
  • Líder técnico del dominio: es la persona o comité que tiene conocimiento no tecnológico sino técnico del área de dominio.
  • Representante del usuario: es el responsable pero no es quién ejecuta. Si solamente nos quedáramos con su postura, probablemente estaríamos presentando un “cuello de botella” al que el usuario se enfrentaría al hacer las cosas.
  • Usuario final: el responsable de la ejecución. Es quién lleva a la práctica el hacer. Muchas veces, al llevar a la práctica el proyecto, se saltea muchos pasos que le resultan molestos por cuestiones productivas. Estos pasos son los que el Representante del usuario probablemente no haya tenido en cuenta.

Analista vs Especialista UX:  

IT: Analista (arquitecto de software)

Toma las decisiones que minimizan riesgos y aseguran la calidad del proyecto. Necesita experiencia que le den la capacidad de tener una visión a largo plazo. A su vez, es capaz de establecer una serie de prácticas en el equipo que permiten que la documentación no solamente funcione sino que, además, sea útil. 

Diseño: Especialista de UX (líder de UX, experto de UX)

Toma decisiones experiencia del usuario (UX), que, por definición, tienen impacto a largo plazo sobre la aplicación. Estas decisiones deben ser compartidas obligatoriamente con el Arquitecto ya que si no están sostenidas estructuralmente afectan el tipo de producto que se va a construir.

La responsabilidad de ambos en el proyecto es muy grande ya que toman decisiones estructurales que luego son muy difíciles y costosas de cambiar.

Desarrollador vs Diseñador de UX: 

IT: Desarrollador (programador)

Es quien tiene a cargo la ejecución. Toma decisiones de menor escala que el Analista. Tiene una visión de futuro más cercana.

Diseño: Diseñador de UX

Implementa experiencia del usuario diseñando los componentes de la interacción, los storyboards, prototipos, navegación, arquitectura de la información.

Ambos perfiles son responsables de darle forma concreta a la visión establecida en la etapa anterior.

Tester vs Tester de UX:

IT: Tester

Verifica que no haya errores, riesgos y vulnerabilidades que puedan presentarse y le hace una constante devolución al programador. La relación entre el tester y el programador es cíclica y se basa en el feedback.

Diseño: Tester de UX

Toma los diseños creados y lleva a cabo las pruebas de usabilidad verificando que los componentes desarrollados sean efectiblemente útiles y usables para el usuario final.

Es imprescindible que ambos trabajen en paralelo ya que el testeo se realiza sobre el producto en desarrollo.