Rediseño de un sistema colaborativo

hace 5 años   •   5 min de lectura

Por Carmen Gerea
sistemas-colaborativos2

Por qué rediseñar un sistema
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 sólo porque tiene problemas de usabilidad o le faltan funcionalidades, pero también por seguridad, performance, para facilitar las mantenciones futuras y aumentar la confiabilidad [1]. 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 (o “Sucursal virtual”), o sistema colaborativo, es una decisión de negocios que puede tener múltiples fundamentos.

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 interacciona 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 planificación de 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.La siguiente tabla resume un conjunto de métodos de evaluación para sistemas colaborativos [2]:
evaluacion-sistemas-colaborativos

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, 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 duda, 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 los diseñadores de Google. 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 al cambio 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ño previos para preparar la nueva salida a producción de un cambio de interfaz. Como resultado, proponen el siguiente marco de trabajo – que definitivamente le puede ser muy útil a cualquier equipo 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 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 el 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 mejoró.

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.

Ahora bien, la pregunta es: ¿Deberían hacerse un check-list y pegar esta lista de 10 consejos en su escritorio y seguirla a la letra? Depende. Google tiende a diseñar servicios excepcionales y su equipo de diseño 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 a 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 usuario, me hubiese gustado ver los cambios primero. Para un sistema que lleva 5-7 años o más sin mejoras concretas, más vale invertir en testeo y rediseño que invertir en campañas de comunicación para explicar lo que se va a cambiar y tení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á.

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

Corre la voz

Sigue leyendo