archivo

Archivo de la etiqueta: usabilidad

Ambas cosas. Una de las máximas de Steve Jobs era que “las funcionalidades esenciales de un sistema tenían que ser sencillas de utilizar por parte de los usuarios”, funcionalidad y usabilidad deben ir de la mano, si bien no siempre van al mismo ritmo, ya que generalmente la funcionalidad va por delante de la usabilidad y es en cierto modo lógico que así sea, porque si bien ambas se realimentan del feedback, hasta que no se va consolidando la funcionalidad, la usabilidad ocupa otro lugar en la escala de prioridades.

Lo anterior no quita que se deba desarrollar con intención la funcionalidad pensando en la usabilidad, si no se hace así, no solo se no se está sacando el máximo partido posible al esfuerzo que se está invirtiendo sino que puede darse el caso de que la funcionalidad tenga que cambiarse posteriormente para adaptarse a una usabilidad que no es posible conseguir con el enfoque inicial.

Esa intención se consigue trabajando con el usuario en la definición del sprint y tratando de aplicar todo nuestro conocimiento y experiencia para asesorarle, teniendo en cuenta que hay que tener la mente muy abierta porque no hay que olvidar que el sistema que estamos construyendo no es para nosotros sino para el usuario y que si el usuario, tras escucharnos, decide tomar un camino, hay que respetarlo por mucho que pensemos que se equivoca.

Tener interfaces de usuario a la última viste muy bien. No hay nada de malo en ello si se ha tenido en cuenta que no estamos haciendo arte y que finalmente hay personas que tienen que utilizar el producto.

El término phat equivale a cool. Este antipatrón hace referencia al desarrollo de interfaces de usuario pensando en términos de ser “guay”, moderno o a la moda, en lugar de en términos de usabilidad.

Esta decisión puede ser tomada por desarrolladores y/o por los usuarios. En cualquiera de los dos casos se trata de un error, ya que el producto no basta con ser atractivo visualmente sino que además debe ser sencillo y práctico de manejar o lo que es lo mismo: eficiente y productivo.

Comenta un desarrollador con mucha más experiencia que yo que la aplicación debe entrarle por el ojo al usuario ya que de lo contrario manifestará rechazo desde el primer momento y será complicado hacerle cambiar de opinión. Si nos ponemos a pensar ejemplos, no está muy lejos de la realidad, ya que en las aplicaciones para smartphones los primeros segundos o minutos de uso de las mismas determinarán el éxito que tendrán las mismas en nuestro terminal.

No se trata exclusivamente de interfaces de usuario, sino también de la dinámica o lógica de funcionamiento de la misma. En resumidas cuentas, se trata de la usabilidad.

En la usabilidad hay buenas prácticas, sin embargo, hay que tener en cuenta un factor importante y que influye mucho a la hora de que un usuario exprese rechazo o no en primera instancia al sistema y no es otra que el tipo de aplicación o sistema que venía utilizando hasta ahora, ya que será la referencia con la que van a comparar el nuevo sistema.

Me he encontrado con casos donde los usuarios ponen por las nubes, sistemas que meses antes pisoteaban. Y no ha sido necesariamente porque el nuevo sistema empeore al anterior, sino porque les ha cambiado la rutina con que hacían sus tareas y existe otra nueva.

Los criterios de usabilidad son importantes, sin embargo, al final la práctica con el uso de la herramienta es la que rompe determinadas barreras que la propia aplicación ha puesto al usuario, ya lo dice la siguiente cita: “con suficiente práctica, cualquier interfaz es intuitiva”.

Hace poco expuse en un artículo lo que eran las pruebas de aceptación. En muchos casos, se utiliza indistantemente un término u otro para referirse a lo mismo, en otros, su alcance está solapado. Respeto a quien maneja dichos conceptos como crea conveniente. Tanto en este artículo como en el anterior, les voy a dar el sentido (acertado o no) que creo más adecuado para cada uno.

Para empezar, ¿por qué la confusión entre un término y otro? Pues principalmente porque suelen venir en el mismo plan de pruebas y ejecutado por las mismas personas, sin embargo la orientación de un tipo de pruebas y la otra es distinta.

