Rediseño de un sistema colaborativo: experiencias y consejos

 

En la práctica, una decisión tan importante como rediseñar un sistema de información, ya sea un portal corporativo, un sitio de autoatención (Sucursal virtual) o sistema colaborativo, es una decisión de negocio que puede tener múltiples fundamentos.

En el diseño de la experiencia del usuario, los cambios de interfaz son recurrentes, al igual que los procesos de rediseño.

Ahora bien, un sistema se puede rediseñar no solo porque tiene problemas de usabilidad o le faltan funcionalidades, sino también por seguridad, performance, para facilitar las mantenciones futuras y aumentar la confiabilidad [1].

Cómo evaluar un sistema colaborativo e identificar brechas

Evaluar un sistema colaborativo tiene definitivamente una complejidad adicional al proceso de evaluación de un sistema con el cual cada usuario interactúa de forma independiente. Algunas formas de evaluar emplean [2]:

• Heurísticas,
• escenarios,
• modelos específicos o frameworks,
• modelos basados en tareas de grupo, etc.

En el contexto de un sistema colaborativo, la típica “tarea” que ocupamos para testear en un protocolo con un usuario, se debe modificar para considerar el contexto del trabajo en equipo [2].

Si eres parte de un equipo de diseño o desarrollo que se encuentra en la planificación del rediseño de un sistema colaborativo, tienes por lo menos cuatro fuentes complementarias de soluciones de evaluación, que puedes ocupar según el contexto del proyecto:

• El testeo rápido de bajo costo, tipo testeo guerrilla,
• la evaluación con expertos empleando heurísticas y/o escenarios,
• los métodos basados en investigación etnográfica,
• otros métodos específicos.

Según Guy [2], a diferencia de la evaluación clásica (cuando un solo usuario interactúa con el sistema) para sistemas colaborativos es fundamental tener una visión holística, desarrollar el modelamiento, la abstracción y la representatividad.

Es evidente que nada de lo anterior se puede basar en un solo formato de evaluación y que para tener una visión holística, es necesario entender muy bien las relaciones que se están dando entre las personas y conocer el contexto de trabajo colaborativo, además de evaluar un sistema para rediseñarlo.

Aprendizajes del proceso de mejora continua de Google Drive

Sin lugar a dudas, Google Drive es uno de los productos estrella de Google, por lo que la mejora continua es a la vez una prioridad y un territorio sensible para sus diseñadores.

A la hora de realizar cambios en un sistema con tantos usuarios, es fundamental mantener el control y evitar la “aversión al cambio”, o la resistencia de los usuarios frecuentes a la modificación de una interfaz.

En “Minimizing change aversion for the Google Drive launch” [3], trabajo presentado en CHI 2013, el equipo de Google relata lo importante que es considerar la curva de aprendizaje en el uso de un sistema.

En particular, el estar acostumbrado a un sistema, hace que incluso frente a un cambio que debería mejorar su experiencia, el usuario familiarizado puede presentar una fuerte resistencia al cambio.

En este sentido, el equipo de diseño de Google se basa en teorías psicológicas, explora patrones de aversión al cambio y analiza la data de lanzamientos de diseños previos para preparar la nueva salida a producción de un cambio de interfaz.

Como resultado, proponen el siguiente marco de trabajo, que definitivamente puede ser muy útil para cualquier equipo que esté trabajando en el rediseño de un sistema:

1. Planificar las etapas del lanzamiento.
2. Evaluar el impacto en el usuario previo al lanzamiento.
3. Preparar a los usuarios para el cambio planificado.
4. Explicar los beneficios del cambio.
5. Ofrecer apoyo en la transición y soporte.
6. Dejar que el usuario pase de la versión nueva a la antigua. Nota: Este punto es probablemente uno de los más complejos ya que es difícil hacer convivir dos interfaces, más aún si hay cambios de tecnología por detrás.
7. Monitorear y gestionar el cambio a través del tiempo.
8. Dejar que los usuarios envíen feedback directamente.
9. Gestionar rápidamente los problemas de los usuarios.
10. Contarle al usuario lo que se mejoró.

Cuando los usuarios están tan acostumbrados

Estos consejos me parecen fundamentales para cualquier equipo que planifica un cambio mayor en una interfaz. En mi trabajo tanto en Movistar como en Sura era el tipo de pregunta constante: “¿Cómo mejoramos la experiencia de todos sin generar frustraciones para algunos?”

Con lo anterior, estaba obviamente el tema de la satisfacción. En este sentido, recuerdo también la problemática planteada por los ejecutivos de un sistema ERP que nos comentaron que un simple cambio de botón, que supuestamente iba a simplificar el acceso a la información para los ejecutivos de atención de una empresa cliente, podría generar un aumento substancial en las llamadas al servicio de soporte.

¿Por qué? Los ejecutivos estaban acostumbrados a hacer 5 clics para llegar a una pantalla y lo hacían de forma casi robótica.

Al cambiar la interfaz y hacer que la misma información esté disponible en 4 clics, los ejecutivos se perdían y no encontraban más la información. Frustrados, llamaban al servicio de soporte de la plataforma.

Rediseño total versus cambios recurrentes

Ahora bien, la pregunta es: ¿deberías hacer un checklist, pegar estos 10 consejos en tu escritorio y seguirlos al pie de la letra? Depende.

Google tiende a diseñar servicios excepcionales y su equipo tiene claramente la experiencia para hacerlo. En la realidad local, como usuario y como manager, uno se encuentra seguido con servicios digitales obsoletos que definitivamente necesitan ser mejorados o literalmente rediseñados y repensados desde cero.

En los casos muy extremos, es tanta la brecha entre lo que existe y lo que el usuario espera o el promedio de lo que estamos acostumbrados a ver en el mercado, que aplicar al pie de la letra cada uno de los pasos sería probablemente innecesario.

Recién me llegó un correo de una empresa financiera anunciando un cambio en su interfaz digital. Como usuaria, me hubiese gustado ver los cambios primero.

Para un sistema que lleva de 5 a 7 años o más sin mejoras concretas, más vale invertir en testeo y rediseño que en campañas de comunicación para explicar lo que se va a cambiar, y tendría que haberse cambiado hace 5 años.

Al contrario, cuando se nota una constante preocupación por la experiencia del usuario y uno percibe cambios menores de forma recurrente, se agradece recibir una comunicación que avise de una nueva funcionalidad u otra que se eliminará.

¿Has participado en proyectos de rediseño de sistemas colaborativos? Cuéntanos tu experiencia.

Sigue leyendo

• La etnografía en el diseño y desarrollo de sistemas colaborativos [reflexiones]
• Usabilidad y experiencia de usuario (UX) en el desarrollo de software corporativo
• Prototipo: qué es y para qué sirve

Referencias

[1] El-Khawaga, G. H., Galal Hassan Galal-Edeen, G.H., Riad, A.M. (2013). Quality Attributes and Software Architectures Emerging Through Agile Development: Pursuit or Overlooking? International Journal of Software Engineering (IJSE), Volume (4) : Issue (1).

[2] Guy, E. (2005). “…real, concrete facts about what works …”: Integrating Evaluation and Design Through Patterns. Proceedings of GROUP’05, November 6–9, 2005, Sanibel Island, Florida, USA. Copyright 2005 ACM.

[3] Sedley, A.Müller, H. (2013). Minimizing change aversion for the Google Drive launch. En Proceedings: CHI’13 Extended Abstracts on Human Factors in Computing Systems, ACM, New York, NY, USA(2013), pp. 2351-2354.