Incorporar técnicas de usabilidad y procesos de diseño centrado en el usuario (DCU) dentro de compañías que no están habituadas a trabajar con ellos puede transformarse en una tarea titánica. Una y otra vez se profieren argumentos que pretenden justificar el rechazo e invalidar la posibilidad de cambio, por mínimo que sea. En este artículo se describen los más comunes y se proponen acciones concretas para refutar los argumentos del no.
A lo largo de los últimos diez años, tuve la oportunidad de trabajar para empresas de distintos sectores y fui encontrando que las dificultades y barreras para la implementación del DCU son bastante parecidas, independientemente del tipo de compañía o del sector en el que operen.
Sin embargo, los problemas van cambiando según el grado de madurez que tiene cada empresa en relación a la usabilidad y el diseño centrado en el usuario. Tomando como guía el modelo de madurez desarrollado por Keikendo podemos segmentar las barreras o excusas comunes que suelen aparecen del lado de los equipos de diseño y desarrollo, y frente a cada una de ellas, enunciar posibles argumentos o acciones a tomar para neutralizarlos:
Etapa de madurez hacia el DCU
|
Barreras y excusas comunes
|
Argumentos y cursos de acción
|
1. Sin intención. La experiencia de usuario no se diseña intencionalmente.
|
Desconocimiento: no se conoce la disciplina.
| |
Rechazo: el diseño de experiencias no hace falta.
|
No hacer nada. Solos se darán cuenta.
| |
Incompatibilidad: la metodología no permite hacer pruebas con usuarios.
| ||
2. Autoreferencialidad. Se diseña como si el usuario fuese uno mismo.
|
Restricciones de costos.
| |
Restricciones de tiempos.
|
Una ronda de pruebas con usuarios se puede resolver en una semana.
| |
Carencia de recursos especializados.
|
Tercerizar, tomar nuevos recursos o capacitar a los existentes.
| |
3. Experto. Experiencia de una persona. No hay método.
|
Metodología no formalizada.
|
Diseñar e implementar una metodología posible no ideal.
|
Percepción de incertidumbre.
| ||
4. Centralizado. Hay un encargado del diseño de la experiencia. Hay método.
|
El diseño de experiencias es necesario para ciertos proyectos, no para todos.
|
Comparar métricas de proyectos basados en DCU con otros que no hayan utilizado esta metodología.
|
5. Distribuido: todos los equipos son conscientes del diseño de una experiencia. Hay método.
|
Resistencia de los mandos superiores.
|
Argumentos y cursos de acción para vencer la resistencia:
- Capacitación: algunas de las acciones que se pueden tomar cuando nuestro interlocutor desconoce las disciplinas de la usabilidad y el diseño centrado en el usuario son brindar cursos introductorios, invitarlo a presentaciones o incluso explicar informalmente en reuniones dentro de la compañía los conceptos fundamentales.
- Elegir las batallas para pelear: los argumentos que suelen esgrimirse para rechazar el DCU van desde “es aburrido” hasta “no hace falta”. Cualquiera sea el caso, no vale la pena invertir demasiado tiempo en convencer a los detractores. Los beneficios del DCU en relación al negocio, la calidad final de un producto o la satisfacción de los usuarios son bastante explícitos. Estar en contra del DCU es más una decisión fundamentada en cuestiones dogmáticas que racional.
- Hacer pruebas con usuarios: además de constituir una de las principales técnicas del DCU, las pruebas con usuarios tienen un gran poder de iluminación. Es importante que participen miembros del equipo de diseño y desarrollo, e incluso invitar a gerentes y tomadores de decisiones. Ver y escuchar a los usuarios finales en directo tiene un efecto mágico sobre quienes todavía se oponen a realizar este tipo de pruebas.
- Comparar costos: la forma de romper con la excusa del costo es justamente evidenciar los costos de no utilizar una metodología de diseño centrado en el usuario. El DCU es más eficiente que otras metodologías y permite reducir costos de desarrollo, mantenimiento, capacitación y soporte.
- Priorizar ante problemas de tiempo: el DCU permite priorizar iniciativas, algo que cuando el tiempo escasea es muy importante para decidir mejor qué tareas se deberán realizar dentro del tiempo disponible para obtener el mejor resultado posible. Una ronda de pruebas con usuarios (con cinco ya se pueden identificar el 80% de los problemas de usabilidad de una interfaz) se puede resolver en una semana, incluyendo generación de documentación valiosa para las decisiones de diseño y desarrollo que deban tomarse posteriormente.
- Apoyarse en recursos especializados: si el proyecto es importante para la compañía y esta no tiene recursos internos en usabilidad y diseño centrado en el usuario, se pueden contratar consultores y, además de resolver el problema, se podrá aprender de ellos.
- Levantar las barreras relacionadas con la metodología: el proceso de DCU no es dogmático, de hecho últimamente se reproduce dentro de las llamadas metodologías ágiles, que se definen también más como un proceso que como una metodología estructurada. Esto permite mayor flexibilidad y capacidad de adaptación a los requerimientos de cada proyecto particular.
- Reducir la incertidumbre: la mejor forma de generar certidumbre y disminuir la resistencia a la adopción del Diseño Centrado en el Usuario en compañías y equipos de trabajo es mostrar los resultados cuantitativos y cualitativos que esta metodología genera. Para ello es necesario tomar mediciones de variables claves para cada proyecto. Las tres más comunes son eficacia, eficiencia y satisfacción de los usuarios.
- Quebrar la resistencia de los tomadores de decisiones: desde la perspectiva del negocio es más convincente utilizar métricas que alimenten la ecuación tradicional de éxito de un sitio Web:
Donde:
I: Ingresos
V: Cantidad de visitantes únicos
C: Tasa de conversión
R: Tasa de retorno
No hay comentarios :
Publicar un comentario