Las pruebas de implantación están orientadas a una revisión de requisitos no funcionales del producto en un entorno de preproducción de calidad. ¿Por qué de calidad? Un entorno de estas características que sea muy distinto al de producción o cuyos resultados no sean extrapolables al mismo provocará en muchos casos conclusiones erróneas y en otro generará muchas dudas sobre el cumplimiento o no de las especificaciones no funcionales.

De esta forma, se considerarán pruebas de implantación por ejemplo, las pruebas de carga o stress, las relacionadas con la seguridad del sistema, etc…

Si un producto no supera las pruebas de implantación establecidas (para ello se requiere la definición de umbrales de cada métrica cualitativa o cuantitativa que se decida medir) no debería pasarse a producción aunque supere las pruebas de aceptación (que se podrían desarrollar en paralelo a las pruebas de sistema), de las cuales también se podría obtener un feedback interesante para las pruebas de implantación, ya que las acciones de los usuarios en las aplicaciones son imprevisibles y el valor de su testing (adicional a la propia validación de requisitos) puede ser muy importante.

Maya Elhalal-Levavi es una emprendedora israelí especializada en Internet y redes sociales. Siendo una importante conocedora del negocio y de la experiencia de usuario resulta muy interesante su siguiente cita:

“La interfaz gráfica de usuario (GUI) siempre es intuitiva para quienes la desarrollan”.

Una gran verdad y un gran error por parte de muchos analistas ya que es necesario tener muy en cuenta a quiénes van a ser los verdaderos destinatarios de las mismas.

Interesante la siguiente reflexión de Kent Beck (traducción libre): “Utiliza la opción más simple que pueda funcionar”.

Mi experiencia está en consonancia con esa reflexión. Empieza por desarrollar la solución más simple que funcione (consensuada con el usuario) para implementar una determinada funcionalidad de un sistema. Siempre habrá tiempo para añadir complejidad.

Cuanto maś simple y más flexible sea la aplicación que se desarrolla (siempre y cuando, insisto, satisfaga las necesidades del usuario), más posibilidades existirá de que sea bien acogida por los mismos y menos esfuerzo extra se tendrá que invertir en desarrollar funcionalidades con una complejidad adicional que lo más probable es que no sea necesaria o lo que es peor, complique la utilización del sistema por parte de los usuarios.

Rick Cook es un autor americano de novelas fantásticas y de ciencia ficción en las cuales, de vez en cuando, hace uso de bromas relacionadas con las TIC.

Una de sus citas más conocidas es la siguiente (traducción libre): “Hoy en día la programación es una carrera entre los ingenieros de software que luchan por construir mayores y mejores programas a pruebas de idiotas y el universo que intenta producir mayores y mejores idiotas. De momento, gana el universo”.

Se trata de una broma de Rick Cook, pero da lugar a interesantes reflexiones, algunas de ellas que difieren de la cita:

– Soy de la opinión de que la usabilidad, sin ser lo más importante (ya que solo cobra importancia en el caso de la orientación a productos tras la utilidad del mismo y en el caso de desarrollos a medida, tiene interés tras la utilidad y en función del tipo de proyecto, unas veces estará por encima y otra por detrás de la mantenibilidad), vale dinero, mucho dinero y si no que se lo pregunten a Apple.

– La usabilidad debe intentar conseguirse poco a poco, recordando a Pareto, conseguir unos niveles aceptables requiere relativamente poco esfuerzo, pero una vez que se busca la excelencia el mismo crece exponencialmente. Por otra parte, difícilmente se dejará satisfecho a todo el mundo, por muy usable que sea el sistema siempre habrá alguien que piense que no lo es y/o que eche de menos el que utilizaba antes, aunque fuera una tortura en comparación a este.

– Los usuarios quieren que las tareas que realizan con los sistemas de información las puedan hacer de la manera más rápida posible, sin cometer errores que les obliguen a repetir alguna acción, sin tener que depender de soporte y sin que sufran pérdidas de disponibilidad (cuando utilizan la herramienta no quieren parones). Damos a un servicio a los usuarios, no hay que olvidarlo, por lo que hay que para que estén satisfechos, hay que intentar que el sistema sea cada vez más productivo y una de las variables que intervienen, sin duda, es la usabilidad.