La usabilidad no es opcional

La cruda verdad: la usabilidad no es opcional

Introducción

En el año 2007 se produjo un hecho que cambiaría radicalmente el dominio de los programadores en el desarrollo de interfaces gráficas: la aparición de IPhone.

Mas allá de todas las críticas que se puedan realizar sobre aquella primera versión, lo que es indiscutible es que transformó la experiencia de los usuarios al usar teléfonos y marcó un camino que luego todos los fabricantes trataron de seguir.

La experiencia del usuario

Hasta aquel momento los teléfonos eran muy diversos y la forma de comunicarse de esas interfaces gráficas estaban todavía dentro del dominio de los programadores

Es cierto que ya en aquel momento había personas que se dedicaban a hacer interfaces gráficas más amigables. Pero lo destacable es el papel del usuario hasta ese momento: se conformaba con lo que le daban para usar. El usuario podía comprar otras marcas y entonces tener que adaptarse a la experiencia que esa marca brindaba con el dispositivo adquirido.

En el mudo de las páginas web y las aplicaciones comerciales pasaba más o menos lo mismo. Es decir, el usuario se debía adaptar al sistema.

Tomemos por ejemplo la siguiente pantalla:

¿Es necesario tener al mismo tiempo todas esas opciones disponibles? ¿ Todos esos campos son realmente necesarios ? ¿Y cada campo a completar tiene la misma importancia?

Tomemos por ejemplo el siguiente sitio web:

¿Es necesario todo ese nivel de información en la Home del sitio?¿Cuál es el objetivo del sitio?¿Qué puedo hacer con él?

Estas pantallas reflejan el tipo de interfaz gráfica con la que el usuario interactuaba a diario.

La experiencia de los desarrolladores

Quienes estábamos en el mundo de desarrollo por aquellos años, y sobre todo si trabajábamos con tecnología .Net, estábamos fascinados por las maravillas que WebForms nos brindaba: controles auto-generados, generación de HTML, CSS y Javascript automático, programación orientada a objetos en el mundo web.

Hacer web por aquellos años con esta tecnología no era tan complejo y, de hecho, así lo propiciaba Microsoft. Teníamos que centrarnos en el código del servidor ya que la tecnología puramente Web no era estrictamente necesaria de aprender.

¿Y entonces qué cambió?

Lo que sucedió es que la web luego de la burbuja comenzó a crecer cada vez más y nuevos jugadores comenzaron a aparecer en escena: Google y Apple.

Ambas companías se focalizaron en brindar al usuario experiencias diferentes con las aplicaciones que ofrecían. Incluso la experiencia de usuario se vio afectada por la forma en que estas empresas permitían comprar, descargar y actualizar el software.

Con el correr de los años los usuarios se acostumbraron a estas nuevas características y se fue estableciendo una especie de "piso", de "mínimo" esperable para las interfaces gráficas, la manera de comprar, instalar y actualizar el software.

De esta forma la tendencia de generar una experiencia de usuario más enriquecida implicó que emergieran nuevos especialistas: los analistas de User Experience (UX).

Estos profesionales deben combinar una serie de técnicas y conocimientos que provienen de diferentes áreas: marketing, psicología, diseño, sociología, diseño industrial, comunicación y sistemas.
Pero además generan actividades y conocimientos que le son propios y no compartidos por otras áreas.

¿Cómo nos afecta en el proceso de desarrollo de software?

El cambio al incorporar un equipo de UX en el proceso de desarrollo es muy importante.

En primer lugar porque ellos deben comprender los objetivos del cliente, del producto. Deben poder definir cada paso de la interacción del usuario, flujo lógicos de información por medio la interfaz. 

Y como resultado de este trabajo ellos generan prototipos de dos tipos: alta y baja fidelidad.

Tradicionalmente este tipo de tarea fue responsabilidad del analista funcional. Y esto es sumamente interesante porque justamente es la parte donde se complementan ambas posiciones. 

Un buen analista funcional hoy en día tiene que tener conocimientos y llevar adelante prácticas de UX. Pero lo mismo resulta para los analistas de UX: tienen que incorporar algunas técnicas y metodologías que tradicionalmente usaron los analistas funcionales.

Esto se debe a que ambos tienen que comprender el producto a desarrollar/mejorar con un enfoque sistemico: entrada, procesamiento, salida y retroalimentación. La diferencia está en que los analistas funcionales se centran en el sistema y los analistas de UX se centran en el usuario

El prototipo en baja fidelidad (Sketch o Wireframe) que producen los analistas de UX es un input sumamente valioso para el desarrollo de sistemas.Con ellos se puede identificar inmediatamente los tipos de entidades y atributos que existen, sus  vinculaciones, los procesos de transformación de información, validaciones y workflows subyacentes.

¡Ah! ¿Entonces le ponemos unas horas de UX a nuestro proyecto y listo?

Esta pregunta creo que se puede responder en parte con la siguiente imagen:

Creer que UX se puede ofrecer por horas es pensar que esta actividad es un condimento que se le puede agregar a la comida que estamos elaborando.

Siguiendo con esta metáfora, no estamos viendo que UX no es un condimento sino un instrumento de cocina tan útil como un cuchillo. ¿Podemos cocinar sin cuchillo? Sí, pero seguramente algo no estará del todo bien...y nos preguntaremos por qué el cliente nunca está satisfecho...

La misión de UX es el usuario, su experiencia. Es el tipo de cuchillo que siempre hemos necesitado en desarrollo. 

En otro artículo mostraré como personalmente entiendo que interactúan las disciplinas de UX con el proceso de desarrollo de software ágil.

Hasta la próxima!