La puedes ver "usada" en listas y rankings de software, en las reuniones de gestión de proyectos, en las reuniones de diseño, y en las cafeterías, pero una cosa sí es difícil; es hacer entender lo que es la usabilidad y la necesidad de aplicarla a los proyectos.
La usabilidad trata de hacer las cosas bien y tiene como partes (entre otr
as):- Facilidad de aprendizaje.
- Facilidad de uso.
- Prevención de errores.
- Permitir al usuario que se recupere del error.
- Reconocimiento antes que recuerdo.
- Eficacia.
- Eficiencia.
Pero si intentas explicar esto a un cliente o un gerente, la respuesta es siempre la misma:
"Todo eso está muy bien, pero cuánto me va a costar. O bien, yo sólo quiero que funcione, para mejorarlo ya lo haremos luego. O bien, deja eso que se nos va de tiempo y dinero."
Las técnicas de usabilidad ya se encuentran perfectamente integradas en los procesos de desarrollo de software, sólo que a los equipos les cuesta pensar en otra forma de trabajar diferente a la tradicional en cascada. Algo parecido pasa con las pruebas de integración continua, no ocupan lugar, ni desplazan los tiempos de desarrollo.
Acerca de un 70% de los problemas que tienen como consecuencia un desvío en los proyectos software tiene que ver con labores de interfaz de usuario, así como una de las mayores tareas de mantenimiento en los mismos. De ahí la importancia de incluir las técnicas de evaluación de la usabilidad en el ciclo del proyecto.
He visto proyectos fallar en la entrega simplemente por no preguntar al usuario con qué resolución de pantalla trabajan en su empresa. Y es que de eso trata la usabilidad de estar en contacto con el usuario, el gran olvidado.
Así que, de entre todas las definiciones de usabilidad que he visto y he intentado aplicar, la mejor forma que he encontrado es definirla una vez más cercana al usuario, con cosas cotidianas y con mis propias palabras:
"Definición de Usabilidad"
La usabilidad es como un restaurante. No importa que la comida sea buena y que quieras ir ahí, además debes sentirte a gusto con el establecimiento. Imagina un restaurante--que posiblemente hayas visitado-- de comida americana. Este tipo de restaurantes suelen tener algo en común y es la cantidad de camareros diferentes que hay por mesa.
Un camarero te toma nota, otro te trae la bebida, otro diferente te trae el entrante, otro el primer plato, otro el segundo, otro el postre, y si no han cambiado de turno el primer camarero te trae la cuenta.
No dudo que este sistema sea beneficioso para la empresa --sus estudios tendrán--, pero no lo es para el comensal, pocas veces está todo coordinado, y la mayoría de ellas un camarero no sabe de las labores del resto de sus compañeros (su función es traer el primer plato cuando esté listo y punto), así que te lo trae, pero como es un sistema en cadena, a veces ocurre que te trae el primero antes que los entrantes, o incluso después del segundo, o al mismo tiempo, o incluso el plato frío porque el camarero de los primeros platos no estaba libre en ese momento. Lo mismo ocurre cuando intentas pedir el postre, o la cuenta, debes dar con el camarero adecuado de lo contrario estarás esperando en balde.
¿Por qué ocurre esto? Por que este sistema no tiene en cuenta al usuario, ni a sus necesidades, está pensado desde el punto de vista del sistema --restaurante--, no del cliente. Puede ser efectivo para el comercio, pero no lo es para el usuario. El resultado es claro, cliente insatisfecho, o por lo menos no satisfecho del todo lo que podría estar.
Y es que, el cliente siempre debería irse con una sonrisa --incluso de nuestra web, o aplicación software--, debería decir: "qué bien funciona esto" y como consecuencia debería recomendarlo a otros potenciales clientes.
Si tenemos una aplicación que hace de todo y mejor que el resto de la competencia, pero los clientes no la usan porque es difícil, acabarán echando pestes de la misma, o lo que es lo mismo publicidad negativa.
Todo esto se puede mejorar aún más. Imagina tener un restaurante con espacio acomodado para personas con discapacidades, rampas de acceso, menús en braille y camareros que hablan con señas. Eso es dar un servicio VIP, lo que se llama comúnmente accesibilidad.
Una nota sobre la accesibilidad. Las empresas públicas deben ser accesibles antes de finales de año por ley. "Cuando las barbas de tu vecino veas cortar, pon las tuyas a remojar."
Resumiendo, la usabilidad no tiene nada que ver con el diseño (tampoco está reñida con él), ni cómo de bien haga los aspectos funcionales la aplicación, tiene que ver con hacer las cosas con calidad, es decir, poner un poquito de IVA (Valor Añadido). Da igual si el restaurante es bonito y la comida es fabulosa, si luego el servicio, el trato al cliente, la higiene y limpieza hace que los clientes no vuelvan al establecimiento.
Espero que si tratas con estos temas y te veas en alguna de estas situaciones y tengas que "vender" las bondades de un trabajo bien hecho, la próxima vez te lleves a los responsables a comer a un restaurante y se lo expliques. ;-)
No hay comentarios:
Publicar un comentario